お久しぶりです。@bussorenre です。 カンファレンスにプロポーサルを登録して登壇するのは、多分初めて…？
スライドは以下の通りです。
マサカリビュンビュンビュン、投げられて滅！にならないようにかなり綺麗にしたつもりですが、おかしいよってところがあれば指摘がいただけると助かります。
老朽化するドメインこそチャンス
短期的な目線として、生成AIの進歩はものすごい。
生成AIの力を借りて、今まで自動化できなかった分野を自動化出来たり、今までの精度をはるかに超える精度をはじき出せていたりと、本当に凄い、と言うのは疑いようがない。自分がその分野の専門ではないので必死にキャッチアップを進めているが、しかし、そのたびに「これ計算量頭おかしくない？」という事に疑問を持つことが多い。
確かに、GPUの進化はものすごいし、ハードウェア的にもソフトウェア的にも10年前にCUDAが世に出た頃と比較して、比較にならないくらいとんでもない進化をしたのは間違いない。一方で、計算量のごり押しで何とかしている部分も多々あり、効率的とはあまり思えない。大手ベンダーの先行投資のおかげで安く使えているが、これが投資フェーズから回収フェーズに移った際に、それが本当にリーゾナブルな価格で恩恵を得られるのか、疑問に思うところがある。やはりベンダーロックインは怖い。
最近、あらゆるものが老朽化しているなと感じる。物理的なインフラだけでなく、ソフトウェアも、社会制度も、人口動態も、人々の価値観も、そして私自身も。
老朽化は勿論悪い意味で使用している。「技術的に枯れている」と言うと悪い言葉のように聞こえるかもしれないが、大きな新しい変化が無く、目新しくはないけど安定していて、安心して利用できるという意味もあるが、老朽化は老朽化だ。本来、新しい部品に置き換えて整備したり、耐久年数を超えている物は新しい物に置き換えないといけない物を、その年数を超えて無理やり動かしている、という時に利用するイメージがある。産業革命から始まった人口爆発もいよいよ終盤に差し掛かり、何もかもが右肩上がりで成長していく時代から、必要な物とそうでない物を選別していく時代に入っていることは間違いない。
さて、壮大な前置きを書いたところで、最近、真剣にソフトウェアの老朽化に向き合わないといけないな、と思う事例が周囲で増えて来たように思う。
使用している環境が既にEOLなのにアップデートてきていないといった初歩的な事例から、事業ドメインが大きく変化したのにも関わらず、当時の事業ドメインを引きずったまま負債となってしまったパターンなど、その課題は多岐に渡る。ソフトウェアがあらゆる面で老朽化している。
ここ10年くらいを振り返ると、老朽化した物に蓋をして、腐敗防止層を定義してコンテキストを分け、境界線で区切られた中だけが「キラキラでピカピカ」なソフトウェア（組織）になっています。という事例が大手を中心に多かったように思う。それはそうで、まだまだ業界は成長産業の中、過去のしがらみにとらわれていては時代の波に乗っていけないので、組織構造ごとズバット切り分けて考えていきましょう、というのは至極当たり前のムーブだったと思う。
が、ついに蓋をしていたものを何とかしないといけない時期が来ているように感じる。成長産業から成熟産業に移っていく中で、大事になってくるのは「投資力」ではなく「コストカット力」。つまり、効率化・省力化である。「粗大ごみを捨てるのになんでこんなにお金がかかるんだよ」と若いころの私は叫んでいたが、それと似たような事が、これから加速していくと思っている。
設計思想が古くて、保守工数が多くて、若者にも人気が無くて人員の採用が難しい。そんな技術スタックを持ったソフトウェアは今すぐ何とかしないといけない。
と、ここまでなんかすごい悲観的な雰囲気の文章を書いてきたのだが、これは私はチャンスだと考えている。
老朽化するまで長期間使われてきたソフトウェアであるという事は、それだけ需要も大きく、事業に貢献してきたソフトウェアであるという事である。つまり、今後10年も事業に貢献し、価値を生み出し続ける可能性が高いと思う。
2010年代のような、とにかく新規サービスを生み出して新規事業の拡大を狙っていくぞ！という時代が終わったとは思わない。まだまだ新規サービスを生み出していく余地は十二分にあると考える。が、ある一定、落ち着いたとは思う。そしてそのパラダイムの変化にこそ、チャンスがあると思う。
生成AIといった最先端の分野は優秀な若手に任せて（もちろんワシも負けへんでという気持ちは捨てずに）、優秀な若者に「なんでこのシステムこんなにレガシーなんだよクソが」って言われて逃げられないようにするのが、おじさんになった私の仕事だなとも思う。そして、そんな汚れ仕事は誰もやりたくない。だからこそチャンスだと思う。
自分は運が良かった
2024年。自分が思っていたよりも早く世界が動いている。
自分の心の時間が2018年で止まってしまっていて、前に進めずにいる。という主観的な理由もある。しかし、それとは関係なく、そもそも世界全体の見通し以上に動きが早いという、マクロ的な視点もある。
常々、自分は「運が良かった」と思っている。
「運が良かった」要因は大きく三つ。
最も大きい要因として、「好きな事/得意な事」が「成長産業」に近い分野にあった事。しかし、これはもう終わりつつあり、IT業界は成長産業から成熟産業に移りつつある。自分が思っていたよりも急速に成熟産業に移っている。非常に危機感を覚えている。
次に、世界の流れが追い風だった事。全体的に見れば世界は平和だったし、日本は好景気のサイクルの中に居た。好景気。と言っても、大規模金融緩和の中で無理やり発生した好景気の中に居ただけなので、それが良かったかどうかはさておき、その恩恵は多分に受けたと思う。
最後に、若かったこと。「若いうちの失敗は取り返しがつく」とよく言うが、本当にその通りだと思う。若いうちの失敗は取り返しがつきやすい事は間違いない。
しかし、これらはまさに生存者の「生存バイアス」である事を肝に銘じて、次の30年、60年に備えなければならない。私を助けて来たこれらの「運」は、もうない。４度目の失敗は、それこそゲームオーバーだと真剣に考えている。「死ぬまで生きる」を全うできないかもしれない。
運が味方をしている内に優位を取れればよかったが、私はそれが出来なかった。
だからこそ悔しい想いをしていたのだが、だからといって諦めたら本当にそこで試合終了である。勤めて冷静に、かつ直勘を信じてまっすぐ行かないといけない。寄り道している暇がもう多分ない。
まず、自分という個体が持つリスクを徹底的に下げていくしかない。今まで解決できなかった自分の問題を徹底的に解決しないといけない。なりふり構わず、それをなんとかしないといけない。
自分が前に立つしかない
やはり、同じ失敗を３度もしたのは非常に良くないと考えている。
１度目は偶然かもしれないが、２度目があった時点で再現性のある失敗であり、３度目の失敗は、その反省を生かせていないか、地震や災害のような物で、数年周期で必ず発生するものと考えなければならない。４度目の発生を防ぐために。あるいは発生しても、そのダメージを抑えるために、抜本的に、自らの性格・あるいは生き方・あるいは環境。何らかの構造の変革が必要だと考なければならない。
私は運がいい。なんせまだ元気に生きてるし。万全、とまでは言わない物の、85%くらいまで回復してきた。
だからこそ、次こそは天に見放されるかもしれないと想定しなければならない。今まで頼ってきた道しるべとは違う道を模索して、生きていく必要があると考える。
その中で、一つ考えていることがある。
もう「自分が前に立つしかない」という事。
世の中には、経営センス・技術力・プレゼンス・人脈・学歴に優れている人がたくさん居る。 どんなジャンルのどんな分野でも、私より優れた才能を持つ人は、文字通り五万といる。
だから、その「私より優れた才能を持つ人」にリーダーを任せ、自分のなすべきことを進める事こそが、 最も賢く・正しい意思決定を組織にもたらしてくれると考えていた。
実際に、新卒で入ったリクルートと言う会社は、まさに「優れた業績を収めた者にリーダーをさせよ」という文化であった。それでリクルートという企業は非常に上手く回っていたんだと思う。人材市場での採用競争が激化し「優れた業績を収めた者」をリーダーに据える事が出来なかった組織から腐敗し、解体されていくのは何度も見た光景だったからだ。
しかし一方で、「優れた業績を収めた者にリーダーをさせたからダメになった」例もたくさん見てきた。ビジネスにおいて「優れた業績」は結果論でしか無く、運の要素も非常に強い。再現性のない成功はそのまま「生存者バイアス」となり、正しく現状が再認識されないまま、部下を疲弊させ組織が崩壊してきた例もまた、たくさん見て来た。
先駆者であったり、上司や先輩、組織のリーダーの言う事が正しいとは限らない。
もちろん、正しい時の方が圧倒的に多い。なぜなら、そこに至るまでに様々な経験や知識が蓄積されているため、より合理的な判断が下せる確率が高いのは間違いないだろう。しかし、人間である以上、所詮は天然のタンパク質でできたディープラーニングに過ぎない。学習していない物は上手く生成できないし、過学習の結果、丁度いい塩梅を超えた物を生成してくることだってある。
私の1/3生（半生と言うには早すぎる）を振り返ると、心身を壊すような失敗を三度した。
その３回はいずれも全部、「自分はAだと思うが、どうしてもBだと言うのならそっちを信じたい」と言う場面で起こってきた。 「リーダーを立てる」とはそう言う事であり、組織とはそう言う物なのだと今でも信じてるし、間違っていないと思う。
「思考停止しているだけではないか」と言う声も聞こえてくるかもしれない。その通りである。組織を前に進めるために思考停止したのである。船頭多くして船山に登る、船を進めるために、思考を止めたのである。集団の優先度を上げ、自己の優先度を下げたのである。そして、その意思決定と行動をしたのは、他ならぬ自分自身であり、その失敗の原因と責任は全て自分にある。
私は、自分の意思を曲げ過ぎた。友人・家族・組織。あらゆる人間関係で、自分の意思を曲げてきた結果が心身の崩壊であり、その反動が「1年間、誰とも関わらなくて平気」という異常な状態を生み出したのだと考える。これは、私個人の性格の問題であり、「それがbussorenre君の良さである」と評価してくれる人も居れば、「それが君の弱みでもあり付け入る隙を与えやすい」と注意する人も居る。
元々持つパーソナリティと、ポジションが付与するパーソナリティを合成することで、きっと、丁度いい塩梅になるのではないか。 自分の希望・わがまま・身勝手。そう言ったものをどんどん主張して、自分の意思を曲げ過ぎない事。かつ、集団のために意思を曲げ過ぎてしまう性格を生かす。
と考えた時に、「自分が前に立つしかない」という結論に至った。
「前に立つ」にも色々と方法はある。一応多分きっと私は分類上エンジニアなので、エンジニアリーダーとして、プロフェッショナルリーダー、テックリード、はたまたエンジニアリングマネージャーなど、前に立つ方法は色々ある。しかし、極論を突き詰めていくと、やはり事業を起こしてその代表をするところに集約されていくと思っている。
最も、優れた起業家なんて物は、「会社作りたい」と思った時点でもうすでに会社を作り何らかの事業を行っているのだろうが、私はそうではない。会社経営が向いているなんて思った事は一度もない。しかし、世の中には「雇われ社長」という言葉があるのだから、なんらかの後天的な学習によって、そこを成す事は出来るかもしれない。起業は若いうちにやれと言うが、EXITは50代でやれと言う声も最近よく聞くし。幸い、私の知人には起業家が結構な数居るので、ノウハウは手に入りやすい。
４度目の失敗になるかもしれない。
しかし、どうせ後は死ぬまで生きるだけなので、やってみて損は無い気もする。
前に立つときに一番大事なのは、後ろから刺されない事。
後ろから刺される不安を持ったまま前に立つことはできない。なので、次は、後ろからしっかりヒールしてくれるアコライト（ネタが古い）を探すことから始めていく。
リクルート退職した
こんにちは。はじめまして。そうでない方は大変お世話になっております。 @bussorenre です。
表題の通り、リクルートを退職しました。 2015年に新卒で入社して6年半近く居たことになります。
大企業を辞めたとなると、「なにか悪い理由があるんじゃないだろうか？」と邪推されがちですが、残念ながらそのようなご期待に沿う事は出来ません。むしろ、リクルートのOBOG、あるいはソフトウェアエンジニアを中心としたIT界隈の人達からすれば「なんで６年半も長いこと居たの？」という事が気になるのかなと思います。自分の反省と今後の展望を世界に垂れ流させていただければなと思います。
なぜ6年半も居たのか？（あるいは、6年半で辞めたのか）
まず、リクルートには「フロンティア」という退職金制度があり、これは一定期間の勤続年数を超えて退職すると、退職金が跳ね上がるという制度です。世間一般で言う早期退職制度のような物です。大体みんな退職金ボーナスを受け取るタイミングで退職します。（定年退職者が居ないと言われる理由の最も大きな理由がこのフロンティア制度なのではないかなと自分は考えています）
この制度は雇用側の視点に立つと、お金はかかるけど人材の流動性を確保し若返りを達成しつつ、かつ退職タイミングを見極めやすいという点で優れています。日本では正社員を解雇する事は非常に難しく、多くの企業が若返りに失敗する中、リクルートはかなり若い人を中心に回っています。
しかし、個人の視点に立つと、6年半というのは非常に長い期間でもあります。特に新卒でリクルートに入社する人は、将来的に起業を目指している方が非常に多く、「実践的な経験を身につける訓練所」として認識している人が強いです。そんな人達にとって6年半は非常に長く、ほとんど３年以内に辞めてしまう会社でもあります。
しかし、それが悪い事かと言われるとそうでもないと思っており、辞めていく同期を見送る際も「自分のやりたい道が明確になったのか。すげーな。頑張れよ」という気持ちで過ごしてきました。
同じグループ企業だけど、全然違う会社を３社経験したと思ってる
長い間いることになった理由は「自分が独立したり転職してまでやりたい事が明確ではなかったこと」もあるのですが、「新規事業開発室」「RMP」「Quipper」という全く毛色の異なる組織に属していたことも関係しています。
大企業ならあるあるな話ですが、事業部が異なれば当然そこにいる人も文化も変わるわけで、部署異動は、別の会社への転職と同じくらいインパクトのある環境変化でした。同じ「リクルート」というグループ企業ですが「新規事業開発室」「RMP」「Quipper」では大きく異なりました。最後のチームは某動画配信サービスからの転職者が多く、実質４社分の文化を経験したことになります。（本当か？
特に RMP のエンジニア組織は私にとっては非常に居心地がよく、同時にソフトウェアエンジニアとしても大きく成長させていただいた組織であります。上司・同僚の皆々様には感謝をいくら述べても足りないと思っております。
新規事業開発部から、RMPのチームへの異動を推薦をしてくださった竹迫先生（セキュリティ&プログラミングキャンプ 2009 の講師を担当してくださった恩師でもあり、社内のエンジニア組織のリーダーとしても私を育ててくださった恩師でもあります）。
前部署での失敗を引きずっていた私に「bussorenreくんには休憩と、自信をとり戻す時間が必要だ」と長い目で見てマネージャーを務めてくださった @rtsutakiさん。
「bussorenreくんは絶対Scalaのセンスがある。書けばわかる」とScalaチームに推薦してくださった、@ainoyaさん、@ma2k8さん、@mpon さん。
Scala 始めたての頃、非常に多くの私のコードをレビューしていただいた @y-yu さん
チームリーダー・スクラムマスターに推薦してくださった、マネージャーの皆様。
全然未熟なリーダーでしたが、一緒にチーム開発を走っていただいた、案件チームの皆様。バックエンド開発を中心としたScalaチームの皆様
最後、退職前のうだうだにマネージャーとして付き合ってくださった @suikwasha さん
あまり書くとエンジニアが全て列挙されてしまうので、よろしくないと思って端折ってしまって申し訳ありません（最初は全員列挙してたんですが、いやそれはそれでアカンなと重いバッサリ削除しました…）。ですが、開発チームの皆様には本当にお世話になりました。
コロナ渦で直接ご挨拶できなかったので、この場を借りて大きな感謝を申し上げます。
控えめに言って最高のエンジニア組織だったと思ってます。
なぜそんな最高のエンジニア組織を辞めるのか？
少なくとも私にとってはオアシスのような環境で幸せに暮らしてきたわけですが、この環境が成り立つためには大きく２つの条件が必要だと考えています。
- 事業が儲かっていること（成長していること）
- 高度に自己組織化されたチームであること
まず、金を稼ぐことは必須です。どんなに良いエンジニアを良い給料で雇用しようと思っても、事業が成功していなければ話になりません。私が所属していたチームはまさに成長の中にある事業でしたので、エンジニアに限らず、企画・コンテンツ製作・営業とあらゆる人材リソースに投資されていました。
一方、成長性がないと判断された事業は潔く撤退します。その判断の速さはリクルートの素晴らしいところなのですが、そうなったら後は滅びるだけです。そこで培った文化もプロダクトも除却を待つだけです。これはあまりにも寂しいし辛い。自分達で作ってきたサービスに自ら鉄槌を下す経験を何度かしてきました。
また、高度に自己組織化されたチームでないと、そこはただの温泉になってしまいます。つまり、自ら意見を持ち目標を立て、プロダクトの成長を技術視点で提案し実行できないと内製エンジニアに価値はなく、言われたことを作るだけのエンジニアになってしまうと、「じゃぁ外注のほうがコスト安いしオフショアでもやる？」となってしまいがちです。
「高度に自己組織化されたチームが事業の成長に貢献する」という状態になって初めて心理的安全性を生むチームとして成立します。
「自分は先輩や上司が築き上げてきた組織に乗っかっただけで、もしそのような環境がなくなれば死を待つだけだったのではないか？」という疑問が２年前くらいから生じていました。そうなったら転職ガチャを引けば良いのかもしれませんが、そこはエンジニアらしく、0から作ってみたくなったというのが、第一の退職理由です。
２つ目の理由として、上記の疑問を持ち始めたのと同時期くらいに、同期がだいたい辞めて居なくなりました。前節で述べたとおり、リクルートはやりたいことが見つかった奴から退職する会社ですので、「起業して会社が当たったら焼肉おごってくれ」くらいのノリで見送っていたのですが、いざ自分ひとりになると、さて、どうしたものか。と思い悩むようになりました。30歳になった今年、「もう30歳か。人生意外と短いかもしれないな」と感じ、「どうせ短いなら盛大にチャレンジしてから死のう」と思って会社を退職しました。
ソフトウェアエンジニアとしての成長ももちろんでしたが、ビジネス的な観点での成長。特に新規事業開発室に２年近く居たことは、かなり多くの視点を得て勉強になったと思っています。当時は事業リーダー達の思考プロセスが全然理解できず苦しんでいたのですが、今ではそれがわかると言うか、「あ～昔先輩たちが言ってたことは、こういう事だったのか！」と、毎日のように再発見を繰り返しています。
何人もの同期がベンチャー企業の経営層として奮戦しており、先を行く同期という存在ほど得難いものはなく、そのような様々な出会いがリクルート時代にあった事は感謝してもしきれないと思います。
退職して何をするのか？
ジザイエ という会社をやっています。今の所VPoE というポジションを担っていて、CTOは現在空席です。将来的に自分がCTOを名乗るかもしれませんし、別のメンバーが担当するかもしれませんし、外部から招致するかもしれません。完全に未定です。が、今現在は、ソフトウェアエンジニアのチーム全体のリーダーという立ち位置になります。
会社自体の説明がまだ難しく、多くのことを語るための準備を目下進めている、というステータスになります。（でも、ベンチャー企業が半年後に事業転換してることなんて当たり前だし、昨日までやってきたことと違うことを始めることはわりと普通だから、とりあえず今の状態を伝えたら良い気もする…？？？ ZENNA というサービスを運営してまして、それについてはぜひ 事業成長を加速させる開発業務に携わるフロントエンジニア募集！ - 株式会社ジザイエのWebエンジニアの採用 - Wantedly などをぜひご覧ください。エンジニア募集しております）
また、それはそれとして「エンジニアの育成」の活動にも再び注力していきます。これは僕の個人事業になります。 色々な方に手を差し伸べていただきながらここまで来れたので、少しでも誰かの力になることができれば、という思いでさせて頂いております。
具体的には Tech Train さんに、メンターとして登録しています。 https://techbowl.co.jp/techtrain/mentors/39
幅広く質問を受け付けておりますので、お気軽にご利用ください。
おわりに
ベンチャー企業の殆どが失敗すると言われている中、周囲では起業チャレンジャーが多く、当初はそのモチベーションの理由がわかりませんでした。成功している人もいれば失敗している人もいる。失敗しても何度も挑戦し続けるメンタリティは自分には真似出来ないと思ってました。しかし、今ではその理由がわかります。
結局、自分がやりたいことをやるには自分で環境を作るしかないのです。自らの生存に適した環境を生み出してきたからこそ、挑戦者は生存者なのであり成功者になり得るのだなと。 生きるためにやるのです。人生は短いのです。元気に生きていればこそ出来ることです。
失敗する気は毛頭ないけど、失敗したら笑ってケーススタディの一つにしてください。成功したらみんなで焼き肉だ！！！！
coordinate compression - 座標圧縮
アルゴリズムの概要
任意の配列の大きさの順序を保ったまま、その値を小さくする（圧縮する）
例えば、以下ののような配列があったとすると、座標圧縮によって
のように値が小さくなる。
以下の手順で実現できる。
- A を コピーして別のコンテナ（A'）に移し替える。 （
a_dash = aでも、copyでもどちらでもよいと思う。） - A' を昇順にソートし、重複を排除する。（重複を排除するには、
eraseとuniequeを組み合わせることで実現できる） - Aの各要素A[i] に対して、
サンプル実装
#include <bits/stdc++.h> #include <algorithm> using namespace std; #define rep(i, n) for (int i = 0; i < (n); i++) #define long long ll #define all(a) (a).begin(), (a).end() /** * cordinate compression - 座標圧縮 * 関係性を保ったまま、値を小さくする操作の事 * * Order(N logN) * * 例 * A = { 8, 3, 5, 2} * A'= { 4, 2, 3, 1} * * Aの順序を保ったまま、値だけを小さくしている **/ int main() { // 入力例を用意 vector<int> a{8, 3, 5, 2}; // A をコピーして退避させる。 vector<int> a_dash = a; // A' を昇順でソート sort(all(a_dash)); // A' から重複した要素を削除する a_dash.erase(unique(all(a_dash)), a_dash.end()); // Aの各要素A[i]に対して // A' にA[i] が存在する場合、そのイテレーターを取得する。 // Aの最初の要素のイテレーターで引くと、圧縮された値を得ることができる。 rep(i, a.size()) { a[i] = lower_bound(all(a_dash), a[i]) - a_dash.begin(); cout << a[i] << " "; } cout << endl; return 0; }
ABC 213 C - Reorder Cards の反省
この問題の肝は、縦と横。すなわちA[h]とB[w]が独立しており、A[h]に対して座標圧縮、B[w]に対して座標圧縮をすればいい。
そこまでは分かっていたが、肝心の、座標圧縮がかけずに敗退……。
（そもそも座標圧縮という言葉すら知らなかった笑 やろうとしていたことは近いと思う）
Submission #24884196 - AtCoder Beginner Contest 213
おおよそ同じようなことをしようとしていたのだが…、詰めが甘い部分が多い。
また、「読み込んだHとW使ってなくね？あれ、俺の考えているアルゴリズムは間違っている…？」と思って思考をこらせてしまったのがよくなかった。もっと自分の考えたアルゴリズムを信じるべきだった。
調べなおして、書き直した結果がこちら。
Submission #24901109 - AtCoder Beginner Contest 213
