技術を推進する技術と心がけ~私が経験した3つの壁と、その乗り越え方~
こんにちは。MagicPodエバンジェリストのYoshiki Ito / 伊藤由貴です。
普段ユーザーさんや導入を検討中の方とさまざまな話をする機会も多いのですが、テスト自動化の推進がうまくいくかどうかを左右する重要なポイントに（改めて）気づきました。
それは、ツールおよびそれに関連するプラクティスを組織に定着させるには、普及推進活動と、それを担う主体が必要だということです。
そしてこの「技術を普及・推進する活動」の考え方は、特定のツール導入に限らず、開発組織をよくしていく過程で広く応用できる知見でもあります。私自身、以前はテスト会社でテスト自動化技術を普及させる組織を立ち上げ、社内のエンジニアのべ約200人に技術研修を行うなどの推進活動をしていた経験があります。その経験も含めて、本記事では技術推進の現場でぶつかる「壁」と、その乗り越え方をお伝えしたいと思います。
目次
「技術推進」とはどのような活動か
まずはじめに、本記事における「技術推進」という言葉の意味を整理しておきましょう。
私なりの定義としては、
会社や組織の中で、特定の技術要素・プラクティス・ツール等を皆が実践できるよう、スキルアップや仕組み化などを主導すること
です。
この「技術推進」のパターンとしては、大きく2つあります。
ひとつは、会社やマネジメント層の意思決定をもとに担当者が任命されて進めるトップダウンで主導するパターン。もうひとつは、現場のニーズをきっかけに誰かが横展開を始めるボトムアップのパターンです。本記事の考え方はいずれにも適用できる想定ですが、どちらかといえばトップダウン側のパターンを想定してお話ししていきます。
また、こうした技術推進の要素というのは、限られた人だけに必要なものではありません（と私は信じています）。
たとえばエンジニアとしてのキャリアを積み重ね、いわゆるテックリードやPMなどのキャリアに進む場合には、こうした推進の要素が求められる場面が増えてきます。また、生成AIの普及によって「エンジニア（やその他特定の職種）が不要になる」などと言われることもあり、私たちは何で価値を発揮するのかを考え、実践することが求められています。（ほんとうに大変な時代ですね。）
そうしたなかで、技術を自分で使いこなすだけでなく組織に広めていく動き方も選択肢のひとつになりますし、同時に「この先生きのこる」うえでの武器になるのではないか、と考えています。
しかし、実際に推進活動をしていると、さまざまな壁にぶつかります。そしてこれらの壁は、全くの初見でぶつかってしまうと越えるのがなかなか大変です。
ここからは、大きく3つの壁と、それぞれに対する乗り越え方についてご紹介します。
壁① 「知らない」「わからない」
なぜ組織内での理解を得るのが難しいのか
技術推進の最初の壁は、「知らない」「わからない」です。どれだけ良いものであっても、知られていなければ使われません。そして「よくわからないもの」に対しては、みな抵抗してしまうものです。
なんらかの取り組みやプラクティスを推進する場合、特にそのスタート時点においては、会社やマネジメント層と現場との間での意識・熱量のギャップがあります。上から「これを導入してほしい」と言われても、現場のエンジニアからすれば「なぜ今これを？」「自分たちの仕事にどう関係するの？」という状態になりがちです。この状態で情報だけを一方的に流しても、なかなか浸透しません。
また、トップダウン型の推進では、担当者が矢面に立つことになります。会社の意思決定であっても、現場の不満がその担当者に向けられるケースも少なくありません。そうなると、板挟みの技術推進担当はなかなかに辛い立場になってしまいます。
「ここを見ればわかる」と「この人に聞けばわかる」をまず作る
この壁を乗り越えるために私が効果的だと感じているのは、情報と人の経路を一旦集約することです。
まず、ナレッジベースや情報ポータルを整備して「ここを見ればわかる」状態を作ります。ConfluenceでもNotionでも、何でも構いません。情報がどこにあるかわからない状態では、興味を持ってくれた人が調べるコストを払えずに離脱してしまいます。
次に、「この人に聞けばわかる」状態を意図的に作ります。最初はあえて属人化させる、ということです。「使いたい・取り組みたい場合はまずこの人に連絡」というルールにしておくと、導入・利活用状況を把握しやすくなるというメリットもあります。ただし、最終的には手離れすることを前提にしておくことが大切です。属人化を続けると推進担当者がボトルネックになりますし、担当者が異動・退職した際に一気に崩れてしまいます。
ここで、先ほど触れた「担当者が板挟みになって辛い」という点と矛盾するように感じられたかもしれません。ここは残念ながら、担当者のマインドセットを切り替えて一定受け入れるしかない部分だと考えています。辛くなってしまうそもそもの原因は「上から言われたこと」を「自分がインターフェースになって推進している」ことにあります。言い換えるならば、この技術推進という仕事が自分の仕事になっていない状態です。このままだとどうやっても辛さは解消されないので、技術推進担当者が「これを推し進めるのが自分のミッションである」と腹落ちしたうえで取り組むことが必須といってよいでしょう。 そのためには、技術推進担当者は自分が納得して他人に説明できるよう、その取り組みの意義などを経営層やマネージャーとよくすりあわせておくことが大事です。
・・・少し熱くなってマインドセットの話が長くなりましたが、情報集約と共有の話に戻ります。 その他のアクションとして、普及先の部会・チーム会などに出向いて直接説明の機会を持つことも有効です。SlackやTeamsで「見ておいてください」「こんなことをやっていきましょう」といった情報を流すだけでは技術推進活動としては全く足りません。足を使って、相手の場に出向いて行ってやっと届くこともあります。こうした、直接的に説明・周知の場を設けて伝えることと、定期的な社内ニュースレターのような形での継続的な情報発信とを組み合わせると、じわじわと認知が広がっていくのを感じられます。
壁② 「手間」「面倒」
「知っている」状態でもなかなか動かない
「知っている」状態になったとしても、次の壁が待っています。「手間」「面倒」という壁です。
現状の仕組みややり方を変えることには、それだけで抵抗が生まれます。「興味はある。でも今は忙しい」「いつかやろうとは思っているけど」という声は、推進担当者なら一度は聞いたことがあるのではないでしょうか。これは個人の怠慢ではなく、変化に対する人間の自然な反応です。
やらない理由をひとつずつつぶしていく
この壁に対して有効なのは、これまた少し強い言い方かもしれませんが、「言い訳をつぶしていく」アプローチです。
ひとつ目は、丁寧なフォローアップです。環境構築を一緒に手伝う、サンプルやテンプレートを用意して提供する、最初の一歩を小さくする——といった形で、「面倒くさい」をひとつずつ取り除いていきます。「そこまでやるの？」と思われるかもしれませんが、推進の序盤はこのくらいの丁寧さが必要だと感じています。
もうひとつ有効なのが、社内制度（特に目標設定や評価）と結びつけることです。通年や半期の個人・チーム目標設定と連動させ、推進したい技術への取り組みを目標として組み込んでもらうのです。導入・取り組み状況を定期的にレポートし、個人が自己評価に使えるようにしておくと、「取り組むとプラスになる」という構造ができます。人は損得を無視できないので、インセンティブの設計は推進活動の中でも特に効果が出やすい部分だと思っています。
壁③ 「がんばっても報われない」感覚
推進役自身が潰れないために
3つ目の壁は、推進担当者自身のモチベーション維持です。これは、推進活動の経験者であればほぼ全員が通る道ではないかと思っています。
「がんばっても報われない」という感覚は、推進活動の中でどうしても出てきます。会社の意思決定であるにもかかわらず、矢面に立つことで不満をぶつけられることがあります。
「あればいいのに」と言っていた人はたくさんいるのに、「ある」状態にしても使ってもらえない。（「あればいいのに」と言われるものは、だいたい「すでにある」のですが。）
「やってくれたらいいのに」と言っていた人がいるのに、「やって」も特に反応がない。（「やってくれたらいいのに」と言われるものは、だいたい「すでにやっている」のですが。）
こういったことが積み重なると、消耗していきます。
数年がかりになる前提で、続けること自体に価値がある
この壁を乗り越えるために、まず持っておきたいのは「組織や文化を変えることには時間がかかる」という前提です。数年がかりになることも珍しくありません。短期間での成果を求めすぎると、自分が潰れてしまいます。
トップダウン型の推進であれば、会社やマネージャーからのフォローが欠かせません。「個人が勝手にやっていることではなく、組織として推進している」ということを全体に対して繰り返し伝えてもらえるかどうかは、担当者のモチベーションに大きく影響します。
成果を可視化し、可視化のための問いを通じてメッセージを伝える
組織における変化が見えないと、報われない感覚は強くなってしまいます。これに対しては、例えば定期的なアンケートで推進状況を可視化するのも有効です。感覚ではなく数字で状況を把握することで、「施策にフォーカスする」姿勢を保ちやすくなります。進んでいない理由を感情的に処理するのではなく、次の打ち手を考えるための材料として使えるからです。
昨今のソフトウェア開発においては「フィードバックを速く、サイクルを速く」という考えが浸透しており、つい他の物事に対しても同じように急いでしまいがちだと考えています。短期間で成果が出るものに価値が置かれがちな環境だからこそ、行動から成果までのスパンが長い取り組みに腰を据えて関わり続けるというのも、エンジニアにとってのバリューの出し方の一つになると思っています。
また、アンケートによって「あなたの職場では〇〇ができていますか？〇〇に取り組んでいますか？」といった問いかけを何度も繰り返すこと自体が、「我々は〇〇をするべきである」というメッセージを暗に伝えることになる、という考え方があります。
下記のような質問項目を定期的に繰り返し問われたとしたら、どのように思うでしょうか。
・あなたの職場では、オープンにコミュニケーションできていますか？
・あなたの職場では、メンバー同士は信頼しあっていますか？
言うまでもなく、こうした質問項目を何度も問うこと自体が、「職場ではオープンにコミュニケーションすべきである」「メンバー同士は信頼しあうべきである」というメッセージを、暗に伝えているのです。
『サーベイ・フィードバック入門』より
アンケートに回答する側からは、もしかしたら「なぜまた同じことを聞くのか」と思われるかもしれません。しかし、同じ問いを繰り返すことで「これは組織として継続的に取り組む課題だ」という認識を徐々に浸透させていく効果があります。
おわりに——「フィードバックを速く」以外のバリューの出し方
技術推進は、相手が「人」であり「組織」であるため、大変です。言ったことがすぐには伝わらない、動いてもらえない、変わらないといった経験の積み重ねです。
ただ、私がこの経験を通じて感じたのは、こうした活動にも確かな価値があるということです。開発組織では「フィードバックを速く、サイクルを速く」というカルチャーが重視されます。それ自体はとても大切なことですが、行動から成果までのスパンが長いものを推進している力にも大きな価値があると考えています。
本記事では「心がけ」側面を強くしていましたが、最後に具体的な「技術」にあたる部分を抜き出しておきます。
情報の周知、認知の獲得
- ポータルを作る、主担当者が表に出てアピールするなど、どこを見れば、誰に聞けばわかるのかを明確にする
- ただし、属人化はあくまでも短期的な手段であり、中長期的には解消する前提でいること
- 部会やチーム会など、推進対象となる部署やチームの定例会議にゲスト参加し、直接説明・周知する
組織内での「面倒」や「やらない理由」をていねいに消していく
- 評価制度と連動させ、目標設定などのネタにしやすくする
- 「どうすればいいかわからない」や「時間が足りない」などのよくある返事に対するカウンターとして、手厚い立ち上げ支援や情報共有を続ける
推進役のモチベーションを保ち、継続する
- 経営層やマネージャーから、組織として重要な取り組みであると定期的に周知する
- 定期的なアンケートで推進度合いを計測しつつ、質問項目を通じて重要性を組織に浸透させていく
開発組織の中でなんらかの技術推進をしている方や、AI時代にエンジニアとしてどのような価値発揮をしていこうか、と考えている方のヒントになれば嬉しいです。
