西康晴氏のソフトウェア開発における標準化に関するツイート

Yasuharu NISHI @YasuharuNishi

まず、メトリクスだの指標だのKPIだのを何のために使うのか、という考え方を再考するのが大事です。誤用の2大パターンは、ばらつきを抑えるために使うパターンと、中長期的トレンドを掴むために使うパターンです。

Yasuharu NISHI @YasuharuNishi

前者に関して、そもそもソフトウェアの品質管理でばらつきを抑えるという考え方が妥当なのか、という点を再考・熟考する必要があります。これは例のスライドにも書かれてますね。ばらつきを抑えるというのは、やり方を同じにすればダメな仕事が発生しないだろう、という仮説に基づきます。

Yasuharu NISHI @YasuharuNishi

大量生産の工場において、人間の微妙な感覚などを利用しない作業であれば、やり方を同じにすればダメな仕事が発生しない可能性は高まります。

Yasuharu NISHI @YasuharuNishi

しかしソフトウェア開発において「やり方」とは何にあたるでしょう。それは「ものの考え方」です。ソフトウェア開発は、ものを考えるという仕事に他なりません。ですからソフトウェア開発のやり方は、ものの考え方そのものになります。

Yasuharu NISHI @YasuharuNishi

逆に言うと、どんな帳票に何をどういう順番でどう書いて誰が承認するか、というのは、ものを考える仕事に付随する「作業」にすぎません。ポイントは、同じ作業を行ったとしても、ものを考えるという仕事そのものは同じにならない、ということです。すなわち作業の標準化は仕事の標準化を意味しません。

Yasuharu NISHI @YasuharuNishi

なぜそうなってしまうか。それは、現在のソフトウェア品質保証、もしくはソフトウェアエンジニアリングの技術が、ものを考えることそのものを取り扱おうとしないからです。ソフトウェア品質管理、もしくはソフトウェアエンジニアリングの本質は、ものをよりよく考える技術の追求だと僕は考えています。

Yasuharu NISHI @YasuharuNishi

言い替えると、ソフトウェアの品質管理とは、エンジニアに賢くなってもらう仕事に他なりません。エンジニアにより賢くなってもらうために、よりよいものの考え方や、ダメな考え方の防止策を提示するのが、ソフトウェア開発における正しいばらつきの低減であり、標準化だと僕は思います。

Yasuharu NISHI @YasuharuNishi

だってさ、構造化プログラミングにしたって、構造化分析／設計にしたって、オブジェクト指向にしたって、きちんと学ぶと賢くなった気がしませんか？元がアホだっただけかもしれませんが、僕はソフトウェアエンジニアリングを勉強したら、とても自分が賢くなった気がしました。

Yasuharu NISHI @YasuharuNishi

したがって、ばらつきの低減という考え方を是とするならば、エンジニアのものの考え方まで踏み込んで、ばらつきの低減をしなくてはなりません。そして指標やメトリクス、KPIは、ものの考え方のよしあしそのものを測定しないといけない、ということになります。

Yasuharu NISHI @YasuharuNishi

バグ密度、すなわち単位ソースコード量あたりのバグ数は、ものの考え方のよしあしを示す特性の代用特性に過ぎません。代用特性には代用なりの誤用のリスクがありますから、そこをきちんと理解して使わないといけません。

Yasuharu NISHI @YasuharuNishi

また、ばらつきの低減のために標準化を行う、という考え方にも誤解があります。標準化とは、その組織の中で最もよいやり方を皆が真似する、という考え方です。そして、最もよいやり方そのものを進化させるという考え方です。

Yasuharu NISHI @YasuharuNishi

しかしソフトウェアの品質保証では、多分大手企業による供給力や雇用の確保という文脈における低スキル人材の強制労働という背景から、属人化の排除というコンセプトと結びついて使われることが多いです。だから標準化はマニュアル化と理解されます。しかしそれは、根本的に間違っています。

Yasuharu NISHI @YasuharuNishi

ソフトウェア開発におけるマニュアル化は、もっとも上手に考えることを皆で真似する、というように実装されません。考えることが苦手な人が考えなくてもいいようにする、というように実装されるからです。これは間違った標準化です。

Yasuharu NISHI @YasuharuNishi

ですから属人化の排除のためにマニュアル化する企業は、下請階層構造の構築において、ものを考える作業を排除するように仕事を分解していきますね。だから詳細設計仕様書の日本語をCOBOLやC、JAVAに翻訳するみたいな仕事をさせられてうんざりするプログラマがたくさんいるわけです。

Yasuharu NISHI @YasuharuNishi

そして大事な点はもう一つ。標準化が、よりよいやり方を見つけ出す行為を含んでいる場合。いやこれは異論もあって、標準化とカイゼンは違う概念だという説もありえます。しかし日本の強い現場において、標準化とカイゼンはセットで使われます。ですから概念は別かもしれませんがセットとして論じます。

Yasuharu NISHI @YasuharuNishi

ある組織がベストなやり方をしていたとします。その時に、よりよいやり方を見つけるには、どうすればよいでしょう。それは「ベストなやり方」から逸脱することです。もちろんそれは、思いつきで、もしくは自分の単なる好みで適当にいい加減な仕事をするという意味ではありません。

Yasuharu NISHI @YasuharuNishi

現時点におけるベストなやり方の問題点を見つけてカイゼンする、仕事の対象や環境の変化に追従するようにカイゼンする、別の考え方でのやり方にトライする、など色々ありますが、いずれにせよ、逸脱は必要です。

Yasuharu NISHI @YasuharuNishi

この逸脱が、よい逸脱、すなわちよりよいやり方を見つける逸脱なのかどうかを、組織や品質保証担当はきちんと認識できないといけません。マニュアル化的標準化は、よい逸脱を認識しませんから、組織はどんどんアホになります。

Yasuharu NISHI @YasuharuNishi

ですので強い工場では、作業標準による標準化とともにQCサークルなどによるカイゼン活動をセットで行うわけです。したがってソフトウェア開発においても、最もよい考え方を真似するとともに、もっとよい考え方をチャレンジしないといけません。KPTは、これに沿ったプラクティスだと思います。

Yasuharu NISHI @YasuharuNishi

まとめましょう。ソフトウェア開発においてばらつきの低減という方向性で品質管理を行うのであれば、ものの考え方に踏み込んでばらつきの低減を行わないといけません。その際には、よりよく考える方向にばらつきを低減させるとともに、もっとよりよく考えられるようにカイゼンやチャレンジが必要です。

Yasuharu NISHI @YasuharuNishi

さて、メトリクスや指標、KPIの話に戻りましょう。中長期的トレンドの把握もそうですが、一般に、そのような測定結果になるメカニズムが把握できないようなメトリクスや指標、KPIは、当然ながら組織を前に進めません。だって、そういう測定結果が出てもどうすればいいかが分からないですから。

Yasuharu NISHI @YasuharuNishi

言い替えると、結果系のメトリクスや指標、KPIは、（容易には）行動に紐付きません。したがって、誤った行動のデザインを導くことが多く、誤用されやすいのです。バグ密度なんてまさにそう。高いからってどうすればいいのか、ちっとも分かってない組織が多い。

Yasuharu NISHI @YasuharuNishi

ですから、ソフトウェア品質管理のように現場に何かしらの行動を促すために測定するメトリクスや指標、KPIは、その測定の構造にメカニズムを含んでいないといけません。すなわち、ものを考えるメカニズム（の一部でも）を含んだメトリクスや指標、KPIでないと誤用されやすくなります。

Yasuharu NISHI @YasuharuNishi

結合度と凝集度なんていうメトリクスもそうですし、サイクロマチック数もそうですが、これをエンジニアの考えの悪さとして認識し行動に移す組織は、よい品質を達成していきます。しかし考えの悪さと紐づけず、単なる基準のようなものとして扱う組織は幸せにならない傾向がありますね。