Think about IT project management
プログラミング言語（含：データベース定義言語、設計ツールのUI）が大きく発展し、その影響を受けてソフトウェアの設計方法も様変わりしました。プログラミング言語が進化すれば、ソフトウェア設計方法も変えて行かなければならないからです。
例えば、詳細設計書について言えば、アセンブリ言語の時代には、ソースコードを読んでも何を意味するのか読み取るのはかなり困難だったため、分り易い表現手段としてフローチャートを用いていました。しかし、プログラミング言語が高水準化し、プログラムのモジュール構造、データ構造、アルゴリズムなどを、フローチャートなしに読み取ることができるようになると、詳細設計書で厳密なフローチャートを書く必要がなくなり、もう少し大づかみの表現で間に合うようになってきました。現在では、JAVAやCなどのプログラミング言語に対応するエディターが整備されていますので、詳細設計書そのものも不要となりつつあります。詳細設計書をソースコードの一部に含めることが可能となったのです。
ソフトウェア開発における熟練技術者の育成には時間がかかります。教育の成果が現れるまでに１０年は要します。コンピュータ技術、ネットワーク技術、システム技術、ソフトウェア工学、プロジェクト管理などについて、基礎から応用に到る深い知識と経験が必要となるからです。プログラミング言語やデータベース、ネットワークを使いこなせたら十分という単純な話ではありません。熟練技術者はどのようにして育成できるのでしょうか。
ソフトウェア開発の熟練技術者を育成するにはキャリヤパスを重視する必要があります。キャリヤパスは、以前に学んだ知識や経験・体験が次のステップの学習に大きく貢献するという経験則から編み出された考え方です。また、キャリヤパスを言う前に、人には向き・不向きがあることを認識しておかなければなりません。
本稿では、ソフトウェア開発技術者として必要な潜在能力、そしてキャリヤパスについて、考えるところを述べたいと思います。
ＩＴプロジェクト失敗の原因は様々です。関係者が情報交換を怠っていると、プロジェクトは混沌としてきます。失敗の規模が大きくなれば、混沌からの脱却は困難になります。プロジェクトのメンバは休みなく、疲労困ぱいして働くのですが、状況は悪化して行きます。このようなＩＴプロジェクトを、私たちは「泥沼プロジェクト」と呼んでいます。最近では、田舎でさえ、泥沼を見ることが少なくなりましたが、底なし沼の恐ろしさに似ているということから、このように命名されたのだろうと思います。
どうすれば泥沼プロジェクトに陥らないようにすることができるのでしょうか。今日では、泥沼プロジェクト予防策や打開策は分かっています。しかし、ＩＴプロジェクト失敗の原因は様々であり、医療におけるような“標準治療”と呼ばれる方法が確立されていないのが現状なのです。
本稿では、私がコンサルティングした事例と私自身の失敗体験とを取り上げ、これらの失敗の原因を明らかにします。そして、同様の失敗を招かないようにするためにどうすべきかについて述べます。
ソフトウェア開発は、ソフトウェア工学の知識と職人的能力を必要とする仕事です。
如何なる仕事であれ、形式知のみでこなすことはできません。熟練者がいて、熟練者のもつ暗黙知を後継者が引き継いで行くことにより、維持・発展・進化します。後継者は、プロジェクト開始時に、十分な知識や熟練度を持ち合わせていなくても、プロジェクトに参加しながら、能力を身につけます。
ソフトウェア（日本のビジネス処理系ソフトウェア）開発の現場を覗くと、ソフトウェア工学知識に偏重したマネジメントを行なっているケースがあります。技術文書に書かれた知識（形式知）に精通していれば、いかにもソフトウェア技術者であるかのような誤解もあるようです。ソフトウェア工学の成果を記述した技術文書は、実際の仕事で成果を上げた方式等を広く知ってもらうために書かれた文書です。しかも、著者は内容を整理・洗練しようと努力していますから、一種のモデルと言っても良いものです。仕事を進める上では必要な知識ですが、実際のソフトウェア開発の現場では、そこには書き表わされていない、たくさんの泥臭い問題に遭遇します。例えば、
ITプロジェクトで行われる利用者（顧客）要求の定義、システム設計、詳細設計、コード化において、レビューは大変重要な意味を持ちます。システム生成の自動化が進めば、レビューは不要になるのではないかと思われるかも知れませんが、自動化とは言ってもほんの一部の自動化が少しずつ可能となってきたにすぎません。確かに１９７０年代に較べるとソフトウェア開発はかなり自動生成されるようになりました。おかけでソフトウェアの種類によっては開発期間は短くなりました。かなりお膳立てがされている状態（パッケージソフトやCASEツール、簡易言語の活用等）から開発が可能となり、システムによっては３ヶ月以内で開発できる案件もあります。しかし、利用者（顧客）要求定義を行い、システム設計、詳細設計、コード化という作業が伴なう限り、レビューが不要となることはありません。
