プレセナ・ストラテジック・パートナーズ Advent Calendar 2025 14日目の記事です。
営業組織は「すぐ対応して欲しい」と言ってくるけど、システム開発の工数は限られていて対応しきれない。
ユーザーの要望が複雑で、技術要件に翻訳するコストが高すぎる。
事業会社のIT部門やそこで働くエンジニアの皆さんの中にも、こういう悩みを抱える方がいらっしゃるのかなと思います。本記事で取り上げる 「内部越境」 が、その溝を埋め、エンジニア組織をさらに活性化させるヒントになるかもしれません。
筆者について
申し遅れました。私はプレセナの中津と言います。研修講師・教材開発担当をメイン業務としつつ、数年前からエンジニア組織にも所属しています。前職（と言っても20年近く前です）はシステム開発会社で、システム設計やプログラミング、ライブラリ管理などの業務を担当していました。当社の組織は、大きな「ユニット」の下に「チーム」がある構成になっています。私は現在、エンジニアユニットで、「自社製基幹システムやツールの保守運用」「非エンジニア組織へのサポート、ヘルプデスク」「情報システム管理」など、社内向けのシステムを担当するチームに所属しています。今回の記事では、 エンジニア組織の枠をまたいで複数の組織に所属すること を「内部越境」と呼ぶことにします。
エンジニアユニットに所属するメンバーの多くはエンジニア採用です。当社は基本的に兼務体制を敷いています。エンジニア採用であっても、9割ぐらいの時間はエンジニア業務をやり、残りの時間は他の業務もやっている、というメンバーもいますが、軸足はエンジニアユニットにあります。そんな中、本業は講師・教材開発領域のユニットメンバーである私が、兼務の立場で彼らと一緒に働く中で、本職のエンジニアではないからこそ見えている部分もあるのではないか、と思っています。
デメリット
私のような立場で、兼務してエンジニア組織に所属することには当然デメリットもあります。
1. スキルの問題による担当領域の狭さ
エンジニアユニットのメンバー約20名中、エンジニア採用でないメンバーは、私含め2人しかいません。エンジニア出身ではない私たち（以下、「越境メンバー」と言います）は、言語やプラットフォーム、インフラなどに関する知識の面、そして実務的な経験の面で、エンジニア採用のメンバー（以下「エンジニア」と言います）とはかなり差があるわけです。そのため、技術的に他のメンバーはできるけど自分はできません、ということが結構いっぱいあります。これがまず１つ目。
2. 専門用語によるコミュニケーションコストの高さ
2つ目はコミュニケーションコストの面です。エンジニアは、エンジニア同士でコミュニケーションを効果的・効率的に取れることが業務で重要になっています。そのため、専門用語、共通言語がやっぱり技術寄りになっていくわけですね。越境メンバーである私たちには、エンジニアの皆さんの共通言語は、第2外国語みたいなところでやっぱりちょっとついていきにくい。例えば、それこそ DevOpsって何なの、スプリント・レトロスペクティブって何よ。 そういうところから、調べないとわからない。調べたら分かるんだけど、エンジニアは知っている前提で会話しているところに、「すみませんわかりません教えて下さい」とは言いづらいですね。基礎的な言語が分からないので、ちょっとそこに入っていきづらい。そして、よく分からなかったことを調べ直すということが都度都度発生する。言葉が通じていないので内容のキャッチアップもたいへん。またそれを防ぐためにちゃんと勉強しなくちゃとは思うけど、他の業務もあるし時間があまりない。こういう状態になりやすい。
3. 割けるリソースの制約
3つ目はここまでと関連するんですが、兼務で割当可能なリソースが限定されるという話があります。当社は兼務が各組織で行われているので、エンジニアも100%エンジニア業務をやっているわけではないんですけれども、とはいえ8～9割ぐらいの稼働をエンジニア業務に充てることができる。一方、越境メンバーは、本業側にリソースをかなり割かれる都合上、エンジニアとしての稼働日が実質月1～2日ぐらいなんですね。そうすると、できることと言うと、30分間の朝会に、参加できる時には参加して、その中で意見交換をしたり、自分の知っていることを共有したり、あるいは個別に持っているタスクの進捗状況を報告する。その後、メインの業務をやり、空いている時間でエンジニア業務をやるという感じになることが多い。技術的な話もあるのですが、リソース的な部分としても、エンジニア業務にエンジニアと同様に力を割くことがなかなか難しい、という状況があります。
メリット・貢献
コミュニケーションコストについては後述しますが、スキルの問題とリソース制約についてはある程度織り込んで、使える工数や業務範囲を限定して参加する必要があるということになります。そんな中途半端なメンバーがいて何が役に立つのかということなんですが、これが実は結構役に立つんです。自分で思っているだけでなく、周りにそう言われることが多いんですね。大きく3つぐらいの話があるかなと思っています。
1. 情報提供
1つ目として、越境メンバーは他の領域の情報を知っています。エンジニアユニット以外、ビジネスを管掌するユニットでどういう方針で今動いているか、この運用はどういう経緯で決まったのか、どういう変遷を経ているのか、実際にどう運用しているか。あるいはエンジニアではない方々との接点も多いがゆえに、他のユニットの人はどういう業務をして、どういう思考をしているのかとか。こういうところを横断的に把握しやすいわけです。
私は講師と教材開発を中心にやっていますが、もう一人、営業を担当している越境メンバーがいます。営業、教材開発、講師という当社ビジネスの3本柱領域について、2人の越境メンバーである程度カバーできるので、ざっくり定例の朝会で方向性を検討できるというのは結構便利なところかなと思います。もちろん正確かつ鮮度が高い情報は現局から入手することが大事ですが、それでもある程度の精度で情報が取れると議論・検討は進めやすいと感じますね。
2. 組織間のコミュニケーションハブ
2点目として、組織間のコミュニケーションハブになることができます。
最近の事例ですが、教材開発の進捗を管理する社内向けワークフローに対して、利用者から「リマインドの飛び方があまりよくないので修正して」というリクエストがありました。これは営業で売れてきた案件をシステムに登録して、教材開発に回って、できた教材を講師が確認するという手続きを管理しています。その時、越境メンバーは本丸が別ユニットにあるので、直接関係者がいる、あるいは関係者と近いチームにも所属していることがある。そうすると、「ちょっとこのあとチームリーダーに方針確認してきます」「チーム内で話し合って、方針を決めてここにまた持ってくるね」みたいなことをやりやすいわけですね。
このあたり、土地勘がないエンジニアだけで話していると、「これどうなっているのかな、こっちから見えている範囲はここまでで、この先はよく分からないな。聞かなきゃわからないけど、でも聞くにしても、聞かれた相手が経緯とか意図とかがよく分からない状況だと困るだろう。じゃあ、その部署に確認をする上で何をどう聞けばいいんだろうか」とかとか、検討することになりまして、これを考えるコストが結構かかっている印象です。そこを、越境メンバーが「これ聞いてきますよ」という感じで持って帰ると、ここで検討するコストが激減するわけです。DevOpsの間の溝をどうなくすのか、そういったところに非常に貢献できるのが、越境メンバーがいることの強みだと思うんですよね。
もちろん、エンジニアが兼務する形で、ビジネス側のユニットに出向くというやり方もあります。システム対応窓口として機能するなど、一定の成果は見込めます。しかし、エンジニア組織内部での議論のスピードを向上させるという点で考えると、やはり非エンジニア組織からの越境メンバーが橋渡しをした方が格段に早い。エンジニアが聞き出しにくいユーザー側の背景や意図をもともと理解しているので、ユーザーの情報をエンジニア組織に適切な粒度で持ち帰ることがやりやすいんです。長期的には、エンジニアと非エンジニア双方から越境できる体制が理想的ですね。
3. 事務方領域の検討効率向上
3点目は、現場に近い領域での検討・協議をサクッと進められることです。ちょっとTips的なところですが、ここで押さえたいのは、 越境するメンバーが実務者である ということなんですね。
業務システムをどう設計・改善するか？という大きな方針を、経営層や管理職層が集まる方針会議のような場で決めていくということはよくあることかなと思います。こういった会議での検討や意思決定の結果として、現場から遠い大きな方針止まりになることが多く、実務観点でみると細かいところがよくわからない、ということが多くなりがちです。先ほどのワークフローの例で言えば、「ユーザーはこのステータスどう見てるの？」とか、「このステータスがどうなっていると使いやすい？」といった細かいところをどう作るかも、全体設計と同じくらい重要です。こういった、細かな事務方領域での検討・協議・実装を進めようとした場合に、現場のオペレーションを知っている越境メンバーがいると、エンジニアがものづくりをスムーズに進めることができます。
越境を実現するためのパスを作る
とはいえ、もしかすると「そんなこと言っても、うちの会社じゃ越境は難しいよね、兼務なんてとても…」という感じになりやすいかなと思います。組織体系がしっかりしている会社だと特にそうかなと。そんなときにどうするか。ここで、なんらかのパス（＝通り道）を通す 、ということを考えてみるとよいと思います。
公式的なパス（制度）の設計
王道は、公式的なパスを作る。兼務をしやすいような制度設計にしていく、ということがあります。一番大掛かりなやり方だと、人事制度の改定とかになります。部分的に兼務できる制度を作っちゃうとか。さすがにそこまではという場合は、「エンジニアは毎朝スクラムミーティングをやるので、 週に2回、15分間だけ顔を出す 」みたいな仕組みにしてしまう。これは先ほど書いたように、エンジニアが兼務して、その知識をエンジニア組織に還元する、ということもいいし、それが相互交流になってくると風通し良くなってくる、ということかなと思います。このときに、わざわざ越境するメンバーに対して、適切な評価をすることも織り込むのが良いですね。直接越境活動そのものを評価というのは難しいかもしれませんが、越境活動を通じて、もとの部門での業務上の課題解決に貢献している、という評価をすることに合意する、というようなやり方があるのではないかと思います。
非公式なパス（個人的な繋がり）の活用
オフィシャルな越境はちょっとやりにくいな、という場合には非公式なパスを作っていくのはどうでしょう。例えばエンジニアが他の部署のメンバーと会議をする。そのときにちょっと長めに時間を取っておいて、そこで関係構築をする。すると、何か困り事があった時に、「あのチームのあの人とは個人的にそこそこコミュニケーション取っているんで、聞きやすいんでちょっとサクッと聞いてみるわ」という関係ができていれば、情報が入ってきて、検討も進むし、判断がしやすくなるのでは、と思います。
認知的負荷を下げるための「言語」の工夫
さて、パスを作ったはいいが、パスがなかなか機能しないということもあります。特に、定例に出てもらうなどのやり方を実行しようとしたときにハードルになるのが、言語と知識。非エンジニアがエンジニア組織の定例ミーティングに参加するのは、認知的負荷が非常に高いため、そこをどう下げるか？が工夫のしどころです。これには大きく２つの方向性があります。
共通語の積極使用
1つ目は、最初から両者が理解できる言葉を使うこと。例えば週2回出てもらう定例では、前半の15分だけはなるべくエンジニアの皆さんも専門用語ではなくて一般用語で話すようにするとか、社内の共通語として使われている言葉を使うようにする、ということをやっていく。どっぷりエンジニア組織で仕事をしていると、下手すると自分が専門用語を使っていることすらわからなくなるときもありますので、一度非エンジニアに説明してみて、わからない言葉を指摘してもらう、という方法がありますね。生成AIを活用する方法もありそう。
エンジニア用語の共通辞書化
もう1つは、エンジニアの方々が一方的に配慮するだけでなく、会議でよく出てくる「この言葉は知っておくといいよね」というエンジニア用語を共通化する、という方法です。共通の辞書に載せ、「これは社内でも横断的に使っていく言葉なんだよ」と布教していく。これによって、エンジニアの思考が社内に伝わり、どのように仕事をしていくとエンジニアにサポートしてもらいやすいのか？を考える手がかりにもなりますよね。こういった「共通辞書」を作成するところを、まさに越境メンバーが担当するというのも一つの手かなと思います。
「内部越境」は、風通しがよくなり、今いるメンバーの知恵や経験が化学反応を起こし、組織を強くする「ワザ」です。
公式な制度から非公式なルール、言語の工夫まで、状況に合わせてできることは多岐にわたります。大掛かりな制度設計は後回しで構いません。まずは、「他部門の定例会議に15分間だけ参加する」「非エンジニアの同僚とランチで専門用語を一つだけ教え合う」といった小さな「越境」を、皆さんも 気負わず試してみる ことをお勧めします。
この一歩が、他部門・社内ユーザーと、エンジニア組織のギャップを、きっと楽しく埋めてくれるのではないでしょうか。
