開発工程を別々に担当してはいけない

古典的なウォータフォールモデルでは、ソフトウェア開発を要求仕様分析、概要設計、詳細設計、実装(コーディング)、内部テスト、統合テスト、運用、保守みたいな工程にわけ、通常は各工程を別々の人が担当するというような方法がよくおこなわれている。

特に、要求仕様の分析、概要設計などは上流工程などとよばれていて、詳細設計、実装とは別の人ないしは組織が担当する。実装とかテストは下流工程などとよばれている。

よくあるパターンとしては元請けが上流工程を、下請け、孫請けが実装やテストなどを担当し、人月単価も下流の方が安い。

ウォーターフォールモデルでは各工程毎に成果物(仕様書や各種ドキュメント、プログラム)が大量に生産される。各フェーズ毎に定義された成果物がそろってから次のフェーズに移行するというのが建前なので、各フェーズでのドキュメントはどうしても冗長になりがちである。

一度固定した文書は次のフェーズで変更するとなると、手戻り工数が莫大になってしまうので、通常は、前工程で決めたことは、後工程で変更はしない。後工程で変更しないという前提で文書を作るので、いろいろ長期間にわたって検討などをするのであるが、実装してみないとわからない事などもいっぱいあるので、なかなかそうは上手くいかない。

実装してみて、できたものは最終ユーザからみると使えないものでも、仕様書に明記されていたものをその通りつくっている限り実装者(製造)の責任ではない。

大量な文書を作るし、各フェーズのレビューの工数も重いので開発スピードは遅くなりがちで、当初予定していた利用環境やユーザの要求というのも時間とともに変化するので、実装が終了した時点では仕様そのものが陳腐化するという事もすくなくない。ひらたく言うと、一生懸命つくっていたのに使えないものができてしまったということである。

ユーザアプリ開発、SI(System Integration)の現場では、おおかれすくなかれ上記のようなパターンがあって、それに元請け、下請けという産業構図がはめこまれていて、元請けが大手ベンダー、下請け、孫請けが中小ベンダーという風になっていたりする。大手がゼネコンの立場になって、多くの下請け、孫請けを使って大規模システムを構築する場合、いろいろな意味あいを含めてITゼネコンといったりする。

工程を別々に担当することによって、数々の問題が発生する。

通常は上流の方が単価が高く、下流の方が単価が安いので、だれも下流をやりたがらない。下流工程は結果として単価の安い経験の浅いエンジニアをつけることになる。工程は通常、組織によってわぎりにされているので、下流工程の作業をやる人がノウハウをためて上流作業をになうという機会がない。元請けはいつまでたっても元請けだし、孫請けはいつまでたっても孫請けである。孫請けの経営者も経営者で、単価は安くても、とりあえず人の分だけ売上があがるので、大手にぶらさがっていれば食いっぱぐれない。そのため経営の緊張感はない。利益率は低いがどうにか食っていける。というような構造がある。

下流にいけばいくほど単価のたたきあいになるので経験豊富なベテランを配置することが難しくなり、若年層エンジニアを使いすてることにならざるをえない。いわゆる35歳停年説である。

業界全体としてエンジニアを使い捨てにすることには百害あって一利もない。にもかかわらず、抜本的な対策、方策がとられているようには見えない。

なぜなんだろう。

わたしには、この工程によって作業を分担するという方法が諸悪の根源であるように思えてならない。小さい会社が何十人もエンジニアを集められないので元請けになれないという事情があるというのは百歩譲ってあるとしよう。大規模な開発をするため何社かで共同作業が必要だったとしよう。その場合の分担を工程ごとに輪切りにするのではなく、機能ごとに縦に切る事を提案したい。

つまり、ある機能について、一社ないしは一人が仕様の決定から設計、実装、内部テストまで担当するのである。キモは設計者と実装者は同一人物とするのである。これを分離しない。

なんでこんなことを言うかというと、実装と設計は不可分で、実装をしてみて初めて気がつくこと、設計をしてみて初めて気がつくことなどがあり、実際の設計と実装というのはいきつもどりつのプロセスである。このいきつもどりつがない限り、いい実装などはできはしない。設計と実装を分断している限り、しょぼい設計としょぼい実装にしかならない。初めから完璧な設計などはないのである。完璧な設計でない以上、しょぼい実装しかうまれてこないのである。

工程を分離するのは悪なのである。

工程を分離するために専門性が蓄積されない。より高度な実装を作成するインセンティブも発生しない。

『「渡された仕様書を実装するサラリーマンプログラマ」の悲哀』にあるのは工程を分離されたプロジェクトの悲哀であって、サラリーマンかどうかは無関係である。

わたしはソフトウェア工場というコンセプトそのものを否定するつもりは毛頭ない。工学的なアプローチによってより品質の高い(バグ密度の低い)ソフトウェアをより少ない工数で生産するということは可能であると思う。QC活動のような方法論ですら有効な場面は少なくないと思う。

しかしXPで実践されているようなベストプラクティスの多くは工程の分離ではなく設計と実装の渾然一体となったプロセスである。

日本のソフトウェア開発の現場の国際競争力のなさというのがあるとしたら、ITゼネコンをよしとした、上流下流工程を是認したソフトウェア生産方法論にあるのではないか。そこに構造的な問題があるのではないかと思うのである。人月で工数をはかる事がやりだまにあがっているが、根本的な問題は、工程を分離して、下請けにだすというソフトウェア生産方法であると思う。

ちなみに、米国のソフトウェア製造業では(マイクロソフトもオラクルも)、設計する人がコードも書くのである。それが一般的な姿である。わたしの場合(DEC時代もオラクルの時)も、そうであった。

プログラマの仕事はプログラムを読むことである/ユメのチカラ
http://blog.miraclelinux.com/yume/2007/10/post_9db7.html

Comments

[投稿： M]

私の職場では、ある機能について一人が仕様の決定から設計、実装、内部テストまで担当するということが実践されています。
その結果、設計書やテスト仕様書の完成度が低く、その一人が抜けた瞬間に、その機能の保守や改善をすることができなり困っています。
工程によって作業を分担する方法は、強制的に仕様書の完成度を高める効果があり、分離自体は優れたやり方だと思います。

ですので、工程によって作業を分担するという方法が悪いやり方とは思えません。
諸悪の根源は、その分担が固定化されていることだと思います。
設計をやっている人はいつも設計。実装をやっている人はいつも実装。
これでは実装をしてみないと分からないような設計問題は、いつまでも分からないままでしょう。

そこで、区切りの良いところで設計担当と実装担当を入れ替えてしまうというのはどうでしょうか。
技術交流もできますし、互いの不満も理解できるようになるでしょう。そんな悪いやり方でもないと思います。

[投稿： RK]

> 仕様書の完成度を高める

仕様書の完成度を高めると、成果物の完成度が高まる、あるいは引き継ぎがうまくいく、とも言えないのが、オープンソースが実証しているところではないでしょうか。
さまざまな方法があるんだと思います。

[投稿： Kanasansoft]

typo見つけたました。
35歳停年説＝＞35歳定年説

[投稿： Kanasansoft]

私も、工程の分離はソフトウェアの完成度の低下を招くだけでなく、スキルの低下を招くと考えています。
国内だけを見ていれば気付かないため、誰も声を大きくしないのでしょう。
下請けの立場からすれば、一刻もはやく現状打破を願うと思いますが、元請けは工程が分離されている方が儲けが大きいため、業界内から変革を起こすのは難しいのではないでしょうか。
工程分割の結果、開発費・開発期間の増加、品質の低下を起こし、一番影響を被るのはユーザです。
他力本願な意見ですが、業界の現況を理解しているユーザから、アクションを起こしてもらえないかと考えてしまいます。

Mさんのご意見、なるほどと思います。
確かにドキュメントの品質を招いています。
しかし、ドキュメントの品質向上を工程分離に求めるのは酷ではないでしょうか。
ドキュメントの品質向上のため、ソフトウェアの品質を落とすということになり、本末転倒になってしまいます。
#申し訳ありませんが、私自身、この問題に対する解を持ちあわせてはいません。
あと、Mさんの「設計担当と実装担当を入れ替え」という案、一部賛成です。
賛成しかねる点は、子の方法だと「自分が設計したものを他人が実装」か「他人が設計したものを自分が実装」するしかないからです。
本当に必要な経験は、「ひとつのソフトウェアを設計から実装まで一通り行なう事」ではないでしょうか。

[投稿： M]

RKさん
オープンソースは、スキルの高い方が参加されていると思いますので、普通の会社が行うようなユーザアプリ開発とは別の話だと思います。
普通の開発者は、コードだけでは作成者の意図を理解できないのはもちろん、処理内容を理解することも困難でしょう。私も、そのうちの一人です。
そのような人たちが大勢集まってものを作るときには、仕様書の精度は重要なものだと思います。

Kanasansoftさん
私は、工程分離が品質を落としていることに同意できません。
私は、「工程毎に分担を変えた開発」と「機能ごとに分担を変えた開発」の両方を経験したことがあります。(規模はあまり大きくなく、10人程度です。)
この両方の開発のうち、最終的なアウトプットの品質が良かったのも、仕様書の精度が良かったのも、前者でした。
前者の開発を行ったとき、私は設計工程を担当しました。
その時は、他人に後を任せることができるレベルの設計になっているか、また仕様書は他の人が見ても十分に分かりやすい内容になっているか、夜も昼も悩み、実装担当と真剣な議論を重ね、設計の無駄をそぎ落とし、仕様書は工夫を重ねて分かりやすくなるよう努力しました。
結果、仕様書は比較的良いものになり、最終的なアウトプットも良いものになりました。
後者の開発を行ったときは、後でなんとでもなると考えましたし、真剣に議論してくれる相手もいませんでしたので、
設計はそれなりに適当なものとなりました。
結果、仕様書も最終的なアウトプットもいまいちなものになってしまいました。

つまり、私の経験では工程分離の方が上手くいってしまったわけです。
この経験があるので、工程分離がまずいと言われてもそれは違うような気がしてなりません。
工程間で真剣で建設的な話ができれば、工程分離は十分に上手く働く仕組みだと思います。

また、経験については、「ひとつのソフトウェアを設計から実装まで一通り行なう事」は確かに重要だと思います。
このような経験をすると、設計の重要さも、実装の重要さも、良く分かるからです。
ですが実務としては工程分離した方が機能的だと思います。
新人は設計から実装までやってみるとか、そんな小細工で体験させてみるのも良いかもしれません。

長文失礼しました。

[投稿： M]

料理の話に例えると分かり易いような気がしてきましたので例えてみます。

自分で作ったものを自分で食べるというのも重要な経験だと思いますが、
自分で作ったものを他人に食べて貰ったり、またその逆のことをした方が、互いに刺激があってより美味しいものを作れるようになると思いますが、どうでしょうか。

分かり難いか・・・

[投稿： ほるほる]

工程を分離すると、工程ごとに別の会社に頼むようになる。

親会社は簡単で儲かる工程を。難しくて儲からない工程は子会社や下請けに丸投げ。

こうして、元請けの会社は上流工程ばかりを行い、下請けは下流工程ばかりを行うようになっていきます。

当然ながら、元請けは下請けのことを考えたりはしません。つーか、下請けが元請けに対して抗議したり意見したりするのを許すはずがない。

こうして、上流工程の質はどんどん下がり、それに比例して下請けの質も下がっていってしまうというのが、現代日本の構造。

そもそも、現在の色々と便利なツールを使えるソフトウェア開発では工程の分離自体が非効率で無意味なものになっています。

[投稿： 中年SE]

昔ミラクルリナックスさんに仕事を依頼したことで、文字通り命拾いさせていただいたSEです。
その節は本当にありがとうございました。
しかし、同時に「あぁ、このミラクルの人達と私は同じIT業界に住んでいると思っていたけど、本当は違う世界に住んでいるんだな」とも思いました。

多分、吉岡様の想定する開発はパッケージやOSといった他のお客様でも再利用可能な製品の開発だと思います。

しかし、日本の多くのプログラマーが従事している開発は、再販できない社内向けのシステム開発です。

よろしければ、その辺を鑑みたコメントいただければと思います。

[投稿： 半日庵]

上流工程、下流工程という言葉がいけないような気がします。上流の方が偉い、難しいという変な印象を与えてしまうような気がするからです。実際に力がある元請が上流をやりたがります。で上手くいかないと実装のせいにする。実際は上流工程に問題があって実装がトラブルと考えるべきなんですが、まあ、力関係からそのような工学的な正しい見方をすることは稀でしょうね。

XPはなぜか日本で人気があるそうです。ある人はその理由をプログラマ中心主義だからと言っていました。それほど、日本のプログラマは虐げられているのでしょうね。私の経験から言いますと、設計も実装も上質でないといいプログラムは出来ません。しかし、実際は実装の重要さは認識されていない場合が多いような気がします。プログラマの工賃が安いのもその一例だと思います。

私は工程の分担が問題ではなくて、それぞれの重要度の評価が間違っているのが問題だと思います。そして、その為に全ての工程を経験したことがない人が設計を行っていることが品質を下げている主因な気がします。経験の順序としては下流工程から上流工程へ順に経験していくことが必要だと思います。まあ、いきなり全部を経験しても力はつくと思います（この場合失敗のリスクが大きくなると思います）が、上流だけの経験では決して力はつかないと思っています。

[投稿： hyoshiok]

多くのコメント、トラックバック、そしてブックマークありがとうございます。

こう言っては身も蓋もないわけですが、工程を分離する方式でうまく行く場合もあるし、うまくいかない場合もある。

わたしの主張する設計と実装の不可分とするという方法は、もちろんわたしの経験の範囲での議論ですが、それについても、適用可能な前提、あるいは適用が難しい分野というのは間違いなくあると思います。

わたしが知りたいのは、どのような条件の時に、工程分離型方式あるいは工程混合型方式がより有利なのか。より品質が高く、かつコストも安いのか。そのような条件を明らかにすることです。

例えば、Mさんの主張する工程を分離しないと設計がおろそかになるという傾向はあるかもしれませんが、それは設計および実装をピアレビューしていない、あるいは設計の品質を向上するプロセスがないということが根本的な問題かなと思うわけです。わたしは設計をいいかげんにしていいという主張はしていませんし、設計の重要性についても理解しているつもりです。設計の品質を向上させるために実装を経験し、その両方をスパイラルで行なうことで品質が向上するという主張です。そこには、間違いなくピアレビューやユニットテスト、リグレッションテストなどの仕組み、仕掛けが必要かと思います。

一方で工程分離によって設計品質を固定するという方式も、それが有効な適用範囲もあると思います。例えば、要求仕様が固定的でほとんど変化がない分野はそのようなウォータフォールモデルでも実装可能だと思います。原子炉の制御システムなんてのは厳密に工程を管理し、一つ一つのフェーズで厳密に正確性を担保しながら開発してほしいと思います。わたしはそのような制御システムを開発した経験はないので想像で言っていますが。

設計者と実装者を仮に分離したとしても、同じ社内で机がとなりで、設計と実装をいったりきたりできるフィードバックのプロセスが取れるのであれば実質的には一人で設計実装をやっている方式とそれほどかわりはないとは思います。一方で、それを分離して別々の会社、組織でやるという場合は、コミュニケーションのコストの増大、フィードバック回数の減少など摩擦係数が増えて不利になるような感じがします。

そのメリット、デメリット、それがどのような条件の時にどう変わるのか、そこらへんを理解したいなあと思うのです。

中年SEさんのおっしゃるとおりわたしの経験はソフトウェア製品開発の現場に偏っています。いわゆるユーザー顧客のSI案件での経験はないです。わたしの経験とその前提をより明示化することで、今回の主張の適用範囲が明確になるかなあと思います。

ブログのうれしい事は、自分の経験をもとに記したことに多くの人たちのフィードバックを得てそれを洗練できることですね。今回もそれを痛感しました。

コメント、トラックバック、ブックマークを頂いた皆様どうもありがとうございました。

[投稿： tarosuke]

私はソフトウェア工場というコンセプトそのものを否定します。そもそも設計と実装がを分けられるという幻想の根源がこの「ソフトウェア工場」にあるからです。いわば諸悪の根源といえるでしょう。

そもそもソフトウェア開発は、工場で製品を作るというより工場そのものの設計に近いと思います。ソフトウェア開発で工場を設計し、ビルドで工場を組み立て、実行で工場を稼働させて実行結果という製品を得るという風に。

[投稿： km]

本来、全部の工程を１人で担当することと、ドキュメントの質が低くなるのは、直接の関係はないと思います。

その組織でのレビューによる修正などが適切に行われず、やりっぱなしになってるとか、時間をもらえなくて、とりあえずコードだけ先行とか、どうせ引継ぎがいないとか、文書かけない人とか背景があるはず。

工程分離もそれ自身のせいで効率が悪いわけではなくて、設計の人が実装しらないとか、実装の人が設計の意図を読めないとか
単価が安いために相当スキルが低かったりとかで、それが試験時にやっと見つかって後処理に追われるとかの要因がある。

XPとか、一人で全工程の担当してみると、視野が広くなって、個人の成長を促進し、ひいては効率が上がることになるだろうということで、工程分離する場合よりも急激にに効率が上がるという訳じゃないと思う。

個人の成長により、ゆくゆくは効率を上げるだろうということだと、中小の会社だと、離職率も高いだろうから、お金的にも人的もそんな長期的話は無理と言われそう。

[投稿：]

工程を分けることに問題があるのでなくて、同時に責任が分離されることに問題があるのではないの？
設計の不備による実装の失敗は設計者(会社）の責任というシステムが確立された場合でも工程を分けることに関する問題は変わらない？