個人開発から失われたもの。AIで前職のマネジメントに戻ってきた話

前職はスタートアップの役員をやっていました。役職はCOO、組織のナンバーツーみたいな立ち位置です。

正社員は大体40人くらい。会社全体を見る役割で、管理部以外はほぼ全部監修するような感じでした。

複数プロダクトの責任者として、営業、カスタマーサポート、開発、デザインあたりも、最初は僕が部長を兼任していました。社員が成長してくるにつれて各部署に部長を立てて、そこから僕は離れていく形です。

COOって結局何をする人なのか、というのは議論にはなるけれど、一般的な認識はそんなにないと思うんですよね。

僕として明確にこれかなと思っているのは、会社のボトルネックになっていることをどんどん解消していくことです。

この部署とこの部署の仲が悪くて、それがいろんな問題を引き起こしているとわかれば、そこを解消しに行く。この新しいプロダクトの売上を出さないと資金調達も採用もできない、となればそこをやりに行く。

そういうボトルネックって、放っておいても解消されないことが多いんです。だから役員が主導権を持たないと動かないことが多いんですよね。

ちなみにCEOは何をする人かというと、旗を立てることかなと。「この会社はこういうものを目指すんだ、みんなここ目指して頑張ってください」と旗を立てるのがCEOの役割で、僕の中では割ときれいに棲み分けされていました。

役員になると、自分がやるべき仕事は何かを考えるときに、自分がやりたいことは完全に切り離して考えるようになります。

権限があるので、やりたいことをやろうと思えばできてしまうんです。だからこそ「これやりたい、楽しそう」でも、自分がやるべきでなければ他の人に任せる。

意味のなくなった定例会議を自分の一存でなくしたり、短時間で議論したいから急遽合宿を組んだり、新しい部署を作ったり。会社にドラスティックな変化を与えられるのは、エキサイティングではあるんですよね。

一方で、日々のルーティンの仕事は面白くないと言っていいんじゃないかと思います。これはそんなに個人差がない気がします。

社員には権限を渡していて、その範囲では相談なく進めてくれます。だから相談や報告が回ってくるのは、基本的にトラブルなんですよね。

システムのバグが起きたら、調査させて、お客さんに連絡を入れて、結果がいつ出るか確認して、ふさわしい人に託す。クレームも状況を整理させて、考えて指示を出す。

自分が現場に乗り込むのは本当に緊急事態だけです。コードを見たり、営業とお客さんのやりとりを全部読んだり、一次情報を取りに行く。

社員の話がある意味で信用できないというときだけ、一次情報を確認しに行くんです。毎回それをやっていたら、自分がやるべき仕事に時間を割けなくなるので。

だからエキサイティングではある一方で、ルーティンが仕事の半分以上を占めたりするので、辛い、面白くないことも多いわけです。

その一方で、趣味の個人開発はすごく楽しかったんです。2020年、2021年くらいからずっとやっていました。

自分でコードを書いて動かして、ユーザーが増えて問い合わせが来ても、その内容とどうしたらいいかが手に取るようにわかる。「あ、あのif分のところ間違えてたわ」「あの条件分岐でこのケース考慮してなかったな」というレベルでわかるんですよね。

これは役員の仕事とは全く違います。役員のときはシステムトラブルが起きても、エンジニアに聞いて「そういう実装で、こういうことが起きるとこうなっちゃう」と理解する。

その理解のレベルが、自分でコードを書いているときとは全然違うんです。個人開発は最高だと思っていました。万能感があって、ものづくりをしているなという手触り感がすごくあって。

だからバランスが取れていたんですよね。組織にドラスティックな変化を起こすエキサイティングな仕事をしつつ、役員の仕事にはない手触り感を個人開発で摂取する。それで精神的にも楽しく過ごせていました。

独立して1年半くらい経ちますが、法人化したとはいえ個人でやっているので、いまも個人開発のままです。

ただ、独立する前くらいから、個人開発は変わってしまいました。AIで作るようになったんです。

最初はAIに実装させて、合っているか怖いのでコードレビューして、ここ間違ってるよと指摘していました。でも、そういう指摘をすることは、ここ1年くらいはないんじゃないですかね。

いまはどうしているかというと、僕はエンジニア上がりでもないので、コードレビューはしていません。

代わりに、まずどのモデルで実装したかを確認します。フルパワーのモデルで回し続けるとすぐリミットが来るので、軽い仕事はトークンを食わないモデルで、間違えたくないところには高級なモデルをあてがう。だから、その実装がどのモデルなのかを気にしています。

あとはどんなテストを通したか。そして僕が一番気をつけているのが、どんなことを考慮に入れて実装したのかを聞くことです。

たとえば課金周りを実装するとき、プランが3つあって、1つ目から3番目に一気にアップグレードすることは考慮しているのか。3番目から2番目にダウングレードするとき、データはどうなると思っているのか。

そういう、実装に関連して考えなきゃいけないことを、これは考慮したのか、どういう状況になってそれがどう変化するのか、と結構ちゃんと詰めるんです。でもコードは全く見ていません。それで判断してプルリクをマージしています。

丸投げではないんですけど、エンジニア上がりの人とはレビューのポイントが違うかもしれないなと思っています。

これが、人のマネジメントと同じになってきたなと感じるんです。

役員のときも、コードの中身はわからない。でも信頼しているエンジニアが言うなら、自分でコードを見に行くより話を信じたほうが正確だし早い。

どんなことに気をつけて実装したのかさえ確認できれば、自分がコードを見るべきではない。これは役員の時に培ってきたスキルでもあるなと思います。

人とAIのマネジメントは、すごく似てきているんですよね。最初は全然違うスキルだったのが、『Opus 5』くらいから変わってきました。ポカミスをしなくなったので。

違うところはもちろんありますが、そこはAIのほうが優れていることが多い。スピードが速いし、文句を言わないし、ものすごく詳しい。一緒に飯は食えないし、今週のワンピースの話はできないんですけどね。

役員の仕事が面白くないと思って個人開発をしていたのに、気がつけば謎に前の仕事のやり方に戻っていて。そしてその経験が役に立っているという、不思議な状況です。

いまは問い合わせが来てもパッとコードが思い浮かびません。仕様がすぐわからないから、「この辺怪しいと思うけど、もしかしてこういうこと起きてないか」とAIに聞いて回答する。これは社員に確認していたのとほぼ同じやり方です。

だから個人開発からは、ものづくりの楽しさが失われたんだと思います。組み立てられていく速度があまりに速いので。前のほうが楽しかったのは楽しかった。でもそれはしょうがないですね。

ただ、他の楽しさは残っています。お金が稼げるかもしれないこと、ユーザーに感謝されること、全部自分で決められること。組織の看板を使わずにやるので、自力でやってきているぞという自信もつきます。

もともと個人開発は、趣味として完璧だったなと思うんです。ものづくりの楽しさもあったわけですから。それでも、いまでもこれほどいい趣味はなかなかないと思うので、全然楽しいんですけどね。

最近よく思うのが、周りのソフトウェアエンジニアがハードウェアに興味を持ち始めていること。『3Dプリンター』とか、小さいロボットを動かすとか、基板を作るとか。まだものづくりの楽しさがそっちに残っているから求めているのかなと。

だから個人開発が楽しくなくなったという人は、ものづくりの楽しさだけ、ちょっと他で解消したほうがいいのかもしれません。盆栽とかでもいいのかもしれないし。

最近、家のベランダで家庭菜園をしていて、これが結構いいんです。なんでこんなにいいのか、あまり言語化できていないんですけど。

土を買ってきて、種をまいて、水をあげて、風が吹いてきたらどう支えてあげたらいいか。種によって支柱が必要なものとそうでないもの、どのくらいで間引くのがいいか、調べながらやっています。

野菜ってちょっとずつしか成長しないから、それが面白いのかもしれないですね。ものづくりの楽しさを、いま僕は家庭菜園で摂取しているのかなと思います。

そういうのが見つかると、いいんじゃないかなと思いました。ありがとうございました。

まとめ

役員の仕事に手触りがなくて個人開発に楽しさを求めていた僕が、AIで作るようになって、気づけば前職のマネジメントと同じやり方に戻っていた、という話です。

• COOの仕事は会社のボトルネックを解消すること。エキサイティングだが日々のルーティンには手触りがない
• AI開発ではコードを見ず、どのモデルで、何を考慮して実装したかを詰める。これは役員時代のマネジメントとほぼ同じ
• 個人開発からはものづくりの楽しさが失われたが、お金・感謝・自分で決められることといった楽しさは残っている
• 失われたものづくりの手触りは、家庭菜園など別のところで摂取するのもいい