2020年8月に、国内企業のエンジニアにフォーカスした1冊の書籍が発売され、非常に注目されました。『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』です。この書籍を企画し、刊行に向けて陣頭指揮を執ったのは、株式会社VOYAGE GROUPの取締役CTO、小賀昌法氏です。

なぜ1つの企業が、しかも、エンジニアのトップの立場で書籍を刊行することになったのか、その背景に迫りながら、VOYAGE GROUPが考えているエンジニアリング、そして、技術力と組織力の向上、その先にある「企業」の強化について伺いました。

• 関連記事：事例で学ぶ！迷えるエンジニアリング組織の処方箋・case3「資金調達した企業に起きがちな 『振り返れば給与格差』問題！」
• 関連記事：チームの心理的安全性を高めるには？場づくりのプロ「金 亨哲」×心理的安全性の第一人者「石井 遼介」が実践している方法
• 関連記事：人事評価なしでも社員の成長を止めない組織を作る。鍵はOKRとフィードバックの効果的な運用――Ubie株式会社・久保恒太氏

『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』の誕生

――小賀さんのこれまでのキャリアについて教えていただけますか。

小賀昌法氏（以下、「小賀」）：プログラマとしてNECネッツエスアイ株式会社へ入社し、その後、ヤフー株式会社、トランスコスモス株式会社や自身での起業への挑戦などを経て、2010年にVOYAGE GROUP（当時 株式会社ECナビ）へ入社し、今に至ります。

もともといた会社ではWindows 95が出てくる前の社会で、いわゆるメーカーのSI、そして、サービス事業のSEなどのキャリアを積み、ECナビ入社後、現fluctのCTOから、グループ全体のCTOに就任しています。

改めて振り返ると、PCが1人1台、企業でもPCを前提とした業務フローに変化する状況を目の当たりにしてきたので、インターネットの普及および世の中の技術進化を体感できましたね。

――技術の変化を肌で感じてきた小賀さんが、今、VOYAGE GROUPのCTOを務めている中で、2020年、自社のエンジニアにフォーカスした書籍を刊行したと聞きました。なぜ、書籍を刊行したのでしょうか？ CTOの立場として、また、一エンジニアとして考えていたことがあれば教えてください。

小賀：今の時代、ソフトウェアプロダクトを活用することは、どんなビジネスでもあたりまえの状況となりました。マーク・アンドリーセンが2011年に『THE WALL STREET JOURNAL（原文：https://www.wsj.com/articles/SB10001424053111903480904576512250915629460）』に寄稿した『Why Software Is Eating The World』の中で表現していた、「ソフトウェアが世界を飲み込む」、すなわち、ソフトウェアの登場がビジネスを転換する世界が到来したわけです。結果として、国境の壁に関わらずどこの企業もIT人材を必要としています。

私たちVOYAGE GROUPは2021年、Zucksやfluctなどアドプラットフォーム、ECナビ、PeX、リサーチパネルといったポイントメディア、サポーターズのような採用プラットフォームをはじめとしたインキュベーション事業など、Web/オンラインで幅広い事業を展開しています。

CTOの立場として、「事業をエンジニアリングする」を標榜する中で、ひとつひとつ取り組むことはもちろんのこと、私たちが何をしているのかを外部に伝えること、それが現時点で最重要課題と考えています。というのも、たとえば1つの例で説明すると、中途採用したエンジニアから「採用面接のときに伺ったときより、VOYAGE GROUPの技術力は高いですね」という声を聞きました。

つまり、私たちは自分たちが持っている技術力を、外に向けてしっかりと発信しきれていない、認知のズレが発生していると感じたのです。

このズレをなくし、私たちの技術力、そして、事業をエンジニアリングするという文化を外部に伝えていきたい、それを目的として『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を企画し、昨夏発売しました。

――今、世の中のIT企業やWebサービスを主戦力とする多くの企業がDeveloper Relations（いわゆるDevRel）という概念を強化し、イベントやオウンドメディアなどさまざまな取り組みをしています。今回の発行にあたって、工夫した点、意識した点はありますか？

小賀：書籍の作り方から説明します。今回は、弊社の技術コーチをお願いしている和田卓人さんに企画、そして、実際のインタビューをお願いしています。この点が非常に特徴的で、工夫した点の1つです。

和田さんは2014年から約7年、私たちの会社に関わってもらっており、VOYAGE GROUPの企業の変遷、とくに技術力の成長、チームの変化・進化を見続けていただいた方です。ですから、外部の人員ではありながらも主観的に、そして、事業部の壁を越えて横断的に横串で「VOYAGE GROUPの技術」を評価、表現できる人材です。

和田さんに関わってもらえたことは、VOYAGE GROUPの技術力を発信していくうえで、とても大きな影響を与えてくれたと感じています。

また、おっしゃるようにエンジニアリングと広報は、採用の観点から非常に重要ではありますが、一方で事業計画のように計画通り進めるのが非常に難しいです。人（採用）はタイミングと縁によるところが非常に大きいですから、まず社内チーム内の共通認識を整備すること、社内広報的な意味も含めて、今回の書籍は企画しています。

会社の文化、共通認識としての技術力を最重要視した組織づくり

――VOYAGE GROUPのこれまでがあったからこそ生まれた1冊と言えそうですね。反響も大きかったのではないでしょうか。また、書籍を企画して改めてVOYAGE GROUPとしてのチーム作り、組織づくりで気づいたことはありますか。

小賀：おかげさまで非常に反響が大きく、うまく行き過ぎたと感じています。採用にも良い影響が出ていますし、その中でも私たちの文化に「共感を得たので（採用面接を）受けてみた」という声を多く聞けたのはうれしかったです。

繰り返しになりますが、私たちは「事業をエンジニアリングする」ことを掲げています。これが文化になるわけですが、その中で、私がつねに考えているのは（事業成功に対する）「銀の弾丸はない」ということです。

ですから、事業をエンジニアリングするには、会社自体の文化を理解することからスタートし、文化にフィットするものを作る、生み出す、つまり、エンジニアリングすることが大事だと考えています。そのために「VOYAGE GROUPでの技術力とは何か」を文章化したもので、社内誰もがいつでも見られるようにしています。一概に技術力と言っても、人によって捉え方が異なるため、まず、共通認識として徹底します。

また、この表現については半年に1回見直して、アップデートしています。見直すことで、急激な変化に対応できるチームであり続けることができるからです。アップデートについては、私を含めたマネジャーからのトップダウンではなく、現場の状況、現場の声も含めて行っていますね。

実際の業務に関しても、私は現場の創意工夫を非常に大切に考えていて、CTOやマネジャーの仕事は、指示を出すことよりも、まず現場に任せること、そして、どういう結果になっても致命傷を追わない、ギリギリまで失敗できる環境を用意することだと考えています。

新規事業や成長事業においては、小さな組織ほどコミュニケーションが持つ意味が重要となり、チーム内コミュニケーションの影響力が大きくなり、それが成功する・しないの鍵を握ります。そのために円滑なコミュニケーションができるように、会社全体で同じ観点で事業へ取り組める、ものづくりできるチームづくり、組織づくりを心がけていますね。

「事業貢献」「能力」「クリード」、3つの観点の評価軸

――小賀さんが考える企業文化、企業としての技術力、それらを束ねた結果としての組織について、わかりやすく言語化していただきました。さらに踏み込んで、組織づくりをし、事業を進めていく中でに、エンジニア一人ひとりの評価というのはどのように考えていますか？

小賀：私たちは3つの観点でエンジニアを評価します。

1つ目は事業貢献、2つ目は能力（専門性）、最後の3つ目がクリード（価値観）です。事業貢献は縦のライン（会社と自分のつながり、上長から見た評価軸であり数値化が難しいため、あえて明文化はしない）、能力はずばり技術力、専門性を含めたエンジニア独自の評価軸、そして、クリードは（VOYAGE GROUPの一員としての）360度評価を意味します。

• 事業貢献＝マネジャーによる評価
• 能力＝技術力を中心とした個人能力評価
• クリード＝360度評価

それぞれを高めることももちろん大事ですが、全社的な目標は「事業」の成長です。ですから、たとえば能力（技術力）だけが突出していても、事業貢献につながらなかったり、周囲とのクリードのズレがある場合、評価は低くなります。一方で、技術力が突出していなくても、事業貢献につながっていたり、周囲とクリードが一致していれば評価は高くなります。

私が考える技術力とは、事業やプロジェクトの制約条件を理解して取り組むことが能力のことです。すなわち、事業を理解する、事業の課題を理解してアウトプットできる力を技術力として考えています。

もともと評価軸は、事業貢献と能力の2つだけでした。私が入社後、社名変更した際に経営理念のクリードが変更され、今に至ります。それまでは、クリード（価値観）の共有・評価が仕組み化されていなかったのです。

社名変更とともに組織が大きくなるにつれて、目に見えるゴール（目標設定やKPI）、また、実際の技術力以外の部分の評価、人の数だけ生まれる濃淡を共有することを仕組み化するために、クリードを含めた経緯があります。

評価制度から見える組織のあり方

――3つの評価軸があるとのことですが、評価はどのようにするのでしょうか？

小賀：私たちは評価に対して、一方的な評価ではなく、評価される側の準備だったり、評価される側・する側、どちらの立場にもなれるような仕組みを作っています。

等級制度には全部でグレード1～グレード4の4段階のグレードがあります。そのうち、グレード2以上になると、評価されるだけではなく、評価する側も担当するようにしています。こうすることで、人に評価される（伝える）という観点だけではなく、人を評価する（相手を理解する）という、双方の立場で考えられるようになるからです。

たとえば、評価に際しては、される側が発表資料を準備し、その発表資料をもとにプレゼンテーションする形式を取っています。過去には1日8時間、3日をかけて発表資料を作ったエンジニアもいましたね。

この評価方法にした結果、いくつかの効果が出ています。まず、評価される側も2回、3回と続く中で（評価は半年に1回行われる）、過去の自分自身の成果を思い出し、調べながら発表資料を作ると非常に時間がかかることに気づくのです。

するとどうするか。日々の業務で自分自身がしたことについて、簡単なメモやしっかりとしたドキュメントをまとめるようになるのです。そうしておくことで、評価プレゼンテーションの準備はそれらをまとめるだけで済み、時間の短縮につながるからです。いわば、自分自身の能力の棚卸しを日常的に行うクセがつくため、今現在の自分の到達点がわかりやすくなるなど、個々人の働き方の効率化、改善にもつながります。

さらに、VOYAGE GROUPが考える「評価」を「評価 = 文化・価値基準浸透のツール」としてそろえることができるため、「評価」にどこまで時間を費やすことが私たちにとって必要なのかも合わせてそろえることができるのです。

他にも、社内の情報共有の観点からも非常に大きな成果で、たとえば、異動や新規採用後に、そのチームが何をしているのか、何をしてきたのか、そのメモやドキュメントを見れば理解を深めることに役立ちます。

また、この仕組みに対して「評価はマネジャーの仕事ではないか？」という声も上がりましたが、私はこの意見に対しては別の見解を持っています。皆、マネジャーが完璧な評価ができる、すなわちパーフェクトマネジャーを夢見過ぎではないか、ということです。もちろん、そうであることは理想ですが、必ずしも、全員がそうであるとは限りません。

ですから、グレード2以上の場合、評価する側にも回ってもらうことで、マネジャーの業務とはなにか、マネジャーの目線を意識してもらえるようにもなっています。さらに、それぞれの立場で評価することで、さらに上位からの視点では「評価の仕方の評価」ができます。その経験をすることで、今度はまた自分が評価される際に、評価を受けるためのレポート作成がうまくなるなど、違う立場に立った経験がそのまま自分の役に立ちます。

これはサービス事業者にとっても重要で、サービス提供と受ける側、双方の立場、考え方で物事を考えられるようになるのです。

このように、VOYAGE GROUPとして全員が評価する・される環境を用意することで、さまざまな立場から「事業」への理解度が高まります。さらに、プレゼンテーションから「周囲の人間に好まれるエンジニア」、つまり「このエンジニアと一緒に仕事したい」という、定量化しづらい部分も見えてきますから、売上やKPIなどの数字では見えづらい部分、深い部分での評価が可能となりました。

短期的な事業貢献だけではなく、一定の間隔で実施することで中長期の貢献度が見えたり、裏側での仕組み（仕事のしやすさ）を評価するといった面を実現できるよう、今もこの評価制度は改善し続けています。

また、この3つのバランスによって、エンジニアにも技術力だけではない、事業を理解する力が必要だという共通の価値観を醸成できます。

ソフトウェアの専門職がなくなる未来

――VOYAGE GROUPが考える「事業をエンジニアリングする」こと、また、そのための組織づくり、チームづくりの理念が見えてきました。まず、価値観をそろえる、そして、事業につながるように取り組むのが重要なわけですね。その手段としての技術力だと理解しました。

最後に、VOYAGE GROUPだけではなく、社会全体に対してのエンジニアの存在、存在意義について、小賀さんはどのようにお考えか、教えていただけますか。

小賀：さまざまなところで言われていることの繰り返しにはなりますが、「ソフトウェアエンジニア」という専門職がなくなる未来がきてほしいですね。それは、どういうことか――端的に言えば「誰もがコンピュータを働かせるための指示が出せる社会」です。

そう考える一番の理由は、この先の日本社会の人口減です。人口減に伴い、労働人口も減るため、今までと同じ労働力を保持するには、いかに効率的に働くか、働ける環境を用意できるかが大切となると私は考えます。

今の日本は、効率的に働くための解決策としてコンピュータを利用するには、まだまだ障壁が多く、コンピュータへの指示ひとつをとっても、プログラミング言語を介すなど、（指示を出す側に）特殊な技能が必要です。

一方で、私が期待している未来にも近づいています。その1つが、最近注目を集めているノーコード/ローコード開発です。この考え方が浸透していけば、特殊なプログラミングスキルを習得しなくても、既存（既成）のコンポーネントを組み合わせてコンピュータに指示が出せる社会が来ると考えます。また、そこまで簡易化できなくても、簡単なスクリプトやSQLで対応できるようになるはずです。

そう考えると、現在、ソフトウェアエンジニアと呼ばれている職域の人材は、課題解決かつコンピュータを操作するために必要なコンポーネントやAPIを作ったり、それらを組み合わせる仕組みを生み出す職業へ進化していくかもしれません。

その結果、誰もが今より簡単にコンピュータを扱い、コンピュータに指示を出し、そして、求める結果を生み出せる社会になるのではないでしょうか。

このように、コンピュータに指示を出して欲しい結果を手に入れるという考え方は、四半世紀前にインターネットが登場した際、人間が検索エンジンが検索しやすいようワードを考えた能力に近いかもしれません。

そういう世の中になることを目指したいですし、今、そのために、ソフトウェアエンジニアが社会に貢献できるように取り組む必要があると考えます。近い将来、今の小学生ぐらいの子どもたちが社会人になるころに、（目指した）理想の社会が来ているかもしれませんね。

――ありがとうございました。

（聞き手：株式会社技術評論社　馮富久、撮影：中村俊哉）

小賀昌法さんに3つの質問