Think about IT project management
プロジェクト管理の実践的な手法として“出荷判定会議”があります。簡単に言いますと、ソフトウェア製品の出荷基準を設定し、それを満たしているかどうかを判定する会議です。基準が満たされているか否かが問われ、開発プロセスや手法について触れることはありません。
出荷判定会議の目的は、言葉通り、出荷基準を満たしているかどうかを判定することですが、出荷判定会議の真価は関係者をやる気にさせる、あるいは創意工夫にまい進させる副次効果にあります。出荷判定会議のキー・ポイントは「プロジェクト関係者が出荷判定基準を満たすことを約束して、その実現に向けて努力すること」にあります。その結果、開発現場に規律を持ち込む足がかりにすることができます。
出荷判定会議を行うに際して必要な事柄を整理すると以下の通りです。
“気づき”、“思い込み”という言葉はＩＴプロジェクト管理とは無縁のように思われるかも知れませんが、ITプロジェクト管理にとってこれらは重要な意味を持ちます。ＩＴプロジェクト管理は人の管理であり、人の思考がＩＴプロジェクトの成否に大きく影響するからです。
以下では、“気づき”、“思い込み”がＩＴプロジェクト管理とどのように関係しているかについて順に述べます。
（１） 気づき
知識や経験が少ない子供にものごとを教えるのは、大人に教えるのに比べ、大変難しい面があります。大人にとって当たり前のことが、子供にとっては何を意味するのか全く理解できないことが多いからです。子供の教育は理屈で教えるのでなく、“気づき”に重点を置かなければならないからです。初めてのことに気づくのは一人ひとりがもっている体験に大きく依存します。教える側が一方的に説明して終わりにすることはできません。やる気がなければ“気づき”は生じないでしょうし、興味がなければやる気はでません。
私が日頃目にするITプロジェクト管理関連の書物はソフトウェア開発方法論や開発ツールに偏重していると感じています。また、方法論や開発ツールを導入すればプロジェクトの生産性が向上し、成功すると思い込んでいる経営者がいるようにも思います。方法論や開発ツールの重要性に疑義を差し挟む余地は些かもないのですが、プロジェクトの成功にはこうした方法論や開発ツールに加えて戦略が必要です。
また、上記の書物の多くは単独のプロジェクトに的を絞った議論になっています。プロジェクト管理を成功させるには、当該プロジェクトを含む組織がどう行動するかを考える必要があります。複数のプロジェクトが同時並行的に遂行されている組織（企業、システムプロバイダー）にとって、組織全体の利益（短期のみならず、中長期的利益）が得られなければ成功とは言えません。一つのプロジェクトの失敗が組織の生き残りを危うくすることがあり、逆に経営判断のミスがプロジェクトの失敗の原因になることもあります。
戦略というからには相手が存在します。ITプロジェクト戦略では、市場という“場”における競合他社が相手ということになります。相手の出方に応じてこちらの出方を決める必要があります。市場はいろいろな要因で変化しますので、その中で、自組織が最も有利となるよう行動するのです。
経営者と現場の管理者・技術者との間に認識ギャップがあり、コンサルタントとして戸惑うことがあります。経営者は自社のプロジェクトに問題があると感じ、当方に相談に乗って欲しいと声をかけてくるのですが、お客様を訪問し、現場の管理者・技術者と面談すると、いろいろ話している内に迷惑そうな顔をするのです。少々問題をかかえているが、ほどほどに進行していると思われるプロジェクトのリーダに対して、具体的な問題点を指摘すると、「それは、自分達も分っている。今、対策を打っているので、近々解決する見込みだ」などと言って断られることがあります。
メインフレーム（汎用機）全盛期のころ、顧客はコンピュータの知識を殆どもっていませんでした。メーカの技術者はどんな知識でも売りものになりました。知識を持てる立場にあったメーカの技術者は顧客から重宝がられたものです。自分は専門家で、相手は素人。この間には優越感が漂います。中には、相手が上司であっても、小ばかにしたような態度をとる技術者を見かけることもありました。
ソフトウェア・アーキテクチャとは何か。“アーキテクチャ”は日本人にとって分りにくい言葉です。何か、もやもやした感触があります。しかし、ソフトウェア開発おいて、ソフトウェア・アーキテクチャは非常に重要な考え方です。
ソフトウェア・アーキテクチャの定義を、
ソフトウェア製品を設計するとき、機能・性能・意匠などから成る全体像と、その製品を構成する要素の、全体像に於ける役割と関係性
とする向きもありますが、あまりにも抽象的で、分りにくく、煙に巻かれたような気分になってしまいます。大切なことは、ソフトウェア・アーキテクチャが何を狙いとしているかを認識することです。
“アーキテクチャ”の日本語訳は「建築学」や「構築スタイル」、「構築方式」などですが、そうならば、“ソフトウェア・アーキテクチャ”を、
・ ソフトウェア構築スタイル
・ ソフトウェア構築方式
と訳しても良いかも知れません。しかし、構築スタイルや構築方式は、ソフトウェア・アーキテクチャの意味をピッタリと言い表していません。スタイルという言葉に対して私達がイメージするのは様式や型です。ソフトウェア・アーキテクチャは、様式や型、あるいは方式を説明の一つの手段として取り扱うことはありますが、それらがソフトウェア・アーキテクチャのテーマではないので、本稿では「ソフトウェア・アーキテクチャ」のままで通したいと思います。
