相対的な指標を組織に落とし込み、文化として積み重ねる　広木大地氏×佐藤鉄平氏が語る、“成熟した良いエンジニア組織”

広木氏・佐藤氏の自己紹介

古川陽介氏（以下、古川）：最初のパネルディスカッションは「フロントエンド組織論」についてのテーマを上げました。登壇いただく方には、私から紹介した上で、さらに自己紹介をしていただこうかなと思います。

株式会社レクター 取締役／一般社団法人 日本CTO協会の理事も務められている広木大地さんと、サイボウズ株式会社 執行役員 開発本部長である佐藤鉄平さんのお二人に来ていただいています。

お二人とも最初はエンジニアとしてキャリアをスタートして、そこからエンジニアマネージャーだったり組織的なところのマネジメントを経て、今はCTOというか開発を統括するような立場にいるかたちで。私も似たような経歴なので、3人とも似たようなバックボーンがあるところを踏まえて話をしていけるといいなと思っています。

ではお二人に簡単な自己紹介をお願いしていこうかなと思います。まず広木大地さんからお願いしてもいいでしょうか？

広木大地氏（以下、広木）：はい。どうもこんにちは、広木です。僕はもともと筑波の大学院を卒業したあとに、新卒第1期でMIXIという会社に入って、その中でソフトウェアエンジニアからアーキテクト的なことや、教育、組織構築に関わる中で、「そろそろ事業のほうにも見ていこう」「事業のターンアラウンドを仕掛けていこう」ということで、最終的にはサービス全体の本部長や執行役員までやりました。

その後退社して、技術的なノウハウと経営の部分の間にあるさまざまな問題を解決するための会社として、レクターを創業しました。

また、『エンジニアリング組織論への招待』という本の中で「こういった課題があるんだよ」みたいなことを世の中に知ってもらおうと発信したり、「一緒に考えていきましょう」という活動として自分たちで作ってきたCTOのコミュニティを日本CTO協会として一般社団法人化しました。

最近では、多数の官公庁とか委員とかもやりながら、「どうやったらエンジニアがもうちょっと生産性高く活動できるような世の中にしていけるんだろう」みたいなことも並行してやっています。よろしくお願いします。

古川：ありがとうございます、広木大地さん。一応いろいろと肩書きを言ってもらいましたが、私と広木大地さんの関係でいうと、最初に会ったのは大学生のころで（笑）。

広木：そうなんですよ。だから（古川さんのことは）「ようちゃん」って呼んでた（笑）。

古川：「ひろきのだいちさん」と呼んでいました（笑）。

広木：mixiとかGREEとかでも。

古川：mixi、GREEが日本で流行り始めたころぐらいに、エンジニアコミュニティの走りみたいなものがあったんですよね。そこでお会いして、その時から（広木さんは）ちょっと考え方がなかなかエキセントリックな（方で）。

（一同笑）

ずっと思っていたんですけれどね（笑）。

広木：しばらくしてね。「あれ？」と思って。

古川：そうそう。それでいうと、私はその時に「あれ？　MIXIの執行役員になっている」と気づいて。それで「うわ！」となって、そこから『エンジニアリング組織論への招待』とかの講演とか、弊社にも1回来てもらって話をしてもらったりを経て、もう1回旧知を温めてこうやって来てもらっている感じになっています。ありがとうございます。

広木：よろしくお願いします。

古川：次の方を紹介しようかなと思います。次にサイボウズで執行委員をやられている佐藤鉄平さん、自己紹介をよろしくお願いします。

佐藤鉄平氏（以下、佐藤）：はい。佐藤鉄平です。私は新卒でサイボウズに入ってからずっとサイボウズにいるという経歴です。最初の10年ぐらいは普通にWebサービスというか、プロダクトをWebエンジニアとして作るというところをずっとやっていて、サーバーもフロントも両方とも触っていました。

個人的な興味としては、どちらかというとフロントエンドのほうが興味は強くて、JavaScriptまわりとかNode.jsとか、そういったところのオープンソースとか、コミュニティでの登壇とか。あとは雑誌の執筆の活動もやりながらWebエンジニアとして10年ぐらいやっていて。

この5年ぐらいはガラッと変わってマネジメントのほうにキャリアを移して、開発本部という、サイボウズでいうところのプロダクトを作っているところ。エンジニアとか、デザイナーやプロダクトマネージャーとかが所属している本部ですが、そういうところの全体のマネジメントをやることをこの5年ぐらいはやっています。経歴としてはそんな感じかな。

古川：ありがとうございます。佐藤鉄平さんと私の関係でいうと、カンファレンスで同じテーマで話すことがよくある。私もバックグラウンドというかメインフィールドがJavaScriptだったりフロントエンドだったりするんです。

あとは鉄平さんも同じフィールドを持っていて、僕の中で印象的なのは、やはりYAPC（Yet Another Perl Conference）と呼ばれるPerlのカンファレンスなんですが、（その）Perlのカンファレンスで2人ともJavaScriptの話をするという。

（一同笑）

古川：カンファレンスの状況が（笑）。

佐藤：ちょうど（そのカンファレンスが）2015年で、ES2015が出たころで。JavaScript界としてはわりとエポックメイキングな年だったから。

古川：そうそう。そうですね。

佐藤：だから、フロントエンドとかJavaScriptがメインじゃない人にも知ってほしいタイプの話題として発表した感じだったんですよね。

古川：そうですね。（JavaScriptは）今もかなり流行っていると思いますが、あの時に本当に流行りが始まった感じがありましたよね。今までのJavaScriptのわかりにくさみたいなところがある程度払拭されて、逆に取っつきやすさみたいなものが出てきて、そういうのを経て今に至るという。

今回はJavaScriptの話ももちろんしていきたいのですが、どちらかというと「どうやって組織を作っているの？」みたいなことで、サイボウズさんはわりといろいろなことをトライしているので、そのあたりの話を聞けたらなと思っています。二人ともありがとうございます。

広木氏がDX Criteriaを作成した経緯

古川：さっそくディスカッションというか、私のほうで聞きたいことというか聞いてみたいことを話していこうかなと思います。私が今回話したいテーマとして「フロントエンド組織論」と書きました。

そもそも何を話すかというと、私はリクルートをやっています。かつ、ニジボックスではデベロップメント室の室長をしています。どういう状況かと言うと、ニジボックスというのはリクルートにおいては子会社という扱いになっています。

その子会社の中で、フロントエンドのエンジニアの方々が7、80名いることを踏まえて、「サービスを作りましょう」となった時に、フロントエンドの人材をリクルートから「アサインしてほしい」と依頼されて動くという立場。ちょっと言い方を変えると、受託の開発に少し近いような感じの開発をニジボックスの中ではしています。

リクルートの中にも組織があり、リクルートの中の組織はどちらかというとエキスパートを醸成するようなことをやっています。その中には、先ほど紹介に上がったような倉見さん（倉見洋輔氏）だったり、いろいろなエキスパートの方がいる状態になっています。

「技術でけん引していくエキスパートの人たちと、それに対して付き従っていくニジボックスのメンバーたち」というような構成でアサインされることが多くて。そうやってリクルート内部のサービスの作り方だったり、アーキテクチャだったりを変えていこうとしている最中です。

要はやりたいこととして、私自身はリクルートの中でもフロントエンドの改革をしようとしているわけですね。

佐藤：改革。

古川：改革は言い過ぎた（笑）。

（一同笑）

佐藤：いいですね（笑）。

古川：改革というかアップデートですよね。今までバックエンドとフロントエンドはそんなに分かれていなかったというか、中には“マークアップエンジニア”の方とかいう呼び方をしたり、“コーダー”という言われ方をすると思うんですけれど。

HTMLで作る人はHTMLで作る人で終わっていて。テンプレートエンジンに組み込むちょこっとぐらいのことはやるかもしれないけれど。

そのあたりの垣根はあまりなかったところが、今はもうガッツリ、サービスに組み込むところまでをフロントエンドエンジニアとして捉えているような気がしていて。そこがやはり変わってきたのかなと思っているんですよね。このあたりのところで、個人的にはアーキテクチャをアップデートしていきたい（笑）。

ここは戦い方がいくつかあるんじゃないかなと思っているんですよ。というのは、私はトップダウンの戦い方とボトムアップの戦い方があると思っていて。

トップダウンの戦い方はというのは、これは広木大地さんに来ていただいた理由の1つなんですけれど。まず、“Criteria”と呼ばれているような基準を明確化して、その基準に対して道しるべを示してあげる。（そして）それに対して担保していくことをやってあげる。これがまず1つの捉え方かなと思います。

ここで具体的に聞いてみたいのは「DX Criteria」を作った経緯とか、なぜ作ったかとか、そのあたりのことを聞かせていただいてもいいですか？

広木：はい。ありがとうございます。DX Criteria（について）は検索してもらえれば出てくるんですが、日本CTO協会が出している、開発者体験とデジタルトランスフォーメーションの両方の軸で組織全体をチェックしていくようなチェックシートです。

僕自身、いわゆるトップダウン的にやってくるチェックシートは、基本的に考え方としては好きじゃないんですよ。そういうものに苦労してきた思いもあるので。

それを作るに至った経緯としては、いろいろな会社に出会っていく中で、まさにボトムとトップの話の中の「こういうものがありますよ」ということが、現場の人が動きやすくなる指針になるところが大きいです。

CTOは実際にいろいろなことを経営や他の部門に説明しないといけません。特に経営との間のつなぎ込みは大変難しかったりします。「でもこういうものがあって、今点数を付けるとこうですよ。次はこうですよ」という説明がDX Criteriaのようなものがあればしやすい。

こういったチェックリストを誰かが作る時に「現場のエンジニアの人たちにとってもやりたかったことだよね」ということがちゃんとリスト化されていることが重要だし、「それが世の中にとってどういう価値になっていくんだよ」と発信していくのは大事だと思っています。このような背景でDX Criteriaをつくりました。

もともとはMIXIの中で開発の、あえて“上流工程から下流工程”という言い方をしますが、プロダクト全体を見た時に、いろいろなボトルネックになりうるポイントを総ざらいして、自分でチェックリストを作って改善していくということをしていたんですね。

その元ネタがありつつ、その元ネタを、最初は自分たちの会社を創業したときにコンサルティングに使うために改良したものを手元に持っていました。

でも「自分たちで改良して使うだけじゃもったいないから」ということで、CTO協会を単なるコミュニティの状態の任意団体から一般社団法人に変えるタイミングで寄贈して、CTOの人たちに叩いてもらって。それで項目とかをいろいろ改善してアウトプットすることをして、今のかたちになっています。

古川：じゃあDX Criteriaは、最初はレクターの中のコンサルティングのツールとして使おうとしていたものを、日本CTO協会に移した時にいろいろなCTOの方からのブラッシュアップ（してもらうこと）を経て、今のあのかたちになっている。

広木：そのとおりです。

古川：なるほど。

広木：最初はコンサルティングに使って、というか（コンサルティングで）診断して「ここを直していきましょう」ということをやっていたんですけれど、そこをクローズにする意味があまりないなと思っていて。

古川：そうですね。確かに。

広木：「オープンにみんなで叩いていければいいな」というところから作っていて、定期的にアップデートとか、時代に合わないものとかを更新しながら、今使うとしたら使い勝手の良いものにしていきたいなと思って、日々いろいろやっています。

古川：ありがとうございます。私も他の開発の現場とかでけっこう技術顧問的な活動の中でやることもあるんですが、DX Criteriaがあることでどこが弱いかがけっこうはっきりわかるような感じがあって。

いろいろな会社を見ていますが、例えば心理的な安全性が低いところ。つまり「何か言ったらミスなんじゃないか」と言われてしまうようなところとか。その会社は確かに会社の雰囲気から（心理的安全性が低いことは）わかっていたんだけれど、DX Criteria（で結果）として出てくるとわかりやすいなと。ツールとしてはすごく助かっています。

DX Criteriaは簡易診断サイトと英語版もリリース済み

古川：これは私の肌感覚ですが、（DX Criteriaは）実際にいろいろな会社に運用されていると思いますが、実際に運用している側の立場から見た時に足りていないものがあるとかはあったりするんですか？　今はどんな状態なんですか？　DX Criteriaを公開してから1年以上経つんですよね。

広木：経っていますね。1つはこういう網羅的に診断として「よいしょ！」と気合いを入れてやるものとして作っていた経緯があるから、何しろ項目が多いんですよ。

古川：そうですね。けっこう多いですよね（笑）。

広木：（1項目の中に）8項目あってそれが40項目ある、みたいな。

古川：そうそう（笑）。

広木：「多いな」という感じなので、僕のほうでいろいろ回収してきたデータを使って、項目反応理論というか、TOEICの点数を付けるような仕組みのやつで、ロジスティックス回帰の直線にして、20問解いたらだいたいの点数がわかる簡易診断サイトも作ったんですよ。

古川：確かに簡易診断サイトもありますね。

広木：項目が少なくてもできるように（簡易診断サイトをやって）「こういう感じなんだな」とわかり、「じゃあ本格的にやってみようか」と（なるように）入り口の部分をちょっと楽にしようと。

古川：導入を楽にさせていく。

広木：大きい会社に行くと、そもそも言葉の意味がわからないとかがけっこうあるので。

古川：ありますね。

広木：そういったことをどんどん解説していく活動に最近は力を入れていて。

古川：すごいですね。

広木：あともう1つは、（DX Criteriaの）英語版を最近公開をしました。

古川：なるほど。

広木：最近は英語をスタンダードな言語としてやっている開発チームもあるし、また、グローバルなチームのメンバーでチェックする時もあるので。主に海外の企業に発信していくというよりも、日本国内の中でも英語がスタンダードになっているような会社さんとか、チームの中で診断ができるようにということで、英語版も公開しました。

古川：なるほど。

DX Criteriaはなぜ開発のボトムからチェックリストに含めているか

古川：DX Criteriaについては今の広木さんの説明にもありましたが、デベロッパーエクスペリエンスとデジタルトランスフォーメーション、このダブルミーニングをかけて“DX Criteria”という言葉を作っているんだと思っていて。

ちょっと気になっているというか個人的に思っているのは、“デジタルトランスフォーメーション”はどちらかというと経営用語的な部分があって、企業文化的な意味でのそれを変えていこうという姿勢（です）。

“デベロッパーエクスペリエンス”は開発生産性というところに帰着すると、開発用語というかエンジニア用語というところがあって。技術的な文化と経営的なものを一緒に扱った時に気になっているのは、技術の部分で経営をリードしていくことができれば、たぶん我々が働きやすくなるところになると思うんですけれど。

それには経営への理解だったり、「そっちにシフトしていこうね」という感覚も必要だと思うんですけれど、DX Criteriaでは実際にそこまで行っているんですかね？　そこがちょっと気になっているんですが。

「開発のここが弱い・ここが良いところだ」ということはたぶん見えるようになっている気がしていて、「じゃあここをもう少し強くしていこう」「これは良い文化だから残していこう」とかは、どちらかというと開発の文化な感じがしていて。

経営の人たちにも「こういう良いことをやっているよ」ということが（DX Criteriaをとおして）わかってくれている会社とか組織とかは出てきたりしているんですか。

広木：そうですね。今は2つの論点があるかなと思っていて。1つ目のなぜで開発のボトムからチェックリストを入れているかというと、開発組織が良くなっていることを可視化して、それに向かってどんどん改善していることを日々されている方は多いし、実際そういう会社は多いです。

でも、それを経営（向け）に見える化していないと「ちゃんとやっているの？」とか言われちゃうので。見える化するための物差しがあったほうがいいよねと。そのほうが日々の活動をポジティブに受け入れやすいというところで、「その物差しを作りましょう」という観点です。

逆にそこがうまく回っていない組織、つまり開発者の文化を作れていないところって、DXが机上の空論になってしまっているところが多くて。

古川：そうなんですよね。

広木：なので僕は2つのフレーズをダブルミーニングで使っているものの、「実はこれは両輪で、両方とも立ち上がっていないとうまくいかないものだよね」と、そう思っています。

古川：本当にそうだと思います。

広木：そこについて官公庁とかのDX推進におけるパブリックなチェックリストみたいなものって、もうちょっと、経営的なんですよ。だけどこれは足回りが整っていなかったり体力が付いていなかったりすると（できない）。自分たちで「手の内」になっているソフトウェアの体験とか組織がないと作っていけないテーマだというところがあって。

古川：そのとおりですね。

広木：そこを可視化するというために作っているというのが1つ。

DX Criteriaを活用して開発と経営をつなげられている企業は増えているか

広木：もう1つは「そういった企業ってありますか？」という話ですが、けっこうブログとかに書いてくれている人は増えていて。

CTOの人がまずはDX Criteria（の部分）を改善していく過程のところを中心にやっていって、「こういう結果が出ました」と経営の中で（伝える）。経営は組織の状況を見える化しながら良くしていくことが重要かなと思っていて、そのための1つの手段として使ってもらってる会社さんは増えてきているなと（思います）。

あと最近はデューデリジェンスとかで書いて渡してくれるところも増えていて、そのように広まってくると、（DX Criteriaが）基準になるのかなと思っています。

古川：なるほど。（今のお話は）すごくヒントで、私がちょっと思ったのは、私はニジボックスではデベロップメント室長で、デベロップメントを全体的に統括している立場なので、そこではたぶんやりやすいと思ったんですけれど、リクルートの中だとグループマネージャーというかたちで、1つの管理職ではありますが「開発を統括する」とかそういった立場にはなかったので、「自分がこの部署の中でこれだけやったとしていても、どこまで浸透するんだろうな」という不安があったんです。

今お話されていたのが、CTOの方とかがそういったことを率先してやっているということあったので、まず私のやり方の1つとしては、まずはニジボックス内でそういうのができているか・できていないかを試して、うまくいってそうだったら、リクルートのもっと上層部にいるような、開発を統括しているような人にも伝えていって、それでまず1つを可視化していく。自分たちの弱いところをどこか見せていくと。

“改革”という言い方をしてしまいましたが、それがアップデートの1つの指針になるんじゃないかと思いました。そこは参考になりました。ありがとうございます。

相対的な指標は「なんでやるのか？」「どう進めるのか？」を補う必要がある

古川：僕の中ではサイボウズの鉄平さんにもいろいろ聞いてみたくて。サイボウズはまずDX Criteriaとかそういったものはやったことがあるかということ。

（サイボウズは）やらなくても個人的にはなんとなくすでにDXというか開発主導の組織になっているような印象を受けているので、そういうことをやるような必要がなさそうな気がする。（もしそうなら、それは）どうやってやってきたのかなみたいなことを聞いてみたい。まず1個目のDX Criteriaはやったことがあります？

佐藤：組織全体として掲げてやったりはしていませんが、私個人としては見て「なるほどな」とか眺めていたりはします。

古川：「なるほどな」「これが弱いんだな」と。

佐藤：こういうのは特に相対的な目線というか観点が持てるかがすごく大事だと思っていて。サイボウズだとありがたいことにわりと離職率が低くて、新卒メンバーもけっこう多いので。そうすると「他社ではどうやっているんだろう」みたいなことを知る機会が少なかったりするんですよね。

そうなると「自社の今の開発スタイルや文化は良いのか・悪いのか」がやはりわからないところがあるので、こういうものがあるとすごく参考になるなと思います。

古川：なるほど。

佐藤：ただ、こういう相対的であったり客観的にあるものって、逆に言えば自分たちの文脈に引き寄せにくいというか。「なんでこれをやらなきゃいけないんだっけ？」みたいなところは、それぞれの会社とか組織で補強していかなきゃいけないところなんですよね。

例えばフロントエンドに近いところで話すと、「アクセシビリティはやったほうがいいですよね」という話は一般論としては「そうだよね」となるけれど、じゃあそれぞれの会社とかプロダクトで「それはどうしてやったほうがいいんだっけ？」というところまでいくと、ふんわりしちゃったりするんですよね。それで現場の取り組みもふんわりとしていったりとか。

古川：そうですね。

佐藤：弊社のアクセシビリティのチームがそこをうまく引きつけるテーマというか話をしてくれていて。サイボウズは会社のビジョンとして「チームワークあふれる社会を創る」ということを掲げていて、そのためにグループウェアやコラボレーションサービスを作っているんですけれど。

そうすると「その中でのアクセシビリティって何だ？」と。（それは）チームにアクセスする能力であると。だから（人によって）チームにアクセスできないようなサービスを作ってしまうと、それはビジョン達成の妨げになりかねないので、そういう文脈で解釈すると、他のアクセシビリティの専門家以外のメンバーも「じゃあそれは必要だよね」ということで進めるみたいな。

古川：なるほど。

佐藤：そういう客観的な良さとか基準とか「こういうことっていいよね」というものを、それぞれの組織とか文化とかと融合していくようなところは、まず1個大事なのかなと思うところですね。

もう1個は、じゃあそこで自分事になっていった時に「でもどうやって進めたらいいの？」みたいなところがあると思うんですよね。このあたりはたぶんけっこう組織のかたちとかチームの構成とか、あとは組織のフェーズ感によると思うんですけれど。

サイボウズの場合、私が組織を見るようになったのが2016年ぐらいですが、それまでは基本的にはプロダクトチームだけだったんですよ。つまり、いわゆるフィーチャーチームというかクロスファンクショナルなチーム、基本的にはプロダクトを良くしていくことをみんなでやっていくチームで、それ以外のところの専門家チームみたいなものがなかったんですよね。

でもそのあとに、例えばフロントエンドエキスパートチームとか、先ほど出てきたアクセシビリティのチーム、それから生産性向上チームとか。そういったプロダクトをメインで見るチーム以外の専門家チームがいくつかできていて、そういう専門家チームとそれぞれのプロダクトチームがうまくコラボレーションすることで、それぞれの課題をその専門家の知見をもらいながら進めていくみたいな。

そういう仕組みというか、やり方というのが徐々にできるようになってきたのかなみたいなところが流れとしてはありますかね。

古川：なるほど。メチャクチャ参考になりました。最初の話で思ったのは、サイボウズの中のフィロソフィーというかビジョン。「チームワークを高め合いましょう」ということがまずあって、それのためのコラボレーションツールを作っているとか、コラボウェアを作っていると。

そのコラボウェアを作るにあたって、アクセシビリティは当然なきゃいけないですよね。「目が見えない人だったり、ちょっと手が不自由な方でもチームワークを大切にするんだったらなきゃいけないでしょ」というビジョンから攻めていって。

攻めていってというかビジョンをまずは掲げて、それに共感している人たちを巻き込んでいくスタイルで、開発のやろうとしていることに巻き込めるようなものを作っていくと。（私は）そこが「なるほどな」と思っていて。

佐藤：弊社の場合は、例えば私とかが「えいや！」と（トップダウンで）言ったのではなくて、アクセシビリティチームのメンバーがそういったものを掲げてくれて、みんなが共感していくという流れでいった感じなんです。

古川：なるほど。

佐藤：だから、私はそんなに仕事をしていない可能性が（笑）。

（一同笑）

古川：そういうメンバーを作るというのも1つの仕事ですけれどね。それはともかくとして「そっか」と思ったのは、ビジョン・ミッションみたいなものがつなげられるようになっているというか。つなげられるように工夫して、そこを持ってきた人たちがいるのがすごく良いなと思っていて。やはりサイボウズのビジョンに共感して仕事をしているというのもあるんでしょうし。

例えばアクセシビリティの話がありましたが、パフォーマンスをやった時に、Core Web VitalsとかSEOの評価に効くようなことってけっこうわかりやすい、お金とかSEOという力の強いKPIとして出てきてしまっていて、「それを到達しよう」みたいな流れが出やすかったんですけれど。

逆にアクセシビリティは、まだそこがないから（こそ）逆に動こうとするモチベーションが会社全体の中ではあまりないという時に、どうやって作っていったらいいのかということを思っていたんですよね。そこにビジョンを絡めていくというのが1つのやり方なのかなと。それはたぶんアクセシビリティだけじゃないということなんですよね。

パフォーマンスだったり、開発生産性向上だったり、いろいろなものについてもそれが言えて、そのものの中でそういうことが発生していくというところですね。なるほどな。

個人的に思ったのが、会社のビジョンとかと絡めていくというのは1個ありだなと思ったんですよね。ただ、リクルート（のビジョン）は「まだ、ここにない、出会い」。

（一同笑）

でも確かに「出会いを求めていくのであれば」ということは1つありますよね。なるほどな。

成熟した組織や良いエンジニア組織は新しいことが取り入れられやすい

古川：あともう1個あったのが、ビジョンの共感のさせ方というのがあったんですけれど、そのあとでさらに最初はクロスファンクショナルなチームしかなかったけれど、専門性のある特化型のチームがその中でポコポコ出てきて。このチームを作ったのは鉄平さんとかではなく、ボトムアップで出てきたんですか？

佐藤：そうですね。現場のメンバーの中で「こういうものが必要だよね」というニーズもあれば、「こういうのをやりたい」という人たちも出てくるし。そういうところを見て「じゃあそういうのを作ろうよ」という話をしていくという感じですかね。

古川：じゃあわりとそうやってやっているのを見て作っていく流れになったということなんですね。そっか、それもまたすごい。

佐藤：クロスファンクショナルなチームだけれど、それぞれの領域で専門家が育ってくるんですよね。そうすると「これを他のチームにも広めたいよね」とか、「他のチームでこれに困っているけどもっと横展開したほうがいいんじゃないの？」とか。あるいは「クロスファンクショナルなチームの中の1つのポイントとしてやるよりは、もっと深めてやりたい」みたいなことも出てくるんですよね。そういうところを拾って分離するような感じですかね。

古川：なるほど。

広木：僕はそこはまさに重要だなと思っています。「今の話は自然とそうやるのがいいよね」ということが積み重なってアクセシビリティに考慮するのが当たり前にだんだんなっていくことって、「合理的にこうだよね」という話ではなく、文化として積み重なっていくものだと思っているんですよ。

成熟した組織や良いエンジニア組織は、文化として新しいことであったり、ビジョンに合ったすべきことを取り入れていきやすい風土があって。そう（いった流れで）回転をし始めているところはどんどん新しい習慣が（生まれていきます）。

例えば「テスト駆動開発をしましょう」とか、「バージョン管理をちゃんとしましょう」とか、当たり前のことが積み重なっていくんですけれど、そこが重なっていかなくなっている状況の時に「これって合理的なんですよ」とゼロから説明するのはすごく難しくて。

そこを作っていかなきゃいけない場所において、「文化資本の見本市みたいなものとして、こういう習慣を取っていけるといいんですよ」と。そういったものをちゃんとリスト化して、まずは食べてみましょう、摂取してみましょう。それでやらないんだったらやらないなりの理由を考えましょうというところから始めていくと、意外と「実はやりたかったんだよね」という人が内部から出てきていて。

それをやってみると定着し始めて「良いものなんだな」と変わっていく。このサイクルを作りたくて。

DX Criteriaも説明責任の向きを逆にさせる（ものです）。「ここまでやっているのを今はスタンダードと言えますよ」と。「やることを当たり前にするためにはどうしたらいいでしょうね」というところから考えていって、逆に「やらなくてもいい。自分たちにとって必要ないよね」と言のであれば、その部分を（なぜなのか）説明しましょうと。

やるべき理由を説明するんじゃなくて、やらない理由を説明していくように変えていけば文化が定着するまでが早いなと思っています。なので、自分たちでサイクルとして積み重ねていけるものに関しては、とても良い状況だからそれはよくて。そこに行くまでを最速で行けるコントロールを作りたいなと。

古川：そうですね。どうしてもやりたいと。「1回食べてみましょう」みたいなことを起こしたいは起こしたいんですけれど、「そこをやったらどう良くなるんだっけ」みたいな、こちらが説明しなきゃいけないことが多いの。

そこをわかってくれると思っていたら言いやすいんでしょうけれど、そこの距離が遠いと、恐らくわかってくれる人のほうが少ない。会社が大きくなっていると、そこの部分の説明にけっこうコストがかかってしまって、「ちょっと難しいな」（となる）みたいなことが、今の我々の組織ではけっこう起きがちなところがあるというところで、困っていると言えば困っているんですよね（笑）。

佐藤：そこは難しくて。例えば、プロダクトチームと専門家チームがいた時に、どうコラボレーションしていくかみたいなことはやはりすごく難しくて。

古川：超気になります！

（一同笑）

佐藤：歴史的にいろいろなものを経てかたちが変わっています。だけど最近だと『チームトポロジー』という本が出て、けっこうそのあたりの語彙とかパターンとかが整理されてきています。

古川：ストリームアラインドチームとか。

佐藤：そうですね。プロダクトチームが“ストリームアラインドチーム”と呼ばれていて、専門家チームはどちらかというと“イネーブリングチーム”みたいに本では整理されています。

じゃあこのチームはどういうコラボレーションをするのかという時に、外側からうまくファシリテーション的に入っていくパターンもあれば、ガッツリ一緒に仕事をするようなコラボレーションもするパターンもあったりする中で、どうやったらうまくいくのかみたいなことはコンテキストによるので、一概には言えないんだけれど、「とにかくいろいろなやり取りをして対話をしながら試行錯誤する」と言うしかなくて。

ただ、やはり一般的にはというか、よくあるのがプロダクトチームはプロダクトを良くすることとか、プロダクトを伸ばすことに自分たちのミッションを持っていて、そこに一番興味があって取り組んでいく。

それ自体は良いことで正しいんだけれど、そこと技術の専門家による別の観点とのバランスを取るのが難しい。

それぞれがドメインの専門家と技術の専門家だったりするから、そこのバランスを取ったりとか、何をするのが良いのかというのは、そんなに簡単な問題ではないんですよね。自明な答えもないし、もともと難しいものに取り組んでいるので、そこはやはり難しいから一生懸命対話をしてやっていくしかないところがあって。

ただやはり、（専門家チームが）外側から何か言うだけではなかなか進まないところがあるから、弊社でも外から支援するところから「じゃあ一緒にプロジェクトを組んで別のチームを作って始めよう」とか、「2つの別々のチームでやり合うというよりは、一緒のチームを作って取り組むプロジェクトを立ち上げよう」とか。そうやってかたちを変えながらうまく進める方法を模索するような感じのことはやっていますね。

古川：すごい。おもしろいですね。

（次回に続く）