富士山マガジンサービスやpaperboy&co.の役員からクラウドワークス、Livertyといったスタートアップ・プロジェクトのアドバイザーまで幅広く務めるのが神谷アントニオ氏だ。

生まれ育ったアメリカの地で大学、起業とステップを重ね、経営者と技術者としての顔を併せ持つ彼は、その手腕をふるいながら時に後進の指導にもあたっている。

神谷氏が「MOVIDA SCHOOL」の壇上で語った言葉をいくつかのヒントにまとめた。

開発のプロセスは変わっていない

開発プロセスは5W1Hで分けて考えるといい。企画プロセスというのは「なぜやるのか」。要件定義プロセスは「何をするか」という話。取得や開発プロセス（ソースをどのように取得するか）は「どのように、いくらでやるのか」という話。

でもこれって古くさい話じゃないの？という人もいる。今ではリーンやアジャイルといった言葉が出てきて新しい話題のように聞こえるかもしれないけど、プロセス自体は基本的に同じ。

イテレーション（繰り返し方）が違うだけ。例えばアジャイルだったら一つ一つの成果物を小さく分けて取得したりする。つまりこれは予算の使い方を考え直しましょうという話題であってプロセスそのものの変化ではない。

企画プロセス：経営者と技術者は費用対効果とKPIで会話せよ

20年近い開発経験で一番引っかかるのは「なぜ経営者と技術者は同じ言葉で同じ日本語で同じ技術用語で話をしてるのに捉え方が違うんだろう」ということ。

多くの経営者がやってしまう失敗は企画プロセスの段階で画面や形を持ってきてサービスの「具体的な形」から入ってしまうこと。企画プロセスでやらなければならないのはユーザーやパートナーに対する仮説検証に基づいた費用対効果の確認と、かけた予算に対して定量的に測定が可能なKPI（key performance indicator）の設定。これがないままに進めると何が失敗だったのか分からなくなってしまう。

企画プロセス：仮説から企画を導け。売上はKPIにするな

例えば商品の上にマウスオーバーすると画像が拡大表示されるという機能追加が開発陣に要求されるとする。売上は1000万目標で予算は200万。トラックするKPIは売上という話が経営陣から出されたとする。

まずこういう企画を経営陣から出した場合「画像を拡大するだけで売上があがるのか」というポイントを開発陣は否定しづらいということを認識すべき。どんな企画でもまずは仮説から組み立てる。ユーザーが何をインセンティブに感じてそれに対してどういう行動を起こし、どういう結果が導かれるのか。

例えばサポートセンターに商品説明を求める声が多い場合は、ユーザーが商品イメージを掴めていないのではないか、もっと大きな画像が必要で、それを解決すれば購入が促進されるのではないか、といった元々の原因とそれに基づく仮説が必要になる。

予定された機能が正しく実装されたかどうかを確認するための方法を持つことも大切だ。売上をKPIなんかにしてしまったら、例えば全然違う要因で商品情報がバズって流入が増えて売上が上がったとしてもそれは正しく仮説が立証されたことにはならない。

例えばこの例の場合は、商品ページからカートに入れられる率を測定値として設定する。同時に元々サポートセンターに「商品が分かりにくい」という話があったことが発端になっているので、ここへの問い合わせ件数が減ったかどうかもトラックすればいい。この二つの数値をKPIに設定して問題解決したかどうかを確認することが大切。

企画プロセス：サービス企画は誰がやるべきか

スタッフに任せなさいというのが答え。自分がエンジニアだったりデザイナーだったりすると自分で手を出してやってしまいがち。しかしこの部分は経営者の仕事ではない。経営者の仕事は予測することであり、予定されている結果が事業の目的を達成できているかどうか検証することだ。

要件定義プロセス：アーキテクチャは開発速度と安定性を天秤にかけろ

その事業のコア・コンペテンシが明確でないと現場の開発者が判断ができない。例えばアーキテクチャの選択で開発速度と安定性を天秤にかけたとする。IBMのAS/400というサーバーはものすごく安定しているけれど調達するのにえらく時間がかかる。一方でPHPだ、MySQLだ、MVCだといった話題は圧倒的にコストも安いし早いがエラーが発生するリスクを持ち合わせている。

新しい情報技術が大量に出てくるようなサービスはフレキシブルな変更が効いて安いアーキテクチャを選ぶべき。比較して金融とかビジネスモデルが変わらないものにわざわざ不安定なものを導入する必要はない。そういう場合は安定性を選択すればいい。このように事業のコア・コンペテンシが明確でないとどちらを選択すべきか分からなくなる。

同時に経営者として着眼して欲しいポイントはプロトタイプをつくるようなシード期のステージでは、人材を獲得しやすいテクノロジを選択すべきということ。確実に利益を出していけるステージに移ればハードやシステムで効率化して人にかかるコストを下げるようにすればいい。

取得・開発プロセス：シード期は見積りなんか取るな

取得開発プロセスでは、社員でも外注でもソフトウェアを買ってるという視点は同じ。ここで重要になるのは見積りはスタートアップにとって大変難しく、またストレスのかかるプロセスだということ。普段買物をするときにわざわざ見積りなんかするか？と考えればいい。

今日は夜のご飯に3000円かける、と決めればそのお金が無くなればそこで終わり。ITも同じように考えるべき。この開発でいくらかかるか、ではなくこの予算でどこまでできるか、費用対効果はどれほどなのかをベンダーや開発者と握るべき。

例えば予算も100万円を10万円という使いやすい単位に分割することで、確認や方向転換がしやすくなる。一つ一つの開発依頼に対してその費用対効果がどれほどだったか、それをしっかりと確認することが重要。

取得・開発プロセス：開発者はエンジニアリングの素晴らしさよりも費用対効果

経営者が開発者である場合、入ってきたエンジニアは必ずといっていいほど「俺の方が（開発速度が）速い」と思ってしまう。ここで経営者にとって重要なのが費用対効果という視点だ。コーディングが奇麗だとか効率のよいエンジニアリングだとかは実はあまり重要なことではない。

要求に対して出ている効果が見合ってるかどうかが重要。しかし、一方で費用対効果のよいエンジニアリングというのは大抵いい仕事をする人が持っているものだ。経営者は個々のエンジニアリング効果に心を奪われてはいけない。自分達は経営者としてソフトウェアを単純に買っているんだという考えが重要になる。

取得・開発プロセス：CTOの役割を理解する

技術を理解しようとするのではなく、技術がもたらすであろう効果を検証することこそが重要。「PVは上がった、コンバージョンも上がった、けれど利益が出ません」はここにいる経営者が全て悪い。成果物を見てそこから予想される効果を検証するには最初は人の経験に頼るしかない。そういう経験を沢山持ったCTOを必要とすればいい。

例えばグーグルのような大きな組織ではCTOとエンジニアリングの担当役員は分かれている。CTOの役割は情報技術を査定してその情報の中から必要な情報を提供してくれる人のことを指す。実務的なエンジニアリングのトップを務める役員とボードメンバーにアドバイスをするCTOの役割が全く違うということを理解しておくべき。

【U-NOTEリンク】：スクール当日にライブで記録されたU-NOTEです。合わせてご参照ください。