Think about IT project management
経営者と現場の管理者・技術者との間に認識ギャップがあり、コンサルタントとして戸惑うことがあります。経営者は自社のプロジェクトに問題があると感じ、当方に相談に乗って欲しいと声をかけてくるのですが、お客様を訪問し、現場の管理者・技術者と面談すると、いろいろ話している内に迷惑そうな顔をするのです。少々問題をかかえているが、ほどほどに進行していると思われるプロジェクトのリーダに対して、具体的な問題点を指摘すると、「それは、自分達も分っている。今、対策を打っているので、近々解決する見込みだ」などと言って断られることがあります。
メインフレーム（汎用機）全盛期のころ、顧客はコンピュータの知識を殆どもっていませんでした。メーカの技術者はどんな知識でも売りものになりました。知識を持てる立場にあったメーカの技術者は顧客から重宝がられたものです。自分は専門家で、相手は素人。この間には優越感が漂います。中には、相手が上司であっても、小ばかにしたような態度をとる技術者を見かけることもありました。
ソフトウェア・アーキテクチャとは何か。“アーキテクチャ”は日本人にとって分りにくい言葉です。何か、もやもやした感触があります。しかし、ソフトウェア開発おいて、ソフトウェア・アーキテクチャは非常に重要な考え方です。
ソフトウェア・アーキテクチャの定義を、
ソフトウェア製品を設計するとき、機能・性能・意匠などから成る全体像と、その製品を構成する要素の、全体像に於ける役割と関係性
とする向きもありますが、あまりにも抽象的で、分りにくく、煙に巻かれたような気分になってしまいます。大切なことは、ソフトウェア・アーキテクチャが何を狙いとしているかを認識することです。
“アーキテクチャ”の日本語訳は「建築学」や「構築スタイル」、「構築方式」などですが、そうならば、“ソフトウェア・アーキテクチャ”を、
・ ソフトウェア構築スタイル
・ ソフトウェア構築方式
と訳しても良いかも知れません。しかし、構築スタイルや構築方式は、ソフトウェア・アーキテクチャの意味をピッタリと言い表していません。スタイルという言葉に対して私達がイメージするのは様式や型です。ソフトウェア・アーキテクチャは、様式や型、あるいは方式を説明の一つの手段として取り扱うことはありますが、それらがソフトウェア・アーキテクチャのテーマではないので、本稿では「ソフトウェア・アーキテクチャ」のままで通したいと思います。
プログラミング言語（含：データベース定義言語、設計ツールのUI）が大きく発展し、その影響を受けてソフトウェアの設計方法も様変わりしました。プログラミング言語が進化すれば、ソフトウェア設計方法も変えて行かなければならないからです。
例えば、詳細設計書について言えば、アセンブリ言語の時代には、ソースコードを読んでも何を意味するのか読み取るのはかなり困難だったため、分り易い表現手段としてフローチャートを用いていました。しかし、プログラミング言語が高水準化し、プログラムのモジュール構造、データ構造、アルゴリズムなどを、フローチャートなしに読み取ることができるようになると、詳細設計書で厳密なフローチャートを書く必要がなくなり、もう少し大づかみの表現で間に合うようになってきました。現在では、JAVAやCなどのプログラミング言語に対応するエディターが整備されていますので、詳細設計書そのものも不要となりつつあります。詳細設計書をソースコードの一部に含めることが可能となったのです。
ソフトウェア開発における熟練技術者の育成には時間がかかります。教育の成果が現れるまでに１０年は要します。コンピュータ技術、ネットワーク技術、システム技術、ソフトウェア工学、プロジェクト管理などについて、基礎から応用に到る深い知識と経験が必要となるからです。プログラミング言語やデータベース、ネットワークを使いこなせたら十分という単純な話ではありません。熟練技術者はどのようにして育成できるのでしょうか。
ソフトウェア開発の熟練技術者を育成するにはキャリヤパスを重視する必要があります。キャリヤパスは、以前に学んだ知識や経験・体験が次のステップの学習に大きく貢献するという経験則から編み出された考え方です。また、キャリヤパスを言う前に、人には向き・不向きがあることを認識しておかなければなりません。
本稿では、ソフトウェア開発技術者として必要な潜在能力、そしてキャリヤパスについて、考えるところを述べたいと思います。
ＩＴプロジェクト失敗の原因は様々です。関係者が情報交換を怠っていると、プロジェクトは混沌としてきます。失敗の規模が大きくなれば、混沌からの脱却は困難になります。プロジェクトのメンバは休みなく、疲労困ぱいして働くのですが、状況は悪化して行きます。このようなＩＴプロジェクトを、私たちは「泥沼プロジェクト」と呼んでいます。最近では、田舎でさえ、泥沼を見ることが少なくなりましたが、底なし沼の恐ろしさに似ているということから、このように命名されたのだろうと思います。
どうすれば泥沼プロジェクトに陥らないようにすることができるのでしょうか。今日では、泥沼プロジェクト予防策や打開策は分かっています。しかし、ＩＴプロジェクト失敗の原因は様々であり、医療におけるような“標準治療”と呼ばれる方法が確立されていないのが現状なのです。
本稿では、私がコンサルティングした事例と私自身の失敗体験とを取り上げ、これらの失敗の原因を明らかにします。そして、同様の失敗を招かないようにするためにどうすべきかについて述べます。
