われわれは、自分が分け入る森が常に、「前人未踏の暗黒の森」であることを理解しておかねばなりません。
ITプロジェクトの開発現場と人という視点で「人」からプロジェクトを探り出す。いよいよ最終回です。いままで、いわゆる「ケーススタディ」のような形で様々なケースを見てきました。
生産設備や、店舗のない、われわれソフトウエア産業は、もっとも重要な要素が人であると言い切ることができます。開発会社のバランスシートもほとんどが人件費と外注費(これも内訳はほとんど人件費)で費用の部分が構成されています。
さまざまなアーキテクチャやプロセスなどの手法を重ね合わせても最上流の提案から実装。そして、プロジェクトを支えるマネジメント、さらに稼働しているシステムの運用に至るまで、あらゆる場面で最も重要な要素は人です。
良くも悪くも、システム開発どころかソフトウェア産業自体あまりにも「人」という要素に深く依存しています。結果として常にプロジェクトの達成指標として語られるQCDは実は人という要素に深く依存する形で構成されています。
そのため、「プロジェクトを深く知る」ためには実は「人を深く知る」必要があるのです。今回人という視点で様々なプロジェクトの「履歴」を見てきたのはそのためです。
ケースNo | 題名 | 概要概要 |
1 | スキルシートでいったい何が分かるのか | スキルシート上は十分な経験を持つEさんが生産性が上げられずにプロジェクトを去ることに |
2 | エンジニアのやる気は報酬だけじゃ維持できない | 業界の構造的にユーザーの支払う「SEへの報酬」は必ずしも技術者個々への評価とはならない。なので、技術者も顧客もある程度はその構造を斟酌して開発を行う必要がある |
3 | エンジニアにとっての本当の「顧客」は誰?! | エンドユーザーとベンダの双方に利益をもたらさねばならないプロジェクトマネージャの難しさ |
4 | すごい技術者はすごいマネージャになれるか? | 技術者の視点でマネジメントを行うと危険な落とし穴がいくつもある。特に見積もりとWBSはコミュニケーションロスを見逃し、自分基準で作成して「厳しく」なる傾向にある |
5 | 良い顧客が良いITプロジェクトを作る | 顧客がITガバナンスを維持していると技術者の評価や修正するアーキテクチャ・フレームワークなどで正しいジャッジができる。そのことはプロジェクトに大きく貢献する |
その結果おのおのの事例には一見して共通性はありませんが、少しずつ分類し整理していくと幾つかの「要素」(ファクター)が見えてきます。一般的にプロジェクトマネジメントの最大要素としてQCDが語られるわけですが、全く別のプロジェクトにかかわる「人」という視点で見ていくとまた違う切り口が見えてきます。
今回目標としていたのは、これらのファクターを整理分析することで「指針」として提供し、プロジェクトの成功法則を「人」という視点でえることでした。これらをまとめることでITプロジェクトという森をあるく地図を作成しようとしたのです。
ところが、プロジェクトというものは、残念ながら過去の事例から検討したわずかな要素をマニュアル化すれば成功するというような甘いものではありません。例えば、プロジェクトにかかわる要素を無作為に1時間ほど抽出してみます。
いかがでしょう? 納期や見積もり、アーキテクチャやインフラ、メンバーのスキルなどすぐに思いつくものから、はてはチーム内の人間関係から風邪の流行リスクまで。わずか小1時間ほどでこれほど大量の要素が存在します。これらは相互に関係し合うので、その完全な組み合わせは無限になります。
よって、すべての要素を監視したり、要素が発生させるイベントをマニュアル化したり予見することは不可能です。つまり、プロジェクトマネジメントはあまりにも広大な森の中で、「すべてのステークホルダーの満足」という1本の「黄金のリンゴがなる木」を探すようなものです。
このあまりにも多い要素は、これから自分が分け入る新プロジェクトという森が常に「前人未踏の暗黒の森」であることも意味しています。すべてのプロジェクトはユニークです。一見同じようなプロジェクトでも顧客の担当者は変わり、あるいは競合他社のシステムの機能は変わり、あるいは顧客企業の経営状況が変わり……。楽勝だと思って分け入った、「前回と同じ」プロジェクトが再び深い森に迷い込んだ事例は枚挙にいとまがありません。
では、どうしたらよいのでしょう? せっかく過去のプロジェクトを比較検討してみたもののそれを学べば次のプロジェクトはうまくいくというわけではなさそうです。残念ながら、あまりにも多いITプロジェクトの要素は「このマニュアル通りにすればすべてのプロジェクトが成功する」という精度の地図を作ることを不可能にしています。
実はその答えは意外に簡単です。マニュアル化しきれないのであれば、その複雑さに効率よく対処できる「開発チーム」を作ればよいのです。つまり、今回過去の事例から無理に完全な地図を作るのではなく「地図が不完全であっても森を効率良くあるいて木を見つけることのできるチームを作る」ための方法であれば可能なのです。
では、良いチームの作り方とは何でしょう? 高額な単金(単位時間あたりで開発者に支払われる金額)のSEを集めればいいのでしょうか? 作業経歴の長いベテランを集めればいいのでしょうか? ところが、実際にCase1はその方法でうまく行っていません。すでに、従来のスキルシートと単金を天秤に載せる方法では良いチームは作れないということははっきりしています。
スキルシートには作業年数しか書かれていません。単金はそもそも能力を平準化して図る方法がない状況では何の参考にもなりません。「安いから」と入れたメンバーが「勉強前提」で、かえって足を引っ張る光景にもよく出くわします。それどころか、時には高いメンバーがすでにアーキテクチャについてこれずやはり足を引っ張るケースも多く見ます。
ですので、従来の単金とスキルシートだけで開発チームを作ることはすでに多くの失敗を招いているアンチパターンなのです。
そこで、最終回ではいよいよ「開発チームを作る」という原点に立ち返って、従来の「作り方」ではない「作り方」を過去の事例から得られるものを元に作りだしていきます。そこで、次のページでは過去の事例から「ファクター」を取り出し、よいチームを作る上での「指標」を検討していきます。つまり、以下のページの5つの「ファクター」を取り出しそれをチームを作る……、人を選び、ロールを与えるための指標とすれば「よいチーム」が作れることになります。
では、5つのケースから「ファクター」を取り出してみましょう。
Copyright © ITmedia, Inc. All Rights Reserved.