倉貫社長には、以前、ウェブシグ(WebSig24/7)のイベントに登壇していただき、ソニックガーデンさんのビジネスについてゆっくりお話をお伺いしたことがある。
高速で無駄のない開発をするチームのための”7つ道具” | Social Change!
何せ本書を読めばわかるが、プロフェッショナルの組織を作られているだけのことあって、ツールの活用についても非常に造詣が深いし、そもそも欲しい物を自分たちで作ってしまう余力があるのが素晴らしいと思いました。
(今回献本いただき読ませていただきました!ありがとうございます)
本書を読み、ウェブシグのイベントでお話をお伺いした内容も加味して、思ったところを書いてみたいと思います。
僕がもしソニックガーデンさんに関係する立場だったら、今、何を狙うか!?というと、間接的にスタートアップの成長に寄与し、成功させるところだろうなと思いました。
実は「納品のない受託開発」が目指す継続的発展が可能なモデルというのは、既存の概念でも可能だ。既存の概念で類することを実現するには2種類のパターンがあると思っている。
・1つは発注主の豪腕で、結果的に継続的改善を実現している場合。
・もう1つは、受注単価がリーズナブルで、信用できる外注先がいる場合。
つまりどっちも小さな納品をイテレーションとして繰り返すということだ。それなりの関係性が続いていれば、成り立ってるところは少なく無いだろう。
多分、僕の周りのWebの受託屋さんはどっちかで生きている人が多いような気がしていて、そういう人たちにとっては、割と当たり前感があって、必ずしも納品のない受託開発の話が、新しい考え方として、しっくり行くというわけではない気がしています。
中小のWeb制作会社の場合は、そもそもリピート重視だと思うので、そういう関係性が成り立っていて、そこまで新鮮ではないのではないか、というのが肌感覚。少なくとも、今の今まで生き残っているところは、相応の柔軟性を持たざるを得なかったところが多いと思います。
問題は、もっとシステム寄りであったり大きな案件の世界なのでしょう。投資規模が二桁以上違っていて、失敗できない、ややこしいケースですね。設計から納品までに1年からそれ以上かかるようなケースでしょうか。それが故に起きている問題というのが、本書に書かれている部分そのものなのでしょう。
ソニックガーデンさんが、既存の発注形態のレイヤーを壊し、破壊的イノベーションに近い立ち位置になるには、大企業の責任回避モデルを合理的なメリットで破壊する必要があるのだと思います。
Windows XPのようなOSを企業に買い替えを促進させるなら、ほどよい期間を開けて、サポートを打ち切ってしまえば良い。買い替え需要が喚起できるならば、サポートが切れたOSを維持するだけの判断は、そこそこの規模の企業の担当者にはできない判断だ。責任回避の部分を逆手に取って、文句が言われないぐらいのところで、サポートを打ち切ってしまえば良いというのが、よくあるパターン。
オープンソースライブラリの利用が制約されるのも責任回避の問題がよく言われる。でも、とことん回避するわけではなくて、そうは言っても、みんな地頭はいいので、大切なのは「責任を担ってくれる人がいること」なのではないかと思う。昔、受託の仕事をしていて、何かの技術選択でお客さんと議論になった時に、「自分が責任を取ります」と言う言質さえ与えてしまえば解決可能な問題というのは以外にあるものだと感じたことがあります。いろんな会社があるでしょうから、それが全てだとは思っていませんが。
問題は、その責任が取れない会社、取れない組織構造、利益構造の会社が、受託モデルで苦労すると、本書に書かれてるような責任回避型の本末転倒な受託ビジネスになってしまうということなのかと思います。
そこでソニックガーデンさんに頑張っていただき、今のビジネスにおける実績を積み上げ、責任をしっかり担ってもらえると言う信頼が出せれば、クラウドのようにこぞって乗り換えが始まっていくのではないかと思います。
要はサービス開発における、やり方の問題ですよね。それこそデザイン思考、リーンスタートアップのような、「いきなり開発しないでプロトタイプから考える」ことから始めていけば、ソニックガーデンさんのようなスモールスタート型の方が、よっぽど、ありがたいところが多々あります。
今、僕もずっとiPhoneアプリ作ってますけど、最初は外注しようかと思ったんですよ。でも恥ずかしながら、僕がイメージ可能な合理的な工数では、人に頼んでうまく行きそうなゴールの絵が書けなかったので、仕方ないので自分で作るという流れになりました。もし、もっと一緒にやってくれる感があるパートナーさんがいたらお願いしたかったですね。
このやり方は、クライアント担当者の人材育成的要素がセットになってたりすると、結構、良いモデルなんではないかと思いますけどね。一品一様の外注モデルで一番ややこしいのは開発業者側のタイムラインと、発注側のタイムラインが同期しないことですよね。さらに時間切れという概念があって、時間切れになるともう気持ちは離れるは、逃げモードに入るわでタチが悪い。「納品がない」というよりも「納期(エンド)がない」ってのは、すごく気楽なことなのだと思ったりします。
それこそこれからインターネットビジネスを始めようだなんて人たちだと、このタイムラインのスピードの差は案件失敗率に直結します。僕は、昔から案件のボトルネックは発注主側の担当者の熱意で決まると思っているのですが、そうは言っても、その人自身が成長途中なことも多々あるわけです。そういうところで、温かい目で付き合えて、なおかつ、お互いしっかり黒字が出せるようになってると良いですよね。
言い換えると、プロジェクト責任者にとってのリスク回避論が、納品という性悪説モデルではない形で解決されれば良いってことですよね。
【PR】ご意見、感想などは是非、mstdn.fmのローカルタイムラインでお聞かせください