![]() ![]() |
![]() |
|
![]() |
||
![]() |
2024-07-16
多重下請けでは構造的にいいソフトウェアが作れない
多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。
多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。
そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。
※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとんどでした。
しかしながら、ソフトウェアというのは実装してみないとわからないことが多く、実装前に完成の形を予測するのは難しいものです。そのため、適切にソフトウェアを構築したいのであれば、事前に作成された設計に完全に従うことは求めず、実装にともなって変更が加わっていく前提にする必要があります。もし設計にたいして忠実に実装できて価値があるソフトウェアになることを保証したいのであれば、実装相当の検証作業が必要になるはずです。
けれども、上で書いたように設計というのは契約の一部であり作業指示です。そうなると、そのとおり忠実に作ることが前提であり、修正は例外という扱いになり「もし変更が必要になれば差し戻す」という感じになります。変更するには上位存在の承認が必要ということもあったりします。
その結果、多少の不備であればいびつな実装になろうとも従ったほうがマシとなり、大きな変更の必要性に気づいたとしてもそれを差し戻していたら作業開始が遅れるのでそのままにするということも起きかねません。
不備であれば差し戻すとしても、よりよいアイデアが浮かんだからといって、わざわざ差し戻すインセンティブはありません。ソフトウェアのアイデアは実装時に浮かびがちにもかかわらず。
また設計側でも、実装しながらの試行錯誤をしないのであれば実装確度の高い前例踏襲で無難なものになりがちで、やることにあわせた特別な設計は行われにくくなると思います。
実装者に創造的能力を期待せず裁量をもたせず責任をもたせず設計通りにやることを求めるということであれば、「PG」という職種は取り換え可能なコーダーということになりますね。
その結果、価値のあるソフトウェアを開発するというモチベーションは失われ、よいソフトウェアを作ることではなく、契約どおり仕様書どおり設計どおりプロジェクトを完了することが目的化します。
それは、「「実装者が設計を勝手に変えてはいけない」というのはダメでは」のようなことを書いたときに「勝手に変えるのはダメ」という反応がいくつかあったものが、それではよいソフトウェアにならないというものではなく、トラブルなく契約を遂行してビジネスをまわすためにダメという指摘であったことからも伺えます。
その設計では使えないソフトウェアになることがわかったとしても、実装者には責任がなく、むしろそれを指摘して設計やりなおしになると実装開始が遅れるものの納期は変わらなかったりするので、価値をうまないソフトウェアをそのままつくるほうがビジネス的に正しいという、モラルハザードのようなものも発生しがちです。
このように、多重下請け構造ではプロセス自体がソフトウェアの性質を反映してよいものを作れるようになっていないために、よりよくビジネスをまわすことがよりよいソフトウェアにつながっておらず、むしろちゃんとまわそうとすると いいソフトウェアを求めてはいけないビジネス形態になっていて、よりよいものを作ることにインセンティブが働かず、構造的にいいソフトウェアが作れなくなってると思います。
継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣
作者:David Farley
日経BP
Amazon
nowokay 2024-07-16 09:19 読者になる
もっと読む
コメントを書く
今こそ見直したい多重下請け構造—DXで内製化シフトは実現するか
※追記 SIerでの大半を占めていると思われる多重下請けの構造の話を書きました
多重下請けでは構造的にいいソフトウェアが作れない - きしだのHatena
多重下請けでは構造的にいいソフトウェアが作れない
taediumの日記
読者になる
現場のためのソフトウェア開発プロセス - たかのり日記
読者になる
設計と実装の狭間で。
読者になる
「2024年開設ブログ」に入りましょう
はてなブログには、同じ話題でつながる「グループ」があります。まずはこちらの「2024年開設ブログ」に入りましょう。同時期に始めたブログとつながることができます。
▼ ▶
2013
2013 / 12
▼ ▶
2012
2012 / 12
▼ ▶
2011
2011 / 12
2011 / 8
2011 / 7
2011 / 6
2011 / 3
2011 / 1
▼ ▶
2010
2010 / 8
2010 / 7
2010 / 6
2010 / 5
2010 / 3
2010 / 2
▼ ▶
2009
2009 / 12
2009 / 9
2009 / 7
2009 / 6
2009 / 4
2009 / 3
2009 / 2
▼ ▶
2008
2008 / 12
2008 / 10
2008 / 8
2008 / 4
2008 / 3
2008 / 2
2008 / 1
▼ ▶
2007
2007 / 12
2007 / 11
2007 / 10
2007 / 7
2007 / 6
2007 / 5
2007 / 4
2007 / 3
2007 / 2
2007 / 1
▼ ▶
2006
2006 / 12
2006 / 11
2006 / 10
2006 / 9
2006 / 8
2006 / 7
2006 / 6
2006 / 5
2006 / 4
2006 / 3
2006 / 2
2006 / 1
▼ ▶
2005
2005 / 12
2005 / 11
2005 / 10
2005 / 9
2005 / 8
2005 / 7
2005 / 6
2005 / 5
2005 / 4
2005 / 3
2005 / 2
2005 / 1
▼ ▶
2004
2004 / 12
2004 / 11
2004 / 10
2004 / 9
2004 / 8
2004 / 7
月の生活 | よなよなエール公式ウェブサイト「よなよなの里」
読者になる
海外POSシステム開発エンジニア募集 by 株式会社Abby
現在、大規模チェーンレストラン向けのレストラン店舗運営システムを開発しています。展開先はアメリカ、オーストラリア、台湾、マレーシア、...
www.wantedly.com
Unityでスマホ、Switchのゲーム開発をしたいエンジニアを募集! by 株式会社Abby
今回は、・Unityを使用したNintendo Switch向けのゲーム開発・Unityを使用したスマートフォン向けのゲーム開発...
www.wantedly.com
2016-09-20
Seasar Conference Final
今週の土曜、9/24にSeasar Conference Finalを行います。
10年前に始まったSeasar Conferenceもいよいよ今度でFinalです。
お申し込みはこちら。
http://seasar.connpass.com/event/38679/
Seasar Projectの面白かったところって、開発方法論が盛り上がったところだと思うんですよ。
マーチンファウラーをはじめとして、著名な人たちのほとんどが「ドメインモデル推し」の中、僕は、「ステートレスなサービス + DTO推し」だったからね。S2Daoは、このために作ったようなものです。
あの開発方法論の議論に、かなりの人が参加したり、自分で考えたりしたでしょう。それが、面白かったところです。みんなが自分の事として考えたから。そんな難しい話ではないし、自分のプロジェクトに即いかせる話だしね。
オブジェクト指向ナンチャラとかDDDとか、素晴らしいものなんだけど、自分のプロジェクトで生かそうとするとそう簡単にはいかないからね。
Seasar2の開発が終了した事で、Seasar Projectに関わった多くの人たちの多くの時間が無駄にされたと、思っている人もいるようだけど、僕はそうは思わない。Seasar Projectに関わった事で、プログラマとしての能力や知名度をあげた人とって多い訳だから、それを否定する必要はないと思っています。
今度のSeasar Conferenceでは、「Seasar Projectのふりかえり」と「SXSW攻略法」の二つの話をします。
「Seasar Projectのふりかえり」では、昔話をしてもしょうがないので、いくつかのプロジェクトを「なぜ始めたのか」「うまくいったところとでその理由」「失敗したところとその理由」を話す事で、これから、新しくプロジェクトを立ち上げる人向けに、少しでも役に立つ話が出来ればと思います。
「SXSW攻略法」では、2016年のSXSWで、RealeaseItというアワードでファイナリストに残る事が出来たので、ファイナリストに残るためのこつ、そしてアワードをとれなかった理由。また、SXSWでは、ブースも出したので、ブースを出すときのポイントを話したいと思います。
Seasar Conference Finalお申し込みはこちらです。
http://seasar.connpass.com/event/38679/