ITプロジェクト

ITプロジェクトは、「ソフトウェア開発」を実行するという特徴を持ったプロジェクトです。ソフトウェア開発という特殊なスキルを持った人を決まった予算内でできるだけ多く集め、納期に向かって、全速で邁進していくためのプロジェクトです。

■ITプロジェクトの特徴

ITプロジェクトの案件は、混乱、混沌から始まります。成果物がソフトウェアという目に見えないものであり、プロジェクトの目的でさえ、ITエンジニアから見ると決まっていないに等しい状態でプロジェクトの立ち上げが行われます。

ITの専門知識がないと妥当な目的や目標を明確化することが困難です。しかし、素人の思い付きで、目的があいまいなまま、納期だけが決められることが横行しています。
ITプロジェクトは、事業の課題を解決したり、売上が拡大させる新しいビジネスモデルを考案するような新規事業のプロジェクトとは違い、単に「ソフトウェア開発」という「作業」をするためのものでしかないと認識されているからです。

そのような状態でありながら、ITエンジニアは、無理矢理にでもプロジェクトを計画し、実行していきます。

ITプロジェクトの構造は、原則、通常のプロジェクトと同じですが、ITプロジェクトの特徴を踏まえながら、IT業界特有の内部構造があります。

■開発体制

プロジェクトに参画する要員は、社内要員と社外要員に分けられます。

社内要員は、ソフトウェア開発のできる「社員」です。社内要員だけで体制を組めるのであれば、ソフトウェアを「内製化」することができます。ソフトウェア開発にかかる工数が減るわけではありませんが、社員に支払う賃金などの固定費だけでつくることができます。いわゆる「出金を減らす」ことができるのです。さらに、ソフトウェアを変更する場合でも、素早く対応可能です。

しかし、実際には、ソフトウェア開発で「内製化」ができる会社は、圧倒的に少数です。ほとんどは、ソフトウェア開発のプロであるアウトソース先のITベンダーを社外要員（いわゆる外注）として調達します。

社内要員と社外要員の比率は、一般的に、１対９、あるいは多くても３対７ぐらいの割合だでしょう。社内要員は社外要員に発注する側であり、プロジェクトマネージャやプロジェクトリーダなど責任のあるポジションには、社内要員が割り当てられます。

仕様を決める要件定義は上流と呼ばれ、それに続く工程は下流と呼ばれます。仕様を決定する責任と権限があるのは社内要員であるため、SEは社内要員でまかなうことが多くなります。それ以外の担当は、社外要員を割り当てます。

社外要員は１社だけとは限らず、開発するソフトウェアが複数の技術を使うのであれば、おのおの得意な技術分野を持つ委託先に発注することになります。たとえば、GUIのスキル、サーバのスキル、データベースのスキルなど、持てるパフォーマンスを発揮できるように分担します。会社毎に、リーダを選定し、その配下にメンバーを配置します。
ただし、コアとなるべき技術を社内で保有しているのであれば、他部門の社内要員を割り当てることもあります。

システムテストは、システムテストだけに特化したITベンダーがあり、開発を実施する社外要員とは別に、専任でテストを実施するだけの社外要員を割り当てます。リーダを選定し、その配下にテスタを配置します。

開発委託先の契約は、主に請負契約となることが多く、作業もおのおのの会社にて実施します。システムテストも請負契約が多いですが、テストを実施する社内の作業場所に出向いて実施します。そのため、場合によっては、委任契約で作業した時間だけ支払う形態をとることが多くなります。

こうして、下図の例ようにプロジェクトの体制が決まっていきます。PM/PL、SE部隊は社内要員でまかない、３つの技術分野にまたがるソフトウェア開発であればA社、B社、C社に開発を委託し、システムテストをD社に委託します。

PM/PL、SE部隊は、すべて一人で兼務するケースも多いです。これは、「一人PL」といわれます。社内要員は、実際に設計やプログラミングなどの手を動かすことはないため、悪い言い方をすれば「その他の雑務」すべてをやって当然だろうと見なされるからです。しかし、このような押し付けが、要件を詰め切れないまま、委託先への「丸投げ」が繰り返され、失敗を生む原因ともなっています。

ソフトウェア開発は、前述したように「人海戦術」です。先決なのは、体制をつくれる頭数を揃えるため、人を搔き集めることです。

ソフトウェア開発の現場では、エンジニアが常に不足しています。人の取り合いが、慢性化していて、優秀なエンジニアであれば空いているほうが稀です。そのため、質よりも量という考えにならざるを得ません。

ソフトウェア開発の大部分を占める社外要員を主体としたプロジェクトでは、いかに優秀なITベンダーを探し、選定できるかがプロジェクトの成功の8割を占めるとも言えます。プロジェクトに必要な経験をもったキーマンがいるITベンダーを探し当て、そのキーマンをアサインできるかがプロジェクトの命運を握ることになります。

一方、エンジニアのレベルは、ピン・キリであり、実際にやってみないと本当の実力がわからないのが現状です。日本のIT関連のエンジニアは、コンピュータサイエンスなどを含めた理工学的なファンダメンタルが乏しい人もかなり多いです。能力にも偏りがあり、指示がないと何もできないエンジニアもかなり存在します。
感覚としては、エース級が一割、平均レベルが５割、残りの４割は平均未満の能力のエンジニアです。ソフトウェア開発の知識は、「習うより、慣れろ」の典型であり、独学によって大きく伸ばすことができます。学歴より、ロジックを考えるために、理論的な文章に馴れ親しんきたかどうかがポイントとなります。

しかし、ITベンダー毎に固定化された人月単価は、このような成長意欲を萎えさせます。できる人に仕事が集中する一方で賃金は変わりません。優秀になるほど、自分の仕事だけでなく、遅れている他の人の仕事までふられる有様です。このような労働環境では、自発的に能力を伸そうとするモチベーションが継続しません。賃金が変わらなければ、平均的なレベルでいいと考えるようになるからです。

このような状況を踏まえると、平均的なレベルのエンジニアの多いITベンダーを見つることが現実的な答えになります。そして、その中にいるエース級のエンジニアを割り当てもらうように調整します。

■開発スケジュール

プロジェクト全体のスケジュールをマスタスケジュールといいます。マスタスケジュールは、ガントチャートで示され、縦軸に作業、工程、担当を書き入れ、作業毎に開始と終了の日付を決め、横軸に線を引いていきます。

たとえば、「仕様を決める」作業の工程は要件定義、担当は社内要員のSEのA、1月6日から開始し、2月14日までで終了するように記載します。同様に、他の作業も書き入れ、ソフトウェアが完成するまでの日程を決めていきます。そして、完成までの間に、マイルストーン（目標）となるイベントを書き入れておきます。

マスタスケジュールでは、最終的な納期の日付、そして、マイルストーンとなる日付が重要です。これらの日付に合わせるため、作業の日程を決める必要があります。原則、ソフトウェア開発のマスタスケジュールは、納期から逆算します。明確なゴールが示され、そこに向かってどう線を引くか、これに誰もが頭を悩ませることになります。

マスタスケジュールの他に、委託先が担当するブロック毎の個別スケジュールを作成します。委託先の個別スケジュールは、マスタスケジュールのクリティカルパスとなります。したがって、マスタスケジュールは、委託先の個別スケジュールで決まることになります。

個別スケジュールは、委託先毎に工程毎の作業を明確化し、作成してもらいます。ただし、マスタケージュールとの整合性が合わないと、いくら個別スケジュールの内容が正しいものであっても意味がありません。納期が決まっているのだから、個別スケジュールを調整し、マスタスケジュールに当て込まないといけません。マスタスケジュールを完成させる手間は、この委託先の出してきた個別スケジュールを調整することに費やされます。

委託先は、工数は決めても、工期についてはなかなか明確にしないことが多いものです。委託先も個別スケジュールを決めるには、細心の注意を払うことになるるからです。

個別スケジュールを決めるのは、委託先のリーダです。作業をどう分解するか、その期間をどうするか、委託先のリーダの力量が発揮される仕事です。ただし、限界もあって、保有している要員だけでは、個別スケジュールを組めないこともあります。そのような場合、委託先から他の委託先への作業を委託することも許容します。「下請分業構造」とは、このような時に機能する仕組みです。

このような個別スケジュールを調整しても、どうしても最終工程であるシステムテストに、吸収しきれない期間のしわ寄せがきます。
幸いなことに、システムテストは、唯一、人海戦術がそのまま期間短縮に直結する工程です。テスト項目の数と期間が決まれば、テスタ一人当たりの消化できるテスト項目数から必要なテスタの数を算出できます。そのテスタ数さえ、その期間に投入できれば完了させることができます。

悩ましいのは、バグなどによる再テストが発生することです。バグがゼロということはあり得ないので、システムテストには、再テストの期間を入れておく必要があります。このような一連のテストを「サイクル」と呼び、再テストが発生するものとして複数サイクルのスケジュールを組みます。

逆に言えば、システムテストまでの間、ソフトウェアの品質を確保しておかないと、システムテストでは吸収しきれず、スケジュールが超過してしまいます。

■開発工数

損益計算書（PL）は、固定費、変動費、利益で構成されます。そのうち、ソフトウェア開発の費用は、固定費と変動費に分けられて計上されます。

固定費は、PM/PLおよびSEなどの社員に給与社内要員の人件費であり、社内で消費されます。変動費は、社外要員の委託費用と機材などの研究材料費です。

ソフトウェア開発で大きな割合を占めるのは、変動費の委託費用です。委託費用は、「工数（人月）×人月単価」で計算されます。

人月単価は、通常、工程毎に異なります。設計から単体テストまでが高く、結合テストやシステムテストについては、多少低くなります。テストは、作業的要素が強くなるため、単純労働的な色合いが濃くなるためです。

工数は、期間（月数）と人数で掛け合わせて算出されますが、工程毎に工数を算出し、それに工程毎の人月単価をかけ、積算します。人月単価は、ITベンダー毎に会社として固定されており、プロジェクト毎に代わることはありません。変えられるのは、工数（人月）だけです。

委託元にとって、委託費用は、そのまま委託先に支払われる「出金」になります。そのため、経理部門から、その額について、厳しいチェックが入ることも珍しくありません。そんな背景もあり、見積もりの時点で、厳しく精査されることになります。

見積もりに記された作業内容を、細かく把握するため、委託先にヒアリングします。作業に曖昧な点があれば明確にし、認識違いがあれば調整していきます。これを丹念にやることによって、無駄な工数をそぎ落としていきます。

ITベンダーからは、リスクを見て「バッファ」をとってあるという言い方をされることがあります。確かに見積もり時点では決まっていない部分が多々あり、技術的な調査が不十分な点があるため、あらかじめ工数が盛られてしまうことはある程度は仕方がありません。ただし、その「バッファ」が妥当なのか、判断がいります。

たとえば、担当者のスキルや経験が不足しているがために、リスク見合いをのせられていることがあります。これはITベンダーがとるべきリスクであり、人月単価が決まっているにもかかわらず、教育費用をリスクとして負わせられる理由はありません。

さらに、設計書のページ数、ソースコードのステップ数など、数字を出してもらうようにします。その上で、工程毎に一人月当たりに生産性（ページ数/人月、ステップ数/人月）を明確化していきます。

数字が見えれば、生産性が高いか、低いか判断できるようになります。低ければ、何か理由があるはずです。その理由を聞いて、それは納得できるものか、そうでなければ対策を提案し、生産性を少しでもあげてもらうようにします。

このような数字として積極的に出してくるITベンダーは皆無です。その理由は、ソフトウェア開発の工数は、正確な「相場」というものがなく、ほとんど「言い値」で決まってしまうからです。担当しているエンジニアが3人月と言えば、「そう言うなら、そうなんだろう」と決まってしまいます。これは、たとえ、超一流のITベンダーであっても同様で、人月単価が高い分、さらにズレが大きくなります。その結果、予算が超過し、2倍、3倍になってしまうこともあり得ます。

ソフトウェア開発プロジェクトにとって、予算は何よりも重要です。予算が枯渇したら、ガソリンの切れた車のように、プロジェクトはその日から停止します。

そのため、予算の消費には、細心の注意を払う必要があります。委託先への支払いが計画と少しでも違えば、それはプロジェクトにとって、死活問題となる。まだ大丈夫だと、ボーとしていると、あっという間に予算が底をついてしまいます。

プロジェクトでは、想定外のことが頻発します。バグ、仕様間違い、納期短縮、作業遅延など、その度に、工数が増えていきます。これらの唯一の解決策が“金”であり、これらが発生する前提で、余分な費用（マージン）を意識して予算を作っておく必要があります。

残念ながら、このようなリスク見合いを理解して予算を承認してくれる優しい組織は存在しないでしょう。そうなると、言い方は悪いが、予算をある程度水増しして、組んでおくことしか方法はありません。発生する可能性のあるダミーの開発や作業を計上します。あるいは、逆に、委託先へ依頼する開発の費用を、多めに計上しておきます。

ソフトウェア開発の鍵は、技術よりも金です。いくら優れたソフトウェアを作ろうと思っても、金がなければどうしようもないのです。

委託先費用を下げる一方で、必要十分な予算を確保しておくことは最重要課題です。それができなければ、予算を削る方法を考えるしかありません。それは、要件を削ることです。

要件には、精査もされないまま、ただリストアップされているものが含まれています。要件に、優先度がつけられていれば、低い優先度の要件を削るか、先送りします。そうでなければ、精査したうえで、不要な要件を削っていきます。

最初に割り当てられた予算内にきっちり収めることがプロジェクトの使命の一つです。原則、プロジェクトの予算が途中で増えることはありません。それでも、工程が進む毎に、再見積もりをし、必要ならば追加の予算を確保する努力はすべきです。

ソフトウェア開発に限ったことではありませんが、多くの場合、リカバリのしようがない状態になってから、人を投入するために高額な予算を確保しようとします。しかし、そうなってからでは手遅れです。

ソフトウェア開発の古典に「人月の神話」という本がありますが、このような状態を揶揄し、こう書かれています。

「狼人間をうつ銀の弾丸はない」

狼人間を出現させないためには、こまめに費用を調達し、金にからむ問題を早期に潰していくことしか手段がありません。

■開発プロセス

プロジェクトを支えるのは、開発プロセスです。ソフトウェア開発の主体となる企業や組織が、この開発プロセスを決めます。開発プロセスとは、ソフトウェア開発で実施すべき「工程」とその作業内容を決めたルールや手順のことです。ソフトウェアをつくるためには、作業を工程と呼ばれる単位に分割します。それらを組み合わせて、完成させます。

プロジェクトは、開発プロセスから逸脱することなく作業を進めていきます。プロジェクトは多種多用で同じものはありません。差異があるにせよ、共通の開発プロセスさえに従ってさえいれば、QCDを確保できるはずだという考え方が根底にあります。

しかし、汎用的過ぎる開発プロセスでは、すべてのプロジェクトをうまく推進することは難しいケースも出てきます。その場合、プロジェクトの特殊性を勘案して、開発プロセスを変更し、独自の開発プロセスにカスタマイズすることも必要になります。

工程を決めるには、「開発手法」を決める必要があります。工程のアレンジは、採用する開発手法によって決められます。
開発手法には、大きく分けて「ウォータフォール」、「インクリメンタル」の２つに分けられます。

・ウォータフォール

川の水が、上流から下流に流れるのと同じように、工程を一列に並べたものです。ソフトウェアの工程とは、以下ががあり、「ウォータフォール」では、順番通りに実施しなければなりません。

　１　要件定義（UI）
　２　概略設計/システム設計（SS）
　３　詳細設計/プログラム設計（PS）　　
　４　プログラミング（PG）
　５　単体テスト（MT）
　６　結合テスト（IT）
　７　システムテスト（ST）

段階を踏んで、工程毎にアウトプットを出し、成果を積みあげながら、最終的にソフトウェアを完成させます。

一般的な仕事で言い換えると、要件定義は「企画」、概略設計は「デザイン」、詳細設計・プログラミング・単体テスト・結合テストは「製造」、システムテストは「評価」に相当します。

たとえば、10カ月の期間で中規模のソフトウェア開発を行う場合、各工程の期間と人数の配分は図Xのようなイメージとなります。要件定義から概略設計までは少数精鋭で短い期間で行い、詳細設計から結合テストまでは、人を増やし、長い期間で実施されます。そして、システムテストでは、期間を限定される代わりに人をかけて行う。下図の場合、工数は以下となります。

　　64.5人月=1.5か月×2人＋1.5か月×3人＋5か月×9人＋2カ月×6人

原則として、工程には、前へ進むことはできるが、後戻りすることはありません。これは、各工程のアウトプットが抜け漏れなく完璧であることを保証しなければならないということを意味します。

一見、当たり前のように思われるかもしれませんが、これが、現場で働くエンジニアにとって、大きな足かせになります。後の工程で間違いが見つかっても、前の工程に戻れないからです。根本的な対策ではありませんが、仕方なく小手先で辻褄を合わせるか、長時間労働でリカバリを図るしか方法がありません。

一方、管理はしやすいです。工程さえ進めていけば、計画通りに終わるはずだからです。
現実は、誰もが欠陥を承知の上で「ウォータフォール」を使っています。納期を決めるには、スケジュールをコミットできなければなりません。「ウォータフォール」の工程が動かないという点が、ビジネスにおいて非常によくマッチします。

・インクリメンタル

「ウォータフォール」の欠点を改善した開発手法もあります。「インクメンタル」（繰り返し型）と呼ばれる手法です。この手法は、工程を何度も繰り返すことで、ソフトウェアをつくっていきます。１～６までの工程を、複数回、繰り返すことになります。どこからどこまでの工程を繰り返すのかは、開発するソフトウェアの状況によって変わります。

工程を繰り返す理由は、ポジティブな理由を言えば、フィードバックループを回すことで、途中の設計ミスや漏れなど早期に検出し、手戻りを抑制できます。一方、ネガティブな理由を言えば、最初は一部しか要件が決められない場合でも、とにかく開発を始めることができます。

しかし、「インクリメンタル」は、納期までに完成するという保証がないというデメリットがあります。納期がきても、半製品のままかもしれない。「インクリメンタル」でのソフトウェア開発は、エンジニアにとってはやり易いが、管理する側にもスキルが求められます。

「インクリメンタル」のデメリットを極力抑え、メリットを享受するには、下図のように、先に要件定義と概略設計まで完成させることで要件とアーキテクチャを固めた後、詳細設計から結合テストまでの「製造」の工程を「インクリメンタル」とします。工程を繰り返す回数も数回だけに限定します。このようにすれば、期間と工数を確保でき、品質も確保できます。

ITエンジニアであれば、「ウォータフォール」のデメリットを実体験で痛感していますが、その反面、「ウォータフォール」での成功体験も数多くあるのも事実です。ただし、その成功体験のすべては、リスクの低いソフトウェア開発だけで積み重ねられたものです。たとえば、既存のシステムやソフトウェアの部分的な変更のためのソフトウェア開発などがそれに相当します。

リスクの高いゼロからソフトウェアを新規開発する場合などは、「ウォータフォール」は全くと言っていいほど機能しません。「インクリメンタル」のメリットである「やりながら考える」という前提が、やってみないとわからないことばかりの新規開発には、非常にマッチします。

ただし、原則として、開発手法は、仕事の常識さえあれば誰でもプロジェクトを管理できる「ウォータフォール」が選ばれます。「ウォータフォール」は、組織などの利害関係者にも、とても説明しやすく、仕組みが単純だからです。
それは、プロジェクトがまだ始まっていないプロジェクト組成の段階ほど、受け入れられやすく、理路整然と「ウォータフォール」の工程が列挙されたスケジュールを一目見れば、問題などないと確信さえ持つことができます。
それは、残念ながら「だまし絵」のようなものです。「ウォータフォール」の「計画変更」と「遅れ」を許さないという絶対ルールの中では、そのだまし絵は、いずれ踏み絵となり、メンバーを苦しめることになります。

現実的な答えとしては、「ウォータフォール」をアレンジすることです。たとえば、リスクの高いソフトウェアを新規開発する場合、「ウォータフォール」を横に並べ、２つのフェーズに分けてすすめていきます。最初のフェーズでは、主眼はR&D（調査・研究）として、一部機能だけ動くプロトタイプを作成し、課題を洗い出し、解決するフェーズとします。そして、それに続くフェーズで完成させます。可能な限り、前段のフェーズでやれることをやりきることが、後段のフェーズを粛々とすすめるための条件となります。

「ウォータフォール」で、スケジュールを変え（計画を変更する）、その後でリカバリをすることは本当に困難です。そのため、逆に言えば、できるだけ計画を変えなくてすむようなスケジュールを考えていかざるを得ません。