システム戦略室 CTO Phone Zaw Phyo（フォン ゾウピョ）氏 ミャンマー出身。2014年、株式会社シーエー・モバイル（現・株式会社CAM）に入社。アプリやサーバーサイドの開発に従事する。2018年、株式会社CyberOwlへ異動、検索メディア『aukana』WEB・アプリを開発する。2019年 同社CTOに就任。技術基盤の底上げ・メンバー育成に従事しながら、インターン生の育成、各部門から寄せられる技術課題の解決に取り組んでいる。

2019年にCTO就任後、まずどんなことに取り組まれましたか？

職種構成比で見るとエンジニアの比率は15%ほど。決して大人数とは言えません。その分エンジニア一人ひとりのパフォーマンスが重要になります。 そこで私が考えたのは、とにかくエンジニア組織を強くすることでした。各自にチャレンジさせるような環境を用意して、スキルを高めることに集中しよう。そんな目標を掲げ、技術向上を目指す組織「マイクロチーム」を発足したのです。社内技術の知識・情報の共有をはじめ、最新技術を導入して当社の複数メディアで活用できる「マイクロサービス」の開発も行いました。また、社内ハッカソンも実施。アプリエンジニアがサーバーサイドへ、サーバーサイドエンジニアがインフラへ…というように、各自が挑戦したい領域に合わせて課題に取り組む機会も設けました。 おかげで技術力が底上げされ、成果が見え始めたので「マイクロチーム」は役目を終えたと判断。現在は新しい形でエンジニアの育成に取り組んでいます。

「新しい形でのエンジニアの育成」とは、具体的にどのようなものでしょう？

毎年インターン生を4～5名採用して一から指導し、将来の有望なエンジニアに育てるというプログラムです。今年でもう3年目を迎えます。 一から指導と言っても、プログラミング等を細かく指示するのではありません。むしろその逆で、インターン生には設計から考えてもらうのです。エンジニアは普段、営業やプロデューサー等のビジネスサイドから「こういう課題を解決したい」という相談を受けます。インターン生も同じ立場になり、1～2週間は設計に没頭する。当然分からないことが出てきますので、先輩にどんどん質問をします。すると、インターン生の頑張りに先輩エンジニアが刺激を受けるというわけです。 インターン生の中には、そのままサイバーエージェントグループに入り、当社に配属されたエンジニアもいます。設計から学び始めた後輩が入ってくるのですから、エンジニア組織全体として技術力がさらに高まる。それが新しい形での育成です。

エンジニアの継続的な成長を考えて、組織運営をしていらっしゃるのですね。

あえて同じ仕事に固定させないという方法も採っています。現在エンジニア組織は、広告メディアの運用に携わる2チームと、『テラコヤプラス by Ameba』の開発・運営に携わるチームの3チーム体制です。 これはあくまで現時点でのチーム編成で、時期によってエンジニアがチーム間を異動することは珍しくありません。新規開発案件があれば、もちろんそちらに携わってもらうケースも。このようにして全員が全ての仕事を経験していると、一人ひとりの技術力が高まりますし、お互いの仕事をカバーできます。先ほどエンジニア組織が大きくはない、という話をしましたね。小規模な組織にとって「この人がいないと回らない」というリスクが下がるのは良いことです。 もちろん仕事との相性がありますから、担当した仕事でモチベーションが上がらないケースもあるでしょう。そんな時には直接でもチャットでも、すぐ私達に相談できるようにしてあります。

フォン様ご自身が現在ハンズオンしているのはどのような業務ですか？

開発にも携わっていますが、他部署の業務上の課題を技術的に解決することがメインです。これはCTOになる前の話ですが、ライターが文章を入力する管理画面のパフォーマンスを向上させました。複数のライターが同時に管理画面で編集作業ができない、記事内に動的コンテンツを挿入できないといった課題を解決したのです。 最近改善できたのはデータ分析ですね。以前は営業から依頼されたデータ収集・分析・レポート出力に数カ月もかけていました。しかしある分析ツールを導入した結果、1週間もかからないようになったのです。データ分析のスピードが上がり、業績にも良い影響を与えているようです。 ただ、私としてはせっかく導入したツールなので、営業にも使ってほしい。そこでITリテラシーの高そうな営業数名に声を掛け、ツールの使い方を紹介。彼らから他の営業に広めてもらいました。ユーザー部門が使えるツールを導入できたことは、とても嬉しいですね。

職種の区別なく、コミュニケーションを大切にされているのですね。

コミュニケーションは何よりも大切です。コミュニケーションをしっかり取っていれば、開発で無駄な労力をかけずに済みますし、実装したものが無駄になることもありません。 新人の営業やプロデューサーの場合、持ってくる仕様書がとても分厚く、指示も細かくなりがちです。私は経験上「本当はもっとシンプルにできる」と分かっているので、仕様書通りにやるのではなく、まず議論をします。そうすると実際シンプルになるのです。シンプルになれば工数が減り、開発が成功する確率が上がりますよね。優先すべきはそういう結果ですから。 そこで日頃からエンジニアにもインターン生にも、口を酸っぱくして「（仕事を）頼まれたら議論から始めるように」と伝えています。言われた通りにやることが上手になってはいけない。そういうアドバイスを受け取ったインターン生のうち、数名が後輩として入ってくるわけですから、先輩エンジニアはのんびりしていられませんよね。