高安氏が30年の業界経験から考える「すごいエンジニア」とは？
30年にわたり、ソフトウェアエンジニアリングを適用したシステム開発やコンサルティングに携わってきた高安氏。アーキテクトとしても活躍し、『システム設計の謎を解く』（SBクリエイティブ）など、著書も多数持つ。同氏がCTOを務めるBTCでは、チームとして仕事を進めるに当たり「テクノロジーとコンサルティングの融合」が不可欠と考え、施策やカルチャーの醸成に取り組んできた。一方、高安氏はさまざまな「すごいエンジニア」と出会い対話する中で、「技術分類・ロール」と「技術の習得・マインド」にそれぞれ共通する特徴があることに気づいたそうだ。そして、エンジニアの成長を支えるにあたり、組織的な取り組みの重要性を実感したという。
まず、高安氏が出会った「すごいエンジニア」のエピソードとして、「圧縮アルゴリズム」についてのエピソードが紹介された。大量のテキストデータの転送（Hadoop）に時間を要していたとあるシステムでは、独自のXMLスキーマが決まっている状態だった。これに対し「汎用的な圧縮アルゴリズムではなく、自分たちで作った方がいい」とアドバイス・実装したエンジニアがいたそうだ。確かに、特殊なXMLの体系化なら独自でシステムを作ったほうが圧縮効率が良く、ネットワークの転送量が減って高速化する。実際に内製したシステムでは、データ量の80%が圧縮された。高安氏は、「圧縮について本質的に理解しているからできたアドバイスだし実装だった」とコメントする。
こうしたエピソードは枚挙にいとまがないが、高安氏はそうした「すごいエンジニア」を分析し、次のような特徴を上げた。
- 俯瞰的な視点：短期的・局所的な視点にこだわらず、俯瞰的に状況を見ながら全体を把握し、問題を発見できる。
- 本質的な理解：常識とされる思い込みやWebで検索した手法ではない、本質的な理解があるからこそ応用がきく。
- 圧倒的なスピード：自身のアウトプットに自信があり、たとえ完璧ではなくても本質的に完成しているものを出すことができる。
そして、これらを可能にする理由として、対話の中から次のような心がけを聞き出したという。
- 原理原則をよく知っている
- アイデアに対して、修正や検討理解が速い
- 書籍を読むなどして体系的な理解を心掛けている
- 幅広く視野をもっている（こうあるべき＝ToBeを知っている）
- ToBeから現実を見て手段を考える
技術的に優秀なエンジニアの中には、最後の「ToBeから現実を見て手段を考える」ができない人もいるという。ToBeにこだわりすぎるあまり、「こうあるべきなのに、どうしてできないのか」と頑なになってしまうというわけだ。そうした人たちは優れた技術を持っていても、現実的な解決案を出すことができない。周囲も「言っていることは正しいけど、それができたら苦労しないよ......」となってしまう。
本当に「すごいエンジニア」は、ToBeを知り、本来の解決策を考えつつも、現実を見る。「今の落とし所」を見出し、対応するのだ。また、現実的な解決策が内包する技術的な負債を認識し、次にそれを直す計画を立てるなど、将来の布石も考えられる。
高安氏は「エンジニアの何割かは、まさにToBeを知り、『こうあるべきなのに、なぜできないのか』と組織やプロジェクト、プロダクトへの不満を持っている人もいるだろう。しかし、一度現実を見てどうすればToBeに近づけられるか、ロードマップを描いて考えてみてほしい」と語る。
実際、高安氏がコンサルティングする際にも、ビジネス側から要求されるToBeがあり、そこへ向かうロードマップを描くことが多いという。ビジネスと技術を融合させるという意味でも、「現実解」を意識することが望ましいというわけだ。
コンサルタントと技術者が対話するには？ 役割を超えた共通言語の重要性
「すごいエンジニア」には、「技術分類・ロール」で共通の特徴があるという。技術をロールごとに分解すると、「アーキテクト」「組織改善・全体技術部門エース」「スペシャリスト／スーパープログラマ」の守備範囲が見えてくる。これをもとに、BTCの「ITコンサルタント」「アーキテクト」「スペシャリスト」の3つの役割に求められる技術を考えると、キャズム論でいう「イノベーター」のような研究的技術ではなく、「アーリーアダプター」や「アーリーマジョリティ」の知識が必要になる。
高安氏は、「技術メンバーは『アーリーアダプター』くらいの技術からキャッチアップをはじめ、それがどのようなビジネス課題に役に立つのかを考える必要がある。また世の中に流布され始める『アーリーマジョリティ』になるとお客さんも興味を持ち始め、課題を解決するためのソリューションも尋ねてくる。そのため、キャッチアップはもちろん、プロジェクトにどう導入するか、どう提案したらよいかを考えて、実際に設定・実装ができるレベルでその技術を習得する必要がある」と解説する。
もちろん役割ごとに求められる技術の習熟度が異なるが、高安氏は「ITコンサルタントだから技術を知らなくてもいいというわけではない」と強調する。「『知っている＝シーズを理解している』レベルで習得している必要があり、そうなることでアーキテクトやスペシャリストと話ができる。一方、アーキテクトやスペシャリストも、マネジメント領域の言葉を知らなければならない。たとえば、『リスク』という言葉の意味を正しく理解し、その技術を使うことのリスクをマネジメントに説明できる必要がある」と語った。
技術者とコンサルタントの会話が成り立たなければ互いに理解が進まず、建設的なコミュニケーションは成り立たない。高安氏自身も「あなたは訳のわからない言葉を話す」とコンサルタントに言われ、困惑したことがあるという。改めて、「コンサルタントも技術メンバーもお互いに歩み寄り、つながっていくことが重要」と強調した。
エンジニアはどう技術を学んだらよいのか？ 技術取得のためのマインドを紹介
エンジニアの「技術取得のマインド」について語る前に、高安氏は「ダニングクルーガー効果（Dunning–Kruger effect）」について紹介した。これは、経験の浅い人が自分の能力を正しく認識できず自分を過大評価する現象であり、技術要素の理解においても起きやすい。初心者は、自分の技術レベルを正しく測れていない可能性があることを認識しておくべきというわけだ。
そもそも技術の選定は、要件に合わせて行われるのが一般的だが、組織における実現可能性もまた重要となる。つまり、どんなにすごいスーパーソリューションでも、自分たちが使えないものを選択しては意味がない。もちろんその技術を使えないことは、テクノロジストとして残念なことであり、同時に技術を導入できる環境づくりにも取り組むべきだ。
ここで高安氏は「より大きな問題を解決するのに必要な副次的な問題を解決するための、一見して無用な行為」を表す言葉として「ヤクの毛刈り」を紹介した。そして、開発現場で起こりうる具体的な例として、JWT（Json Web Token）をAWSのCognitoで発行した場合の検証コードを挙げる。aws-jwt-verifyというライブラリの書き方は、Blogやリファレンスを見ればわかる。しかしながら、Cognitoの階層構造をみていくと、それぞれのつながりが見えてくる。つまり、JWTを理解するには下階層のPKIや電子署名を理解している必要があるということだ。
高安氏は「3行ほどのコードでも、本当に理解しようと思ったら、中身を細かく分解し、ベリフィケーションしなければならない。電子署名の鍵がどこにあるのか、JWKのキーを使って検証している過程など、掘り起こして理解する必要がある」と語る。コードへの深い理解を実現するために「ヤクの毛刈り」が重要だというわけだ。
高安氏は「全部できないという話もあるが、頭の中で書き出すだけでもいい。技術マップを書き、自分に何がわかって何がわからないのか、理解を棚卸しすることが大切。わからないことが問題なのではなく、わからない部分を認識できないのが問題。自分が何を勉強すればいいのか認識できることが大切であり、『ヤクの毛刈り』のようにいろいろと調べながら、成長のきっかけを掴んでほしい」と語った。
このような姿勢は「ソフトウェアクラフトマンシップ宣言」にも記載されている。効率を重視すると失われる可能性があるが、エンジニアとして忘れたくはない意識だ。また、高安氏はソフトウェア工学の良書として『SWEBOK』（松本 吉弘・訳、オーム社）、『継続的デリバリーのソフトウェア工学』（David Farley・著、日経BP）、『実践ソフトウェアエンジニアリング』（Roger S. Pressman, Bruce R. Maxim・著、オーム社）を紹介した。
高安氏は、「キャリアの考え方や目標によって、技術に対する立ち位置が違う。モノづくりの観点から『技術の価値』と『ビジネスの価値』を問えるのは、エンジニアならでは。アプリケーションを支えるインフラ技術の在り方や動作しているものの裏側など、深い部分までぜひ技術取得のマインドとして意識してほしい」と語った。
技術者の成長を組織で支える──「貢献」を定義して、市場で評価されるエンジニアへ
最後に、こうしたエンジニアの成長を支える技術組織の取り組みとして、BTCの事例が紹介された。BTCでも、2015年に技術組織が立ち上がるまでは「プロジェクトをどれだけ頑張ったか」という軸のみで評価を行っていたという。確かにプロジェクトの達成で利益を得ている組織ではあったが、たとえば技術で自動化して作業時間を減らすと「頑張っていない」という評価になってしまう。それではテクノロジストが育たないという気づきのもと、技術組織という新しい取り組みがスタートしたという。
技術組織の担い手として、高安氏はまず社内にコミュニティを作り、エンジニアが望む評価について議論した。また、2017年にはトップ経営層をAWSの主催する技術イベント「re:Invent」に無理やり行かせたことについて、高安氏は「自分を褒めてあげたい」と語る。内容の理解はともかく、役員らはその熱気に圧倒され、全社的にクラウドにシフトするきっかけとなった。2018年にはクラウドCoE組織が立ち上がり、業態変革を進めている。また2020年からは、アジリティCoE組織も立ち上がり、ウォーターフォールでドキュメンテーションや納期ばかりを意識する体制から、よりビジネス価値にフォーカスするようになったという。
高安氏は「こうしたエンジンを掛ける部隊があることで、みんなの意識が少しずつ変わり、ビジネスも変わっていった。CoEという取り組みは非常に効果的だった」と振り返った。
そしてもう1つ、「可視化」も組織に対して大きなインパクトがあったという。開発において感覚的な○％の進捗という表現に違和感を持っていた高安氏は、進捗率を可視化して評価するために「BTC Codebase」を開発した。
こうした技術組織の立ち上げについては、プレゼンテーションを通して「ミッション」「ビジョン」「バリュー」の浸透にも力を入れたという。バーチャル組織として週に2時間の会議からスタートし、予算化や評価の仕組みも整えていった。そして技術組織の成果として、書籍用予算を確保し書棚に並べ、誰もが勉強できるような環境づくりができたという。また、前述した評価制度や組織への貢献についての議論、またCoE組織の育成で、全社的な雰囲気が変わった。
高安氏は、「本当の意味でエンジニアの組織を作るのは難しい」と改めて振り返り、「技術者の成長は難しいけれど、促すことができる。成長のきっかけや枠組みを、どのように組織に落とし込むかを考えてきた。実践こそが最も成長する場であり、提案時からどうすればそのような場を提供できるかを考える」と語った。なお、技術メンバーはたびたびスランプに陥ったが、その時に頑張れたエンジニアは次のステージへと進むことができ、その成長は目に見えてわかるほどだったという。
「技術の立ち位置や方向性を決めて、どう成長させるか。会社が求めているものに、どうアライメントするか。すべてのエンジニアのやりたいことに対応するのは難しいが、経営陣が技術者をリスペクトし、成長や待遇のバランスを考え、組織にとっての『貢献』を定義することが大切。技術の大切さが分かり、ToBeを高いレベルで示せる技術者こそ、市場でも評価されるだろう」と締めくくった。
一緒に働く仲間を募集しています！
BTCは、高度なテクノロジーとコンサルティングによって、クライアントのビジネスをサポートしています。
グローバルネットワークを拡大しながら、成長を続けているフィールドでともに成長できる人材を求めています。本記事で興味を持たれた方は、BTC採用ページをご覧ください。
