Think about IT project management
ソフトウェア開発は、ソフトウェア工学の知識と職人的能力を必要とする仕事です。
如何なる仕事であれ、形式知のみでこなすことはできません。熟練者がいて、熟練者のもつ暗黙知を後継者が引き継いで行くことにより、維持・発展・進化します。後継者は、プロジェクト開始時に、十分な知識や熟練度を持ち合わせていなくても、プロジェクトに参加しながら、能力を身につけます。
ソフトウェア（日本のビジネス処理系ソフトウェア）開発の現場を覗くと、ソフトウェア工学知識に偏重したマネジメントを行なっているケースがあります。技術文書に書かれた知識（形式知）に精通していれば、いかにもソフトウェア技術者であるかのような誤解もあるようです。ソフトウェア工学の成果を記述した技術文書は、実際の仕事で成果を上げた方式等を広く知ってもらうために書かれた文書です。しかも、著者は内容を整理・洗練しようと努力していますから、一種のモデルと言っても良いものです。仕事を進める上では必要な知識ですが、実際のソフトウェア開発の現場では、そこには書き表わされていない、たくさんの泥臭い問題に遭遇します。例えば、
ITプロジェクトで行われる利用者（顧客）要求の定義、システム設計、詳細設計、コード化において、レビューは大変重要な意味を持ちます。システム生成の自動化が進めば、レビューは不要になるのではないかと思われるかも知れませんが、自動化とは言ってもほんの一部の自動化が少しずつ可能となってきたにすぎません。確かに１９７０年代に較べるとソフトウェア開発はかなり自動生成されるようになりました。おかけでソフトウェアの種類によっては開発期間は短くなりました。かなりお膳立てがされている状態（パッケージソフトやCASEツール、簡易言語の活用等）から開発が可能となり、システムによっては３ヶ月以内で開発できる案件もあります。しかし、利用者（顧客）要求定義を行い、システム設計、詳細設計、コード化という作業が伴なう限り、レビューが不要となることはありません。
「ITプロジェクトに於ける知識継承」では、一般的な開発モデル（Waterfall型）を使って知識継承について述べました。前工程から後工程に向けたミッション･タイプの知識継承について述べています。しかし、実際にはそれだけでなく、コミュニティ・タイプの知識継承があることを補足しておくべきでした。経済学者フリードリッヒ・ハイエクが言っているように、重要な情報は「当事者」が分散的にもっています。ハイエクは経済システムを動かしているのは包括的な知識とか統計的に集計された大きな知識ではなく社会の様々な場面に従事している個々人がそれぞれに不完全なままに矛盾するものとして分散的にもっている知識であると述べています（「ボランタリー経済の誕生：実業の日本社」より引用）。このことは経済に限らず、ソフトウェア開発においても当てはまることです。
Ｗａｔｅｒｆａｌｌ型ソフトウェア開発では、前工程でまとめ上げた要求仕様や構成仕様を、詳細設計以降を担当する技術者へ、一方向に知識継承することを要求しています。現実のソフトウェア開発では、知識継承はそれほど単純ではありません。顧客の要求を熟知し、また、後工程を担当する技術者がもつプログラミング言語の制約条件や開発ツールの特性知識も必要となります。ソフトウェアの構造を設計するために、一人の技術者がすべてを知り尽くしていることは稀です。誰が何を知っているかさえ分らないこともあります。そこで必要となるのは目的を達成するために、顧客、営業、コンサルタント、SE、プログラマ、品質管理、ｅｔｃ．の異なる領域のメンバが集まって知識を出し合う“場”です。コミュニティと呼ぶのが相応しいでしょう。コミュニティに参加するメンバはすべて同格であることが必要です。コミュニティの進行役は茶の湯のにじり口効果（亭主も客同士もここを通れば身分、階級の差がない対等な関係）を狙った運営を図り、各メンバが何にもとらわれない発想を促します。
「ITプロジェクトに於ける知識継承」で述べた知識継承は役割を決めて行われるのでミッション・タイプと呼びます。それに対して、異能の人材が集まって、目的達成のために知識を出し合う知識継承をコミュニティ・タイプと呼ぶことにします。
ソフトウェア開発はミッション･タイプの知識継承とコミュニティ･タイプの知識継承とを組み合わせて実行することが肝要です。■
ソフトウェア開発に多くの人が関係する場合、知識継承コストの増大という問題が発生します。組織の「知識継承性」と「ソフト開発要員数」には次式の関係があります。
１
＜知識継承性＞ ＝ 
＜ソフト開発要員数＞
この式は感覚的な式です。ソフトウェア開発要員が１人であれば、＜知識継承性＞は１となりますから、＜知識継承性＞＝１は知識継承性が最大である ことを意味します。ソフト開発要員数が５０人になると、知識継承性は５０分の１になるという計算です。この計算の数値には特に意味がありません。しかし、 要員の増加は知識継承性を落とすということは分かります。
本稿では、「ITプロジェクトにおける組織的知識創造の仕組み」を実際にどのように適用するかについて説明したいと思います。ITプロジェクトで採用する方法論が、組織メンバ（上から下まで）全員に染渡っていることが大切です。NHKの番組「その時歴史は動いた」で「日露戦争100年 日本海海戦 ~参謀 秋山真之・知られざる苦闘~」をご覧になられた方は多いかと思いますが、秋山参謀が司令長官東郷の命を受け、ロシアバルチック艦隊と如何に戦ったか、その戦略と実戦がドラマチックに紹介されています。この戦いでは秋山参謀が立案した丁字戦法が効を奏したのですが、司令官、参謀、現場指揮官、戦闘員に到るまで、丁字戦法を理解し、訓練を繰り返し、戦法を頭に叩き込んでいたことが臨機応変に事態の変化に対応でき、組織力を発揮できたと言われています。ITプロジェクト管理と日本海海戦は一見関係ないように見えますが、ITプロジェクト管理は日本艦隊の丁字戦法とその組織的取り組みに学ぶ点が非常に多いと思います。キナ臭いと切り捨てるのは簡単ですが、役立つ考え方は貪欲に学び、取り込むべきではないでしょうか。
