透明性のある「エンジニアリング組織」をつくるためにやったこと

フォロワーを増やす

永江耕治氏：続いて、3つ目の話に移っていきます。第3章は「フォロワーを増やす」という話です。

みなさんほとんどの方がTEDをご存じだと思います。世界的に有名なプレゼンテーションのイベントです。ここで発表された有名な3分の動画があります。デレク・シヴァーズの「How to start a movement」という、見たことある方もいらっしゃるかもしれませんが、「社会運動はどうやって起こすのか？」という話です。これはずいぶん参考になった考え方でした。

どういう話かといいますと、たくさん人がいる広場の中で1人踊り始めるんですね。そうするとみなさんどう思いますか？　「なんか変な人だな」と思いますよね。でも、そこでもう一人が加わって2・3人ぐらいで踊り始めると不思議なことが起こりました。

しばらくすると更に数名が集まってきて一緒に踊りだしたんです。そうすると、特定の変わった人ではなくて、グループになってくるんですよね。グループになってくると、「なんかちょっとおもしろそう」となって、ここから10名、20名、30名と増えていくんですよ。

このあとどうなったかというと、あっという間にこうなりました。「もう加わらないほうがおかしいよね」という感じで、「加わらないほうが損だ」というムーブメントになって動き始めたんです。

何を言いたいかというと、組織を動かすのは、もちろんリーダーにとって重要な役割です。0→1にするということ。ですが、2人目、3人目が加わることで、それが5名、10名、20名、30名となってくれる。この2人目3人目のフォロワーが組織を結果的には大きく動かしているんです。

2つの事例から見出したこと

これを参考にして行った施策を2つご紹介したいと思います。1つ目は、Python資格取得を推進した話です。

2017年にPythonの認定資格制度が開始されたのを機に、資格取得を奨励することでプログラミングに興味をもつ社員を増やそうと考え、5人で1チーム作って競争をするというゲーミフィケーションの要素を取り入れ資格取得施策を行ったんです。

1年間で50人取得という目標を掲げて、オフィスの中の大きいホワイトボードに、このように5人1チームで名前を書いて、合格したら花を選挙ボードみたいな感じでつけていったんですね。5人最初に揃ったチームには賞品も出しました。

スタートしたら最初の10人ぐらいはサクッと取るんですよね。ただ、そこでしばらく停滞しました。

なぜかというと、当社はITエンジニアがほとんどなのですが、ネットワークエンジニアが非常に多いんです。なので、コーディングに心理的な抵抗がある人が実はけっこうな数います。なので、止まっていったんですね。

ですが、ある出来事から変わってきます。事業本部長も受験して合格し、勉強方法を全社に共有したんです。すると……チームリーダーたちは、自分より上位の役職の人でかつ忙しそうな人が取ってしまったことに、「やばい」と思うわけなんですね。

そのあとすぐにチームリーダーみんなが資格を取ったんです。資格を取ったチームリーダーは、次に自分のチームのメンバーに声をかけるんですよ。こういったことが短期間でなされて、一気に30名ぐらいが資格を取ったんです。

そのあとはもう爆発的に増えて、80名ぐらいまでいきました。30名以降はリマインドをすることや、進捗を追いかけなくても一気に取得者が増えていきました。

臨界点は合格者が30名ぐらいだったと思います。最初の10名はもともとコーディングをやっていた当社の中では特別な人だったので、他のメンバーから見ると「僕とは違うよ」みたいなところがありました。しかし、そうでもない人たちが資格を取り始めると、そこから一気に変わり始めたんです。

その結果、この資格を運営している団体から、これだけ短期間でこの人数が取ったのは珍しいので「一緒にプレスリリース出しませんか？」という話があって、実際にニュースになったというような話もおまけでついてきました。

2つ目は「イベント登壇ラッシュ」を作った話です。2018年の話になるんですが、トップダウンで大きいイベントに登壇することに決めて、誰が登壇するかも決めずに申込みをしました。これも実はけっこう反発があって、「そんなのトップダウンで決めんなよ」とかなり批判されました。

まずはDevelopers Summitに2名の社員が登壇し、3月にはMANABIYAというイベントに登壇。4月はJapan Container Days、今はCloudNative Daysになっていますが、そこにも登壇したり、Interop Tokyoでも登壇し、多くの方に聞いていただきました。それから7月のJANOG42 Meetingでも登壇する社員が出てきました。

大きいイベントに登壇することが特別ではなくなったので、2019年は特別そういうことをやっていないのですが、大小のイベントに様々な人が自然と出ている感じに今はなって来ました。

このケースでの臨界点は、大きなイベントへの登壇が半年ほど続いたときぐらいだったと思います。以前では考えられなかった「社外の大型イベントでの登壇」が、今や特別なことではなくなってきています。

この章のまとめです。フォロワーが増えると社員も変わります。フォロワーの臨界点を越えると組織も変わっていきます。

透明性を高める

4章目のアジェンダです。「透明性を高める」です。

「アジャイル中期経営計画」なるものをやりました。先ほどのお見せした冊子ですね。これを昨年作ったのですが、経営陣が作成したものをトップダウンで落とすのではなく、作成途中のα版・β版を社員に開示して、社員から意見・質問を集め反映させるという取り組みです。

社員からのフィードバックには経営陣がすべて回答しました。未完成な計画を途中で開示することで社員とあえてコンフリクトを生み、その説明をしていく過程により相互理解が進みました。

α版を社員に開示したのは昨年9月30日、β版は11月に出しました。そして1.0版が12月に出て、それをきれいにデザインをしてまとめた紙版が、今年の1月に配布をしたものになります。完成形がここまでできました。

具体的に何をしたかといいますと、α版に記載したのは経営から事業部への期待がメインだったんですが、言葉も洗練されていないし、まだ議論の途中の内容も含めて全社員に開示しました。

そのあとに、Googleのフォームで意見や質問などを全社で書けるようにしたところ、百数十件ぐらい意見が出ました。「そもそも表現わからない」「何を言ってるんだ」ぐらいな感じの批判もけっこうあったんですが、社員はたくさんの意見を書いてくれました。

それらをもとに各部門の部長以上の合宿などで議論して、事業計画に反映させていきました。

11月に入って、今度はβ版をリリースしました。合宿で話し合った事業部の詳細もβ版には含めてあり、α版への意見・質問についての回答も全部まとめてテキストで全社に開示しました。

さらに、現場報告会という社員200数十名が集まるイベントがあるのですが、そこのなかでワークショップ形式でこんなことをやりました。4人1チームになって、意見・質問を1個出してもらいました。それを紙に書いてもらい、そのイベントの中で回答しました。

これは回答している様子ですね。集まったものに対して、その場で事業部の責任者に回答してもらいました。時間が足りなかったので全部はできなかったんですが、できなかった分はすべてテキストで回答しました。

そしてその後、また管理職が集まって意見が出た部分をさらに詳細化をしていきました。12月の段階でα版・β版のフィードバックをすべて反映した事業計画を社員に発表することができました。

そして翌年の1月にデザインも少しきれいにして全部まとめた冊子を配布しました。

ここで終わらないんですね。年に2回実施してる社員総会があるのですが、ここもイベント的な感じにしました。スマホで意見を入力できるような、Sli.doみたいなものを使いまして、その場で、あるいは前日から意見や質問を入れられるようにしました。匿名で書けるので、社員はいろいろ書けます。その場でステージ上にいる取締役たちが1つずつ回答していきました。回答しきれなかったものは後日テキストで回答しました。

こんなことを半年ほど続けてきたところ、こういう感想を社員からもらいました。「このようにサンドバッグになる覚悟があるのはすごいことだと思います」。褒め言葉として受け止めています。

「アジャイルな状態」とは

アジャイルな状態とは？　これは『エンジニアリング組織論への招待』の141ページにはこう書かれています。「情報の非対称性が小さい」「認知のゆがみが少ない」「チームより小さい限定合理性が働かない」「対人リスクを取れていて心理的安全性が高い」「課題・不安に向き合い、不確実性の削減が効率よくできている」「チーム全体のゴール認識レベルが高い」となります。

まさに事業計画は、数百人単位とかになってくると非対称性が大きくなり、かつ認知のゆがみも大きくなっていきます。完全ではないもの、半年ぐらい議論をあえて巻き起こしてやることは……例えば声の大きい社員が全社員が見えるなかで公開の質問をして、「いったい経営陣ってどうやって回答するんだろう」って、おもしろい見世物じゃないですか。社員にとってはおもしろいんですよ。

できあがったものや完成したものを渡すだけだと読み込まないところも、こういう方法をとることで見てくれるようになって、それが理解になりコミュニケーションになっていって、非対称性が小さくなっていくわけなんです。

この章をまとめていきますと、透明性を高めると、認知の非対称が小さくなります。認知のゆがみも少なくなります。結果、不安が減って、不確実性の削減を効率よくできるようになってきます。

自ら動きはじめる

最後の章です。「自ら動きはじめる」。その変化はどうなっていたのかという話です。

当社は、「APアカデミー」という社内大学を作っています。社員数が数百名程度の会社としては、かなりのコストと労力をかけてつくっています。

ほとんど内製なんですが、昨年時点で120講座、今はもう少し増えています。こんな講座を作っています。

ですが課題もけっこうあって、運営する中でこんなこともありました。当社のエンジニアが講師として技術研修をやるのですが、講師と受講生の上司との間で受講生のキャリアプランに関する意識にギャップが生まれてしまい、ここに壁ができてしまいました。

講師は、お金のためじゃなく熱意でやってるんですよね。すごく一生懸命受講生をサポートして進捗確認をして、そこをフォローしています。

受講生のキャリアについては、研修の講師ではなく受講生の上司が本人と一緒に考えるのですが、講師陣からこんな声がありました。「受講生の上司が研修の進捗を把握していない」「成長した人の異動を真剣に考えてくれていない」。

管理職の人たちは一生懸命業務をしていて、それぞれ立場があるので決してサボっているわけではないんです。しかし、それぞれの立場で考えると、キャップが生まれてしまうことがありました。

そこで、エンジニアの講師チームと上司チームを一緒にして、数回の飲み会を企画しました。飲み会といってもテーマが設定されていて、それについて話をする会です。

私や役員クラスもそこに入ったりして、飲み会なのに翌日には議事録も出てきました。そうして率直にお互いの意見をぶつけあう場を設けたのです。

その結果、上司側から「学級委員長」と呼ばれる調整役が設置されました。学級委員長は講師陣と受講生の上司と連携を助け、受講生の進捗確認やサポートもやってくれ、全体の関係性が前よりすごく良くなっています。

社員が自律的にやってくれるのはすごくいいのですが、揉めていたりちょっと良くないところに気がついたら、放置せずに多少の関与はしたほうがいいと思います。「自走できるように、でもへこたれさせないように」ということは、組織の運営の観点でいうと非常に重要だと思います。

部署横断で関わるエンジニアリングメンター

最近、こんな動きも出てきました。「部署横断で関わるエンジニアリングメンターをはじめました」。当社のエンジニア社員のnoteです。こんなことを自律的に始めてくれています。

彼は先ほどのプロフェッショナル職のエンジニアなのですが、上司ではないけどエンジニアの育成に貢献したいという思いを強く持っています。「メンタリングっていい手法だよね」というところから、これを始めました。そしてそれを人事部門と相談し新しい部署を作り、今はそこを兼務するかたちで仕事をしています。

社員の「やりたい」を尊重し、新しい部署を設立したのです。これは人事部が「作ってくれ。やってくれ」というところからスタートしたわけではありません。社員の自律的な行動から始まったのです。

こういったことが起こるようになり、ここ数年で組織と社員は変化してきました。例えば、書籍を執筆する社員が増えてきました。とくに右側の2冊は最近のもので、このAnsibleの本はつい先日出ているのですが、当社の社員がその執筆陣の1人になっています。『Software Design』のような記事に寄稿するような社員も、少しですが出てきました。

そして、今はRed Hatさんと提携をして、ネットワーク運用の自動化のサービスパッケージを作ってソリューションとして提供しています。これはAnsibleを得意とする社員の存在がきっかけとなり始まりました。このようなこともエンジニア主導で進むようになってきています。

当社ではこのような自社製品を持っています。ネットワークのSIの中に、ファイアウォールの評価という作業があります。これがかなりの手間と時間がかかるものなのですが、「これはもうイヤだな」と感じた当社のエンジニアが、コーディングのスキルを身につけて開発したところから始まった製品です。今は事業としても黒字化するようになってきました。

最初はファイアウォールだけだったのですが、L2・L3の分野のテストもできるようになって、マーケットも少し広がってきています。InteropTokyoでは、Best of Show Awardのファイナリストまでいくことができました。

そしてこんなサービスの開発が今社内で動いています。「KITE」という名前のアプリケーションなんですが、「みんなで”なりたい”を育てる」というコンセプトのキャリア開発を支援するWebサービスです。これは12月にリリース予定なのですが、社外に出すのではなく、社内向けとして作ってくれています。これも、エンジニアたちが自律的に企画し進めているプロジェクトです。今はβ版が出て、ファーストユーザーが試している最中です。

この章のまとめです。リーダーシップをとるのは役職者に限りません。「パワー（権威）を持っている人＝職位が上位の人」ではないんです。

職位＝権威というのは、左側の公式の権威です。強制力を持つ権限として必要なものです。右側の非公式の権威も実は重要な役割を果たしています。この人たちは実質的な影響力を持っています。

この2つが共通してできることは、「方向性を示す」「衝突をコントロールする」「ルールをメンテナンスする」。これらは非公式の権威でもできるんです。

社員の「やりたい」ことと、会社の「やりたい」ことを重ね合わせれば、こういった非公式の権威を持つ人たちが増えていきます。先ほど紹介した事例の社員たちは、非公式の権威を身にまとっている社員たちなのです。

エンジニアリング組織を作るということ

最後に全体のまとめです。エンジニアリング組織を作るというのはこういうことなんじゃないかと思っています。

この写真はヨーグルトなんですが、これはエンジニアリング組織を作るメタファーになっていると思っています。

何かというと、エンジニアリング組織は善玉菌が発酵するかのように、時間をかけて作られていくものだと思います。勝手にできるわけではなく、環境を作りそれをより良くしていくことで、そこの中で自律的な社員が増えていくことが経営的な視点でいうと重要なことになるのではないかと思います。

組織にストレスをかけて揺らし続けながらも、良きフォロワーが増えるような良い環境を作り続けることに、経営は苦心し続けなければならないと思っています。

クライアントワーク企業でもできるエンジニアリング組織のつくり方に必要なのは、この3つです。2～4章で話したことから、そして自ら動き始める。この一連の流れのことだったと思っています。

今の当社は、マネジメントもできなかったところから、徐々に自己組織化された組織に向かっています。とてもじゃないですが、まだ完成されているとは言えません。今はまだ道半ばではありますが、前進はかなりできているかなと思います。今日はそのリアルなお話をさせていただきました。

私からの発表は以上です。ありがとうございました。

（会場拍手）