理系白書から考えるソフトウェア工学（つづき）

『理系白書から考えるソフトウェア工学』の記事のつづき。ソフトウェア工学が自然科学で証明できるものでなく、先人の知恵を体系化したものであるならば、ソフトウェア工学を現場で普及、適用させようとする人々は、ソフトウェア工学が現場にもたらす効果や組織への貢献について丁寧に説明しなければならない。

正しいか、正しくないかではない。現場にどんな効果をもたらすか、組織にどんな貢献をするのかがキチンと説明できないといけない。

今、自民党の総裁選挙のまっただ中だが、新しいソフトウェア開発手法や検証技術を現場で普及させようとしている人は政治家と似たところがあると思った。

政治家は政策を国民に説明し理解を求める。政策がより多く支持された方が選ばれる（べきだ）。これが、その人の人柄とか人気とか風貌とかで支持してしまうと、最初はよくても後で問題になることが多い。

自然科学のように効果効能の是非を白黒付けることが難しいソフトウェアの世界では、ソフトウェア工学をいかに現場の技術者が理解できることばで説明し、習慣づけるところまで持って行けるかどうかがカギとなる。そのときの流行とか有名な人がいいと言っているとか、あの企業が採用したからという持って行き方は、人・者・金を動かす権限を握っているハードウェア出身の組織上位層には使ってもいいかもしれないが、現場のエンジニアには使わないほうがいい。（そういうステークホルダの人たちとは提案する施策に対する価値観を共有できるようにしたい）

物理や化学の方法論の場合、その方法論の効果はやろうと思えばその場で実験できる。環境さえ整えればいつでも再現できるのが自然科学の強みだ。でも、ソフトウェア工学は人が相手なので、どんなに著名な人が提唱した方法論でも、どんなに参照回数の多い論文でも、目の前にいるプロジェクトで効果を発揮するかどうかはわからない。（もちろん、多くのプロジェクトが取り入れて成功した方法論は成功の確率が高い）

そう考えると、ソフトウェア工学の適用を現場に説明する際に一番大事なのは「いま、このプロジェクトに足らないものは何か」「なぜ、それが必要なのか」「これを適用するとこのプロジェクトにどんな効果をもたらすのか」を説明することだと思う。そして、その方法論をプロジェクトに適用し、何らかの形で効果を計測しなければいけない。やりっぱなしではいけない。だから、ソフトウェアの世界で小さいながらも組織やプロジェクトでイノベーションを起こしたいと考えている人は、適用しようとしている方法論についてまず、考えて、考えて、考えて、考えて、理解して、説明できるようになることが大事だ。間違っても、ツール屋さんの宣伝文句を右から左に流してはいけない。

プロジェクトマネージャとして経験を積んでいる方やソフトウェアプロジェクトを支援している組織内外のコンサルタントの方達に話を聞くと、みな「現場に方法論を押しつけてはいけない」「納得させながら一歩一歩進むことが大事」という。

開発現場からプロジェクトを支援する立場に移ると何かとイライラすることが多い。自分が主導権を持ってやっていたときの時間の流れ方とプロジェクトを側面から支援して必要なことをやってもらうときの時間の流れ方がまったく違う。プロジェクトマネージメントのベテランは過去を振り返ると、最初は自分の経験をベースにあれやれこれやれと現場に支援・指導するのだが、しばらくするとそれではうまくいかないことに気づくという。現場が「今のままではまずい、新しい何かが必要だ」と感じさせることがまずは大事だというのだ。

このことがよく分かっていなかったころ、『ここが変だよ日本の管理職』や『日本人はリスクを表に出すのが嫌い？』といった記事で、現場のプロジェクトマネージャやプロジェクトメンバの問題点について愚痴を書いていた。しかし、問題点は問題点として、今後もその状況ではまずいということを自分だけでなく現場にも気づいてもらわなければいけないし、そうしないとカイゼンは進まない。

『ここが変だよ日本の管理職』的な考え方は、ひとつは欧米的にトップダウンでカイゼンを推し進めることができないのかという問いかけなのだが、日本人は『アメリカ人と日本人』の記事で書いたように「あたたかい人間関係の中のやさしい一員」的気質であるため、もともと『ここが変だよ日本の管理職』的な進め方がうまくいきにくい環境なんだと思う。だから、カイゼンが早く進まないことに対してブツブツと愚痴をこぼし、プロジェクトマネージャのふがいなさを嘆くのではなく、ほんの少しでもプロジェクトが今とは違うカイゼンの一歩を踏み出す方策はないのかについて、何とか知恵を絞ることの方が大事だ。

このことに気がついた、というよりはそんな心境になったはプロジェクト支援の仕事をするようになって1年を過ぎたころだろうか。新しい職務に就けば誰だって早く成果を上げ、組織に貢献していることを示したいものだが、ことソフトウェアの開発効率アップとか品質向上の成果を示すのには根気もいるし時間もかかるということがだんだん分かってきた。

今現在、これは正しいといえるのは、何か新しいことをプロジェクトにやってもらいたいと思うのなら最初は大変でもできるだけ環境を整え敷居を低くして、さんざん文句を言われても「がんばれ」「効果はでてきたぞ」と現場を励ましながら、新しいことをルーチンワーク化して、結果的にその施策をプロジェクトの習慣にさせることだ。習慣になると自然と何がよくなったのかが見えてきて文句も言わなくなる。この明確な計画なしに「あたたかい人間関係の中のやさしい一員」の中で慣習化させるどちらかと言えばボトムアップ的なカイゼンこそ、日本的プロセス改善なんだと思う。

さて、ピーター・F・ドラッカーは著書『プロフェッショナルの条件』で、イノベーションの成功の条件として次の3つを挙げている。（こちらの記事も参照のこと）

【イノベーションの成功の条件】

1. 第一に、凝りすぎてはならない。イノベーションの成果は、普通の人間が利用できるものでなければならない。多少とも大きな事業にしたいのであれば、さほど頭のよくない人たちが使ってくれなければ話にならない。つまるところは、大勢いるのは普通の人たちである。組み立て方や使い方のいずれについても、凝りすぎたイノベーションは、ほとんど確実に失敗する。
2. 第二に、多角化してはならない。散漫になってはならない。一度に多くのことを行おうとしてはならない。これは「なすべきこと」の一つとしての的を絞ることと同義である。
3. 第三に、未来のためにイノベーションを行おうとしてはならない。現在のために行わなければならない。たしかに、イノベーションは長期にわたって影響を与えるかもしれないし、20年たたなければ完成しないかもしれない。だが、「25年後には、大勢の高齢者がこれを必要とするようになる」というだけでは十分ではない。「これを必要とする高齢者はすでに大勢いる。もちろん時間が味方だ。25年後には、もっと大勢の高齢者がいる」と言えなければならない。

※ピーター・F・ドラッカーは著名な経済学者で『プロフェッショナルの条件』は6年間で44刷りもしている。ここでドラッカーを引用したのは自分が考えていたことと、この本に書かれていたことに共通点があり、ドラッカーを引用することで、その考え方の根拠がより広範囲に裏付けられると考えたからである。

ちなみに、ここで論じていることはとどのつまり組織成熟度と組織成熟度に応じて適用すべき適切な施策のことを言っている。それって、CMMIのことかっていうことになるが、そのとおりCMMIと同じことを言っている

CMMI（Capability Maturity Model Integration）

米カーネギーメロン大学ソフトウェア工学研究所が公表したソフトウェア開発プロセスの改善モデルとアセスメント手法であるCMM（Capability Maturity Model）に、有識者の意見や多くのプロセス改善事例を反映させて作成された新しい能力成熟度モデルのこと。

でも、日本の組織でCMMIのレベル○○を取るように頑張ろうというと、多くの場合うまくいかず、無理にごり押しするとすぐに形骸化する。形骸化する理由は、ドラッカーが言っているイノベーションの成功の条件に合っていないからであり、凝りすぎて、散漫であり、現在のための施策になっていないからだ。凝りすぎて、散漫であるというのは、すなわち CMMI のレベルが低いということになるのだが、そもそも CMMI で組織成熟度を格付けすることが、そのプロジェクトやその組織の“現在のための施策”かという点が引っかかる。（皮肉にも日本ではCMMIを受けいられるくらい組織が成熟している場合のみCMMIの効果がでる）

さらに、日本人の気質は「あたたかい人間関係の中のやさしい一員」であるため、特に格付けや監査を毛嫌いする傾向があると思う。ようするに格付けされたり、監査で重箱の隅をつつかれてカイゼンするのではなく、誰とは言わず自分たちのプロジェクトの内側から問題を解決することを望む傾向があるということだ。

そして内側からのカイゼン力が低い組織・プロジェクトに外側から格付けや監査をしようとすると、バリアを高くしてどんどん殻に閉じこもる。これが、『日本人はリスクを表に出すのが嫌い？』といった状態だ。こうなってしまった場合は外側から殻をこじ開けようとするのではなく、内側のカイゼン力を回復させてあげることに注力を注ぐべきだと思う。（『カイゼンを実現できる多能工を目指そう！』を参照のこと）

こういう場合、一番いいのはプロジェクトリーダのリーダシップで引っ張ってもらうことだが、プロジェクトメンバ全員がリーダも含めて「あたたかい人間関係の中のやさしい一員」的気質である場合は、支援者が小さなカイゼンの方法論と環境を提供し、その小さなカイゼンを自分たちのものになる（ルーチンワーク化する）までサポートしてやるといいと思う。その心は「内側からのカイゼンに対して自信を付けさせる」ということだ。

日本の製造業においてQC活動は生産品質向上に大きく貢献した。おそらく、内側からのカイゼンで組織の成熟度を高めるというやり方が、「あたたかい人間関係の中のやさしい一員」的気質にピッタリ合っていたからだと思う。CMMIも目指しているところは同じだと思うのだが、対象としているのが人間であり、その人間は地域や組織によって気質が違うということを考慮しなければいけないのだ。

ソフトウェア工学は先人の知恵を体系化したものであり、対象は人間である、だからソフトウェア工学をプロジェクトに適用するときは、凝りすぎず、散漫にならないように気をつけ、現在の問題の解決のためになることを明確にする、そして、終わってみればそのカイゼンがプロジェクト内部のエネルギーで成就したことになっていることが大事である。

ちなみに、本当にこの通りうまくいくと、そのプロジェクトは成果を内外で発表したくなる。このように成果を発表して振り返ることはその組織やプロジェクトにとって非常に大事なことであり、積極的に行うべきだ。

でも、その発表を聞いたカイゼンが進んでいないプロジェクトはこの成果を取り入れる前に、方法論採用の是非をこの記事に書いた原理原則に照らし合わせてよく考えてみる必要がある。自分のプロジェクトに対して凝りすぎていないか（難しすぎないか）、現在の問題の解決のためになっているかチェックしなければならない。

ソフトウェアにおけるカイゼンは対象が人間であるが故に、技術的な施策にも増して意識改革への取り組みが重要なことが多い。ソフトウェア工学は自然科学では証明できない部分が大きいということに着目すると、現場に対して何を支援・指導すべきかが見えてくる。

P.S.

ソフトウェアの世界でも産学の協調がよく話題になる。産学の協調でうまくいったケースとして、1960年代、1970年代の品質機能展開(QFD）の技術があったと思う。（『組込みソフトで勝ちたい人に捧ぐ』参照のこと）　企業は自分たちの製品の品質表を作成し、研究者が現場が一体となって改善点を探り、改善点をQFDの理論として体系化していった。ソフトウェアの世界では対象が人間であるため、産学連携が成功するには研究者が開発現場にどれだけ関われるかにかかっていると思う。また、研究者はある現場で成功した方法論が他の現場でもうまくいくかどうかよく考え、うまくいく根拠を明示して欲しいと思う。