予防的なプロジェクト管理のすすめ

プロジェクトである以上、どうしても大勢の人と一緒にチームを組んでの仕事となります。一緒に仕事をやるといっても、多くの場合には、最終的には1 人で作業を行えるように仕事を分解していきます。最近ではペア・コーディングというような、本当に2 人で一緒に仕事をするというのもないわけではありませんが、多くの場合には1 人で仕事をできるように細分化していくわけです。

例えば、ソフトウェア開発で考えると、仕事を細分化して実行した後に、成果物を統合しながら、設計通りにできあがっているかどうか確認していくのが試験作業となります。1人で全部を作っているときにはあまり問題になりませんが、大勢で分担をすると、どうしても解釈に差が生じて、試験のときにそれが発見されるということになります。もともと試験作業というのはそうした齟齬を発見して修正するのも目的の1 つですから、ここでバグが発生することそのものが問題なのではありません。

しかし、その解釈のブレ幅があまりにも大きかったり、たくさんのバグがあったりすると、全体の修正量が増加して、コストにも納期にも悪影響を及ぼします。そのために、日本では伝統的に「暗黙知の共有」が大事にされてきました。いつも同じメンバーで仕事をすることにより、お互いの個性や仕事の癖も理解しあった上で、以心伝心で大体こんな感じといえばシステムができあがってしまうような作り方です。このやり方をとると、閉鎖されたチーム内では効率的に仕事が進むのですが、新規参入者はうまく仕事ができずに簡単に仲間には入れられないといった問題が生じます。

一方、欧米で採用されている方法は、暗黙知に頼らずにすべてを形式知に落として情報共有するというもので、新規参入者でも容易にプロジェクトの構成員として受け入れやすい反面、ドキュメントの記述とメンテナンスの負担が大きいという問題点もあります。

こうした文化の違いは、これまであまり問題が生ずることは少なかったのですが、21 世紀に入り本格的なグローバル化が進み始めると、多くの局面で問題が生じました。今まで日本国内では立派に通用していた仕様書や設計条件書でも、中国やインドに発注したとたんに、日本特有の「行間を読む」ことが期待できずに、問題が発生します。暗黙知ではなく形式知で仕事をすることが求められるのです。

こうしたことは、外国と一緒に仕事をして目立った形で現れたのですが、これまでの日本国内での仕事でもなかったわけではありません。そこで、これらの問題を解決するために、「予防的」な方法をとるべきではないでしょうか。いくら形式知化するといっても、森羅万象すべてを記述するのは非効率なので、ある程度は暗黙知に依存する部分は残ります。

暗黙知の形成といっても、これには時間がかかりますし、流動性の高い雇用条件化では成立しにくいものです。そこで「演繹的な暗黙知」の共有が有効です。プロジェクトを進めるにあたっての、目的や判断原理を10 項目ぐらいに取りまとめて、参加者全員と共有しておきます。そして、後はあらゆる判断局面においてこの判断原理に基づいて判断を積み重ねることとします。共有するのは原理だけなのですが、プロジェクトの参加者が同じ原理で動くことにより、暗黙知の共有と同様の効果があげられるのです。