Build Insiderオピニオン:長沢智治(4)
エバンジェリストの頭の中 ― ロジカル思考 基本編
組織をうまく巻き込みながら、日々の現場をどう改善していけばよいのか。エバンジェリストとして活動した経験を基に鋭く考察する。
エバンジェリストの活動
私は、エバンジェリストという職業に10年近く携わっている。
エバンジェリストという職業は、基本的にはマーケティングに位置するのだが、エバンジェリズム活動というのは、おおむね破壊的なマーケティングである。
セオリー通りに行う一般的なマーケティング活動と異なり、先を見て市場を作っていったり、あるべき世界に向けて情報を発信したりしなければならない。それを「人」が起点となって行うのだ。
単に言われた通りに情報発信をするのであれば、エバンジェリストである必要はないだろう。マーケティングのプログラムにのっとり、本社(外資系企業のエバンジェリストを想定)のメッセージやガイドラインに従い、情報発信するなら、それこそ、どこかの話し上手なイケメンにやってもらった方がウケがいいだろう。
エバンジェリストの協調モデル
エバンジェリストの行動・活動は、社内外にとっても理解しがたいものも多い。とはいえ、組織として同じ方向を向き、マーケティングと協調しながらエバンジェリズム活動(=テクノロジなどの啓もう活動)を行わなければ目的を達成できない。
なぜならば、エバンジェリストは、「人」だからである。人であるからこそ、その「人柄」や「経験」、「他の人からの支援」が絡み合い、情報発信に味が出てくる。
エバンジェリストが行動すると最初に反応してくれるのは、社内ではなく、社外の方々であることが多い。私の活動も、基本的に社外の同志に反応いただき、そこからモメンタム(勢い、イケてる感)を作っていくことが多い。社内は、後から「なんかすごいことになっている」「あ、うまくノッたらいいかも」と思うのだ。
難しいのは、このニワトリ-タマゴな状況で、どのように予算を確保したり、取りあえずの理解を得たりするかだ。
入力と出力の明確化
過去に、私が行ったエバンジェリストとしての活動を例に出してみよう。マイクロソフト時代に行った「Agile Day」というイベントだ。
「エバンジェリスト」(人)が、「アジャイルのイベント」(活動)を開催する
ご存じのようにアジャイルとは、特定に技術に依存するものではない。従って直接、マイクロソフトの製品やサービス、技術にとって一見関連がないように感じる。そのため、「マーケティング的な力学からすると、訴求対象が見えない」という理由で、優先順位は下がってしまう。
しかし、そこに以下の視点を投入すると「意義」を見いだせるようになる。
「アジャイルのイベント」(活動)を行う前:
- アジャイルが再び注目されてきている
- マイクロソフト技術(以下、MS技術)の開発者が他の技術の開発者よりアジャイルをキャッチアップ仕切れていない
「アジャイルのイベント」(活動)を行った後:
- アジャイルの波に乗る
- アジャイルな新機能を搭載した開発ツールの訴求になる
- MS技術の開発者にキャッチアップしてもらうきっかけができる
- 他の技術の開発者もMS技術に注目してもらえる
- * 実際にこの試みは、部内で承認され、有力情報誌でも取り上げていただけた。ちなみにそのときのAgile Dayについては4年の時を経て個人ブログにまとめてみたので関心を持った方は、こちらもご覧いただければ幸いだ。ちなみに上述したものはサンプルであり実際の提案書からの引用ではない。
ここで重要なのは、その活動自体を推すのではなく、「入力」と「出力」を明確にしているということだ。言い換えると、「現状」と「結果」である。これがあるのとないのとでは全く説得力が異なる。また、ここでは明示していないが、数値的なデータがあることが望ましい。
そしてこれらは、仮説であって構わない。要はその仮説に投資価値があるかが分かればいいのだ。仮説である以上は、仮説を検証するタイミングと、見直しをかけることを計画として盛り込んでおけばよい。
いかがだろうか? 残念ながら多くの活動では、これらなしで活動が進められることが少なくない。
- 本社に言われたから
- 今までやっていたから
- 実施することが自分のミッションだから
- やりたいから
という思考は、何も生まないのではないだろうか。
これらを私は、「打ち上げ花火系」と呼んでいる。
現場改善でも通じる
さて、これらは皆さんの現場の改善でも通用すると考えられるであろう。
- ツールを導入したいです
- アジャイルをやりたいです
といったことも含めて、まずは、上述したように考え、提案してみてはいかがであろうか。
講演でもよく話をさせていただくのだが、全ての行いは、人と、活動と、成果で表せる。成果は、入力(現状)と出力(結果)がある。この構成で物事をロジカルに考えると説得力が増すだろう。巻き込み力も増すだろう。そして何より、この活動に挑む自分自身や周囲のモチベーションが上がる。
開発者の得意技
ここまで読んで、Build Insiderの読者なら気付いたであろう。そう、この思考は、プログラミングと同じなのだ。
var result = ActionItem(currentCondition);
そして仮説と検証は、TDD(テスト駆動開発)よろしくやっていけばよいのだ。まず、現状と結果を想定してから、活動内容を詰めていくのだ。
ちなみにリファクタリングでは、やる活動とやらない活動や、連動する活動を考えていくとよい。とりわけ、「やらない活動」を見いだすことが効果的な現場改善やマーケティング活動には必要だ。
この投稿も
今回、少し間を置いてしまった後のコラムなので、心機一転、視点を変えてみた。いかがだったでしょうか。
この投稿自体も、読者はこういう情報(と少しの裏話)に関心があるという仮説で執筆をしてみた。ここから結果を見いだし、仮説を検証するには、読者からのフィードバックが不可欠である。ツイートでも、はてブでも直接のメールやメッセージでも、ご意見いただければ幸いだ。
ちなみに、今まで悲しいかな一度も生の声をいただいていない。このコラムの執筆のモチベーションのためにもぜひ反応いただければと思うw
長沢 智治(ながさわ ともはる)
革新的なビジネスモデルでソフトウェアデリバリーを実践し続けるアトラシアン株式会社のエバンジェリスト。
ソフトウェア開発のライフサイクル全般を経験したのちに、日本ラショナルソフトウェア、日本アイ・ビー・エムなどでプロセス改善コンサルティングに従事。2007年より7年間、マイクロソフトのエバンジェリストを務め、2014年1月よりアトラシアンで初のエバンジェリストとして活動中。
- ブログ: Re:WorkStyle ITとビジネスの可能性@ITmedia オルタナティブブログ
- メール: tnagasawa@atlassian.com Twitter: @tnagasawa Facebook: Tomoharu.Nagasawa
※以下では、本稿の前後を合わせて5回分(第1回~第5回)のみ表示しています。
連載の全タイトルを参照するには、[この記事の連載 INDEX]を参照してください。
3. あなたのコード届いていますか? 開発現場は見えていますか?
コードを完成させる「Code Complete」から、ユーザーが求めている何かの提供を完了させる「Feature Complete」へ、開発現場の意識を変えていこう。