エンジニアは消える。
Time is money
「アジャイル開発を再定義しよう。」
これは、僕が社員によく投げかける言葉だ。
アジャイル開発は、確かにウォーターフォールよりは優れている。しかし、新規事業という荒波を乗り越えるには、従来のアジャイル開発では、まだ"遅い"と言わざるを得ない。かつて僕が大手企業におり、新規事業に挑んでいた頃、このスピード感が、やはりボトルネックになった。
さて、大企業が新規事業を推進する上で、最も見えづらく、それでいて無視できないコストが存在する。それが、この”時間”である。
例えば、ベンチャー企業の創業初期の社長の給料を考えてみてほしい。多くの場合、大卒の新入社員と大差ないか、それ以下だろう。オフィスも自宅やカフェ、コワーキングスペースで十分事足りる。つまり、固定費といえどもレバーがあり、状況に合わせて調整が可能なのだ。
一方、大企業の場合はどうだろう。給料は良くも悪くも固定されている。（往々にして、収益化する前の新規事業に見合う給料ではないことが多い。）さらに、新規事業部は本社オフィスの一部で活動するため、家賃も変更可能なレバーではない。
そして厄介なことに、これらのコストは、往々にして"見えない"のだ。部署内ですら、個々人の給料に触れるのはタブーとされている。さらに家賃に関しては、本社オフィスの賃料を各部署に固定費として配賦するケースは皆無に等しい。
しかし、全社経営目線では、それらは確かなコストであり、そのサイレントコストの中で、各事業部には費用対効果を求めている。これは、新規事業部も例外ではない。
さて、そのような状況下にある大企業の新規事業部において、僕は同一期間内でコストを削減するのではなく、期間そのものを短縮することが、最も経済合理性が高いと考える。
何故なら、まず、先に述べたような理由の為、同一期間内で削減できるコストには限界があるからだ。（変更不可である上、可視化もできない。）次に、そんな中で無理にコストを削減しようとすれば、メンバーのモチベーション低下や、ステークホルダーからの質の低いアウトプットを招き、結果として競合に対する遅れを生み出す可能性があるからだ。
よって、必要な投資はしっかり行い、最高のパフォーマンスを追求する。一方で、その代わりとして期間を短縮する。
これが、僕が大企業時代に学んだ最適解だ。大胆に、しかしスピーディに。
そして、それをあらゆる事業で実現していくことこそが、僕らの「バクソク」の事業ミッションであり、僕らの存在意義なのだ。AIやPaaSを使い、アジャイル開発を再定義し、開発プロセスを爆速化する。新規事業における目まぐるしく変化するビジネスサイドの要望に、遅れることなくキャッチアップしていく。
Speed takes all。品質を落とさない爆速化こそが、自社の唯一無二のバリュー（USP）だと、僕は考えている。
<参考>
新規事業開発を３倍速で実現するAI搭載型開発サービス「バクソク」をリリース
データドリブンで意思決定を。
新規事業の開発において、もう一つ忘れてはならない重要な観点がある。それは、"データ"だ。
なぜなら、新規事業において、「リリースした途端にユーザーが爆発的に増え、事業が黒字化した」などという話は、奇跡に近いからだ。
だからこそ、プロダクトをユーザーに当てながら、PMF（プロダクトマーケットフィット）に向けて、改善を繰り返していく必要がある。
例えば、オライリー・ジャパン発行の「LEAN UX」によると、PMFを達成した後のAmazonでさえ、プロダクトをユーザーのニーズに適合させるために、11.6秒に1回の頻度で本番環境のコードを書き換えていたという。（その後、さらに改修頻度が上がり、今では1秒に1回の頻度で改善が繰り返されている。）
さて、おそらくは、細かく改善を回していくことの重要性については異論はないだろう。
ここで重要なのは、「では、どの方向に改善していけば良いのか」という視点だ。Amazonほどの規模の企業やスケールした事業では、当然のことながら分析チームが存在し、徹底的な分析に基づいて改善を回していく。一方で、新規事業やスタートアップでは、Google Analyticsで解析するのが精一杯ではないか。データベースまで連携し、ユーザー軸で細かく導線（流入とアプリケーション内の動き、それによるデータ変動等）を分析できているか？というと、答えはNOだろう。
しかしその分析をなくして、再現性のある顧客獲得には至らないのもまた事実ではないだろうか。URLに紐づく閲覧情報だけではユーザーの動向は観察できない。
そして、上記を達成するために必要なのは、可視化と課題特定である。流入経路を明確にした上で、プロダクト内の動きもすべて透明化する。各アクションに対してスクリプトが発火するように実装し、ログを蓄積する。必要に応じてデータベースに蓄積する。さらに、必要な全てのURLにパラメータを付与する。これらを、プロダクト完成後に後付けで行おうとすると、厄介である。しかし、開発の際にそこまで考えて設計しておけば、難しいことはない。
ただし、この可視化フェーズにおいて、ただむやみに情報を取得すればよいのかというと、そうではない。「課題を特定するための可視化であること」を忘れてはならない。つまり、ここで行うべきことは、目標と現実のギャップを明確にすることであり、それを細かく追う仕組みを作ることだ。そして、可視化による課題特定ができたら、それを改善の運用に回していく。
ようやく、ここまで来たら、あとは実際に課題を特定し、プロダクトを改善していけばよいということになる。僕たちは、これらの流れを、事業者の負担なく実現できる「バクソクボード」を作った。詳細は非公開だが、概念の説明としては十分であろう。
エンジニアの存在価値
さて、ではなぜ、これらの解析を、僕たちは開発者側から行うのか。確かに、仕様書通りに物を作ればリスクなく利益を得ることができる。しかし、僕たち開発者がなすべきことは、仕様書に沿った納品だけなのだろうか。
それは違う。
僕たちがコミットすべきなのは、事業の成功である。開発した事業がスケールしたかどうかが全てである。その観点に立った時に、これまで記載してきたことを、僕たち開発者側から用意することがいかに重要であるか。開発者が開発したプロダクトの評価なくして、開発者を評価することはできない。これは、顧客にとっても重要な視点であるが、開発者としての評価にも、ひいては僕たちの企業成長にも、決して欠かせない重要な要素である。
その一方で、日本には、自分が作っているプロダクトのKGIすら理解していないエンジニアやSIerが多く存在するという。これは明らかなチャンスであり、そういう角度から見るとブルーオーシャンが広がっている。
僕は、夢を語らない事業に興味はなく、目標を共有してこそ本当のONE TEAMの始まりだと思っている。クライアントの事業を受託し開発するのがメインであるが、関わっている事業において、ただの受託者に甘んじるつもりはない。開発物に伴走し続け、やるからには、勝つ。そのために最高のチームを作り上げていく。
さて、少し話が逸れるが、先日アリババのグループ企業が、プロンプトからの実行指示のみでアプリケーションを構築するAIを開発したそうだ。
<参考>
わずか数分でアプリを開発。アリババ、大規模言語モデルを用いた「AIプログラマー」発表
これはほんの一例に過ぎず、これからどんどん、今のエンジニアがやっている作業が、AIに変わっていくのだろう。コードを生成するなんて、LLM（大規模言語モデル）の最も得意とするところだ。人間が描くよりもシンプルで、解読しやすいコードを、人間よりもはるかに早く、ミスなく書くことができる。
こんな時代の中で、意志なき開発は無価値になる、というのが僕の主張だ。開発物の成功を考えず、リスクばかり気にして、仕様書を戦略的に書き上げている開発会社は、もはや無価値なので今すぐ市場から撤退すべきだ。
その代わり、僕たちがプロダクトに意志を込め、データを分析し、熱量を注いでいく。それが僕たちの成すべきことなのだ。
日本ではまだ現実感がないかもしれないが、実際に、僕たちBiz Freakの中で、コードをゼロから書いている人間なんてもはや存在しない。もし仮に、うちでAIやPaaSを使わずにコードを書いていたら、暇だと思われ膨大な仕事がふってくるか、給料が下がる。しかし、だからこそ、３ヶ月程度の期間があれば、Biz Freakでバリューを発揮することができるわけだ。
本当の意味での、エンジニアとは、熱量であり、思いであり、人である。それが僕たちだ。それこそが、AIにできない領域であり、且つ市場では永久に枯れないニーズであると、僕は捉えている。
今、世間一般でいわれている"エンジニア"は、今後間違いなく、消えていく。開発をすることを目的にフレームワークや言語に不要にこだわり、車輪の再発明をするロールは、市場から不要になる。今日のエンジニア市場をスコープに、市場価値を考えて、ある意味戦略的にキャリアを築いてきたエンジニアは、そのまま停滞する船に取り残されることになる。
それとは別の潮流で、Bizdevと"エンジニア"の領域はどんどん溶けて無くなっていく。「アウトプットが何であり、どう社会課題を解決するのか？」のみに主眼は絞られ、上記とは別の競争が生まれていく。
そして、それとともに、エンジニアは、プロダクトのKGI・KPIの理解はもちろん、開発におけるROIを常に意識するようになり、その観点からフレームワーク選定・開発物の選択を行っていく。そんな、僕たちが考えるエンジニアが、きっと市場を席巻していくのである。
