「納品のない受託開発」についての雑感

 こんなツイートをしていたら、

これについては、自分の考えをブログにかくか。 顧問弁護士や顧問税理士のような「顧問プログラマ」という仕事と働きかた http://t.co/d04FRlSC9y

— 松下正嗣 (@masatsugumatsus) April 30, 2014

本が出てしまったので、遅ればせながら、書く。

「納品」をなくせばうまくいく ソフトウェア業界の“常識"を変えるビジネスモデル

ソフトウェアの価値の源泉はソースコードとプログラマ

倉貫さんのブログは以前から読んでいたのだけど、根底にあるのは

「ソフトウェア開発において、価値を生む出すのは、ソースコードであり、それを生み出す 有能なプロフェッショナルとしてのプログラマである。」

という洞察だと思う。

これは、『組織パターン』の「中央の生産者」パターンとしても指摘されている。

組織パターン (Object Oriented SELECTION)

結局仕様書があったとしても、その文脈や顧客のビジョン、仕様の抜け漏れも含めて、ソースコードを生み出すプログラマが理解していなければ良いソースは生み出せない。

「プログラミングは設計である。」

良いソースがなければ、結局、どんなドキュメントもゴミ。

プログラマにとっては、大抵のドキュメントは意味のないものにうつる。

不明確である場合も多いし、不正確だったりもする。最近の言語では、かなり文章のように書けるものを内部設計書、外部設計書、要件定義書に同じようなことを書く必要があり、無駄に感じる。

ビジネス価値を生み出すのが、ソースであり、プログラマであるなら、それを現実のビジネスで費用対効果とプログラマの報酬に直結させる仕組みが、開発プロセスであり、ビジネスモデルなんだろう。

ソニックガーデンのモデルは、プログラマの生産性（工数に対するビジネス価値）を最大にするように設計されているように思う。

その一つの側面が「納品のない受託開発」であり、絞り込んだ技術であり、アジャイルなプロセスなんだろう。

プログラマがなにやらコンサルタントのスキルも持たなければならない、ということで「フルスタックエンジニア」問題と同じような印象を受ける人もいるかもしれないけど、よいコーディングをする、というのは、よい問題解決者であるのとイコールだと思う。

そもそも、コンピュータ黎明期のアメリカは、プログラマが要件を聞いて、書いてたっぽい。下記の本に、プログラマが顧客より立場が上になる例が書かれている。

ワインバーグのシステム行動法 ソフトウェア文化を創る (3)

どちらかというと、ソニックガーデンのプログラマに必要なのは、アプリケーションエンジニアとしてのスキルで、基盤系の知識はクラウドを活用して、職人を抱えなくてもよいようにしている気がする。

既存開発会社の市場を食うか。

現在のソニックガーデンさんのモデルは既存のSI企業と競合しないかもしれないけど、

「ソフトウェア開発において、価値を生む出すのは、ソースコードであり、それを生み出す 有能なプロフェッショナルとしてのプログラマである。」

という洞察はソフトウェアの製品特性に依存するものでない。ここを出発点に、既存のSIの開発について、自分なりに考えてみたい。

• システム特性（社内システム）
• 納品と瑕疵担保責任
• 規模の不経済

システム特性（社内システム）

本の中では、新規事業やコンシューマ向けシステムと相性がいい、とあるが、パッケージ導入した方がいいような基幹システムは別として、大抵の社内システムも、社内ユーザーが顧客みたいなもの。アジャイルに、継続的に改善していく方がフィットするのってかなりある。

ただ、企業内システムで、他システム連携や移行がある場合、受け入れ試験を実施するのが、かなり顧客として負担になる部分もあるね。まあ、それも継続契約の中で解消していけばいい話。顧客としては、そこらへんはPM専門のコンサルタントを使ってもいいかもしれない。

やはり今でも、社内システムに関しては、パブリッククラウドがNGっていう企業も多い。中々難しいけど、最近はDockerやら使えば、環境起因の無駄なコスト増はある程度防げるかも。プログラマからしてみれば、クラウド環境での動作を保証して、デプロイは顧客が責任を持つって形がいいのかな。そこまでやってたら、リーズナブルな価格設定は難しくなるかも。

個人的な意見では、大企業のグループ会社が、グループのプライベートクラウドを利用して、「納品のない受託開発」をやるのが結構いい選択と思っている。課題は、エンジニアの能力とマインドだが。。。

納品と瑕疵担保

• 私見では本で指摘されている問題の多くは「納品」に起因するものではないし、パブリッククラウドでしかできないものではない。通常の製造物と同様な「瑕疵担保責任」を負う事が業務用のソフトウェアの場合そぐわないなら、定額で、顧客資産の開発を進めるという形（変形のSES？）もあり得るだろう。結局、仕様なんて決めきれないのだから、これは、バグか、仕様か、みたいな不毛な議論に工数かけるよりも、継続的に機能追加していくことで培われる「信頼」をベースに修正していった方が双方にとってメリットはあるだろう。（ただ、誰が悪い、という犯人探しをするには、納品というメカニズムは中々便利。）

• 納期がないと、計画が立たない、というのは、ビジネス的なリスクである、という議論は確かにあるが、多分、それは見積もり、ターゲット、コミットメントを混同している。３ヶ月毎にマイルストーンを話し合うというし、もし、発注者がかなり具体的なビジョンを持っていて、ビジネスターゲットが明確なら、ある程度正確な見積もりはできる。コミットメントをしないだけ。どちらかというと、顔の見える、有能な実装者が見積もりを行うのだから、顧客の言われるがままに適当に算出した見積もりよりも正確。発生した問題もアジャイル的に開発するから、早期発見、早期対応ができる。 大規模ではいくらベンダがコミットしても、終盤になってはどんなに残業してもリカバリきかない事も多いのだから、結局は同じこと。リスクを許容し、それをコントロールする能力を信頼するのか、リスクなし、の幻想をそれが破綻するまで見ていたいのか、という問題。もしくは、遅れたとしてもベンダのせいにできるか、できないか、という問題。ビジネス価値を重視するのか、政治的な利得を重視するのか。

ソフトウェア見積り

また、開発中に、顧客がエンジニアの能力に疑問をもっても、今の契約なら、発覚した時点で「ふざけるな、なんとかしろ」と言えばすむ事を、キチンと受け入れ試験をしたり、エンジニアを評価しなければならない分、顧客担当者の負担は増えるかもね。

結局、顧客、エンジニアとして、正直に、信頼し合う関係で、問題が起こったら、お互いに協力しあいましょう、というスタンスにどこまでついてこられるか、という問題、かな。

規模の不経済

さて、ここでやはり問題になるのが、ソフトウェアの規模との関係。エンジニア一人が担当することで、余分な管理コストの発生を防ぎ、保守性の優れた高品質をリーズナブルな価格で提供しているが、それが許されない規模の案件に対して、どういう絵が書けるのか。

ちなみに、少数精鋭チームと大規模開発の問題は、ブルックスの時代から議論されていたらしい。

人月の神話

多分、一人の優秀なプログラマが仕様を理解し、構築までする品質と生産性を基礎数字に、２倍の生産性を出そうとすると、２人ではでずに、３人〜４人くらいは必要になる気がする。人数が増えれば、増えるだけコミュニケーションコストがかかるから。自分たちのために文書も作成する必要がある。その倍の生産性となると、さらに当然８人ではなく、１０人〜１５人。その時点で優秀なプログラマを確保するのが、怪しくなってくる。。。スクラムチームだと、３〜４チームか。この辺りが、保守性の高いコードをつくる限界な気がする。自己組織化チームも限界か。

それ以上だと、多分、コア機能と周辺機能を分けて品質で妥協しつつ、マネジメントを取り入れる必要がでてくるかなあ。

とはいえ、優秀なプログラマが一人でできる生産性の４倍程度となると、相当な規模のアプリケーションを作れるような気がする。２倍程度でも、パッケージ導入しないようなアプリはかなりカバーできんじゃないかなあ。

問題は、一旦、基本機能を作りきってしまったら、それまでの生産性を維持するほどの需要がないから、同じ金額を払い続けるモチベーションが顧客側にないことかなあ。

ただ、既存の開発案件と比べたら、圧倒的にリーズナブルであるはず。

大抵の請負契約は真のリスクを隠して、お金の問題でなく、担当者個人や組織に責任がいかないようになっているだけな気がする。

それを越えて、シビアにリスクとビジネス価値を考える顧客とそれに答えられるエンジニアが増えていけば、価値あるソフトウェアが増え、価値あるエンジニアが評価されるようになって行く未来が描けるかもしれない。

熊とワルツを - リスクを愉しむプロジェクト管理

その時に、自分が生き残れるかは、また、別の話。