マイクロマネジメント型で最適化されたチームは、どうエンパワーメントしていくべきか？
篭橋裕紀氏（以下、篭橋）：では何個か質問もきているので、まくっていけたらなと思っています。
まず、ヨシノさんから「マイクロマネジメント型のチームをエンパワーメント型へ切り替えていくことに対して難しさを感じています。例えば、チーム状況に合わせてマイクロマネジメントをあえて選択したプロジェクトがあったとします。その中でチームは経験を積み成熟していくものの、マイクロマネジメントの仕事のやり方に最適化されたチームが完成しますが、このマイクロマネジメント型で最適化されたチームは、どのようにエンパワーメントしていく・変化していくべきだと思われますか？」ということです。このあたり広木さんはどうでしょうか。
広木大地氏（以下、広木）：そうですよね。これはけっこう難しい部分があります。あるプロジェクトをやろうとした時に、マイクロマネジメントにしないとそもそもできない。リーダーも本当はマイクロマネジメントをやりたくないのかもしれないけれど、どんどん介入していって、その結果メンバーは考えて成長していく時間よりも、細かく切られた仕事をこなしていく時間が増えていってしまう。そして、また成長しにくくなってしまうという、こういうサイクルはどの会社にもあるのかなと思っています。
メンバーに伸びしろがあるという前提でお話しすると、いい仕事を振れない状況、つまりリスクをちょっと取ってもじっくり考えて検討して成長していくまでの時間的猶予のある案件や、あるいはそれによって乗り越えられるリスクをテイクできるような仕事が少ないと、どうしてもマイクロマネジメント型でカツカツやっていくということを繰り返してしまいがちで、やはりそこが難しいと思います。
なので1つは、僕は「失敗できるという福利厚生」という言い方をしているのですが、エンジニアにとってやはり失敗できる場所というのは、失敗の低減において強さにつながっていくと思います。
ただ、若いうちにメチャメチャな、これ損失するよみたいな案件にアサインされて、その一部として仕事していると、リスクに怯えてしまいます。要は大企業の人とかが、なかなかチャレンジできないとか、なかなかこういうことをできないよとなってしまうのは、最初から大きな仕事すぎて、いい感じに転ばせてもらえないのですね。
自転車って、ちょっと転んでも大丈夫なところで練習するじゃないですか。そういう自転車に乗れる場所があまりない組織は、どうしてもマイクロマネジメント型に寄っていってしまうので、きちんと自転車練習場を作ることなのだと思います。
篭橋：ふんふん、なるほどなるほど。ありがとうございます。ヨシノさんはどうですか。
ヨシノ：はい、ありがとうございます。自転車練習場を作っていくというのは、もうまさにそうだなと思いました。ただ私たちの中で小さくやってみようというかたちで、「なんとかエンパワーメントで切り替えいけないかな」とやろうとしたものの、やはり全員が誰かのレビューを通っていないと怖いみたいな、いわゆるコンフォートゾーンがもう固く形成されてしまっていて、小さくやる場合にそこに飲まれてしまうという状況が今発生しています。
もう明確に自転車練習場を作って、これは失敗してもいいんだとか、これはもうレビューを入れなくていいんだというところを割り切って進んでいくのがいいのかなぁと理解したので、明日から、来週からちょっとやっていこうかなと思います。ありがとうございます。
広木：はい。
篭橋：ありがとうございます。でも難しいですよね。どういうふうに権限を与えていくのかというところですね。
アジャイルなどは本来哲学的・思想的な補助線がある上で理解されるべきこと
篭橋：（質問を見て）ワダさん、ありがとうございます、「輪読会にてみんなで書籍を読ませていただいています」。
広木：ありがとうございます。
篭橋：「書籍序盤からとても共感できる内容で感激しました。本の中には哲学的、歴史的な話がたくさん出てきます。現場で必要とされているような開発の知識とは別に、これらの哲学的な知識を身につけられた経緯、興味を持ったきっかけなどを教えてもらえると」ということです。
広木：もともと好きな部分はあって、中学校ぐらいの時、ご多分に漏れず厨二病的な感じで図書館に篭っていたらですね、人類学やら哲学やらの本がたくさんあって、よくわかりもしないのに読むという日々を過ごしていました。そうしたら、だんだんとそういうものが考え方として入っていくようになっていきました。
特にアジャイルだとか、そういう話の文脈でこの話が出てくると思うのですが、そういった歴史的経緯や、哲学的・思想的な潮流みたいな補助線があって理解されているはずのことが、バズワード的にはやってしまったので、中途半端に捉えて半可通として振る舞って仕事しちゃっている人がいるなと。
例えばアジャイルを教条的に捉えてしまって、その背景にあるトヨタ生産方式や品質工学を知らないとか。あるいは、背後にあるアメリカのプラグマティズムを知らずに言葉を使っていると、表面を上滑って本質的じゃない部分に対してこだわってしまったりとか。あるいは、そこにはそう書いていないからよくないみたいな、教条主義的になって考えることを放棄しちゃっている場面を、アジャイルの初期ではすごくよく見たんですね。
今でもいろいろなバズワードで存在すると思うのですが、それを1個ずつ解きほぐして、「そもそもこれってこういうものだったよね」「そもそもこれってこういうものだったよね」と、マネージャーになった時にいろいろな人に順番に伝えたいなということがたくさん出てきたのです。
それがたくさんあるから、飲み屋でグダグダと2時間ぐらい話していたら話せるかもしれないけれど、それを多くの人にアルコールを使わずに意思疎通するのは非常に難しいなと思っていました。
いつか本に書こうと思っていて、機会に恵まれたので順番に書いていっていて、書ききれなかった部分がたくさんあるものの、背景を知ることでより深く思考できることを多くの人に知ってもらいたいなというところから、僕自身は興味・関心を持っていました。
篭橋：ふんふん。
ワダ：ありがとうございます。自分も哲学の本を読むのが大好きなので、書籍の内容にものすごく共感したところがあります。開発における抽象的思考を組織論まで拡張しているところが書籍の魅力だなと思いました。
ビジネス側もエンジニア側も互いの領域を知って議論しなければならない時代
ワダ：それでいくと、エンジニア以外の人たちにもこういう考え方を理解してもらわないといけないと思うんですよね。業種の違う方たちに『エンジニアリング組織論への招待』に書かれているような考え方を理解してもらうことはできるんですかね？ そこで行き詰まった経験はありますか？
広木：うん、そうですね。ただまぁ3章に書いたかなと思うんですけど、もともと日本のトヨタであるとか製造業が華やかだった頃のエッセンスがすごくあって、本来、日本人が持っていない概念ではないと思うんですね。
なので、そこからきちんと伝えていく部分も必要かなと思います。もう1つ、僕がさまざまな場面で発信していることとしては、今日冒頭でお話しした仕事の定義みたいな話に近いと思うのですが、コンピューターが仕事の中にどんどん入ってくる中で、半導体に仕事をしてもらうか人間に仕事をしてもらうかは、きちんとフラットに議論して考えなきゃいけない時代に変わっていく。そして今も変わっていっていると思っています。
その中で今までの組織論は人間が人間に指導し、人間が人間の遂行するためのもので、コンピューターのコの字もない状態で定義されているものなんですね。だけど僕は、この問題を解決するのをコンピューティングリソースにするか、それとも人間にするか、比較的フラットに考えなきゃいけない問題だと思っています。
つまりシステムを設計すること、組織を設計すること、マニュアルを作ること、ソフトウェアを作ることは、ほとんど等価なのじゃないかなと。特に最近プロンプトエンジニアリングとかの文脈も出てきて、そういった度合いがどんどん高まっていくとは思うのです。
こういった中で経営学もソフトウェアともっと密接に議論できなきゃいけないし、ソフトウェアエンジニアリングも、事業のことを無視して議論できる状態はもう終わっているなというのが僕の肌感覚で、それをより多くの人に知ってもらうために両面で活動していっています。
なので、どちらもあるのかなと思っています。エンジニアリングのことが、実はエンジニアリングに閉じているだけではなくて、ビジネスそのものの話なんだよということも言いたいし、ビジネスの人たちにとって、ソフトウェアエンジニアリングとはあくまでエンジニアの人たちだけに対して機能する話ではなくて、それは世の中の知識とか仕事をすることすべてに関わる話なんだよ。この両方の発信活動をしていっている日々なので、そういう活動をしている人を見かけたらぜひ生暖かく見守っていただければなと思っています。
ワダ：ありがとうございます。時代が変わったばかりでまだみんなが追いついていないというか、これから全員が1段上の抽象的思考に持っていかなきゃいけない感じですね。そう理解しました。
広木：なので書籍のタイトルに「招待」とつけさせていただきました。あくまでイントロダクションかなと。
ワダ：ありがとうございます。
「問題解決のために人々の思考、組織などの構造をリファクタリングしなきゃいけない」という結論に至った経緯とは？
篭橋：はい、ありがとうございます。それでは岡部さんからも質問がきています。社内の輪読会は岡部さんが中心にやっていて、そこで（『エンジニアリング組織論への招待』を）読ませていただいています。「書籍の冒頭で『問題解決のために人々の思考、組織などの構造をリファクタリングしなきゃいけない』とありましたが、結論的にここに至ったのはどういうきっかけがあったのでしょうか」という質問です。
広木：ありがとうございます。端的に言うと、僕はいざこざになった時も両方の人が好きだったことがあるんですよ。この人は悪い人じゃないし、別に変なことを考えていないのだけど、なんかこの人と仲が悪いなと。
気がついたらそれが組織の問題になっていたり、大事になっていたり、仕事が進まない原因になっていたりするということを見た時に、どっちも別に悪い人間じゃないけれど、こうなっている。これは仕組みが違っていればそうは考えなかったはずなのに、結果的に人間が問題に向き合えていない状況や、生産的じゃない状況になっているのだなと気がついた。つまり、人が悪いと思えなかったというところが一番大きな入り口かなと思います。
実際そこを変えて、構造的に問題に取り組めるようにした時に、僕が思った以上に生産的な仕事、サービス、技術を発見して生み出していくことができるようになった。要は組織のかたちに対してボトルネックになってしまっていただけだったんだなという思いが結果として見られたので、そういったことだったのかなと思います。
岡部：ありがとうございます。「お互い良い人なのになんでだろう？」と僕も本当に思うところでして。エンジニアの方だとどうしても仕組み化したり、技術的なアプローチでなんとかしようとしてしまうところがあるのですが、この書籍を読んでその関係性をあらためるとか、会話をしなきゃいけないとか、本当に勉強になっています。ありがとうございます。
広木：ありがとうございます。
不確実性の高いタスクに先に対応するためのコツとは？
篭橋：じゃあ最後は、市川さんですね。「PM視点での質問です。不確実性からどうしても逃げがちで、確実性の高いタスクからスケジューリングしてしまう癖が未だにあるのですが、不確実性の高いタスクを仕組み化して先に対応する計画を立てるには、何を気をつけるほうがよいでしょうか」という感じですね。
広木：ありがとうございます。本当にシンプルに以前Qiitaとかにも書いた方法で言うと、そもそも不安そのものの量、つまりこのタスクはどのぐらい不安なのかなとか、不確実はどのくらいなのかなと評価する時に、うまくいけばどのぐらいかかって、うまくいかなかったらどのぐらいかかるという、その2点を見積もりします。
2点の見積もりをして、すごく時間かかるとなったものって、要はわかっていないことが多いからなんですよね。ソフトウェアプロジェクトとかで最初に実装し終わった後にもう1度これをやろうと思ったら、もうちょっと簡単にできるなと思うことが多いじゃないですか。
実際にソースコードを書いている量ってメチャメチャ少ないんですよね。例えば1日当たり平均的なプログラマーが書いている行数って、8時間きちんと働いているはずなのにプロジェクトで平均すると30行とかなんですよ。
じゃあなんでそのぐらいになっているのかというと、それを生み出す過程のさまざまな調査や、わからないものを知っていく過程にエネルギーをけっこう使っていて、その分だけ時間がかかる。つまりタスクの見積もりで時間がかかると思っているのは、調べる量が多いと思っているからなのですが、調べる量が多いというのもどれだけなのかがよくわかっていないという話だと思うんですよね。
本当にわかりきっているタスクはコンピューターの中ではすごく簡単です。「わかりきっているんだったらソフトウェアにしてLoopにしちゃえば終わりじゃん」みたいなことになってしまうので、本当に1個1個やらなきゃいけない作業はそんなに多いわけじゃないんですよ。
実はタスクというのはわからない量を反映しているので、2点見積もりのギャップがでかいものを見つけていくと、不安量が可視化されたりします。そこから取り組んでいくようにすると、思いのほか早く終わったりするやつが出てくるはずです。
そうするとわからないものに対して早めに取り組める状況になるので、「こういうのがよくわからないタスクなんだ」とか「不確実性が高いものなんだ」というのを早めにプロジェクトで発見していくことができるといいのではないでしょうか。
市川：ありがとうございます。そうですね、タスクごとに2点見積もりをすることは今まであまりしたことがなかったです。確かにそこの観点で見てみると、だいたい問題になってくるのは大きい・小さいというところが一番大きくて、事前から見えてはいると思うので、優先順位を立てて計画していけば自然と確実性の高いものが後ろにいくイメージですかね。
広木：はい。
市川：ありがとうございます。
篭橋：はい、ありがとうございます。本日は広木さん、ありがとうございます。また実際に全員で本を読んで、私はビジネスですが、そっちの観点からもいろいろ読んで学びたいなと思っています。ありがとうございます。
広木：ありがとうございます。
