プログラミングファースト開発は物神化に並ぶ人月商法脱却の解か

プログラミングファースト開発と最初に聞いて、ソフト開発の手順としては当たり前過ぎて、最初は何が新しいのかさっぱり分からなかったんだけど、肝は如何に受託開発でそれを貫徹するかの交渉術や契約形態にありそうだということに合点がいった。人月に代わる値付けの方法、機能や品質に応じた対価を得る手法として、パッケージ販売やSaaSといった共通化と利用者拡大の他に、相対取引での値付けにも新たな道は広がるのだろうか。
実は世の大半の名だたるソフトウェアに厳密な仕様書などないし、受託開発でも設計書と呼ばれているものがコードと同期している可能性はかなり低い。これはソフトにとって役に立つこと、問題を起こさないことが、仕様書通りに動くことよりずっと重視されてきた結果であって、みんな心のどこかで気掛かりではあるけれども、マクロ的には合理的なトレードオフの結果であって必ずしも悪い話ではない。
恐らくプログラミング・ファースト開発のアプローチって実はソフトウェア開発の保守本流で、このところの受託開発の在り方が、本来あるべき姿から遠く離れているのではないか。課題は弾さんのいう通り、どう値段をつけるかだ。ひがやすを氏の提案は受託開発で開発側の裁量をかなり認めつつ、リスクをある程度は顧客と共有している点、最後は一括請負で成果に対する対価を取っているところが非常に興味深い一方で、この契約を相手に飲ませるって弾さんの指摘するように、非常にタフな交渉だ。
昔からソフトの価格って難しかった。汎用機の時代、ソフトは非常に高価なハードのおまけだった。FTC裁定によるソフト・ハード分離でソフト市場が分離し、PCの普及でパッケージ・ソフト隆盛の時代がきた。今度は相対で根付けするのではなく、ある機能セットを持つソフトウェア・コンポーネントに対して対価を求めるようになった。ソフトの提供する機能を切り出して物神化することで、開発やサポートにかかる役務と価格設定とを切り離した訳だ。
その後もSaaSとかプロフィットシェアとか、様々な提案があるけれども、基本的にはモノや汗ではなく、コトに紐付けてカネを取る風に如何にしていくか、如何に再利用の促進で分母を広げることで単価を抑えていくか、さらにその価格を如何に支払いではなく費用を相殺する収益機会に転化するか、といったことに注力している。
対顧客との関係に於いて、労務やビット列ではなく、彼らに取って重要な"コト"を売っているという関係性に如何に転化していくかは今後も重要であり続けるだろうけれども、それをパッケージ化、サービス化といった物神化だけでなく、まずコードで顧客にとっての価値を可視化することを通じて実現できるかは非常に興味深い。
顧客との共同作業で出口が見えたところから急に「ここから一括請負で、一式いくらいくらで」と切り出そうものなら、普通の客なら「お前ら開発の目処がみえたら急に高飛車に出やがって」と、逆切れしても不思議じゃない気もするけど、そうじゃない客は互いの立場を尊重して相手を対等のプロフェッショナルと認めてのことだろうし、それはソフト開発者の地位を高め、いい仕事が報われる好循環をつくる可能性がある。
プログラミング・ファースト開発はソフトウェア科学としての開発方法論というよりも、いまの日本のSIerや受託開発の直面する現実を受け止めた上で、プログラマーが技術的に自然な判断をできるよう適切に権限を委譲することで潜在能力を引き出し、成果に見合った対価を得るための交渉術として興味深い。これが手法として概念化され注目を浴びることで、ユーザー企業側で、頼む相手を考えてプログラミング・ファーストで発注した方が従前の取引と比べて素晴らしい結果を期待できそうだ、というパーセプションが広がってくれば、今よりずっとSIerの仕事が面白くなってくるのではないか。

最初に要件定義をして概算の見積りを出す。これは準委任契約(成果物ではなく、人月で請求する)。
次に顧客と仕様を実装に落とす部分(プログラミングファースト)も準委任契約で行なう。これも工数がどれくらいになるかは確定しにくいから、準委任契約が良い。
プログラミングファーストで仕様が固まったら、後は、一括請負(成果物ベースで請求する)でドキュメントやテストなどを行なう。
この形態なら、SIerでも契約しやすい。

まあそんなわけで、プログラミングファーストは相当のマッチョでないとキツイというお話。少なくともプログラミングの腕だけでは駄目で、顧客に対して相当強気に振る舞える人でないと難しい....