良い目標、良い環境のチームにエンジニアは集まる　ニューノーマル時代のエンジニアの働き方

部門跨ぎのコミュニケーションを意図してやるマネージャーのほうがパフォーマンスが高い

石山洸氏（以下、石山）：分断と結合というちょっと社会学的な目線な言葉も出たので、せっかくなので小林さんにもちょっとうかがってみたいなと思います。調査結果の内容でもいいですし、今日、松岡さんと古川さんから実際の調査結果に対する回答はいっぱいもらえているので、ここまでの流れを踏まえて社会学者目線で思ったことがあれば、ぜひコメントいただければと思います。いかがでしょうか？

小林 祐児氏（以下、小林）：いくつかあります。まさに部門とか非エンジニア・エンジニア、そういう区分けを跨いでコミュニケーションがどのぐらい起こるかが前提としては大事なのかなと思うんですけれども、いくつか観点としてあるのは、本日せっかく「ニューノーマル時代の」みたいな冠があります。テレワークに関して実は我々のシンクタンクでかなり調査しているんですね。

テレワークにおいて活躍できている、つまり組織のパフォーマンスを上げているマネジメントの特徴って何だろうというのを分析したんですけど、1つおもしろいなと思ったのは、「他部門・多職種との調整がうまい」みたいなことが数字的に出てきたんですよ。

「あ、なるほどな」と思いました。オフィスにでている状況であれば、横の島に企画部門がいて、その横にIT部門がいて、その横にマーケがいるみたいな構成で、すれ違いざまの交流みたいなことが起こるので、共通の言語や共通のコミュニケーションが生まれやすい。横断の調整ごとも偶発的に生まれやすかったのだろうなと。

でも、今はテレワークですよね。ITエンジニアは、テレワークにすごく向いている人たちなので、おそらくかなりバラバラに働いていると思います。そうした中でも、やはり部門跨ぎのコミュニケーションや調整を意図してやっているマネージャーのほうがパフォーマンスが高くなります。

このあたりみなさんどう感じているのか、今後テレワークが前提となって人を採用していく領域だと思うので、何か最後のほうに時間があったら聞いてみたいと思っています。

石山：ありがとうございます。じゃあせっかくなので、もうテレワークというキーワードが出ちゃったので、松岡さんにも少し聞いちゃいたいなと思うのですが（笑）。

松岡剛志氏（以下、松岡）：はい。

テレワークは全般的にどう受け入れられているか

石山：エンジニアにとって、今このニューノーマルでテレワークになっているのが、全般的にどう受け入れられているかみたいな話と、実際にテレワークが長期化していく中でなにかいいプラクティスとか、そんな話があればぜひ教えていただければと思いますが、いかがでしょうか？

松岡：了解です。まず、エンジニアといってもいろいろといますので、出社したいエンジニアもいれば家の中にいたいエンジニアもいるので、なかなか一概に言うのは難しいなと思っています。ただ、いくつか私の持っているデータで言いますと、コロナ前からデジタル企業、デジタル売上比率が非常に高い企業というのはテレワークの状況を整えていました。

2020年の4月に公開した私どものデータでは、4割以上の会社が「個人の判断でリモートワークが可能」でした。上司に相談のうえなど、少し条件が加わるものまで入れると、その倍以上がリモートワークに取り組まれていました。デジタル先進企業ってすごいなって思います。なので、コロナになって、そういう意味で働き方が変わったのかと言うと、「テレワークの量増えたね」ぐらいの認識の方が多いんじゃないでしょうか。

次にそれがじゃあどうなのかと言いますと、ここからは人によります。やっぱり「寂しい」という声もあるし、「快適で仕方がない」とかもあります。また今度は管理者の目線で言うと、「ちゃんとあいつ朝起きているかな？」みたいな、「毎日朝5時にコミットしてるんだけど、大丈夫かな」みたいな、そういうさまざまな細かい問題が起きています。「うん、まぁテレワークにはテレワークの問題、出社したら出社の問題、あるよねぇ」みたいな。そういう意味では、受け入れて日常になったという感覚があります。

石山：ありがとうございます。せっかくなのでちょっとだけうかがってみたいのですが、さっきの「朝5時にコミットしてて大丈夫かな？」みたいなところの延長線上で、例えばコミットのログを解析してメンタルヘルス上のpredictionをしてなにか問題を解決するとか、そこらへんまで突っ込んでいる人たちっているんでしょうかね？

松岡：まず、その事例そのものを聞いたことはないです。ただ、やっていてもまったくおかしくないなと思います。でもこれは、要は勤怠で、みなさんの会社でも「月曜日の朝来ない人リスト」ってこっそり取っていると思うんですけれども、まぁ同じ話ですよね。うん。だから、あんまりそんな表立って言わないんじゃないですか。みんな。

批判が今までとしたら、これからは称賛

石山：ありがとうございます。すみません。ちょっとなかなか聞きにくい話を聞いてしまいましたが……。うかがった背景の1つとしましては、次のトピックでまさに今日のタイトルにあります「良いエンジニア環境って何だろう？」ってところを深堀っていきたいと思いました。

今のようないわゆるテレワークが整備されているハード面もあると思うのですが、そのほかにもたぶんいろいろな環境という部分の意味合いがたくさんあると思うので、そのへんをうかがっていきたいんですけれども。

じゃあまずはちょっと古川さんからですね。具体的に現場で良いエンジニア環境を作るためのビジョンとか打ち手でやられていることがあればうかがってみたいのですが、いかがでしょうか？

古川昌幸氏（以下、古川）：パーソルグループのビジョンは「はたらいて、笑おう。」なんですね。働く環境がよくないと最後に結果を出して笑えないと思うので、やっぱり働く環境というのはすごく意識しています。

そのビジョンを達成するために我々DXに取り組んでいるメンバーはどうしているかというと、働き方もテレワークが増えて、今アジャイル型のスクラムのチームをたくさん作ろうとしているんですね。

そうするとスピード優先になり、最初から100パーセントを目指すのは難しいので、そこの何パーセントだったらサービス提供できるか、サービスインできるかという見極めが必要です。そこから100パーセントにどんどん近づけていく活動というのは、「ダメじゃん。70パーセントしかできてないじゃん」って批判するのが今までだとしたら、これからは「おっ、この70をがんばって75にしたね」って称賛をするような、そっち側に僕はシフトしていかなきゃいけないんじゃないかと思っています。そこを組織のオペレーションをやる上で大事にしようとしています。

それをやるためには、やっぱり各個人がそういう意識を持って動いていかないといけません。誰かがやってくれると思うと絶対それはうまくいかないので、常に自ら学ぶ習慣を持った組織にならないといけません。そのために、外に出ていろいろなことを学ぶ機会を僕らがちゃんと提供できるようにと意識しています。

あと、新しい案件とかプロジェクトとか、ちょっとした機能の追加でもそうなんですけど、「なにか1個やりたいことがあったら、3つ捨てろ」って言っています（笑）。技術もどんどん変わっていくし、やることがどんどん積もっていったら手が回らなくなってしまいます。何か1個やろうと思ったら、3つぐらい捨てて身軽にならないと真剣に新しいことには取り組んでいけないので、そこを文化として大事にする環境づくりは、今目指すところの1つです。

石山：ありがとうございます。小林さんのリサーチの中でもまさに今日も何度も出てきます「混ざる」と「目指す」というのがあったのですが、「はたらいて、笑おう。」という「目指す」があって、具体的にそのアジャイルのチームを作っていくという「混ぜる」があって、それが両輪で動かれているのかなと思います。さらにはそこを強化していくためにやらなくていい仕事のオミットをうまくマネジメントがやるというところと、余裕ができることによって戦略的な自発的な学習力を高めていくような文化の組織にするというところは、すごく的を射ていると思いました。ありがとうございました。

10割を目指して7割達成ぐらいがちょうどいい

石山：じゃあこの古川さんの回答に対しまして、また答え合わせに入っていきたいと思います。DX Criteria、それからいろいろなエンジニアのマネジメント経験もされている中で、松岡さんが答えとして持たれている部分があればぜひ教えていただければと思います。

松岡：ありがとうございます。今の時代のモノつくりというのは、挑戦回数とか経験数がすごく大事だと言われています。Googleとかがやっているレポートで「DORA」というのがあるんですけれども、そこでは「four key metrics」という単語がありまして、そのうちの1つがデプロイ頻度。

これ、「デプロイ頻度が多くて、リリースの時の失敗率が低くて、障害復旧が早くて、コミットしたコードがすぐ本番リリースされるという企業は、基本的にKPIの達成率がそうじゃない会社に比べて倍良い」みたいな話があるんですね。と言った際に、7割でいいというメッセージはすごくいいんじゃないかなと。

基本的にこれからの時代というのは小さい失敗ができるための環境整備というのが非常に重要だと思っています。挑戦回数を増やしたいなら失敗を許容しなきゃいけない。そうすると、どんどん技術的なアプローチ・企画的なアプローチの双方でそれを支えなきゃいけない。

技術的なアプローチだと、フィーチャートグルとかカナリアリリースとか、そういうのがありますよね。ああいうものをまず組み合わせていって失敗する。どんどん失敗を奨励する。そういうのがいいと思っていて、まさにそういうメッセージだったのかなと思っています。

もう1つ7割という数字で思い出すのがモチベーション周りの話。アンディ・グローブさんが作ったOKRなんかが注目されていますけれども、ああいうものも、その立てたKey Resultというのは「だいたい7割達成できればOKだよね」というようなかたちにしています。

やっぱり人間、10割を目指して7割達成ぐらいがちょうどいい。そういう目標のほうがモチベーションが上がりやすいというのがありますし、あわせて、とてもいい目標設定なんじゃないかなと思っていました。

石山：ありがとうございます。例えば具体的にOKRみたいな手法も出ましたが、パーソルの中でもOKRとかって使われているのでしょうか？

古川：「OKR」という言葉としては使っていないのですが、意識としては似たような考え・発想でやっているかなと思います。

OKRがあることによって混ぜる・融合が進む

石山：ありがとうございます。あと、小林さんもたしかパーソルってOKRを導入するためのソフトウェアも開発して展開されているとうかがっているのですが、実際に組織マネジメントをしている中で、OKRっていわゆる先端的デジタル企業じゃなくて大企業の中でも導入され始めているとかっていうのを、うかがってたりしますか？

小林：私、OKRとかが出てきた時には「よくできたMBOのことを言ってるだけか」と思ったんですけど。

でも最近ちょっと違うなと思ってきたのは、先ほどの7割達成という話は、あれは別にMBOでも実現できる話だなと思っています。ストレッチの利いた目標を立てられないというのは、今のMBOがうまくいっていないからよく出てくる話なので。しかし、OKRがMBOと1つ違うなと思ったのはやっぱり目標の公開ですね。

隣の人が何の目標を立てているのか仕事がわからないというのがほとんどの今の会社のMBOのあり方で、OKRの基本思想の中には公開していくというのがある。最近ですと、花王さんとかも公開型に変えましたけれども、目標の透明性を上げていく動きはかなりおもしろいなと思っています。

自分の上司がどのような目標を持って自分に命令しているかがわからない状態だったのはある種異常だったなとも言えます。そうしたことが明確になることによって、部門横断でも、「他部門のあのマネージャーはこう動いているんだったら、この話持っていったら喜ぶかも」みたいなことが分断ではなく融合のほうに進むかもなとか思っています。現在、調査も行っているんですけれども、なんかそういった意味での可能性みたいなのはすごく感じながら今のお話を聞いていましたね。

石山：ありがとうございます。「OKRがあることによって混ぜる・融合が進む」というのはすごくおもしろい視点だなと思いました。ありがとうございました。

なぜ内製化したいのか

ここから、小林さんのリサーチの中でもmake・buyみたいな話もありましたが、良いエンジニア環境の話になると、「内製化ってできているのか？」とか、あるいは「内製化ってそもそもどのレベルなのか？」みたいな話とかが話題に上がると思うので、具体的に聞いていきたいと思います。

まず松岡さんに、内製化のキーワードに対して、「内製化って実際にどのレベルだったらいいの？」みたいな話をちょっとうかがってみたいのですが、いかがでしょうか？

松岡：そうですね。その「じゃあ内製化って何？」「レベルって何？」みたいな話があると思います。「正社員でエンジニアが100パーセントいたら内製化達成なのか？」「有期雇用契約社員エンジニアがいたら達成なのか？」、などなど。

そのうえで「なんで内製化したいんだっけ？」に立ち返ってみると、僕たちは早くモノをいっぱい作りたい。なので、それに対して都度リソースを調達するという発想だと、毎回毎回リソースを探索して、評価して、クロージングというか、まぁ選定しなきゃいけない。このコストを減らしたいから内製化をすると考えています。

そうなった場合、「じゃあ結局それって何だ？」ていうと、リソースのコントローラビリティ。ちなみに、開発者として自分のことをリソースと言われたらイラッとするので、今違う脳みそでしゃべっているので言い訳させてください。まぁいったん置いておいて。

リソースのコントローラビリティがどっちにあるのかが経営目線では非常に重要だと考えておりまして、内製化とは1つ、自社に、事業会社側にリソースのコントローラビリティがある方が、デジタル人材が多く存在する状態だと考えています。

石山：ありがとうございました。なるほど、リソースのコントローラビリティ……リソースと私も言っちゃいましたね。失礼しました。古川さんにうかがってみたいのは、パーソルがどんなかたちで今内製化しているのかの実態もちょっとうかがってみたいんですけれども、いかがでしょうか？

自分でイニシアティブを取れなかったら、それは内製化じゃない

古川：パーソル自身は自分で作りたいとか内製化志向が強い文化を持っていると思います。やはりまず自分でっていうところは最初に来るので、それは今松岡さんから言っていただいたコントローラブルというのが大前提ですが。

僕自身はどっちかというと、イニシアティブをちゃんと持って進めていくことが内製化かなと思います。ただ、人が潤沢にいるわけではないので、どうしてもやりたいことを実現するためにパートナーさんの力を借りながら一緒にコラボレーション、コワークしながらやっていくというスタイルになっています。

ただ大事なことは、意識の問題もあって、どうしても「要件定義をビジネスサイドがやって、その要件に基づいていいものを作る」って言ってると、やっぱり受け身のスタイルになっちゃう。あるいは、ややもするとやらされ仕事になっちゃう。ルーチンワークみたいなかたちで。そうするとやっぱりなかなかこう……僕の定義で言うと、自分でイニシアティブを取れなかったら、それは内製化じゃない気がするんですね。

だから、けっこう厳しい言い方になりますが、イニシアティブを持って仕事をするというのは、自分のやりたいこと・実現したいことと、それに伴う結果に自分でちゃんと責任を持てる状態を自分が作り出すというのが、内製化ができているということです。そういう組織であれば、結果、楽しく働けることにつながっていけると思います。

ちょっと自分ごとになっちゃいますけど、例えば僕もコンサルタントをやっていました。今、事業部門でやっています。コンサルタントっていくら良いことと正しいことをお客さんにレポートを作っても、最後まで自分でできないのでコンサルの結果の責任を取れないんですよね。それってすごくもどかしい部分がありました。

でも内製化をユーザー企業側の立場でやると、そこは自分でちゃんと結果まで責任を持ってやれるというのがやっぱり1つの醍醐味だし、イニシアティブを持った内製化の姿なのかなと思います。

マインドチェンジができるかどうかがポイント

石山：ありがとうございます。小林さんのリサーチの中でも「目指す」って話がありました。さっき古川さんが「イニシアティブ」という言葉を使っていましたが、いわゆるSIから例えば事業会社に移った時に、目指すものを自分たちが作るところにもう一歩内製の本質みたいのがあるというお話をうかがったんですけれども。

そういう意味では、例えばSIとか受託をやっていた会社さんから事業会社へ行く人とか、事業会社へ行って活躍する人はどんなタイプのエンジニアなのかというのを、松岡さんにうかがってみたいのですが、いかがでしょうか？

松岡：一言で言うと、マインドチェンジできるかどうかなんだと考えています。SIerさんのビジネスモデル的に、QCD、まさに要件に対してちゃんと納品する、例外もあると思いますが、これが重要なケースが非常に多いと思っています。

一方で事業会社の場合、それが納品されたところで、社内納品したところで、KPIが上がらないとどうしようもない。会社潰れちゃう。なので、QCDを守ることが仕事ではあるんですけれども、それを超えていかなきゃいけない。このマインドチェンジができるかどうかが、活躍できる人材かどうかに変わるポイントなんだと考えています。

石山：ありがとうございました。3人とも非常に勉強になるお話を教えていただきました。では最後に、今日は、良いエンジニア環境に関する取り組みという話だったのですが、未来型の話も含めて、それぞれお二人にこれから取り組んでいきたいこと、あるいは今足元でこんなことがさらに進んでいるみたいなところをうかがってみたいと思います。では、古川さん、いかがでしょうか？

チームとグループは違う

古川：今日いろいろお話ししましたが、本当にまだ道半ばの部分が多くて、なかなかこう、DXそのものもそうだし、もう1つのデベロッパーエクスペリエンスもそうだし、今はやっぱりどちらも道半ばなんですね。でもいいチームを作りたいと思っています。

それは……僕はチームとグループって違うと思っているんですよね。チームというのはそれぞれチームの中に、ラグビーのスクラムでもそうですけど、役割がちゃんとあって、個々人がその役割を果たす中でバインドしてアウトプットを出す。これがチームだと思っていて、なんとなくぼんやり集まっているのはグループでしかないと思います。僕は、ちゃんと強いチームを作りたい。

その強いチームでスクラムを組んだらすごいことがたぶんできるようになるし、たぶんすごいスピードでモノづくりも含めてできるようになるだろうと思っているので、それをとにかく実現していきたいなと思っています。

ただ、そうは言ってもなかなか、冒頭小林さんからもあったとおり、じゃあどうやってそういう人を採用したらいいんだろうと。なかなかそのスクラムを組むための人も集まらないということで言うと、特にある程度会社としてのネームバリューがある会社だと応募もあって採用できますけど、そうじゃない規模の小さい会社だとやっぱり募集しても応募してくれない。

そのあたりを解決するために、グループ全体でうまく人を採用して、その中で適所適材を実現するようなことに取り組んでいこうと思っています。そうすると、希望の収入と自分の実際の収入のギャップも減ってきて、シニシズムも低くなっていくのかなと思っています。

石山：ありがとうございました。じゃあ最後に松岡さんから、今CTO協会もそのほかの仕事も含めてかなりいろいろなことを取り組まれていて、今日古川さんとの答え合わせ的なかたちでお話ししましたが、その答えの未来みたいなお話があればぜひちょっとうかがえればと思います。

良い目標があって、良い環境がある

松岡：まず、世の中のエンジニア、デジタル人材の需給というのがもうメチャメチャ崩壊していると思っています。たしかエンジニアの求人倍率が今8倍ぐらいですかね。なので、エンジニアという生き物はどこでも行けるんです。転職しようと思ったらいつでもできる。なんだったら転職すればするほど給料が上がる。

逆にエンジニアからすると、じゃあ自分はそういう場面で何をするべきなのか、けっこう考えているはずです。先ほどのお話で言いますと、グループは目標がない。なんとなく集まっている。いい話です。これをわかりやすい言葉で言うと、チームは役割があって目標がある。やっぱりどこでも行けるのであれば、いいことをしたい。いい目標・いいゴールに向かって走りたい。

ですから、良いエンジニア環境に対する取り組み、あるいはエンジニアがどんどん集まるのは、おそらく社会的に価値のあるいいことに取り組み、それを発信し、共感し、そして2つのDXにコミットしていてすばらしい環境があるから、「いい目標があって、いい環境がある。じゃあ入ろう！」みたいな構造になっていくのかなと理解しています。

石山：ありがとうございました。今日は第1次世界大戦の話から始まりまして、壮大なお話から始まりつつ、いわゆるDXの未来型のお話というところまでいろいろお話ができて、非常に私もモデレーターとして話をうかがえておもしろかったです。ありがとうございました。