僕が2年前に進めたプロジェクトの話。
僕が担当しているお客さんのシステム構築。
このプロジェクトでは、新しい開発プロセス、言語、設計方法を取り入れた。
未経験のことを始めるとき、今までやってきた経験が何もかもが役に立たないかのように不安になったり、急に手が止まり、尻込みしがちだ。
そのような技術者もいたが、僕を始めとする若手メンバー達は、まだまだ怖いもの知らずで危なっかしいが、大きな責任を任されることの嬉しさで、モチベーションは高かった。
しかし、決して思うような効果は得られなかった。
中途半端な適用で現場は混乱したように思う。
経験者が少なかったこと、
開発プロセスがプロジェクト特性に合わなかったこと
僕がプロジェクトをうまく舵取りできなかったこと
多くの原因がある。
新しい開発プロセスを適用は難しい。
開発プロセスは多くの優れた技術者が書籍などで述べられているが、それとは別に僕は感じることがある。
プロジェクトの開発費は億を超え、開発期間は1年6ヶ月に渡った。
僕が進めたプロジェクトの中で一番規模が大きかった。
このプロジェクトでは、組織の意向もあり、次を期待して新しい開発プロセス、言語、設計方法に挑戦することになる。
技術力を向上させたい。
生産性を上げたい。
品質を上げたい。
業界の動向に遅れを取りたくない。
しかし「生産性向上」「品質向上」の効果は思うように上がらず、方針を見直したり、建て直しを幾度と試みた。
結果的には、採算や納期など問題なく終わった。
しかし、僕が学ぶ点は多かった。
僕が開発プロセスの適用で感じたこと。
開発プロセスの導入により、相性のいい開発言語やツールを使いながら、「工学的成果」は芽を出していたと思う。
しかし、依然として多くのプロジェクトでは思った効果があげられず、むしろ新しい試みにより混乱が発生しているように思う。
開発プロセス論は「要件定義」「設計」「実装」「評価」「リリース」のライフサイクルと成果物をスコープとしている。
このプロセス論に従って、ある一部分の作業(技術やプロジェクト管理)を切り出し、改善を試みても、成果が限られてしまうのは当然だ。
なぜならば、ソフトウェア開発には、経営部門、管理部門、営業部門、開発部門、顧客、委託先など多くの利害関係者が存在する。本来の目標を達成する為には、プロジェクトだけではなく、開発方法論を超えて、各部門を説得しながら、全体最適のアプローチが必要がある。
部門は個別に改善活動を行って、成果の出ない改善活動に諦めたかもしれない。
または、目の前の課題に追われて、改善する余裕すらないかもしれない。
企業規模、組織構成、組織文化、経営目標、業務課題によってすべてアプローチが違うかもしれない。
それらを尊重しながら進める必要があり、
結局、僕達は周囲を巻き込む意識が欠けていた。
プロセス改善は組織改革そのものだ。
時は流れ、会社全体が方法論に本気で取り組み始めた。
これからが面白いと思う。
