ニューノーマル時代のエンジニアに働きやすい環境を作っていけるか
石山洸氏（以下、石山）：本日モデレーターを務めます、株式会社エクサウィザーズの石山と申します。よろしくお願いいたします。
先ほど大変おもしろい、第一次世界大戦のお話も出ましたが、小林さんの話を受けまして、これからニューノーマル時代に向かってエンジニアにとっての働きやすい環境を作っていけるのかをテーマにお話できればと思いますので、よろしくお願いいたします。
それではここから、パネリストに改めて自己紹介いただければと思います。最初に、古川さん、よろしくお願いいたします。
古川昌幸氏（以下、古川）：パーソルホールディングスのCIOを務めています古川です。
僕は社会人になった時はSIerのエンジニアとして働いて、そのあとコンサルタントを経験し、その後、ユーザー企業の情報システム部門のマネージャーを経験し、現在はこのパーソルホールディングスにいます。エンジニアからスタートしていろいろな立場を経験しましたので、今日は組織の中で働くエンジニアの働き方についてみなさんとディスカッションできればと思っています。よろしくお願いします。
石山：続きまして、オンラインからの参加になりますが、松岡さん、よろしくお願いいたします。
松岡剛志氏（以下、松岡）：よろしくお願いします。松岡です。私は現在、株式会社レクターという技術組織・技術経営のコンサルティング企業の代表取締役と、あとマザーズ上場のB2B SaaSの会社うるるの社外取締役と、そして一般社団法人日本CTO協会の代表理事を務めています。今日はその日本CTO協会のほうにウェイトの置いたセッションになると聞いていますので、少し日本CTO協会の紹介をさせてください。
こちらは「日本の企業経営に先端テクノロジーを」というミッションを掲げており、日本で一度でもCTOを経験した方が589人所属している団体です（イベント開催時点）。
主な活動内容は、デジタルトランスフォーメーションというのが今トピックに上がっています。では、いったいどうやったらこれを達成できるのかというのが非常に曖昧なので、これに対して「DX Criteria」という基準を作っています。
この基準を作ったのちに、「みんなどうやっているんだろう？」というのが知りたくなると思いますので、これを叶えるようなオンライン・オフラインのコミュニティを運営しています。
そして、「じゃあどういうことをやればいいんだ？」「みんなどうやっているんだ？」の後は社内の説得ですよね、となった際にファクトでたぶん会話したいと思いますので、さまざまな調査・レポートを行っています。
また、これらの活動を通じて、政策提言、国のDXもお手伝いすることを目標している団体です。今日はどうぞよろしくお願いします。
「混ぜる」と「目指す」でシニシズムをどう超えていくのか
石山：よろしくお願いいたします。引き続き、先ほど発表いただいた小林さんにも残っていただきながら、調査結果の内容をみんなで深掘っていきたいと思っていますので、よろしくお願いします。
小林 祐児氏（以下、小林）：よろしくお願いします。
石山：社会学者という立場からの小林さんと、まさにCTO協会の代表でありエンジニアの松岡さんと、そして今現場で実際にDXも含めて進められている古川さんというですね、まさにクロスオーバーしながらいろいろな話を展開していければと思います。
まず先ほどの小林さんの調査結果なんですけれども、私自身はどちらかというとエンジニアで、かつ、エンジニアをマネジメントする立場にあるのですが、社会学者の人から見ると、もう想定外の発想の分析結果になるというのがすごくおもしろかったです。
実際に、今日はニューノーマルというのもイベントのタイトルにも入っており、台湾のIT担当大臣のオードリー・タンさんがまさにこの「混ぜる」と「目指す」をうまく絡めながら行ったコロナの封じ込めも事例として出てきました。さらにパーパス経営の話もありましたが、そういったものが、企業経営の中に生かされてDXを通じたイノベーションを生んでいけるのか立ち向っている古川さんのお話もうかがいながら、小林さんと松岡さんからヒントを得つつ、本日はこの問題への解決方法を深堀っていきます。よろしくお願いします。
「混ぜると目指すでシニシズムを超えていく」という話があったのですが、松岡さんにうかがいます。実際この課題感に対する回答に近いものをCTO協会の中でも「DX Criteria」として準備し始めているとうかがっていますが、「DX Criteria」を簡単にご紹介いただければと思います。お願いできますでしょうか？
「DX Criteria」とは？
松岡：はい、わかりました。そうですね、私どもが作った「DX Criteria」という基準、これは何かといいますと、デジタル時代の超高速な仮説検証能力を得るには2つのDXが必要不可欠というストーリーを作っています。
今はデジタルフォーメーションの時代です。企業のデジタル化をして、そのデジタル化の先にエコシステムを作り、さらにトランスフォーメーション、変革していきたい、新しいビジネスを作っていきたい。ただ、はたしてこの順番でこうやって誰かに何かお願いしてできますかというと、そういうものではない。なぜなら、世の中は非常に不確実性が高い状況になっていますので、多様なトライ・エラーが必要になります。
そうした際にもう1つ重要なのは、先端開発者にとっての働きやすい環境や高速な開発を実現するための文化や組織・システムが存在するということ、その会社にケイパビリティとしてあるということ。これを意味する「デベロッパーエクスペリエンス」という言葉があります。この2つを兼ね備えないと、これからの企業はなかなか生き残りが難しいというお話をしています。
「DX Criteria」は、実際にはこの5つポイントで構成されています。
1つが「組織文化と『見えない』投資」。これは高速な開発を行う際に、組織は一度体験しないと「これは本当に意味があるのかな？」と、わからないことが多くあります。技術者だったら「まぁ、そうだよね」と思うことでも、それ以外の方には「それ売上につながるの？」みたいな。ただ、こういうことにどれだけ投資できているかが企業の競争優位性に関わってくる時代になりました。
2つ目が「タスク型ダイバーシティ」ですね。事業価値のあるサービスを実現するためにさまざまなデジタル人材と既存事業人材の相互理解、共創関係が必要です。これはそれこそ先ほどの小林さんの横断の話にも近いかもしれません。
3つ目は「メリハリのあるIT戦略」。エンジニアやデジタル投資というのを全部内製化するのは、かなり難しいと思います。リソースが足りない。そういった際には、共創するべきポイントに関しては内製化、それ以外に関しては外部のサービスを利用する、そういうメリハリというのが非常に重要になります。
昔正しかった何かをどんどん忘れていかなければならない
そして4つ目、「組織学習とアンラーニング」。技術の変化が非常に早い。このために、どんどん学ばなくてはならず、また昔正しかった何かをどんどん忘れていかなければなりません。そのため「これを忘れられていますか？」というチェックリストがあるのが「DX Criteria」のおもしろいポイントです。
最後は「自己診断と市場比較」です。自分たちでチェックをつけて、何ができている・何ができていないというのがわかり、そして目標を立てて進めていくことができます
多くの基準の課題として、なかなか「抽象度が高い」ということがあります。これに対して「DX Criteria」は320項目がありまして、極めて具体的な「明日からこれ直せるね」というような項目を立てました。
5テーマ×8カテゴリ×8項目。なので、この場では全部読み上げることはしませんけれども、そういう制度を作り、超高速な仮説検証をできるようなケイパビリティを会社が持てるように提案しています。「DX Criteria」の紹介は以上です。
石山：松岡さんありがとうございました。もうかなり細かく作り込まれていて、すぐにも使えそうですが、これ実際に使おうと思った場合はどういうアクションを取ったらよろしいのでしょうか？
松岡：「DX Criteria」と検索窓に入れていただくと、GitHubでインターネットに公開されていますので誰でもお使いいただけますし、こちらはライセンス的にも商用でお使いいただいてもまったく問題ないようにしていますので、広がってほしいと心から願っています。
石山：ありがとうございます。今日もうさっそくいい情報をいただきまして、私も今晩からちょっとチェックして使ってみたいと思いました（笑）。ご紹介ありがとうございました。
時代や技術の変化に追いついこうとするには、心理的安全性が必要
石山：続いて古川さんにうかがっていきたいと思うのですが、冒頭まず小林さんから「組織シニシズムを超えていかなきゃいけない」という話と、その超えるための方法論として先ほどの「DX Criteria」を松岡さんからもご紹介いただいたかたちでした。実際に今パーソルではどんなDXをやられていて、例えば「デベロッパーエクスペリエンス」みたいな言葉も先ほど出ておりましたけれども、いわゆるデベロッパーエクスペリエンスを高めるために心がけられていることとかがあれば、簡単に紹介してもらえればと思いますが、いかがでしょうか？
古川：わかりました。パーソルの中でも「DXに取り組んでいかないと、やはり次の成長はできない」ということで取り組もうとはしています。でも、やはりエンジニアって、今までの仕事の仕方から言うと、けっこう保守的な捉え方をすることが多いんですね。
そうすると時代の変化とか技術の変化に追いついていこうとすると、心理的安全性みたいなものがないとそこにグーッと入っていけないところがあるんですね。僕らの立場からすると、どうやって組織に心理的安全性を用意していくかというのが1つのポイントになってきます。
実際に僕のところの組織でも、2〜3年前にちょっと忙しくなったりすると組織のコンディションが悪くなることに気がついて、組織のコンディションをよくするためにどうやって心理的安全性を用意していくかが課題でした。
1つパーソルとしていい文化だなと思うのは、「壁打ち」と呼んでいるんですけど、若手だったりある程度中堅だったり、みんなやっぱりそれぞれエンジニアの人も含めて、ふだんの仕事をするのに悩みながらやっている部分ってあるわけですよね。コーチングに近いんですけれども、それを上の人が壁になって聞いてあげて、いろいろな相談に乗ってあげることでその心理的安全性が保たれている。やっぱり1人で抱えさせないことが1つ大事かなと思います。
DXそのものではありませんが、組織文化としてはまずそういうところの心理的安全性を用意した上で、ようやくDXにグッと入っていける、それからエクスペリエンスのところを目指していくところに入っていく、ということを今取り組んでいます。
心理的安全性を高めていくと売上生産性が上がる
石山：ありがとうございます。実際にパーソルの中では心理的安全性を高めるために壁打ちとかコーチングを具体的な手法としてご紹介いただいたかたちかなと思います。せっかくなので、今ご回答いただいた内容について松岡さんにも少しうかがってみたいと思います。「DX Criteria」の中で具体的に心理的安全性を高めるためのプラクティスとか、あるいは事例みたいなもので「こんなものがありますよ」みたいな話があれば、今の古川さんのご回答との答え合わせになりますので、ぜひ松岡さんからもご紹介いただければと思いますが、いかがでしょうか？
松岡：「DX Criteria」の5つあるテーマの1つに「チーム」というのがあります。その中に「心理的安全性」というチェックリストがあります。ここはけっこう厚く取り扱っていまして、8項目もあるんですよ。「チームメンバーの心理的安全性を測る指標があって、定期的に計測していますか？」とか、「1on1や、落ち着いた場面でのオフサイトミーティングなどの直接業務に関わらないキャリアやタスクの壁打ちを、月に１度程度は実施していますか？」とか、あるいはなんらかの行動に対して「明示的に承認行動をとる習慣がある、つまりちゃんと感謝していますか？」とか、「挨拶や雑談をはじめ、会話していますか？」とか。
やっぱり心理的安全性というのは非常に大きなトレンドだと思っています。Googleさんの研究でも「心理的安全性のあるチームのパフォーマンスは高いよね」という会話はされています。また、チームのパフォーマンスを上げるキーファクターとしても心理的安全性が非常に重要であるという論文は、「psychological safety」＋「team」とかでちょっと検索すると死ぬほど出てきます。
これを認識して進めるというのは、この時代においては重要なトピックの1つなんじゃないでしょうか。
石山：ありがとうございます。実は私の所属しているエクサウィザーズでも心理的安全性は毎クオーターアセスメントしています。分析したら、心理的安全性が上がっていくとEmployee Net Promoter Score（従業員満足度）が上がっていき、確実に相関があることがわかったんですね。
ということで、心理的安全性を高めていくといわゆるモチベーションが上がって、Employee Net Promoter Scoreが上がったら売上生産性が上がるというのはもうグローバルな調査で自明です。そういうデータのチェーンもいろいろこのデータドリブンでも見えてきている時代になっていると思いまして、これが第1次世界大戦と比較して今後どうなっていくのかに期待が高まるわけですが。
エンジニアと非エンジニア間で共通のプロトコルを作る
石山：小林さんの調査で、1個のキーワードに「混ぜる」という話があったかと思うんですけれども、あえて極端な対比で見た時に「エンジニア vs 非エンジニア」みたいな構図がもしあったとしましょう。第1次世界大戦の職工身分制度の時の具体的な事例も参考にしつつ、ここを今度は逆に混ぜると考えた時に、具体的にどういう混ぜ方があるのかを次のトピックとしてはうかがっていきたいと思うのですが。
いわゆるこのデベロッパーエクスペリエンスを高めるために、エンジニアと非エンジニアはどうコミュニケーションすべきなのか。今度は最初に古川さんから「パーソルにおける取り組みでどんな事例があるのか？」を少しうかがってみたいと思います。
古川：エンジニアと非エンジニア間でコミュニケーションを成立させるのは、最初のうちはなかなか難しいと思います。エンジニアの特性として、やっぱり間違っちゃいけないとか正しく伝えたいという気持ちがすごく強いので。
エンジニアじゃない非エンジニアの人からすると、なんか技術的な専門用語を使われて、何を言っているかわからない、というところがけっこうあったりするわけです。だから、その共通のプロトコルをどうやって早く見つけるかが重要だと思います。
昨今だと、会社の中でコミュニケーションを取る・在宅をやっている中でコミュニケーションを取るのにTeamsなども活用しています。その中で、特にチャットみたいなかたちで、そんなに長い文章じゃなくても、日常的に会話をしている言葉の中でコミュニケーションをとっていくことが、共通のプロトコルを作っていくことの1つになるのかなと思っています。
あとはやっぱり……うーん、そうですね、エンジニアと非エンジニア、事業部門とIT部門で見た時に、どうしても委託と受託の関係になりやすくてどっちが偉いみたいな話にすぐなっちゃうんですけど、その関係が続いているかぎりなかなか会話は成立しないと思います。
とにかくエンジニアのほうからも業務のほうに踏み込んで提案できるような、そういうところに対して今取り組んでいこうと。どんどんはみ出していくようなかたちですね。それが1つ混ぜるというところにつながってくるんじゃないかと思います。
今のトレンドは「アジャイル」「フィーチャーチーム」
石山：ありがとうございます。古川さんのお話を聞いて、この混ぜるというのを進めていくのが本当に難しいんだなと思いました。実際にアメリカでもトランプ政権の時に、一部の労働者の方が「カリフォルニアのITのエンジニアの人たちが魔法を使って儲けている」みたいな話もあって、いわゆるそれが分断みたいに言われていた時代もあったかなと思うのですが。
松岡さんに次にうかがってみたいのは、小林さんの「以前の第1次大戦の教訓も受けると、混ぜるというのが1つのベストプラクティスとしてあったよ」って話ですが、今ITエンジニアと非エンジニアの世界においては、この混ぜる、いわゆる融合する方向か、それとも分断する方向に向かっているのか、そのへんがどうなっているのかなんですが。実際どうなんでしょうか？
松岡：両方あると思っています。toBでドメイン知識が深いようなビジネスの場合、分断を選択する企業さんもあるなと思っています。逆にtoCのビジネスの場合、分断という戦略をとる会社さんは少ないなと思っています。
融合のほうがやっぱりテーマとしてはおもしろいと思っていて少し楽しくしゃべりたいなと思っているんですけれども、この「融合」というテーマをキーにした時、あるいは「職務横断」というのをキーにした時に思うことは、アジャイル村で会話されている内容です。
何かといいますと、従来のチーム構成、「開発部」「企画部」「XX部」というような構成は「コンポーネントチーム」と呼んでいて、もう1つ、それに対して「フィーチャーチーム」という概念が流行っています。「フィーチャーチーム」というのは、顧客に提供する機能に対して、必要な職能を持った人が全員集まっているチームのことを指します。
これがなんで流行っているのかと言いますと、今の時代、結局何を作れば当たるのかがよくわからなくなっています。なので、どれだけ開発の経験数、同じ期間に何回トライできるかによって企業の生き残りが決まると思っています。
受発注構造というトレンドからコラボレーションというトレンドにどんどん変わっていっています。ただ、これは別に新しい話じゃないんですよね。第1次世界大戦の話が出ましたけれども、同時に野中郁次郎先生とかが1990年代とかに「大部屋」みたいな。新しい企画とかをやる際にいろいろな役割・職能の人が集まっていろいろなコミュニケーションを生むことで、イノベーションが生まれる。そんなことがありました。
これがまたソフトウェアの世界でも起きていると思っていまして。今のトレンドとして「アジャイル」あるいは「フィーチャーチーム」というのが来ているなと。なので、そうやって横断が進んでいるなと感じています。
今実際にパーソルはどっちのほうに向かっているのか
石山：ありがとうございます。今、野中郁次郎先生の話も出て、エンジニア目線で見てもイノベーション理論というのをいろいろ考えられているんだなというのがすごくおもしろいのですが、最近私イノベーションのことを「PPAP」と呼んでいたりするんですね。
こっち側にエンジニア人材がいて、こっち側に非エンジニアがいて、「うんっ」ってやったらイノベーションが生まれるという。実際にうちの会社だと介護のAIとかをやっているので、介護士とエンジニアの人が「うんっ」ってやって一緒に超高齢化社会の社会課題を解決するプロダクトを作るみたいなこともやっています。
先ほど松岡さんのお話の中で、B2Bだと分断になるリスクもあったり、toCだと比較的融合しやすいみたいな話がある中で、パーソルのビジネスモデルってマッチングモデルなので、B2B2Cみたいな形のモデルになりがちなわけですよね。そういう意味ではどっちにもいきやすく、いろいろな選択肢がありそうだなと思うのですが、今実際にパーソルはどっちのほうに向かっているのでしょうか？
古川：パーソルの場合は、人材派遣も人材紹介も、お金をいただくお客さまはB＝法人になります。人材派遣の場合はスタッフの方にそこで継続的に就業いただくのでB2B2CとかB2Cに近いビジネスモデルになりますね。
一方で紹介の場合は、求職者と法人をマッチングしていくビジネスなので、それをどうテクノロジーあるいはエンジニアのサポートをしていくかというと、どうしてもいろいろなサービスを増やしていかなきゃいけない。そうなると、分断はしやすいです。
ただ、結局分断するんですけど、例えばそれを使いたい求職者の個人の人というのは1人しかいないんです。複数のサービスを使いますけど、利用する人は1人なので、僕はやっぱり融合型を目指していきたいです。あまり分断が進んでいくと無駄玉が増えそうだなっていう印象ですかね。
（後半へつづく）
