エンジニアが事業で勝つための「概念整理」のスキルについてーー事業開発の現場で学んだ「技術と事業をつなぐ」思考法
私は都内のベンチャー企業でSaaSの開発をしているエンジニアです。
最近、事業を進めるなかで感じていることがあります。それは、エンジニアとしての「優秀さ」の定義が変わってきているな、ということです。
もはや技術力では勝負がつかない
かつてエンジニアの優秀さの定義は「いかに高い技術力を持つか？」が大きな割合を占めていました。
しかし、いまの日本のWeb事業において、ぶっちゃけ「技術力」が事業の決定打になることはほぼありません。
たとえば「Wantedly」のような求人掲載サービスも「クックパッド」のようなレシピ共有サービスも、機能として見たときには大きな違いがないですよね。情報が登録できて、表示されて、検索できて、いいねや検索条件の保存ができて……と、基本機能はほぼ同じように見えます（あくまで外から見た限りですが）。
私たちが開発中のSaaSも、基本機能は「データ入力、保存、表示」なので、さほど変わりません。
いまはデバイスの性能が上がっているので、最適化が決定打になることもほとんどありません。特に立ち上げ期においては、最低限の機能しか実装しないので尚更です。開発周りのツールも昔よりずっと簡単になって、かつAIも出てきたことで、正しい指示さえできれば８割ぐらいの精度でコードを書いてくれます。
衛星を飛ばしたり、自動運転をしたりしない限りは、技術力だけで勝敗が決まることはほとんどありません。
では、そんな時代における「優秀なエンジニア」とはどのような人なのか？
私は「課題を特定し、解決策を提示し、それを仕様に落とし込めるエンジニア」が、「優秀なエンジニア」と呼ばれるようになっていくだろうと考えています。
必要なのは、技術と事業をつなぐスキル
「AIが台頭すればエンジニアは不要になる」と言う人もいますが、それはまだ先の話でしょう。よりよいサービスを作ろうと思ったら、裏側の設計を理解しているエンジニアが、専門性に基づいて指摘や改善をすべき場面がかならず出てくるからです。
AIでコードを書くことはできますが、その前提として「そもそもどんな機能を実装すべきか？」は、人間が判断しなければなりません。事業の状況や、お客さんの課題を総合的に考えて、できることとできないことを提示し、仕様に落とし込む。
そういう能力が、これからのエンジニアには求められていくと思います。
もちろんこれまで通りプロとしての技術力も必要ですが、それに加えて「技術」と「事業」をつなぐスキルが重要になってくる。結果的に、技術力が占める割合は小さくなるというイメージです。
そこで今回の記事では、私が事業開発の現場で働くなかで感じた、エンジニアが事業にコミットするために必要なスキルについてまとめてみました。
・要件定義に必要な「概念整理」のスキル
・不確実性の高い状況での意思決定に必要な「境界とトリガー」
主に上記のトピックについて取り上げています。
いまエンジニアとして事業開発に関わっている／関わりたい方にとって、少しでも参考になれば幸いです。
私は何者か
……本題の前に、冒頭からいきなり持論を語ってしまったので、簡単に自己紹介をさせてください。
私は今、プレックスというベンチャー企業でSaaSを作っています。
新卒ではDeNAに入社し、主にスマホゲーム開発に必要とされるサーバ機能を提供するゲームプラットフォームの開発に関わっていました。その後YOUTRUSTでのサービス開発を経て、今に至ります。
プレックスでは、まだエンジニアが一人もいない時点でSaaSチームに参加し、初期設計の段階から、インフラ、データベース、バックエンド、フロントエンドまで含めた開発をやってきました。
いま作っているのは『サクミル』という建設業界向けのバーティカルSaaSです。
正式にリリースしたのは約1年前。今年に入ってからかなりのペースで伸び始め、毎月100件以上のペースで新規導入が決まっています。
開発のペースとしては、毎週必ず１つリリース、１カ月に１つは絶対に大きな機能を出すと決めてやってきました。（最近はサービスが大きくなってきたので、少しペースを落としています。）
事業自体が伸びているのでどんどん新しい課題が出てきて、開発ペースも速いため、すごいスピードでフィードバックループが回っていきます。個人的にはかなり成長できる環境だなあと感じています。
「仕様のすり合わせ」がものすごく重要
では、本題に入ります。
まず冒頭でも触れたように、事業開発をするうえでものすごく重要なのが「ユーザーやPdMからの要望」と「実際につくる機能」のすり合わせです。
開発の流れとしては、まずお客さんからの要望をもとに、PdMが仕様のたたき台を作ってくれます。エンジニアはそれを実際の機能に落とし込んで開発していきます。
ただ、上がってきた仕様をそのまま実装するわけではありません。
お客さんやPdMから見えている景色と、エンジニアから見えている景色は違います。そこをすり合わせてから実装しないと、後々バグが発生したり、無駄が多くて重いサービスになってしまいます。
そのため「仕様のすり合わせ」は、事業開発においてかなり重要なポイントになるのです。
ただ、このすり合わせは「エンジニアリングができる人なら誰でもできる」というわけではないかもしれません。
あくまで感覚ですが、エンジニアの思考だと、ものごとをデータの連なりとして、トップダウン的に考えていきます。
たとえば「請求書の作成・管理」の機能をつくりたいとします。
エンジニアから見えている景色は「『案件』の下に『写真』や『請求書』があって、その下に『振込先』や『金額』の情報があるよな……」という感じです。
それに対して、お客さんはボトムアップ的な感覚でサービスを見ています。
「前に作った請求書と同じものをつくりたい」とか、「前と同じ口座に振り込むときに、履歴を参照したい」といった視点になるわけです。
この視点の不整合を意識すると、上がってきた仕様に対して質問すべきことがわかってきます。「それってたぶん違うよな」「本当に必要なのはこの機能じゃないかな」という疑問が降ってくるのです。
「無意識の前提条件」を見つけ出す
具体的な事例をひとつ話します。
『サクミル』の開発過程で「請求書のデータをどの『単位』で管理するか？」という話になったことがあります。仕様書には「事業所ごとに分けて管理する」と書いてあったのですが、なんとなく違和感があったのでPdMに質問しました。
「これ、本当に『事業所ごと』でいいですか？」
「そもそも僕らが今対象にしている中小規模の会社で『事業所』なんて単位がいつもあるんですか？」
話していくと「請求書に記載する『振込先』は、事業所ごとに分かれているはずだ」という前提でこのような仕様になっていることがわかりました。
しかし実際には、そもそも「事業所」という概念がないお客さんもいれば、同じ「東京事業所」でも複数の振込先を使っている場合や、会社全体で１つの振込先しかない場合もありました。
そう考えると、事業所ごとに請求書を分けて管理するのではなく、請求書の「テンプレート」を登録できる機能をつくったほうがいいだろうと思いました。
ネットバンキングで「よく使う送金先」をマイパターンとして登録できるような感じで、「よく使う請求書」をテンプレとして登録しておく。そうすれば、事業所や振込先がどのような形態だとしても対応できます。
PdMやお客さんからの要望には、このような「無意識の前提条件」が含まれていることがよくあります。エンジニアは実装前にそれを見つけ出して、きちんと揉んでおく必要があるのです。
では、このような「すり合わせ」を適切におこなうには、どんなスキルが必要なのでしょうか？
私は「概念」でものごとを捉えるスキルだと思っています。
ここまでの話からすると「ユーザー目線で考える力」とか「コミュニケーション能力」が必要なのかな……と思うかもしれません。
もちろんそれはそうなのですが、適切な思考やコミュニケーションの「前提」となるのが、概念の理解なのです。
たとえば、同じ「案件」という言葉でも、お客さんによって微妙に概念が違うことがあります。仕事のことを案件名で呼ぶ人もいれば、「田中さんのところの……」と、クライアント名で呼ぶ人もいるし、「田中ビルの」とビル名で呼ぶ人もいる。それによって、データの扱いや設計が変わってきます。
初期はお客さんやPdMのなかでも、そういった概念があいまいだったりします。そのままだと、そもそも適切な議論ができません。無理やり機能を作っても、のちのちバグが出たり、重大な作り直しが発生したりする可能性があります。
そこでエンジニアが「概念の整理」を手伝ってあげるのが大事です。
日本語で説明できないことを、プログラムで書けるわけがない
私に「概念整理」の大切さを教えてくれたのは、学生の頃にお世話になったプログラミングの師匠でした。
彼から口すっぱく言われていたのが「日本語で説明できないことを、プログラムで書けるわけがない」ということでした。「まずは日本語でプログラムしてください」と叩き込まれていたのです。
この考え方は、前職のDeNA時代にも活きました。
DeNAでは協業の大きな開発案件に関わっていたため、失敗が許されない状況でした。だからコードを書く前にまず「日本語」で概念整理をすることを徹底していたのです。
「スケジュール」と「勤怠」は何がどう違う？
コードを書く前に「日本語でプログラムする」とはどういうことか。ひとつ具体例を紹介します。
サクミルの開発過程で「日報」の機能を作っていたときのことです。
あるお客さんは「工程表」という名前で「スケジュールと日報が混ざったもの」を使っていました。
どういうことかというと、「まずカレンダーに未来の予定を書き込む。その予定が終わった後に、実際の作業時間や起こったことを書き加える」……という方法で、１つの表のなかで予定と日報の両方を管理していたのです。
それをそのまま実装すると「未来」の予定と「過去」の日報が、同じ管理画面に表示されることになります。こういう場合、裏側のデータをきちんと分けて管理しないといけません。
最初にカレンダーに記入するのは、未来の予定。
予定というのは「緩いデータ」です。「緩い」というのは「未確定でも問題がない」ということです。
しかし、そこに日報として勤怠やお金まわりの情報を書き加えた瞬間に、それは「硬いデータ」になります。「この日はこの場所で、この作業をやっていた」という「揺るがない過去の事実」になる。それをもとにお金が計算されるので、絶対に確実な情報でないといけません。
過去か未来かによって、データのゆるさが変わってしまう。なので当然、これを一緒くたに管理するとよくないです。
画面上では、お客さんにとって分かりやすいのが一番なので、同じ場所に表示されていい。でも、裏側のデータとしては「緩い」と「硬い」に分かれている。
つまり、未来の予定だったものが、過去の事実になったタイミングで、「緩いデータ」から「硬いデータ」に移行するように設計しないといけない。
こんな感じで、まずは日本語で概念を整理したうえで実装に移りました。
感情的にならずに議論ができる
概念の言語化ができると、余計な摩擦やコミュニケーションの齟齬も生まれにくくなります。
たとえば、お客さんから対応の難しい要望がたくさん来てしまったとき。「うちはこういう機能だから、難しいんです」と説明しても、なかなか噛み合わないこともあります。
でも「御社ではこういう人たちが、こういう業務フローをやってて、そのうえでこれが必要なんですよね」「逆にいうと、この人たちがこれをやらなかったら、この機能いらないってことですよね」という感じで、概念を整理してあげると、きちんと議論ができるんです。
「自分たちがつくってるものは間違ってたんだ……」みたいに感情的にダメージを受けることも防げます。「この概念がこうだから、このお客さんに合わなかったんだね」みたいな話ができる。「あいつはわかってない」と、余計な摩擦が生まれることもありません。
新卒の頃に教えてもらった論理学で、好きな一節があります。
論理的であれば、他者を理解することができ、かつ自分を理解してもらうこともできるのです。
健全なコミュニケーションのためにこそ論理を磨く。そういう意味でも、概念整理はとても大切にしています。
「それっぽい意思決定」を防ぐには？
プレックスに転職し、SaaSの開発責任者という立場になったことで、一番大きく変化したのは「意思決定の数と時間軸」です。
それは、以前までのキャリアでは経験したことのないハードルでした。
なにをどうやって作るか、すべて自分で決めて責任を持たなければいけない。人に聞かれたら答えられないといけない。しかも上がってくる情報が日々変わる中で、それをやっていかなければいけません。
それまでは自分のタスクだけをやって「できました」で終わりでした。でも、今はより長い時間軸で、自分の仕事の良し悪しを見るようになりました。「このサービスが続く限りは、何がどうなって動いているのか、すべて自分が把握しておかないといけない」と考えるようになったのです。
さらに、私はもともとバックエンドのエンジニアとして働いていたのですが、プレックスではフロントエンドまで含めた開発を担当することになりました。
ただでさえ答えがわからない立ち上げ期に、慣れ親しんでいない分野において、数年単位の意思決定をしなければならない。
これはちゃんと考えないとまずいなと思いました。そうでないと、タスクから逃げるためだけの「それっぽい意思決定」をして「なんとなく動いている」状態になってしまう。この先メンバーから疑問が飛んできたときに、答えられない状態になってしまうなと感じたのです。
そこで始めたのが「境界」と「トリガー」の設定でした。
「正しい設計」や「正しいコード」というのは、その時々の状況や背景によって変化するものです。「当時はこの仕様が正しかったけど、今は事業の状況が変わったから正しくないですよね」ということが起こりうる。
だから正しい意思決定をするためには「今の意思決定は、どのような条件においての最善であり、どんなことが起こったら最善ではなくなる瞬間がくるのか？」を認識しないといけません。
これを私は「境界」と「トリガー」というふうに呼んでいます。
たとえば『サクミル』の開発初年度は、あえて「権限」の機能をつくりませんでした。「この資料はこの役職の人しか見れない」といった、権限を設定する機能はつけなかったのです。
理由としては、
・セグメントが定まっておらず、顧客の業務フローを理解できていない
・どの役割の人が、どのような情報を見て、どのように判断して、なにを行うのか把握しきれていない
・協力会社など、社外の人の責務の範囲がわからない
といった不確定要素があり、そのまま進めると大きく間違える可能性があったからです。また「お客さんに小さい事務所が多いので、権限の機能がなくても成り立っている」という状況でした。
このような前提条件を「境界」として引きました。
この前提が崩れて、もう一度考え直す必要が発生することを「トリガー」と呼んでいます。
ちょうど最近、トリガーとなる状況が発生しました。
「お金の管理」の機能をリリースしたのです。それで前提条件が変わって、これまでやっていなかった権限の機能を開発することになりました。明確に「権限機能が必要」な状況が発生したためです。
結果的に、当初よりも機能やお客さんが増えて、多くの情報をもとに設計できたので、よりいい機能を開発できました。
そうやって、概念の境界を捉えること。そのうえで「境界の前提条件」と「考え直すトリガー」を把握しておくところまでが意思決定だと私は考えています。
今はエンジニアにとって、ある一定以上のスキルを身につけることがけっこう難しい時代なのではないかと思います。
営業などの業務とは違って、プログラムには不確実性が全くないので、言い訳の余地がありません。間違っていれば絶対にエラーになるし、正しければ必ず動く。早い・遅いの差も数値ではっきりと可視化されます。だからすごい人の「いいコード」を見て学びやすい。これはプログラミングのいいところですし、ある一定のレベルまでは効率よく学びやすいと思います。
ただ「いいコード」に至るまでの「思考プロセス」に関しては、あまり可視化されていないのが現状です。
「この人は、なぜこんなに早くこんな設計を考えられるんだろう」「このデータ構造やアルゴリズムって、どうすれば思い浮かぶんだろう」といったことは、プログラムに比べると、パッと見ただけではわからないんですよね。
アウトプットは明確にわかるけれど、そこに至るまでの思考がなかなかわからない。特に昨今はリモート勤務がほとんどなので、プロセスを知る機会が本当に失われていると感じます。
しかし、より主体的に事業にコミットする能力を身につけるには、コードに至るまでの思考プロセスを体得することが重要です。
できる限りそこを伝えられるように、メンバーに教える際にも気をつけていますし、Slackのtimesチャンネルなどを使って可視化するようにしています。
答えがわからない中で動くために
えらそうに語ってしまいましたが、もちろん全てのエンジニアが事業にコミットする動きをするべきだとは思いません。
私自身、大企業とベンチャーの両方を経験して、エンジニアに求められる仕事は「事業フェーズ」によって全く違ってくると感じています。
大企業のように「これをやればちゃんと儲かるし、勝ち切れる」というビジネスモデルがすでに確立されている場合は、きっぱり分業化したほうがいいです。エンジニアがPdM的な動きをする必要はなくて、職人的にいいコードを書けるスーパーエンジニアを目指したほうがいい。
一方で、立ち上げ期のように「まだ答えがない」状況で動く場合には、本記事のような考え方やスキルが役に立つのではないかと思います。
私たちのチームもみんな答えがわからない中でやっていますし、競合もわかってないでしょうし、お客さん自身も自社のデータ管理をどうすれば売上に繋がるのかわかっていない状態です。
そういった答えがない環境下では、職種にかかわらず事業に向かう必要があるのかなと思います。そのうえで自分の専門性の切り口からちゃんと意見を言って、健全にぶつかる責任がある。
大企業は基本的に、ビジネスモデルもチームも盤石です。それは極論「誰も頑張らなくてもちゃんと動く体制」でもあって、それはそれでとても正しいと思います。
でも、ベンチャーはやっぱり全然違います。立ち上げのときなんてもう「その人がいないと回らない」人しかいません。チームにいる全員が「この事業の競合優位性は自分です」と答えられるぐらいじゃないといけないと思います。
純粋に仮説検証を楽しめる
おなじエンジニアという職種でも、事業フェーズによってゲームが全然違う。そのうえで、純粋に仮説検証を楽しみたい人は、立ち上げ期の事業に関わるのが個人的にはおすすめです。
立ち上げ期の会社は意思決定が速く、思いついたことをすぐに試せる場合が多いです。「ここをつついたらどうなるんだろう、見てみたいな」というマインドがある人にとっては楽しい環境だと思います。
逆に、正解があったほうが安心する人にとっては、このフェーズは結構大変かもしれません。
これは主観ですが、エンジニアって、もともと仮説検証が好きな人は多いと思います。自分で考えて価値をつくるとか、モノをつくるのが好きな人は多い。
ただ、それを組織でやるとなると、いろんな歪みが出てくるのかなと思います。
たとえば「とにかくバグを出さないこと、問題を起こさないことが正義だ」というカルチャーの組織であれば、極論「動かないほうが正しい」という力学が働きます。「余計な仕事を増やされるのが嫌だ」という人が多ければ、当たるかわからない仮説なんて主張しないほうが「正しい」かもしれません。
組織や個人の向かう先が歪んでいるがゆえに、歪んだ環境に最適化した結果、もともと好きだったモノづくりのワクワク感に蓋をしてしまう。そういうケースも一定あるのかなと個人的には感じていて、それはすごく勿体無いんじゃないかなと思います。
同じ志をもつ仲間と、楽しく仕事をするために
仕事は人生において大きな割合を占めます。
それならやっぱり楽しいほうがいいと私は思います。綺麗事と思われるかもしれませんが、食い扶持を稼ぐためというよりも「やりたいからやろう」と思えることをしていたい。
今回紹介したような概念や境界、トリガーといった考え方は、適切な実装のためはもちろんですが、仲間とのコミュニケーションを健全なものにして、信頼関係を築くという点で、やはりとても重要だと思います。
各々の職責を尊重し、自分のできることをわかりやすく提示して、建設的な議論をする。チームとしてこれができると、みんなで同じ「こと」に向かっていけるので、組織の雰囲気もすごくよくなります。
純粋に楽しいと思えることを、同じ熱量の仲間と一緒にやれる。そんな日常を過ごせることは、自分にとって間違いなく希望です。
これから組織が大きくなってサービスが広がるのと共に、そういう希望や明るいエネルギーも、世の中に伝播させていきたいなと思います。私たち自身、そんなチームであり続けられるよう、これからも精進していきます。
＊
最後に、弊社の採用情報を載せておきます。エンジニア積極採用中ですので、気になった方はぜひお気軽にDMください！
【SaaS事業】テックリード
【SaaS事業】ソフトウェアエンジニア
【ダイレクトリクルーティング事業】フロントエンドエンジニア | テックリード
【ダイレクトリクルーティング事業】ソフトウェアエンジニア
【人材紹介事業/M&A仲介事業】コーポレートエンジニア