本章では、前章までの議論を踏まえて、ソフトウェアの開発プロジェクトの事例を対象 として、開発プロセスにおける工程間分業ならびに協業の編成が、開発のパフォーマンス、
特にコストや品質、納期、メンバー構成、プロジェクト運営といった点について、どのよ うに関係しているのかを明らかにする。ここでは、こうした開発パフォーマンスの観点か ら、成功あるいは失敗であったと評価される開発事例を取り上げ、そこでの工程間分業お よび協業の編成がプロジェクトの成否に対してどのように影響を及ぼしたのか、に焦点を 当て分析を行う。
(1) 調査概要
① 調査目的・意義
ここまでの議論を通じて、日本のカスタムソフトウェア開発の多くが、Waterfall Model に基づいて要件定義や設計などの上流工程からプログラム作成やテストなどの下流工程へ と進む開発手法を取り入れてきたことが確認された。一方で、この管理を中心とし、工程 を分割して開発を進める方法には、変更に弱い側面や下流工程の製造工場化に伴う作業者 の知的活動の阻害などさまざまな問題があることも明らかにされた。
ソフトウェアを開発するには、効率性を高めるという観点から作業や工程を分割すると ともに、高度な専門性を持った技術者がチームを組んで取り組む必要が存在し、そのため、
分業と同時に工程間の協業や連携を如何に編成するかという点が重要となるが、これまで の研究ではそういった開発現場の分業と協業の実態まで踏み込んだ研究は少ない。
そこで、本研究では、実際のソフトウェア開発の現場において、開発作業やその工程を どのように分割され、さらにそれら工程間の連携がどのように編成されているのか、その 事例を分析する。ソフトウェア開発プロジェクトの工程や知的部分の結合において、特に 問題が発生した事例を対象とし、そうした問題発生の背景にどのような要因があり、さら に開発の現場においてそうした問題に対し開発従事者がどのように対応しようとしたのか を分析する。
② 分析の枠組み
ソフトウェアの開発は、開発プロジェクトによってその方法も大きく異なる。開発の規 模や進行方法、ユーザー企業との関係など、条件が異なればその方法も変わってくる。
ソフトウェア開発の個々のプロジェクトの目的やゴールはさまざまであり、似たような 要求仕様であっても、プロジェクトによってその要求の背景や制約条件、メンバーが異な っている。そのため、類似プロジェクトは存在しても、まったく同じプロジェクトは存在 せず、個々の要求を分析してもその関係性が正しいとは限らない（須賀・牧野・加藤, 2014）。
一般に、製品開発や生産の現場の競争力を測る標準的な指標としてQCD（品質、コスト、
納期）が存在するが（藤本, 2003）、ソフトウェア開発についてもその評価について QCD を基準とすることが多い（浦塚, 2011; 神原, 2012; 長田, 2013; 桑原, 2016）。
そこで本研究で、分析の対象とする 3 つの事例にそれぞれについて、a)プロジェクト概 要と目的、b)メンバーとその分業構成、c)開発の特徴を検討するとともに、またプロジェ クトの結果について、単なる成否にとどまらず、d)品質（Quality）、e)コスト（Cost）、f)納 期（Delivery）ならびに、g)人的・技術的サポート（Service）の4点を分析の焦点に置くこ とにより、プロジェクトとしていかなる帰結を迎えたのかを分析する。その上で、h)プロ ジェクトの事後的評価、についても検討を加える。特に、プロジェクトに対する社内での 評価や顧客からの評価、その後の発注状況への影響、さらにソフトウェア開発プロセスに おける知的活動がどのように展開されたのかに焦点を当て、プロジェクトとしてどのよう な結果、成果が導き出されたのかを分析し、そうした結果、成果をもたらすに至った要因 を明らかにする（表 8-1）。
表 8-1 開発事例の分析のフレームワーク（焦点）
プロジェクトの特徴
a) プロジェクト概要と目的 b) メンバーとその分業構成 c) 開発の特徴
プロジェクト結果の分析
d) 品質（Quality）
e) コスト（Cost）
f) 納期（Delivery）
g) 人的・技術的サポート（Service） h) プロジェクトの事後的評価
③ 対象の選定
本研究では、ソフトウェアの開発プロジェクト事例として3つの事例を選定した。
いずれの事例も、開発プロジェクトとして完遂されたものである。しかしながら、その 成否という点では必ずしもすべてが成功した事例ではない。分析の焦点となる QCD とい った開発パフォーマンスの個別の評価点については、成功と評価されるものもあれば、失 敗と評価せざるを得ないプロジェクトも存在する。
こうした事例を選定した背景には、北米など海外のソフトウェア開発では途中で開発プ
ロジェクト自体を中止してしまうこともあるが、日本のソフトウェア開発ではそのプロジ ェクトが QCD のすべてを十分に満たせなくても最後まで完遂させることが多いという事 情がある133。また、リスクがあっても受託会社は開発を請け負うことも多く、顧客との継 続的な取引関係の維持という点ではコストの面で赤字になろうとも、それが必ずしも失敗 プロジェクトといえない場合もある。
例えば、一度開発したソフトウェアはその開発企業が続けて保守作業や改善に向けた次 期プロジェクトを受注することが多く、そうした同じ顧客からの継続した開発案件の獲得 のために採算ラインぎりぎりで受注する場合がある。また、技術的に難しくかなりのコス トが見込まれるものの、多くのユーザー企業が発注先の企業を選定する際にそれまでの開 発実績を重視することから、そういった開発実績や経験を得るために受注することもある。
本研究で取り上げる事例企業に限らず、ソフトウェアの開発は一企業の中でも多くのプ ロジェクトが稼働しており、それらプロジェクトによって開発プロセスも大きく異なる（東 京大学社会科学研究所, 1989）134。特に、開発プロセスは企業や各種関係部署、プロジェク トのリーダーの考え方に少なからず左右され、さらに開発の規模や難易度、メンバーの熟 練度などにも強く影響される。そのため、各開発プロジェクトのプロセスの実態やそこで の問題を知るためには、プロジェクト・リーダーやメンバーに対する聞き取りやプロジェ クト報告書などの書面による調査により、各プロジェクトを精査していく必要がある。
しかしながらその一方で、このようなソフトウェア開発プロジェクトの多様な性質から、
その実態を反映するような定量的調査を通じてその実態に迫るデータを収集することは難 しい。さらにほとんどの企業は、守秘義務や顧客企業との関係を考慮することから、プロ ジェクトの詳細まで公開することはほとんどないため、しばしばインタビューによる調査 自体も困難を伴う。
こうした調査に伴う困難について、中尾（2009）は、ユーザー企業やITベンダーがソフ トウェア開発に失敗した場合でもその事故原因を公表しないことを指摘している。さらに 中尾は、たとえソフトウェアの開発が失敗したとしても、自社の損失に結びつくようなそ の事実自体が企業より公表されることは少なく、公表されたとしてもその詳細まで明かさ
133 日経コンピュータ（2008）が実施した8,800社（有効回答数814社）へのソフトウェア 開発の調査によると、QCDをすべて満たしたプロジェクトは31.1%であり、残りのプロジ ェクトは何かしらの問題を抱えていることが指摘されている。ただし、日経コンピュータ の調査によると、ソフトウェア開発のプロジェクトの成功や失敗をどこで判断するかとい った明確な定義が存在しないことを指摘しており、QCDをすべて満たせなかった場合、完 全な成功ではないもののそれがすなわちソフトウェア開発プロジェクトが失敗したわけで はないといえる。
134 古い調査であるが、東京大学社会科学研究所（1989）によると、71.5%の企業がプロジ ェクトチーム方式をとっており、企業の部・課による開発方式は24.5%だという。さらに、
技術者は幾つものプロジェクトチームに参加することも多く、そのうえプロジェクトによ って担当する工程も異なることが多いことを指摘している。
れるような事例はほとんど存在せず、そのために正確な事例が存在しないと述べている。
当然ながら、これまで述べてきたようなソフトウェア開発の失敗要因に関する先行研究は 数多くあるが、その多くも守秘義務によりその公開や内容に制限がかけられていることが 多い。こうした調査上の問題から、本研究でも、各事例の分析にあたって企業や個人が特 定できないよう処理が施されるとともに、対象企業において調査、開示可能な範囲での分 析とならざるを得なかった。
本研究が検討する事例は、プロジェクトの規模が50人月未満の中小規模のものを対象と している。これは、独立行政法人情報処理推進機構編（2014）の調査結果にあるとおり、
ソフトウェア開発は小規模化しつつあり、特に10人月未満の開発が5割以上を占めている ことが明らかとなっており、さらに今後もその傾向が増すことが考えられるからである。
ただし、10人月未満の開発になると、1人から3人程度のメンバーで構成されることが多 く、人数も極端に少ないことから工程ごとに作業の分割を行うのではなく、全工程を協働 でこなすようなこと多い。このため、本研究では、10人月より少し規模の大きい、20人月 から30人月程度の開発事例も含めた50人月未満の開発規模のプロジェクトを対象として いる。
④ 事例に関する調査の方法
対象となる事例は、国内中規模のITベンダーのA 社の開発プロジェクトであり、ユー ザー企業による内製ではなく、すべてITベンダーであるA社が担当することとなった開 発プロジェクトとなる。
事例の調査方法として、プロジェクトの開始報告書、および終了報告書による書面調査 を中心に行った。また、実際に開発に関わったA社のプロジェクト・リーダーやメンバー に対し、質問票をもとに聞き取りを行った。
調査時期は、2015年から2016年にかけて行っており、対象となるプロジェクトは、2012 年から2015年にかけて遂行されたものである。
前述の対象の選定でも述べたように、A社においても守秘義務契約や顧客企業との関係 からプロジェクトの詳細までを明らかにすることができなかった。各事例の分析にあたっ ては、開発費用等の数値は非公開とし、また対象となるプロジェクトやその正確な実施時 期、参画したメンバー、企業を特定できないよう処理を施すとともに、対象企業において 調査、開示可能な範囲で分析を行っている。
⑤ 事例の概要
事例の概要は、次の表に示されるとおりである（表 8-2）。
本事例のソフトウェア開発プロジェクトの受託企業であるA社は、1960年代に創業した 独立系のソフトウェア開発会社であり、従業員規模は約300人、売上高は27.3億円（2015