このエントリーをはてなブックマークに追加LINEで送る

3.1. 利害の対立

ハッピィ・エンジニアリング表紙

 ユーザ企業と元請けの両社に利益をもたらすWin-Winの関係は理想として唱えられている。しかし、ユーザ企業と元請け、マネージャとSE・プログラマはさまざまな場面で利害が対立する。古来、個人との間や企業との間で適切な利益配分という行為がなされるのは、ごく短期間にすぎない。Win-Winは単なるキレイごとであり、その実態は一方が他方のおこぼれを頂戴しているだけだったり、寄生しているだけだったり、搾取しているだけだったりする。特にユーザ企業と元請け企業は、一見すれば第三者からは公平な利益配分のように見えるが、当事者同士はどちらも「自分は割の合わない立場に置かれている」と思っているのが現実の姿である。

 

 特に大きな利害の対立として語られるのが、仕様変更に関わる開発工数の増大である。ユーザ企業によるシステムに対する要求の変更は、好むと好まざるとに関わらず開発現場では随時行われる。しかもそれらは、SEが書いた被害者意識いっぱいのプロジェクト管理本に書かれているような、あるいは一部のSIベンダが強く主張する要件定義工学本に書かれているような、「発注側の検討不足によるミス」ばかりではない。

 

 むしろビジネス環境の変化への対応という外部要因による、予測不能な、また回避不能な問題が多い。例えば、競合他社が新たなサービスを打ち出してきた場合に、同業他社の経営陣が、いっせいにシステム部門に迅速な追随を命じるようなケースである。

 

 ビジネスの視点で考えれば、システム戦略は個々のプロジェクトに優先する。さらに経営戦略はシステム戦略に優先する。単純な思いつきで仕様に変更を加えていくことは論外だが、経営戦略やビジネスプロセスを変更する必要性が生じた場合には、システムの変更を行うのは当然のことである。

 

 さて、個々のシステム開発プロジェクトに限定して考えたときには、この仕様変更に対する要求がさまざまな問題を生むことになる。一般的に、以下の2つの問題が発生する。

 

 第一の問題は、開発対象システムの正確性・一貫性・整合性の確保である。ソフトウェア開発は、ほかの製造業と同じように生産体制が分業化されている。ひとりがすべての工程に関わるよりも、分業化により作業範囲を限定することで専門性が生まれ、全体の生産性は向上する。その半面で、分業と同時に品質を維持するためのプロセスやマネジメントの重要性が大幅に高まることも、ほかの製造業となんら変わらない真理である。しかし、システムは工業製品とは異なり、単なる部品の組み上げ作業として成立できず、現状においては生産ライン化が不可能なことが、ほかの製造業との大きな違いである。

 

 例えば詳細設計まで終了しプログラミングを行っていた場合の要件変更に対しては、要件仕様書・基本設計書・詳細設計書などのプログラミング工程の上位のドキュメントに仕様変更を反映する必要がある。そして、その実装を確認するには、単体テスト仕様・結合テスト仕様・システムテスト仕様・運用テスト仕様を修正し、プログラムロジックから業務要件までの整合性を確認しなければならない。つまり、ひとつの変更がすべての工程に影響を与えるのである。

 

 第二の問題は、変更に対する合意である。日本におけるシステム開発の取引実態は、欧米流の契約主義という建前と、日本流の合意形成主義(お互いに含むところはあっても、話し合いを通じて最終的な「落としどころ」を見いだす方式)という本音の二重構造が存在する。

 

 商取引がグローバルになってきたために錯覚しがちであるが、ビジネスの進め方は、それぞれの文化・商慣習に大きく依存し、実に多種多様な形態がある。日本において、相手の立場を相互に理解するということは、日本流の合意形成主義にとってなくてはならないことである。

 

 経営陣によるビジネス変化に対するシステムの対応要求は、すなわち経営戦略に直結したシステム戦略である。「経営戦略上必須の仕様変更」による経営陣のシステム部門に対する圧力は、「単なる見落としミスのリカバリとしての仕様変更」によるユーザ企業から元請けへの発注側の圧力よりはるかに厳しいものである。

 

 欧米では、このような避け難い仕様変更に対するリスクを、契約により分担するが、日本では、なれ合いの中で「落としどころ」を見いだしている。しかし、日本流の合意形成主義は、システム開発に限らず、往々にして強者の無理が通り、結果として「押しつけ」を生む。

 

 発注者経営層→発注者ユーザ部門→発注者システム部門→元請け(プロジェクトマネージャなど)→一次下請け(プロジェクトリーダなど)→二次下請け以降(プログラマなど)……という力の強弱がある以上、どう美辞麗句を並べても、各レベルで行われていることは、「押しつけ」にすぎない。「仕様変更への対応」というゴールには「ビジネス」という、より高い次元の正当性があるが、そこに至る合意形成プロセスには力関係による「押しつけ」が存在している。その押しつけが開発者への「しわ寄せ」という形になってしまっている。そして、開発者は、この「押しつけ」に付随する「ごまかし」と、「ごまかし」がもたらす「うさん臭さ」を強く実感している。

 

 プロジェクトマネージャは、日本的な合意形成プロセスが生む「押しつけ」を緩和するうえで重要な役割を持つ。その役割とは、なぜ決められていた要件や仕様に変更が生じるのか、変更の発生理由と目的や効果について開発チームに十分に説明をし、変更に対応することの動機づけを行うことである。

 

 動機づけを行わない場合、プログラミング工程に入って残業が続いているプログラマは、「忙しい時期だというのに、きちんと決めるべきことを決めていないから、こんな結果になるんだ」という意識しか持つことができないからである。その結果、次々と発生する変更要求に対して、顧客にサービスするという意識は失われ、開発チーム全体のモラルの低下を招き、品質に大きく影響するということを、プロジェクトマネージャは肝に銘じておかなければならない。また、同様にプログラマは、変更要求は顧客から発生していること、プロジェクトマネージャはプロジェクトの成果物を期日までに顧客に納品する責任があること、納品した成果物が顧客から検収を受けなければ、その対価が支払われないこと、納品後1年間はSIベンダが瑕疵担保責任を担っていることなどを理解しておかなければならない。

 

 立場が大きく異なり、利害が対立する中で、プロジェクトを円滑に遂行するためには、お互いの置かれている立場や持っている役割を理解し、その中で現実的な妥協案を打ち出すことが重要だ。相手の立場を理解せずして、自らの立場を主張したところで、結果として満足の得られるシステムが完成するわけがない。プロジェクトのゴールを明確にしたうえで、それに向かっていくこと、相手の立場を理解した上で、お互いが最善の解を求めることこそが大切なのである。

 

 本章では、プロジェクトに登場するさまざまな利害関係者それぞれの立場、本来あるべき役割を明確にし、その問題点と解決策を提示する。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

3.1. 利害の対立 ハッピィ・エンジニアリング関連ページ

3.2. 発注側
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
3.3. 開発側
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング