読者です 読者をやめる 読者になる 読者になる

GoTheDistance

ござ先輩と言われています。(株) クオリティスタートという会社をやっています。

プログラミングファーストには期待しています

やっと自分の見解がまとまってきたので、今頃この話題に足を突っ込む。

プログラミングファーストのメリット・デメリット

色々関連するエントリを見させて頂いて*1多分こういう感じだろうと思いました。ざっくりと。

主体者 メリット デメリット
ユーザー 早期に最終成果物を共有できる 単なるコスト増になる可能性がある
システム屋 エンジニアの能力・創造性を価値に変えられる 少数精鋭・内製志向に適したビジネスモデルの構築が困難

こういうお話は「ユーザー目線」と「システム屋目線」に分けて考えるとわかりやすいと思います。

ユーザーにとってのメリットは早期に最終成果物を見ることができることだと思う。もちろん「最終」というまでには設計も必要だろうしテスト結果も必要なんだけど、「実装してユーザに使ってもらう」ことによるメリットは少なくない。システムって使ってみて初めて価値がわかるものだし、品質を決める基準はユーザーのビジネスに対する貢献度合いにあると思っています。そうあるべきです。その結果として、メンテナンスビリティの高いコードがある。コードは手段。手段が目的化しちゃいけない。

デメリットはこれってプロトタイプとどう違うのっていう話になったり、プログラミングファーストでもドキュメントファーストでもほとんど変わりませんでした、っていうBADENDにもなり兼ねない所。イテレーティブに開発していくことは大切だと思いますが、プロトの難しい所はUIのように実際に目に映る所の実物を見てしまうと「アレもコレも」っていうのが止まらなくなりがちな所。ユーザーの恣意って、申し訳ない言い方をするが、SIerからみたらコストになる。そのジレンマはずっと続いている。

で、実際問題ドキュメント書きませんなんて話にはならないし、従来通り文書化の工数は絶対必要で。

システム屋(プログラマと考えてもよい)にとって大きなメリットは、出来るエンジニアが正当に評価されやすくなるってことだと思う。人月も良し悪しがあるわけですが、悪い所の最たるものはレベルの差に限らずみんな「1人月」という単位でくくられてしまい、委任契約でマンパワーのみご提供というスキームが横行しちゃっていること。プログラミングファーストって、スキルの高い技術者で無いと回せない。しかも、交渉能力も求められる。ハイブリッドな人材でないと仕様を決めるのは相当難しそうだ。価格設定としては、従来なら5人月×1Mのところを、1.5人月×2Mにしていく感じだろうか。デメリットは、色んなところで言及されているけどビジネスモデルの構築が難しいことに尽きると思います。顧客にどう受け入れてもらうのか。

開発プロセスはビジネスモデルの根幹

僕は内製回帰派なので、このプログラミングファーストの考え方は好きです。可能性もある。試みとしてすごく面白い。

が、僕はSIerにとってシステム開発プロセスを変えることはどれほど難しいことかを、ずっと感じている。システム開発プロセスそのものがSIerのビジネスモデルそのものだから。それが中心になって上流と下流がつながる。コンサル部隊を増強して戦略立案能力が上がったとしても、それ頭打ちだよきっと。話がずれたけど。

例えば今まで社内で使っていたライブラリやフレームワークがあったとする。で、プログラミングファーストに適したフレームワークが別にあって、すいません来年からこっちに乗り換えてくださいと言って、中の人がいない現場に持っていって話が通じるのかどうか。イヤだよ、って言われちゃう可能性が高いと思うんだ。SIerも結構色んな失敗をしている。パッケージ担いだけど失敗したっていう話は後を絶たないし。ビジネスモデルの変革はトップの強いコミットメントが無いと出来ない。折衷案的な感じでやるとすれば、プログラミングファーストな子会社作って親会社のシステムをその子会社に作らせてみるっていう話に落ち着くだろう。巨象も踊るけど、踊るためには色んな条件がきっと重なる。

作り手にとって有意義なものが、ユーザーに対する価値を構築できるのではないか

色んな問題あるけどプログラマ目線で言えば最大の問題は工程の分断によるフランケンシュタイン化に尽きるんじゃないかな。ツギハギだらけ。それを紡いでいくのは、プログラマしかいない。プログラミングファーストは明らかに垂直統合の思想。作り手としてはこちらの方が望ましいと思う。少なくとも僕はそう。実際に作る人にとって価値のあるやり方をやらずして、ユーザーに価値を提供できるわけがないのではないか。そういう思いがきっと裏には隠されているんだと思います。

プログラミング・ファースト開発はソフトウェア科学としての開発方法論というよりも、いまの日本のSIerや受託開発の直面する現実を受け止めた上で、プログラマーが技術的に自然な判断をできるよう適切に権限を委譲することで潜在能力を引き出し、成果に見合った対価を得るための交渉術として興味深い。これが手法として概念化され注目を浴びることで、ユーザー企業側で、頼む相手を考えてプログラミング・ファーストで発注した方が従前の取引と比べて素晴らしい結果を期待できそうだ、というパーセプションが広がってくれば、今よりずっとSIerの仕事が面白くなってくるのではないか。

僕もそう思います。色んなやり方があっていい。一石を投じることはとても意味があること。このムーヴメントは消えて欲しく無いと切に願っています。

*1:10個ぐらい読んだ