DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

筆者が考えるプロジェクトの構成要素（エンティティ）は、プロジェクト、フェーズ、タスク、インプット、アウトプット、テクニック、ガイドライン、ツールなどである。

これらは、どのような関係になるのだろうか？
プロジェクトの実行は、マネジメントプロセスと開発プロセスに分離できる。開発プロセスは、IT企画、要件定義、設計などのシステムという成果物を作るために必要なプロセスを示している。一方、マネジメントプロセスは、決められた期間内に、目標とする品質の成果物を与えられたコストの範囲で完成するための重要なプロセスである。

プロジェクトマネジャーは、様々な役割のメンバーを開発プロセスで定義されている各タスクにアサインし、マネジメントプロセスを実行する。マネジメントプロセスと開発プロセスの同期が取れて、プロジェクト活動は正常に機能する。
組織の中で最適な人材をプロジェクトにアサインする。そして、繰り返しプロジェクトをシナリオに従って実施し、組織的な経験を積み重ね、プロジェクトでの各役割を担った人材のスキルを鍛え上げる。開発とマネジメントプロセスの構成要素が明確になっているから、経験知を蓄積でき、改善も可能になり、ビジネスシナリオの再現性が高まるのだ。

私が言いたいのは、ビジネスシナリオに従ったプロジェクトに対して、ここで説明するような組織的な学習を積み上げることが、強いIT組織をつくるために重要だということである。

方法論で規定された繰り返しのプロジェクト経験が、やがて強い組織的な能力を保有することにつながる。

ノウハウ、事例などは、体系化された方法論に従って開発プロセスやマネジメントプロセスを実行し、蓄積されてこそ、有用な知識体系となる。次々と類似のプロジェクトを実行すればするほど、信頼性もより高くなる。

蓄積された事例やノウハウから、ユーザーのニーズを分析し、パッケージ化するソフトウェアの候補が現れるかもしれない。様々な場面で必要な業務のパターンや機能が見つかれば、汎用的な製品やサービスを生み出す機会になる。また、これらのノウハウは、人材を育成する際にも重要なノウハウになる。

日本には優秀なエンジニアは多いが、ノウハウや技術の蓄積をする方法は、“独自の文脈的なコミュニケーション”に頼っている。要するに“ムラ（村）”の中では、かなり緻密なコミュニケーションが可能であるが、伝統的な方法で、技として引き継がれるものであり、ごく少数の限られた人にしかその技は、伝わらない。他人からは、よくわからないし、伝承速度は、遅くなってしまう。システム開発における方法としては、広がりとスピードという点を考慮すると不適切だといえる。

日本的コミュニケーションのすべてを否定するわけではないが、技術の再現性の点からすれば、実際に作られる現場や物理的な物作りのレイヤーで、そこにしかない技の伝承の方法よりも、一段抽象度を上げて、“論理モデルやコンセプト”として、あるいは汎用性のあるモデルとして、ノウハウをまとめ上げることができれば、見違えるほど「再現性」が高まる。この部分が、日本の技術者の弱点になっている。

欧米のITビジネスは、この“論理モデルやコンセプト”をベースに製品化、サービス化して顧客へ提供し、再現可能にすることで、付加価値を高めた上でビジネスを展開している。
これに対して日本は、技はあるが、伝承性、再現性に乏しく、コンセプトを掲げて展開する欧米型のビジネスには、かなわない。

日本発祥のカイゼンや生産方式、経営手法などが、主に米国においてコンセプト化され、日本に再上陸してきている。再現可能なメソドロジーを重視して上流のコンセプト、論理モデルを明確にし「伝承と高付加価値化」を目指そう。

なぜならば、日本には、オリジナルの高い技術があるからである。