mofmof inc.エンジニア兼代表取締役の原田です。
最近とある語学留学にいって帰ってきた方とちょっとした雑談をしたんですが、受託開発の話で「あくまでも作るのは我々ではなくてあなた(クライアント)なんですよ」っていうようなことを話をした。
あーいい話だなーと思ったのでちょっと書き留めておきたく。
サービスやプロダクトを作るのは誰か?
mofmof inc.では月額制の受託開発をやっているのですが、ご相談いただいた際に、ご一緒に仕事して本当にうまくやれるかどうかを非常に気にします。
昔からソフトウェア受託開発の世界では、いわゆる「丸投げ」っていう発注の仕方をするケースがあって、極端な言い方をすると、ざっくり要件を伝えるから、あとは開発会社の方で行間読んで良きに計らってねっていう形です。
で、ぼくの経験上このケースは本当にうまくいかない。よくあるのが、設計段階で確認したときには「オッケーオッケーそんな感じでやっておいてー」みたいだったのが、開発終盤になって動くものが見えて来た段階になるに連れて「え、ここはこう動いてもらわないと困るよ」とか「思ってたの違う」みたいにごにょごにょしちゃって、結局あんまり使い勝手がよくないものが出来上がっちゃう。
そして、こうなるかならないかは「クライアントがどれだけ主体になって作ったかどうか」というポイントが分かれ道になってる。色んな方々と仕事させてもらってきたけど、ホントこれ。もちろん開発者サイドにも改善出来ることはたくさんあるんですけど、それは主旨がブレるので一旦棚上げで。
なぜクライアント自身が主体的であるほうがうまくいくのか?
ソフトウェアでビジネス価値を実現しようとしている場合、なんらかの課題があって、そのソリューションを作ろうとしていることが多いわけなんですが、良いソフトウェアを作るには、その課題をより近く感じていて、それを適切な言葉で表現出来る人がどうしても必要だと思ってます。
課題を浮き彫りにするのってそんなに簡単じゃないんですよ。コスト削減のために「経費申請システム」を作りたいって言われたとします。じゃあ作りましょうって、ただ単に作ったってコスト削減にはつながらないんです。
「なんで既存のサービスじゃダメなのか?」「Excel+Dropboxで十分なんじゃないのか?」「運用を改善すれば解決する課題なんじゃないのか?」というところは当然明らかにすべきだし、実際に既存の経費申請フローをくまなくチェックして、何がどう非効率で不満なのか、それを使う人の体験を十分に分析しなきゃならんのです。そんな泥臭いことをやらなきゃわからんのです。「最適なソリューションを提案します」とか軽々しく口に出来たもんじゃない。
ソフトウェアを作るなんて簡単なことですが、本当に価値あるソフトウェアを作るのはそれほど簡単じゃないです。だから本当はソフトウェアを作るより前と、作ったあとの継続的改善が勝負どころなんです。
で、それを最もやれる立場にいるのがクライアント自身ですよと。
クライアント自身がソフトウェアに責任を持つ作り方
上で言及している通り、ソフトウェアで価値を実現するには、多くの試行錯誤が必要になります。ただ作っただけのソフトウェアがたまたまうまく行くなんてことはめったにないです。にも関わらず、ソフトウェア開発には「完成」を求められる。
果たして「完成」とはなんだろうか? 仕様書通り作れば一応「完成」させることは出来ますが、それは「ビジネス価値の実現」とは全然別ものなんじゃないですかね。思うに「ビジネス価値の実現」にフォーカスした場合「完成」という明確な状態が存在しないんじゃないかと。
従来のように開発者サイドが成果物責任を負うということになると、クライアントが「ビジネス価値の実現」を求めているのに対して、開発者サイドは「仕様書が定義する完成」を目指さざるを得ないのです。それも「ビジネス価値の実現」をほっぽり出してまで。
だからmofmof inc.の受託開発では月額制で「準委任契約」という契約形態で、ソフトウェアの完成責任を負わないが、エンジニアリングという役務に責任を負うという形態を選択しているわけです。
誰だって作ったものを成功させたい思いは同じはずなのに、契約形態や責任という理由で、チームの向いている方がバラバラになんてしまうのは本当に残念な話じゃないですか。
マインドを変えたり、やり方を変えたりすることで、チームを強く出来る可能性があるし、もっとエンジニアは価値を出せるはずだと信じてる。ぼくたちはそんなことに挑戦していきたいなと思ってます。