下記の記事で、Vモデルが後工程から前工程に戻ることがない、という思想に根差していること、Vモデルにいう要件定義からUATまでの工程のあらましとそれぞれの工程でよくある問題などについてお話をして参りました。
エンタープライズシステム(大企業の業務管理のためのシステム)の構築に関わっていく場合、Vモデルというワークフローに従って…
今回の記事では、実際のシステム構築プロジェクトで問題になる納期・工数(≒予算)・人員の制約の中でVモデルに従った開発を進めた時に生じる色々な問題を、具体的に説明させて頂こうと思います。
※参考までに、Vモデルの概念図を再掲します。
システム構築プロジェクトの制約条件―納期・予算・人員
それでは、システム構築プロジェクトでの制約条件について、それぞれ見ていきたいと思います。
プロジェクトの制約条件「納期」
１つ目の制約条件は、納期です。
システム構築プロジェクトは、多くの場合、発注者の示した要件に従って、システム構築を終えて各種テストを終了することで、対価が支払われることになります。
前回の記事で説明したとおり、そのシステムの構築の納期は要件定義プロセス終了時点で決められてしまいます。
これが１つ目の制約条件です。
【無料あり】エンジニアが解説！プログラミングスクールおすすめ５選プロジェクトの制約条件「予算」
２つ目の制約条件は、予算です。
ところで、システム構築プロジェクトにおける予算の大きな部分は人件費によって占められています。
システム業界では、人件費は(その人員の能力に応じた1か月の稼働に対する単価)×(人員の数)の合算として計算されます。
システム業界では、労働力を「人月(人員1人を1か月働かせることによって得られる労働力)」という単位で計算し、その積み上げた労働力を「工数」といいます。
(ちなみに、これは建築業界と同じ考え方なんですね。)
もちろん、ハードウェアの購入費等物品費もかかりますけれども、およそシステム業界では予算≒工数と考えてよいと思います。
プロジェクトの制約条件「人員」
３つ目の制約条件として、それほど一般的な考え方ではないかもしれませんが「人員」という要素を加えて考えるべきであると私は考えています。
というのも、プログラマやシステムエンジニア、ITコンサルタント等にはそれぞれ得意・不得意のバラツキや出来不出来の程度の差が非常に大きく、実務的には同じ1人月でも、Aさんの1人月の働きとBさんの1人月の働きの程度が数倍あるいはそれ以上異なると考えなければいけません。
すると、リソースとしてのキーマンとなる人を押さえられるかどうかは、工数というリソースとはまた別の要素として考えられるべきだと思っています。
往々このキーマンを押さえられるのか、働きの悪い人員を押し付けられるかは、そのプロジェクト首脳部の人脈や政治力の程度によることが多いです。
制約条件によって発生する問題
一度決まった納期は、よほどのことがない限り後ろ倒しはできません。
予算については、前回の記事で触れたようにコンティンジェンシーという予備費を確保してあるプロジェクトの場合は、それを切り崩しながら既存人員の残業を増やして工数を増やしていくのですが、コンティンジェンシーには限りがありますし、長時間労働の強度が上がっていくにつれて、同じ人員の時間当たりの労働生産性もどんどん落ちていきます。
そして、新しい人員を確保しようとしても、窮状を救ってくれるようなスター技術者は大概の場合予算にも納期にも余裕のある成績の良いプロジェクトにおさえられていることが多いために、現実的はなかなか引っ張ってこられません。
人員を新しく獲得しようとすると、大概は並かそれ以下のメンバがあてがわれることが多く、新規参画メンバーに対する教育の手間がかかるためにかえってシステム構築自体の作業にさらなる遅延を来すことすらあります。
そんな中で、プロジェクトを定められた納期・予算内で遂行するために、プロジェクトマネージャーたちは血のにじむような努力をします。
そもそも、一説によれば、日本においてシステム構築プロジェクトが当初の予算・納期通りに終わるケースは、全体の10％ほどといわれています。
他方、現実的には受発注者の力関係に差があるため、一度契約を締結したのち、予算や納期の変更は非常に困難です。
そこで、見積もりを出せと言われた際に、プロジェクトマネージャーは、可能な限りのリスクを織り込んで長めの納期、多めの予算で見積もりを出します。
しかし、大概の場合は、売り上げ確保のために会社の上層部から見積もる納期の短縮、予算の圧縮を命じられて、これにプロジェクトマネージャーは従わざるを得ません。
そこでプロジェクトマネージャーは、業務の一部を切り分けて下請けのベンダーに委託して予算の圧縮を図ります。
すると元請けの収支には若干の余裕ができますが、下請けのシステムベンダーは元請けが発注者から受け取った予算よりさらに少ない予算しか与えられないのが普通なので、下請けのシステムベンダーの労働条件はより過酷なものになります。
そして低い賃金しか払えないシステムベンダーに勤める技術者の質も、決して高いものとは言えないことが普通です。
ある種の裏技として、システム構築ののちには当然にシステム運用が始まるわけですが、システム運用の契約はシステム構築の運用とは別になされることが多いために、形だけなんとかシステム構築を「終了」させて、残った不具合はシステム運用のフェーズで解消するようにクライアントと話をつけることもあります。
しかし、この場合、システム運用の契約でとれる予算はシステム構築が問題なく完了した前提で見積もられるので、大体の場合本来割り振られているシステム運用人員ではとても運用中のトラブルに対応しきれず、運用メンバーに過大な残業を強いるか、応援人員の調達を必要とします。
この時応援人員に対する予算をクライアントから取ることは実際問題として難しいために、その分の人件費は会社の損失になります。
Vモデル開発に潜む問題点―不具合は結合テストフェーズまでは顕在化しない
日本においては、普通基本設計書までをお客さんと直接会話するシステムエンジニアあるいはITコンサルタントが担当し、詳細設計書・製造(コーディング)・単体テストは担当するプログラマ一人で実施することが多いです。
当然、詳細設計書が完成した時には同レベル又はより上位のレベルのプログラマーによる検査(レビュー)が行われますし、製造・単体テスト(これは実務上、2工程セットで考えられていることが多いです)が終了した時には、やはり検査が行われます。
しかし、ドイツで提唱されているVモデルに忠実に従えば、詳細設計書作成、製造、単体テスト実施は別々の担当者によって行われなければなりません。
というのも、ある人は詳細設計し、コーディングしたソースを単体テストする際は、どうしても単体テスト実施時に「不具合はない」というバイアスが入りやすいからです。
本来、少なくとも詳細設計及びコーディングは同一の担当者が実施するにしても、単体テストは別のプログラマに実施させた方がいいように思いますが、小規模なプロジェクトや予算に余裕のないプロジェクトでは、そのような厚い人員配置ができないのが現実です。
すると、単体テストが終了し、結合テストが別の担当者によって実施された時に、初めて色々の不具合が見つかることになります。
この段階で不具合が見つかり始める理由は、詳細設計書作成から単体テストまでを同じ担当者が実施することだけでなく、結合テストの段階で、いわば小さなプログラムの部品であるモジュールとモジュールをつなぎ合わせて、一つの機能(エンドユーザーがつかう一つの画面、出力する一つのレポートなどを「機能」という単位で呼ぶことが一般的です)が基本設計書通りに動作するかを試すことになるので、モジュール同士がうまくかみ合わない、ということがこの段階にならないと発覚しない、ということもあります。
結合テストで不具合が見つかると、原因究明が行われ、もしコーディングのミスに起因するのであれば、もう一度単体テストがやり直しになります。
もし基本設計自体に問題があることが分かったら、もう一度基本設計書を修正して、詳細設計書も修正し、コーディングもやり直し、単体テストもやり直して再度結合テストを行い、その結合テストで問題の解消が解決された段階で不具合が解消されたことになります。
普通、この手の基本設計レベルのミスが雨後の筍のように次々見つかるために、基本設計からコーディングを経て結合テストに戻るループが幾度となく繰り返されることになります。
結合テストが進んできますと、そのような不具合がリストアップされて、同時並行で修正作業が進行していきますので、さながらアジャイル開発のような観を呈してきます。
Vモデル開発の不条理―総合テストやUATでエンドユーザーの不満が続発しやがて爆発…
プロジェクト開発手法の研究者によれば、そもそもエンドユーザーにとって、システムが出来上がる前に本当にそのシステムに望む要件を言語化することは不可能なのだそうです。
私も、実体験に則してそのように思います。
結局のところ、実際にシステムを使ってみて初めて気づくニーズというのがあるのです。
本来、知的労働のアウトプットには、そのような特徴が共通してあるように思います。知的労働は、知的労働者が依頼者よりもその専門分野については詳しいことが前提にあります。
そのため、往々知的労働者への依頼は漠然としており、それを知的労働者はかみ砕き、専門的な知見に照らして合理的にアウトプットを作り出し、依頼者はそれを妥当なものとして受け取って報酬を払うのが普通です。
医者に「病気を治してくれ」という患者が、「病気の直し方」や「治り具合」について文句を言うことは普通ありません。
弁護士に事案の処理を依頼して、裁判所に提出する書類や判決結果にケチをつける依頼者も、それほど多くはなく、もしいれば弁護士は躊躇なく辞任します。
しかし、どういうわけかシステムエンジニアの作成したアウトプットには、エンドユーザーから情け容赦ないクレームが飛び、それをシステムエンジニアは受け止めなければいけないというある種の社会的なコンセンサスがあります。
これはとどのつまりは、医者や弁護士に比べてシステムエンジニアの社会的地位が低いと考えられていることにあり、その主要な原因のうちの一つは、システム業界にとっての顧客である大企業において、システム管理部門がコスト部門として、営業部門やマーケティング部門よりも低い位置づけしか与えられていないことによると思います。
従って、総合テストやUATの結果不合格がユーザーから出たとしても、理論的にはこれを必ずしも不具合と考えるべきとはいえないでしょう。
とはいえ現実問題として、総合テストやUATで発注企業のシステム部門担当者やエンドユーザーから修正要求が飛んできますから、これに何らかのリアクションを返さなくてはいけません。
システム構築プロジェクトは多くの場合請負契約ですので、発注者が検収合格を出さなければ受注者であるシステム開発企業は支払いを受けられないのです。
(この点、例えば弁護士は判決結果にとても責任は持てませんから、委任契約を結びます。
しかも、途中で辞任しても丸々損にならないように、一定の着手金を請求します。)
総合テストやUATは、多くの場合結合テストと並行して行われます。
つまり、結合テスト合格となった機能から順に、総合テストやUATが行われていくのです。
したがって、不具合に対する修正やテストのタスクが山のように積み上がり、技術者の労働負荷が一番上がる時期になります。
総合テストやUATは、システムが全体として要件定義通りに使えるかどうかのテストですから、当然機能と機能をつなぎ合わせた時に生じた不具合の修正は、結合テストで発見された際の不具合よりも修正に多くの工数を要します。
また、これまでこの記事では一貫してソフトウェア設計についてしか触れてきませんでしたが、現実にはソフトウェア（コード）が動くためにはデータベースなどのミドルウェア、ネットワークやストレージとも噛み合って動作しなければなりません。
これがうまくいかないと、そもそもソフトウェアだけでなくハードウェアをも含めたシステムの作り全体を直さなくてはいけなくなってしまいます。
この段階になって出る不具合は、もはや当初計画の納期や予算ではとても対応できるものではないことが多いです。
(人をどんなに酷使しても、1日に24時間以上は働かせることはできません。)
そこで、後続の追加契約をどういう内容・条件で結んで、どうやってシステムをだましだまし運用し始めるか、という点がポイントになってきます。
すると、受発注者間の上層部ではすでに当初計画の納期後の契約の交渉を始めているわけですが、あくまでもマネジメントは一線のスタッフレベルに対しては当初納期の順守を厳命し、納期は決して変わらない旨脅し続けますので、スタッフは馬車馬のように働くことになります。
ただ、ある程度経験のある技術者は、納期遵守が現実的でないと分かった瞬間に、目立たないようにサボタージュを始めます。
納期遅れを上司や発注者から責められても、あまり気にしなくなりますし、躊躇なく病欠を取り始めます。
結局システムの不具合修正は自分たちしかできないわけですし、納期を守れないことを見越して上層部が交渉を始めていることは分かっていることなので、技術者たちはある意味本能的に身を守るために行動するのです。
逆にプロジェクトマネージャーからすると、技術者の間にこのような雰囲気が蔓延しては、もはや作業は全く進まなくなります。
このフェーズでは、大概の場合どのメンバーも疲労困憊しており、将来の昇進昇級をエサにしても、今後の不利益な取り扱いの可能性をちらつかせて脅しても、あまり技術者側は反応しなくなります。
ただ、レアケースではありますが、プロジェクト開始から良好な人間関係が築けているプロジェクトは、この一番苦しいフェーズを乗り越えるために、火事場の馬鹿力を発揮して難局を乗り越えることがあります。
その意味で、システム構築プロジェクトにおいて、プロジェクト内の人間関係の良し悪しは、プロジェクトの成否の決定的な要因の一つといえます。
Vモデルについてのまとめ
さて、この記事では、Vモデルに基づくシステム構築が、実務において実際にどのように進められ、どのようなトラブルがあり、またどのような問題点や留意点があるのかについて、具体的にご説明をしました。
この記事を読んで、システム業界入りを考え直す人もいるかと思いますが、システム業界にはシステム業界なりの面白さもあればやりがいもありますので、それはまた別の機会にお伝えできればと思います。
最後までお読みいただき、ありがとうございました。