このページの本文へ

前へ 1 2 次へ

SHIFT川口耕介氏と語るソフトウェア開発の本質、世界との闘い方、パラシュート人事のつらみ

成否は朝ミーティングで決まる 一休CTO伊藤直也氏が、はてな時代から学んだチームビルディング術

2025年01月27日 17時00分更新

文● 福澤陽介/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

 SHIFTは2024年11月、同社の技術顧問を務める川口耕介氏が“いま話したい人”をゲストに迎える対談イベント「SHIFT EVOLVE もっと良くなる日本のIT」の第2回を開催した。

 SHIFT EVOLVEは、エンジニアのコミュニティ活動に注力するSHIFTが手掛ける技術イベント。今回、“Jenkinsの父”として知られる川口氏が対談者として選んだのは、新卒入社したニフティでブログサービス「ココログ」を立ち上げ、その後CTOを務めたはてなでは「はてなブックマーク」の開発を主導、2016年には一休のCTOに就任した、伊藤直也氏だ。

 伊藤氏が過去の経験から得たチームビルディングの秘訣などが語られた、この対談の様子をお届けする。

川口氏と伊藤氏は今回が初対面

プロダクトを一人で作った経験が、開発チームを導く源泉に

SHIFT 技術顧問 川口耕介氏(以下、川口氏):伊藤さんがはてなに在籍されていた頃は、伊藤さんの影響もあってか、エンジニアリングコミュニティが情報発信することに向き合い始めた時代でした。

一休 CTO 伊藤直也氏(以下、伊藤氏):今でこそ毎日どこかで勉強会やカンファレンスがありますが、はてなにいた15年前は、これほど頻繁になかったですね。開催されても、いつも同じようなメンバーで、必然的に仲良くなるという時代でした。たまたまこうしたコミュニティの中で、発信する機会を多くもらって、結果的に名前が知られるようになりました。

川口氏:技術だけじゃない、エンジニアでしか語れないマネジメントの話も発信されていたのが新鮮でした。

伊藤氏:マネジメントについて発信することは、僕にとっては特別なことではなかったです。当時のコミュニティが何によって結びついていたかというと、ブログ。SNSが登場する前になるので、自分の存在を他の人に知ってもらう方法は、ブログを書くことでした。今よりも私的なテリトリーを扱うサービスはなかったので、テクノロジーのことも、趣味のことも、マネジメントのことも書いていました。

一休 CTO 伊藤直也氏

伊藤氏:(自身の経験の特徴は)プロダクトに必要なものを、上から下まで自身で作った経験があることです。一人で実装して、デザインを考えて、なんなら運用やインフラ構築までする。当時の普通のエンジニアとは違う感覚を持っていたかもしれないですし、少なくともそれが、今の仕事においても重要なパーツになっています。

川口氏:初期からプロダクトに携わることの特権でもありますね。

伊藤氏:その感覚がどう活きているかというと、僕が開発チームをみる中で「良いチームかどうか」の判断軸になっています。良いプロダクトが作れるチームは、コミュニケーションの在り方とか、ミーティングでの改善のリズムとか、テクノロジーに対する妥協のなさとかがぎゅっと詰まっている感じがする。

 それは、僕が上から下までプロダクトを一人で作っている時の“ノレている感覚”とすごく近しいです。テクノロジーやソースコードが上手く組めていて、UIなどユーザーの問題も把握できていて、自分がやるべきことを言語化できている。僕の会社での役割は、チームをそういう状態に引き上げることですね。

文章もプレゼンもソフトウェア開発も、本質は「コンテキストを相手に合わせる」こと

SHIFT 技術顧問 川口耕介氏

川口氏:色々な記事を拝見すると、伊藤さんは言語化が得意な方だと感じます。

伊藤氏:よく言語化が上手だねと言われる気はするのですが、そこに強みがあるとか、こだわっているとかいう感覚はゼロです。2010年より少し前のコミュニティで一生懸命ブログを書いていた人たちは、おしなべて言語化能力が高い気がします。

川口氏:僕は、ソースコードを書くというのもある種の“表現”だと思っていまして、その表現によって人をコントロールしている感覚があります。

伊藤氏:その認識はすごくあります。文章力は分からないですが、むしろプレゼンテーション能力が、仕事で重要な役割を果たしていると感じることが多いです。さらにいうと、基本的に文章を書くことも、プロダクトを作ることも、社内に影響を与えることも、本質は“コンテキストを相手に合わせる”、ただそれだけです。

 文章を書く時は、読者が何を読みたいかを考える。プレゼンでは、ここにいる人達にどういう言葉を伝えたら動いてくれるかを考える。ソフトウェアでも、どういうインターフェイスにすれば、そこから意図を読みとってくれるかを考えるなど、全部共通しています。

問題起点の思考に至ったのは、はてな初期の修羅場から

伊藤氏:この「コンテキストを相手に合わせる」というのは仕事の本質でもあります。出すべき結果が明確にあるので、それに対して良い影響をおよぼすことを、自信を持ってやれば良い。

川口氏:CTOという立場だと、選べる行為の幅が広すぎるので、何をやればインパクトが出るのか、何を期待されているのかが難しいということはないでしょうか。「これやってもいいのかな」と心配になって、精神的にヘルシーではないなと。

伊藤氏:基本的にはCTOはヘルシーじゃないです(笑)。ただ、CTOとして何をやるべきかと悩むことはないです。良いプロダクトをチームで作る必要があれば、チーム足りないものは何か観察して、足りないものを加えたり、今いる人だけじゃ無理なら採用するなり、達成しなければいけない領域は見えますね。

川口氏:うらやましいです。自分は、常に解決すべき問題が、解決できる問題より多いのがプレッシャーにつながっているかもしれないです。

伊藤氏:僕はあちこちの問題をすべて解決しなきゃという感覚はないので、“今起きている問題の中で一番重要なもの”を解決すれば、それで良いと割り切っています。元々はマネジメントをやりたくなかったのですが、はてなにいた時にやらなきゃと思ったきっかけがあったのです。

 はてなのサービスに人気が出てくると、サーバーが落ちまくって、毎日障害に対応しなければいけなくなりました。当時社員が5人しかいない中で、役割分担して解決を試みるも、いつまで経っても悪循環から脱却できない。何がいけないのだろうと考えた時に、担当を明確にしているがゆえに、それぞれの“キャパシティの限界以上の問題”は解決できないという結論に至りました。

 “どう問題を解決するのか”ではなく、“個々ができることの範囲で問題が解決するかもしれない”という逆のアプローチをとっていたのです。物事を考える順番は、マネジメントと現場のメンバーでは全然違う。そこから、まず問題を明らかにするという「問題先行型」で思考が回るようになって、今もそれは変わらないです。

 重要なのはマネジメントのプロセスのノウハウではなく、解くべき問題があるかどうかです。問題があって、困った状況に置かれた人が解きたいと思ったら、勝手にチームはビルドされるのです。多くの人が、問題を明らかにすることじゃなく、どうチームを作れば良いかに苦労しているようで、変だなぁと思います。

前へ 1 2 次へ

カテゴリートップへ

  • 角川アスキー総合研究所