komagataのブログ

「新卒の時からウォーターフォール開発じゃあ既になかった。」

というアジャイルネイティブ（コンチクショウ！）な方には少し分かり辛いかなと思い少し補足を。

受託開発から離れた理由 - komagata

（僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。）

「開発会社とクライアント（開発を依頼した会社）の利害が必ずしも一致してない」というのは極端に言えば下記のようなことがあるということです。

下記は全てフィクションです

開発会社が論文検索システムを4人月（1人月＝100万円）と見積り受注した。全文検索にはクライアントも知っている名のある商用パッケージを使う前提で見積もったが、土日で試してみたApache Solrを使えば半分の工数（というか土日で仕様の70%を満たしたプロトタイプが出来てしまった。）で出来そうだということが判明した。

当初の予定であった商用パッケージはより機能が豊富だが、今回の案件の規模にはオーバースペック気味で、検索UIには少し制限があり微妙に使い辛く、デザインがダサくなる。対応表明しているハードウェアやOSのバージョンが若干古く、運用も少し面倒そうだ。

要するに、「半分の値段・期間でより良いものが出来そうだ」ということが契約後に判明した。

見積りと契約にはクライアントも納得していたし、採用実績の多い商用パッケージに比べて初採用するならSolrを使うことには多少のリスクを伴う。

ちなみに現在期末であり、当案件の受注を獲得した営業担当にとっては受注金額の半減が決定した時点で今期目標の未達が確定する（笑）

さてここでこの開発会社が取るべき選択肢はどれ？

クライアントにも理解できる言葉で全てを説明した上で再度決定を促す。
わざわざ損を取る馬鹿がいるか。当初の契約通り行く。契約書の内容と照らし合わせても合法行為である。
ウヒョー！クライアントには「商用パッケージと同機能のオープンソースパッケージがありました。ライセンス料を考えたら後者をお勧めします。」と言ってライセンス料だけ引いた金額で再契約すれば、更に2人月別の案件に投入出来て売上アップだぜ！
この案件は既存の論文検索システムが使い辛いとのエンドユーザー（学会会員）からの多数のクレームから始まったシステムリニューアルの案件だ。エンドユーザーにとって一番使い易いシステムと柔軟なUIが構築できる可能性が高いSolrを採用した再提案をすべき。
仕様も期間もそのまま、人月50万で下請けに流す。

ではどうすべきか

前述のエントリーは本文を読んでいただければわかりますが、「受託が嫌だから離れたよ」という話だけではなくて、「過去離れたけど今戻ってきて勉強中だよ」というお話です。

どの選択をすべきかという点については僕にはまだわかりません。

ただ、「開発者にとっては受け入れがたいが、ビジネス上反論できない選択肢が存在する」というジレンマがあるため、多くの開発者が悩み、それを解消すべくアジャイル開発などの方法論の開発や経営を含めた契約形態の模索が行われている。アジャイル開発には商売上、受託開発最大のメリットである「商品を作る前から買い手と値段が決まっている」という点と真正面から対立するというこれまたジレンマが存在する。という認識です。

既に、「昨今ではそういう問題は解決してて、普通はこうやってるよ。例えばこの本読めば分かるよ。」みたいなのがあれば教えていただけると非常にありがたいです。また、そういった勉強会を行われている方や実際に答えを持っている方が居らっしゃれば是非、お話を伺いに参りたいです！

数年前、受託開発の会社を辞めてこれから自社・製品サービスを作ってる会社で働こうと思い、会社を転々としつつ今（FJORD, LLC）に至ります。

上記のような事を思った切欠は下記の様なことがあったからです。

中規模の案件

その時、僕はコンシューマ向けのWebシステムの案件を５〜６人ぐらいのチームで取り組んでいました。データベースに保存されたデータをPHPでXMLを返すAPIを作り、Flashで表示するサイトで、時代が時代だったので「このトラフィックをPHPで構築するなんて。Javaでやるべきだ。」なんて言われてましたが今考えるとおかしいですね。

サーバーとFlashクライアントが連携するのでAPI（XMLのSchema）に関してはデザイナーとも結構密にやり取りしていたように思います。僕はガントチャートとにらめっこしながらも案件の後半になってもそれ程デスマという感じも無く、定時で帰れるメンバーも普通にいて、

「余裕という程では無いにしてもどうやら無事リリースできそうだな」

なんて考えていました。

そんな時、Flashクライントも担当していたデザイナーの@946さんから、

「この部分のUIはこう変更した方が使い易いのではないか？」

という提案がありました。それに対して僕は、

「確かに改善案はもっともですね。僕も使い易くなると思います。しかし、今までのやり取りの感じだとクライアントはその分の工数追加を認めないでしょう。」

と答えました。

そしてその後凄く落ち込みました。

（僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。）

受託開発という商売

商売の仕組みとして受託開発はとても凄い。ソフトウェアを開発する前から買い手と値段が決まっているんだから。皆がこぞってやるのも当たり前だ。世の中に需要が一定数あるかぎり、ローリスク・ミドルリターン？のとても手堅い商売だ。

僕もその時まではデマルコやワインバーグに始まってAgile関係の書籍を読んだり実践したりして、受託開発がより良く進化していくことに期待していた。しかし「はじめの契約形態、要は契約書になんて書くの？」が解決しない限り本質的に問題は解決しない。（何度か受託でAgile開発系のイベントに行って質問したが、決まって「業務請負契約にしてもらっています」という答えだった。これは僕には妥協に感じられた。）

実際に昨今では永和システムマネジメントの価値創造契約など、その問題に正面から取り組んだ企業出てきた。（これは僕のように逃げずに真正面から受託開発に取り組む本当に素晴らしい姿勢だと思う。）

しかし、そういった問題は経営から考え方を刷新しないと無理だ。その時点で平凡なプログラマーである僕には「まず確実に5年はこの状況がかわることは無いだろう」と考え（実際に5年たったが変わってない）、「ならばエンドユーザーと直接金銭をやり取りする自社製品・サービスを作る仕事をしよう」と考えて転職した。（要は逃げた）

そして現在

現在のFJORD, LLCでも自社サービス（怖話）で利益を上げようと頑張っているが、それだけで食べていける状態に達していないので受託開発も承っているが、僕は上記の様に受託開発を良くしようとする方法論の進化から遠ざかっていた。しかし、下記の2点からまた勉強を始めました。

5年ぐらいたっているので僕の知らないだけで上記の問題が解決しているのではないか？
メンバー2人でもAgile開発の恩恵が無視できない。

「ニワカほどよく語る」と申しますが、恥をかくのは得意なので、Agile開発について勉強したこと、疑問なども書いていこうと思います。

追記

新卒時を除いて、僕の経験した受託開発とはほとんどがコンシューマー向けWebシステムなので、エンタープライズシステムのゼネコン体質などといった、更に難しい問題が無かったのは幸運でした。