開発速度を上げるには
公開日
2021/07/23
著者
福島 良典｜LayerX 代表取締役 CEO
東京大学大学院工学系研究科卒。大学時代の専攻はコンピュータサイエンス、機械学習。 2012年大学院在学中に株式会社Gunosyを創業、代表取締役に就任し、創業よりおよそ2年半で東証マザーズに上場。後に東証一部に市場変更。 2018年にLayerXの代表取締役CEOに就任。 2012年度IPA未踏スーパークリエータ認定。2016年Forbes Asiaよりアジアを代表する「30歳未満」に選出。2017年言語処理学会で論文賞受賞(共著)。2019年6月、日本ブロックチェーン協会（JBA）理事に就任。
LayerXは開発のスピードが速いとよくお聞きします。僕は実装のスピードがあまり速くなく、そういった環境に置いていかれている感覚があり不安です。どのようにすれば開発のスピード、もしくは実装のスピードを速められるでしょうか？
2つの観点から話していきますが、結論から言うとLayerXで働くのがいいんじゃないかなと思っています。環境はすごく大事なので、それが結論です。
その理由を2つ話すと、1つ目は基礎体力をつける、2つ目は意思決定力をつけるみたいな話で。
基礎体力をつける
1つ目の基礎体力をつけるというのは、実装のスピードは一定の基礎体力がなければ上がってこないかなと。いろいろなデザインパターンを知るとか、いろいろな良いコードに触れるとか。独学でも良いんですけど、良いチームの中で良いコードを見たり、コードレビューをしてもらえるという経験が基礎体力をつけるという意味では1番大事かなと。
よく言われる1万時間の法則で、効率の良い正しいやり方で鍛えていく。がむしゃらにやっちゃダメですよ。そのためには優秀なエンジニアに囲まれるのが大事かなと。
「今の自分は実装能力が高くない」という自覚があるから、優秀な開発陣のなかで働くのは不安だというのはよくある話なんですけど、まず根本から間違っている。
「能力がある人がチャンスを掴む」「能力をつけてからチャンスに飛び込もう」と考える人が多いんですけど、逆で。野生力というか。
「実装力高くなりたい」「開発スピード速くなりたい」「凄いエンジニアになりたい」という強い思いからチャンスに飛び込む人。飛び込んだ結果として、そのなかで切磋琢磨して能力がつくという話。
たとえば甲子園優勝とか、バスケのインターハイ優勝を目指すときに、「全国に行く力をつけてから強豪校に入ろう」じゃなくて「今の自分の実力はもしかしたら足りないかもしれないけど、絶対にその中で切磋琢磨すれば行ける可能性があるから強豪校に入って、なんとかついていってレギュラーをとるんだ」みたいな考え方の方が多分上手くいくと思うんですよね。
とにかくチャンスを掴みに行こうと。良いチームの中で働こうと。そのなかで基礎体力をつけるというのが1点目。
意思決定力をつける
2点目は意思決定力を高めようというところで。さっきの基礎体力が出せるキャパの話だとすると、意思決定力というのはどこにリソースを割くかという話なんですね。
僕は「技術意思決定力がすごく大事」という話をよくしているんですけど、たとえばここ10年くらいでクラウドコンピューティングとか機械学習ってすごく発達したと思うんですよ。まあ、あらゆる技術で言えることかな。コンテナの技術とか、データベースの技術とか、サーバーの負荷を分散する技術とか、アプリを作る技術とか。いろいろなものがオープンソースないしはクラウドで早くなってると。ノーコードみたいなものも出てきてますし、開発者向けのSaaSみたいなものも増えてきました。
そういうなかで、何に乗っかって、何を自分たち独自で実装するのかという意思決定力がすごく大事だと思っています。
どの巨人の肩に乗るかを正しく選択する
たとえば10年前。「AWSとかAzureに乗っからずに自分たちでオンプレでサーバーを持って、そこのインフラの改善も自分たちで投資してやっていこう」としたチームと、「AWSに乗っかって、そうではない（=そこにフォーカスするのではなく）、ユーザーの課題とかアプリケーションの部分を解決しよう」としたチームのどちらが成功したかって言うと後者ですよね。もしかしたら金融の超高速トレードのような特殊な場合は自前のサーバーが必要だったかもしれないですけど、99%が後者なんですよね。
何が良いかと言うと、そういうインフラ的な基礎研究に投資する体力ってほとんどの会社にはないので、自前で持つと、持った段階で（プロダクトの）改善が止まっちゃうんですよね。自分で投資もすごくしないとインフラの技術も磨かれない。
一方で、AWSを入れようと決めた会社は、その会社は何もしてなくてもAmazonの技術投資の恩恵を勝手に得られるわけですよ。しかも比較的安い価格で。こういう、勝手に改善されていく部分に乗っかる、巨人の肩に乗っかるみたいな発想がすごく大事です。
機械学習もそうですし、データベースの技術もそうですし。あらゆる技術において巨人の肩、基礎研究なものに乗っかって、より個別性の高いユーザー課題は自分たちが解くというふうに分ける意思決定の問題がすごく大事です。
そうすると同じ100のキャパがあったとしても、クラウドでまかなえるのに60のキャパを自社でなぜか内製して持っちゃって、4割しか（ユーザー課題の解決に）リソースを割けないというところよりも、そこはクラウド/SaaSに任せて、100のキャパをユーザー課題を解くことに使うというところではスピードが全然違うと思うんですよね。
フォーカスがスピードを生む
さらにもう1つ深ぼっていくと、技術意思決定力の一歩先にはビジネス意思決定力、ないしはユーザーの課題に優先順位をつける意思決定力みたいなものが必要になってくる。
アプリケーションサービスを提供していると何かしらのビジネスの構造がありますよね。ここのポイントでユーザーがアハ体験をするだとか、こういうロジックでユーザーが集まってきて継続利用してくれてお金を落としてくれるみたいなビジネスの流れがありますよね。で、基本的にそこにリンクする課題を優先して解く。
つまり巨人の肩に乗っかるか乗っからないかという意思決定のレイヤーと、どの課題を解くかという意思決定のレイヤーの2つが組み合わさるとすごいフォーカスが起こるわけですよね。100のキャパの人が100を1個の課題を解決することに使えると。このフォーカスがすごい大事で。
人間は複数の目標をそう簡単に追えないので。たとえば1年、2年のスパンを置いたときに、作り込める機能やKPIはせいぜい1個か2個くらいだと言われているんですよね。なのでそれを見つけて、それに必要な開発を効率よくやる。結果的にそれって、ユーザーから見たときにすごくインパクトのある機能が早く実装されていくので開発スピード速いねってなるわけですよ。
キャパが100どうしの人が戦っても、優先度決めが正しい、ないしはどの部分で巨人の肩に乗るのか乗らないかの選択が正しいかで差が出ますというところですね。
まとめると、環境に置いていかれそうで不安ですと。不安を感じる前に飛び込むというのがまず大事です。良い環境で働くことが大事で、良い環境には基礎体力を鍛えられる場があるというのと、良い環境は意思決定の精度が高いので、そのなかで働くと自然とその行動容態を真似することができる。そういうところで結果的にスピードが速くなるのかなと。そういう話でした。
※この記事は配信者の許可を得て公開するものです。
【追記】
他の関連コンテンツを見る：福島 良典の名言