体験を伝える―『ガジェット通信』の考え方

面白いものを探しにいこう 本物を体験し体感しよう 会いたい人に会いに行こう 見たことのないものを見に行こう そしてそれをやわらかくみんなに伝えよう [→ガジェ通についてもっと詳しく] [→ガジェット通信フロアについて]

「自分の人生を他人に預けるな」──元nanapi CTO和田修一氏のプロアクティブ・エンジニア論 #engineer_moshi

CTOが守るべきものは、プロダクトとしての正義

CTOの役割はビジネスモデルによっても変わってくる。

「例えばBtoBですでに一定の市場性があるビジネスであれば、CTOは組織を管理することを優先させてもいいと思うんです。反対にBtoC領域で、市場性が皆目見えないという状況では、CTOのクリエイティビティが重要になる。ときにはCEOと対立しても、自分が思うところを貫く必要もありますね」

和田氏にとって理想のCTOが率いる、究極のエンジニア組織とは何だろうか。

「エンジニアなのですから、技術やプロダクトとしての“正義”や“筋”といったものを最優先することがまず重要。もちろん、ビジネスですから売上げも大切。それは当たり前のことだけれど、それを振りかざしすぎるとプロダクトが前に進まない。あくまでもプロダクトとしてはどうなのかということを、エンジニアやデザイナーが議論できる環境。これは絶対になくしてはならないと思います」

技術やプロダクトの論理を優先させる。それは必ずしも、「エンジニアの独りよがり」を意味しない。

「俺はこうやりたい、私はそれをやりたくないというのではなく、このプロダクトはこうあるべきだという論理で議論し合えば、必ず着地点は見えてくるはずです」

組織が拡大するにつれて、CTOの役割が変わるのは当然だ。

「4~5人規模の組織が一番動きやすいと思います。チームが10人以上になると中間管理職のような立場の人が必要となってくる。しかし、十分に人を育てないままマネージャーに引き上げてしまうと、いろいろと問題が生じる。これは私にも失敗の経験があります」

マネージャーは一種の専門職。誰にもできる仕事ではない。その見極めが重要なのだ。エンジニア系と非エンジニア系の職種が混在する組織の場合、両者の職種の壁をどう超えるか、超えさせるかも、CTOの重要な役割だ。

「例えば情報共有ツール。IT/Web業界ではエンジニアが使うそれが最も進んでいると、私は思います。とすれば、非エンジニアの人たちにも、GitHubやQiita:TeamやSlackを使ってもらう。

ちょっとした文章を書くときも、Markdown記法を意識させる。文系出身の社員も簡単なコードが書けるように研修プログラムを作る。一言で言えばエンジニアのやり方に全員が引き寄せるということ。この方が結果的にうまくいく、というのが私の経験則です」

CTOはエンジニアキャリアのゴールなのか?

昨今は、エンジニアの間ではCTOの人気が絶大だ。エンジニアを何年か続けて技術を磨き、やがて社内のトップエンジニアになって、そこからCTOを目指す──そのようにエンジニアのキャリアの最終形=ゴールにCTOという職種を設定する人もいる。

「若いエンジニアがCTOを目指すというのは決して悪いことではない」と前置きしつつ、和田氏はCTOという仕事についてこう語る。

「CTOというのは、経営陣の中で一番技術がわかっている人にすぎない。言い替えれば社内で一番技術がわかっている人ではない、ということ。なぜなら技術の進化は早く、その幅もどんどん広がるので、CTOが常にテクノロジー全体をリードすることなど不可能なのです。

むしろ、自分にはできないことをしてもらうために、自分より優れた人材を採用・育成・活用することができる人、それこそが理想のCTOだろうと思います」

「CTOはもっと採用に関わるべきだ」というのは、和田氏の以前からの持論だ。

「会社の成長フェイズに合わせて、今どんなエンジニアを採用すべきか、採用基準を確立するのはCTOの仕事です。採用時点でのスキルの優劣ではなく、今後、スキルをどれだけ伸ばせるか、その伸びしろを判断するのもCTOの役割になります」

エンジニアの技術的専門性と、優れたエンジニアを採用するための判断は別のスキルだ。従って「CTOはエンジニアの専門性の延長にあるわけでもないし、誰もが惰性でなれるものでもない」。

1 2次のページ
CodeIQ MAGAZINEの記事一覧をみる
  • 誤字を発見した方はこちらからご連絡ください。
  • ガジェット通信編集部への情報提供はこちらから
  • 記事内の筆者見解は明示のない限りガジェット通信を代表するものではありません。