こんにちは。CTOの八幡です。

先日、弊社エンジニアとの会話の中でこんなことを尋ねられました。

「八幡さんはなんでそんなに勉強しているんですか？」

そのときは答えがまとまっていなくておかしな答えを返してしまいましたが、なぜ勉強を続けるかというのはHow Google Worksという著書の中にある「ラーニングアニマルであれ」という言葉が大きなヒントだったりします。

そして、これはもしかすると私自身のCTOとしての考え方に繋がってくるかもと思えたので、この場をお借りして少し掘り下げてみたいと思います。

アルバイトからフルタイム、CTOへ

私は大学時代からアルバイトスタッフとしてEyes, JAPANに勤めており、web制作やハイブリッドアプリ開発・画像処理システム開発など幅広く携わらせていただいておりました。
そして昨年度からは会社で初めてのCTOという役職をいただくことになり、現在は人工知能関連プロジェクトにメインでコミットしております。

さまざまなプロジェクトを経験するなかで、同時にエンジニアとしてのスキル不足も痛感して…痛感させられてきました。ただありがたいことに、私はその時々で自身のスキルを活かせるような仕事を与えていただいていたように思います。

一方で、まわりのエンジニアの中には、私などよりよっぽどハイスキルであるにもかかわらずそれを活かしきれていない（ように見える）人もいました。
そんな状況はあまりにも勿体無い、みんながもっとスキルを活かせる場を作りたい。そのためには、もっと技術寄りの視点から、技術とビジネス・技術とデザイン・技術とそれ以外をつなぐ役割が専任で必要なのではないか？
というのが、CTOの役職をいただく以前からの私の考えでした。

CTOってなんだ？

そもそもCTOってなんなのでしょうか。

まず言葉どおり見てみると、CTOとはChief Technology Officerつまり最高技術責任者の略称です（ちなみに、私は時々Chief Tea Officerになることもありますｗ）。
「技術のトップでしょ」とか「経営にも関わるって聞いた」とか、いろいろ見方があるかと思いますが、CTOの役割は会社によって異なるというのが一般的な認識のようです。
確かに会社によって技術とビジネスの関係性は異なりますから、会社によって役割が異なるというのは当然といえば当然なんでしょうね。

例として、GREEのCTO藤本氏はこのようにブログを書いています。

• CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineers' Blog

翻って弊社におけるCTOとはなんなのかを考えてみると、まだ明確なJob Descriptionがあるわけでもありませんから、明確な定義をここに書くことは難しいと言わざるを得ません。上で述べた「技術寄りの視点から技術とそれ以外をつなげる」というのも少し曖昧です。これから少しずつCTOの要件を言語化し公開していく必要があるだろうと思います。たとえばQiitaで有名なIncrements株式会社では、GitHubにJob Descriptionを公開したりしていますね。

CTOの系統分類について述べているこの記事によれば私はテック系CTOにあたるのでしょうが、少なくとも「CTOである私は他のすべてのエンジニアより技術的に優れている」というようなことは微塵も考えていませんし、考えるべくもありません。
とにかくエンジニアひとりひとりが尖ったハッカーであってくれることを望んでいます。

ちなみに、CTOと混同されやすい役職としてVP of EngineeringやTech Leadなどがありますが、その違いについてはこちらのポッドキャストが参考になるかもしれません。

• Rebuild: 126: Anti-Democratic Product Management (higepon)

CTOに求められることってなんだろう

エンジニアとして自分で気を付けていることはいろいろありますが、特にCTOとして気を付けなければ、と考えていることが3つほどあります。

1. 必ず技術フィードバックを返すこと

コードレビューをするときや、「こういう技術を使いたい」と言われたときなどには、OK/NGの結論だけでなく技術的な理由も含めたフィードバックを返せるように心がけています。理由を理解した方が、言われた側も動きやすいですからね。

質の高いフィードバックを返すために新しいことを学ぶというのは、とても楽しくもあり、同時に不安なプロセスでもあります。
それでも、そうしてようやく相手の話にのって対話ができるようになって、楽しそうに話をしてもらえるようになった瞬間は本当に嬉しいです。私にとっては心からやりがいを感じる瞬間のひとつです。

2. 技術を選択するための評価基準をもつこと

評価のものさし（デザインパターン、RASIS、ACID、CIA、コーディングガイドライン、パフォーマンス測定方式など）を色々知っておくことで、技術をより正確に評価できるようになります。

ものさしをうまく使って好みの問題に決着を付けるのが、CTOの役目のひとつであると考えています。もちろん自分だけで評価をするのは視点が偏ったり抜け漏れの危険性がありますから、自分よりも正確なものさしを持っている人を見つけ、意見を聞くことも大切です。

3. 技術史や哲学を学ぶこと

技術史のダイナミクスを知り、技術の背景を深く知ることで、技術への向き合い方や理解度が変わってきます。

たとえば、最近web技術として登場してきたWebSocketなどは、UNIXのSocketの考え方をかなり応用することができます。ITは歴史が短い技術ではありますが、故きをたずねて新しきを知るとよりよい設計ができたりします。
また、他の人との会話中に知らない技術が出てきても「専門外だから全く分からない」ではなく理解のきっかけをつかめるようになる…と私は感じています。

まとめると

いろいろと小難しいことを書いてしまいましたが、まだまだ学ばなければいけないことは山のようにあります。「技術を正当に評価する」というのは私の信条ですが、この言葉を心に留めながら頑張っていけたらと思います。

Eyes, JAPANでは、優秀なエンジニアを不定期で募集しております。ご興味のある方はぜひお問い合わせくださいませ。

• お問い合わせ | 株式会社Eyes, JAPAN