top of page

エージェンティック開発で「中にはいる」(2)

9月26日
読了時間: 4分

中にはいるエンジニアをどう見分けるか?


大勢の部下全てと十分なコミュニケーションが取れる訳ではありません。ましてや「中にはいる」経験を自分でしてこなかった経営者からすると、部下が中にはいっているのかそれとも口先だけなのかを見分けることはとても難しい課題になります。大企業のトップが外形的議論にひきずられて判断を誤るのはそんな瞬間ではないでしょうか。

「中にはいる」エンジニアは外形的なことに関心が薄いことも多く、性格的にエキセントリックだったりすることもあります。システム開発の本質とは関係のない言動まで同じ土俵で評価され、システム開発の門外漢に言い負けてしまうのはよくある光景です。どうすれば口先エンジニアと本物を見分けることができるのか、これもGeminiに聞いてみることにします。 <Gemini:「中にはいる」エンジニアの見分け方>


経営トップから見て、この2者を見分けることは非常に困難です。なぜなら、皮肉なことに「外形的なエンジニア」の方が、経営層へのプレゼンテーションが上手く、物事をスムーズに進めているように見えがちだからです。

外形的なエンジニアは綺麗なポンチ絵(概念図)を描き、「ベンダーにやらせます」「スケジュール通り進めます」と耳障りの良いことを言います。一方、「中にはいるエンジニア」は、システムの制約やリスク、非機能要件の課題を指摘するため、時には「歩みが遅い」「ネガティブだ」と誤解されることすらあります。

技術的な知識を持たない経営トップが両者を見分けるためには、技術用語そのものではなく、「トラブル時の振る舞い」と「問いに対する解像度」に注目する必要があります。


「中にはいる」エンジニアを見分ける3つのリトマス試験紙

経営会議やプロジェクト報告の場で、以下の違いを観察してください。


1. トラブル発生時の「第一声」と「原因究明の主語」

最も顕著に差が出るのが、システム障害やプロジェクト遅延が発生した瞬間です。

外形的なエンジニア(伝書鳩):主語がベンダーになります。「ベンダーに調査させています」「ベンダーからの報告待ちです」と答え、上がってきた報告書をそのまま右から左へ流します。

中にはいるエンジニア(当事者):主語が自分になります。「ログとデータ構造を見たところ、〇〇の処理にボトルネックがあると推測しています。現在ベンダーにその仮説に沿って裏付けをさせています」と、自ら一次切り分けを行い、ベンダーをコントロールします。

2. リスク管理の「解像度」

新しいシステム導入やAI活用の提案を受けた際、どこにリスクを感じているかで判断できます。

外形的なエンジニア:「スケジュール遅延」「予算超過」「UIの使い勝手」など、目に見えるプロジェクト管理上のリスクに終始します。

中にはいるエンジニア:「データ連携時のバッチ処理の負荷」「既存システムのデータ品質」「セキュリティの境界線」など、システムの深部(目に見えないアーキテクチャ)に潜む構造的なリスクを指摘します。


3. ベンダー提案に対する「技術的根拠の言語化」

ベンダーから提案(見積もりや技術選定)が出てきた際の対応を見ます。

外形的なエンジニア:「A社は実績があるから」「B社の方が安いから」という外形的な理由で判断します。

中にはいるエンジニア:「当社の既存基盤との親和性を考えると、A社の提案するアーキテクチャの方が長期的には技術的負債になりにくい」と、「なぜその方式・技術なのか」を自らの言葉で(経営層にも分かるように)翻訳して説明できます。


経営トップが投げかけるべき「魔法の質問」 もし会議でエンジニアのスタンスを確認したい場合は、次のように問いかけてみてください。

「もし明日、このシステムを開発・保守しているメインベンダーが倒産して一切連絡が取れなくなったら、我々だけでシステムを維持(あるいは他社へ引き継ぎ)できる状態になっているか? 足りないピースは何か?」

外形的なエンジニアは「契約上、そうならないようにしています」「ソースコードは納品させています」と手続き上の回答をします。

中にはいるエンジニアは「仕様書の〇〇の部分がブラックボックス化しているので、今のままでは引き継げません。だから今、時間をかけてコードと仕様をリバースエンジニアリングして社内ドキュメント化している最中です」と技術的な現実と具体的な対策を答えます。


評価基準のアップデートへ 「中にはいる」ためには、膨大な仕様書を読み、既存システムの構造を理解するための「目立たない、しかし膨大な時間」が必要です。経営トップがこの時間を「サボっている」「遅い」と評価してしまうと、エンジニアは生き残るために「外形的な調整役」へと姿を変えてしまいます。

経営トップが両者の違いを理解し、泥臭く「中にはいろう」と奮闘しているエンジニアを正しく評価・称賛する風土を作ることが、すべての出発点となります。

(以上、Geminiの回答)


続きを読む

 
 
bottom of page