00:00
株式会社株式スタイルの後藤秀典です。この番組では、エンジニアリングチームで起きている問題について、技術、組織、ビジネスといった複数の観点で深掘りし、問題の正体へアプローチしていきます。
今回のテーマは、イシューからはじめるとはどういうことか、です。
これは有名な本があって、今日はその本について取り上げさせていただいて、簡単な解説と、私がどう考えているのかというか、どこを強調したいのかみたいなところをお話ししたいと思っています。
エンジニアリングマネージャーの問題集
はい、では今日も始めていきますが、今日またタイトルにあります通り、本に関してちょっとした紹介と、そこから私が考えることみたいなのをお話ししていきたいなと思っています。
ところで、これ収録しているのが7月14日ですね。
昨日、実は東京のほうへ行っておりまして、大吉ジョージPMというテックカンファレンスというんですかね、そういうイベントがあって、それの懇親会と、あとナイトパーティーっていうのがあってですね、それにちょっと参加してワイワイしてきて、
いろんな方とまたその場で、特に懇親会とかでお話しできて、今までお話したことない方とかお話しすることができて非常に良かったなと思ってまして、やっぱりなかなか私自身も新しい場に出ていって、知らない方とお話ししてっていうことを最近ちょっと意識的にやってる部分がありまして、
特に名前を売ろうとか、そういうことではないんですけれども、やっぱりよりいろんな方の状況とかを知ったりしたいっていう、私の中にある欲求みたいなのがあって、それを叶えたいっていうことでもあるし、
私の話を聞いて多少役に立ってくれるような方もいらっしゃるかなと思っていて、そういった方とちゃんと私が出会うということも大事なのかなと思ったりするので、数は多くないけれども、出会った方とは結構しっかりお話をさせていただいたりして、私自身もすごく楽しかったりしてます。
そんな感じでね。昨日はちなみにナイトパーティーっていうので、クラブっていうんですかね、踊るみたいなことやってたんですけれども、そういうのもいいですよね。ガチな話をするだけじゃなくて、同じ空間で時間を過ごすということに集中するというか、そんなのも私も好きだったりするんで、そういう機会あったらお誘いいただけるといいなとか思ったりしてます。
03:06
話を戻しますと、今日取り上げる本は、「イシューから始めよう!」という本ですね。こちら、著者が渡川和人さんという方で、結構ツイッターだったりブログだったり読まれてる方多いんじゃないかなと思います。
このイシューから始めようという本に関して、私も結構前から読んでいて、誰にでもお勧めしたい本の一つではあるというところがあるんですが、この本に関して、このポッドキャストで真正面から取り上げたことがなかったので、取り上げようと思ってます。
ちなみにこれ取り上げようと思ったきっかけも、BHPコミュニティでちょっとだけ知ってる方がこの本についてブログ書かれてて、いいなと思ったので、私もちょっとそれに乗っかるのかなという感じだったりします。
このイシューから始めようという本、そんなに分厚い本でもないんですけれども、章で言うと序章があって、それから1から5章まであるので、序章を合わせると6章立てになってる本ですね。
序章のところにベースの考え方が書いてあって、1章にイシュードリブンということで、読む前に見極めるみたいな話が書いてあります。
2章と3章が仮説ドリブンということで、より立てた仮説についてブラッシュアップしていくというんですかね。
そのような話が書いてあって、例えば2章はイシューを分解してストーリーラインを組み立てる、だったり3章はストーリーを絵コンテにするという話になってます。
4章からがよりイシュー自体を表現していく方に入っていくんですけれども、4章はアウトプットドリブンということで実際の分析を進めていくお話だったり、5章で最後にメッセージドリブンということで伝えるものをまとめるというような構成になってる本です。
全然プログラミングとは違う種類の本だと思うんですけれども、本屋に行っても置いてある棚が全然違うので、知らない人は知らない本なのかもしれませんけれども、私としてはマネージャーだとかそういうこと関係なく、やっぱりビジネスパーソンとして仕事をしていく上で非常に大事な考え方だったりスキルだったりのことが書いてある本だと思うので、
聞いてらっしゃる方の中には、俺はマネージャーはやらないと、IC、インディビジュアルコントリビューターとしてやっていくという方もいらっしゃると思うんですけれども、そういう方でもやっぱりコードを書くというかソフトウェアを作るだけではない問題にどこかから関わらざるを得なくなってくると思うんですよ。
06:03
だったり、ソフトウェアの中の問題に対してもある程度通ずるスキルというか考え方だったりするので、ぜひ多くの方にこの本を読んでみていただきたいなと思っているところです。
今回というか私自身がこの本に対して特に大事だなと思っているところ、これは私がという視点なので、皆さんの立場だったり他の方はまた違うところを押すと思うんですが、私はこの1章に書いてあるイシュードリブン、説く前に見極める、何をイシューとするのかっていうのを見極めるところですね。
もうここが本当に肝といいますか、これなくしてそれ以降の活動っていうのの意味をなさないというんですかね、というぐらいに思っているので、ちょっとここを中心にまず本の内容を軽くお話しして、あと私の考え方みたいなふうに話そうかなと思っています。
この本に書かれているイシューの見極め方というか、良いイシューっていうのを見つけろっていうことなんですよね。だったり、より本質的なイシューっていうんですかね、そういうものを見つけましょうという感じの話が書いてあります。
例えば、イシューっていうのは具体的に解くべき問題として提示されたものということなんで、ちょっと後のほうでも具体例少し話そうかと思ってるんですが、例えばエンジニアリング系であれば、生産性が低いので上げましょうみたいなことがイシューとして示される場合があったりするんですよ。
それが良いイシューなのか、良くないイシューなのかとか、そういうことを考えていく必要があるということなんですけれども。
この本に書かれている良いイシューの3条件というのがあって、1つ目が本質的な選択肢であるということ、それから2つ目が深い仮説があるということ、3つ目が答えを出せるということですね。
それぞれ本を読んで皆さんしっかり理解していただきたいところであるんですが、かいつまんで簡単にお話しすると、本質的な選択肢っていうのは、逆に本質的じゃない選択肢っていうのは、そのイシューに対して何か答えを出しても、そんなに体制に影響がないような類の問題っていうんですかね。
そういうものもたまにあったりするんですよ。そうではなくて、答えを出すことが結構、チームだったり組織だったりビジネスだったりに対して、その瞬間だけでなく、未来にわたっても方向性を変えてしまうような、そういった意味があるような大きさのインパクトがある選択肢が含まれているようなイシューということだったりします。
09:14
この本質的な選択肢であるっていうところの章の中に、よくない例として、本質的ではないものの傾向として、何ちゃってイシューみたいな話がコラムとして書かれてるんですよね。
こういうのも非常に、私自身も自分でも何ちゃってイシューみたいなものを過去に選んでしまってたなみたいな記憶がありますし、やっぱり起きがちなんですよね。何ちゃってイシュー的なものを課題と見成してしまうことが。なので、その何ちゃってイシューじゃないのかどうかっていうのは、よく見極める必要があるところだと思ってます。
あと、少し補足的な話で、若干ずれるかなっていう話なんですけれど、このイシューっていうのは、最初にイシューとして設定したかもしれませんが、仮に良いイシューを見つけて、会社全体で合意して、それを解くんだと言って進めていた場合でも、何か別の外部要因みたいなもので、そのイシューが一気に、イシューじゃなくなっちゃう場合とかもあるんですよ。
これを、あたかさんは書籍の中で、イシューっていうのは動く標的であるというふうに書かれていまして、なので、もう一回設定したらとにかくそれを成し遂げることだけが全てと考えるのも若干違っていて、やっぱりいろいろな状況の変化っていうのは常に今の現実の社会の中では起きるので、
そういった状況もキャッチしながら、イシューを解決に向かっていくと言うんですかね。そんなようなマインドセットというか、そういうものも必要なんじゃないかなみたいな話も書いてあります。これが一つ目の良いイシューの三条件の一つ目の本質的な選択肢であるということ。
二つ目の深い仮説があるっていうのは、イシュー自体が本質的なインパクトが大きいものであるということとは別として、インパクトがどういうロジックでもって、仮説なんですよね。どういう仮説でもってそういうインパクトが導き得るのかというか、どうしてそういう答えになるのかっていうところ。
この仮説が表面的なものではない、より深いところの考察というか構造を捉えて提示されているのかというところだったりします。これも本当に簡単に説明できない気がしますし、本の中でもちょっとサラッとした例ぐらいしか書かれてないので、なかなか腹落ちさせるのが難しいところなんですけれども。
12:05
書かれてる説明でわかりやすいものとしては、常識っていうか会社の中でみんながそう思ってるみたいなことに対して、ちょっと疑ってみるというか、そうじゃないんじゃないか。
実は反対側の構造みたいなのがあるんじゃないかというようなふうに考えてみる。実はそれが仮説としてももっともらしかったりもするということだったりもするということで、例えばビジネスをやっていって、今のやり方のままで市場も成長しているので、
基本的にはこの路線を続けていけばいいという前提で、会にある何かイシューを解決しようとするみたいな話があったときに、そもそも前提となっている市場が大きくなっているというもの自体が間違っている場合だとかがあったりすると、それは市場の捉え方自体を変えなければいけないので、
その別の観点で見たときに、そもそも市場をピボットしなきゃいけないというか、そういうことのほうが会社にとって大事なんじゃないかってなってくると、もう最初に設定していたイシューっていうのは全く意味を持たなくなってしまうので、変えましょうということだったりしますよね。
そんな感じで、深い、ちゃんと構造を捉えた仮説があるのかどうかっていうところだったりします。
あと最後に三つ目の良いイシューの条件として答えを出せるというところで、結局答えがない問いみたいなものもあるわけですよね。
人間の歴史の中で昔から問われ続けているようなタイプの問いを設定してしまうと、仮にそれに答えが出たとしたらインパクトは確かにあるかもしれないんだけれども、そもそも答えを出せないというものもあったりするので、それはさすがにイシューとして設定するスコープが間違っているんじゃないかと。
答えを出せないので、その答えを出すことに無限大の労力がかかってしまうということになってしまうので、それは少なくともこの本で話しているイシュー、価値のあるアウトプットを出すためのイシューみたいな話なんですよね。
ということを考えるときには、ちょっとそういうものじゃないよねということを言われています。
っていうのが、イシューを見極めるっていうところの話でして、一旦イシューが見つかったと仮定して、それを分解していったりだとか、ストーリーラインにしていったりだとか、よりきちんと実行に移していくために他の人に納得してもらわなきゃいけないので、どう納得してもらうかっていう表現の仕方あたりに落とし込んでいくって話になっていくので、そこはそこで非常にそれも大事なんですよね。
15:17
それもないと、やっぱりイシューを見つけましたっていうだけでは物事動かないので、そういった後のところの話もしっかり皆さんには読んでいただきたいところであるんですが、今回はそこは取り上げずに、このイシューを見極めるっていうところにフォーカスしたいなというところです。
僕が一番、やっぱりこのイシューを見極めるっていうところが、僕自身の活動テーマみたいなところでもあるんですけれども、やっぱり何ちゃってイシューっていう表現が面白いなと思ってるんですが、本当に何ちゃってイシューになってる例っていうのをよく見てきました。
これはぜひ聞いてる皆さんも注意してほしいなと強く思ったりするところなんですが、後でまた話すんですが、これもなかなか使い分けが難しいところもあったりしますが、一旦ちょっと何ちゃってイシューに関して話していくと、
これも人類のそういう性質なのかもしれませんけれども、「これが問題です。」って言われると、もう本当にそれを問題だと、所有の問題として捉えてしまって、「じゃあその問題を解決しよう。」っていうふうに、問題を疑わずに解決策を考える。
行動に移ってしまうというか、もう頭がそっちに行っちゃうっていうことが、私自身の過去も含めてそういう方は結構いらっしゃるんじゃないのかなと思うし、ソフトウェアエンジニアみたいな解決策を作ることを企業としている種類の人たちにはより傾向が強いんじゃないかなと思うこともあるんですよ。
なので、もちろんソフトウェア作るとか、それはそれで大事なことなんですけれども、このイシューから始めようみたいな、イシューを見極めるっていうことを考えたときに、ちょっとその性質が良くない方向に作用してしまう場合もあるんじゃないのかなと思っております。
例えば、私の過去ですと、社内でいろいろ物事を急激に進めているときとかって、いろんな不協和音というか、出てくるわけじゃないですか、チームの働いてる皆さんから。
18:09
そういうのが結構多くなってきているっていうような状況が経営層のほうまで届いて、そこから問題を解決しなければいけないみたいな号令がかかって、一旦問題を全部理解しなければいけないので、
社内に対してアンケートというかヒアリングというか、そういうものが走り始めるんですよね。
なんかすごい、そんな長い時間じゃないけれども、一定の人数が一時的なプロジェクトチームとして立ち上がって、膨大なアンケートだったりワンオンだったりをやって、その問題の声みたいなのを集めていって、それがまとめられて、こういう問題がありましたっていうのが出てくるんですよね、アウトプットとして。
うまくそれをイシューに消化できた場合もあるんですけれども、やっぱりよくありがちなのが、その出てきたもう一つ一つの声自体が問題です。
どこどこチームと何か一緒にプロジェクトを進めるときに、こういうところが効率が悪くて、すごいやりづらかったみたいな、なんかすごい個別の話みたいなのが出てきて、それが問題ですみたいに上がってくるわけですよ。
そうすると、もうそれ自体を解かなければいけない問題であるかのように見なされてしまって、急にこういう声があるんだけど、これどうにかならないの?みたいなふうになったりするんですよね。
なおかつ、一時的なソリューションみたいなのが提案されて、それでそれに対しては対処しましたみたいなことになって、プロジェクトが完了しましたみたいに言われていくというのを横から見てたりもしたんですけれども、なんかこれっておかしいなというか、聞いてらっしゃる皆さんもそういう感じを受けるんじゃないのかなと思うんですけれども、
なんか、形外化したようなやり方というか、になっちゃってるように感じましたよね。特に現場の皆さんが何を思ってるのかっていうのは、一つ一つすごい大事なことではあるので、その一時情報源というか、本当にどんな感情を持ってるとか、何が起こったとか、そういうことを集めること自体は大事なんですけれど、
でも、そういうのって、構造的な別の問題みたいなのがあって、それによって引き起こされてる結果みたいなものだと僕は思うんですよね。
21:14
なので、皆さんが言ってくれてること自体が問題なのではなくて、そういう状態を引き起こしてる構造というか、歪みというか、そこを見つけに行って、それ自体を直すというか、調整するというか、言うようなことをしない限り、なんか表面的にパッチを当てるというか、
そういうことだけしても、裏の構造を見極めずに表面的な対処だけしちゃっても、何も直されていないというか、同じことがまた起きますよねっていうことだと僕は思うんですよ。
なので、本質的な問題、イシューを見に行くっていうことが大事と言われたら、その通りだねって、頭ではわかるんだけれども、実際にこういった状況を想像してみてほしいんですけれども、こういう問題があるので解決してほしいって、なんかもう上司から言われるわけですよね。
それが、実は本質的なところを捉えていなくって、すごいそういった現場から上がってきた声を直接受け止めて、もう問題としてそのまま捉えてとこうとするというようなことだったりするわけですよ。
なので、そういう状況で、それって本当に問題なんですか、大事な問題なんですかっていうのを、少なくとも自分の中では問い直してみたり、もしくは上司にそうやって言えるとか、なんかそういうことが必要なんですよね。
なので、そういうときにこのイシューから始めようみたいなことを知っていると、その良いイシューとして降りてきてるのかどうか、降りてきてるというか設定されてるのかどうかっていうところを、自分でもチェックすることがある程度できると思うんですよね。
ここは僕自身の経験も踏まえて、結構陥りやすい罠だと思っているところでして、本当に問題にすぐ飛びつかない。誰かが問題と言ってたから、もうそれが問題なんだって考えないようにするっていうのが、まず本当に一歩目として大事なところなのかなと思っています。
この話は非常に大事で、言われたものが問題なのかどうか、良いイシューなのかどうかっていうのを自分で判断するっていうことが必要になってくるんですけれども、これ実際に判断しようとすると、考えようとすると、
24:04
自分の今持ってる責任範囲の知識だったり情報だったりっていうものだけでは、判断できないことっていうのがすぐに出てくるかなと思っています。
この辺が僕がこのポッドキャストでずっと言ってきてるような、例えば技術、組織、エンジニアリングみたいな、エンジニアリングだけじゃない観点、知識を出もって起きている事態を見ていきましょうみたいなことだったりもするんですよ。
なので、たとえ言われてる問題がエンジニアリングチームの中の話であったとしても、そこにその問題の根本的な構造っていうのが、エンジニアリングチームとプロダクトマネージャーたちだったり、ビジネス側の人たちとの認識の疎後が頻繁に起きるとか、そういう問題だったりすると、エンジニアリングチームだけでは解決できないですよね。
なので、両者の問題というか、共同で解決しなきゃいけない問題みたいなところに設定し直す必要があったりするんですよ。
それってなぜ起きるのかみたいなことは、プロダクトマネージャーなのか、ビジネスチームというか、そちら側の人たちがどんな考え方で、どんな方針のもとに行動していて、何が足りないのかとか、そういったところを見極めてようやくわかるようなことだったりするんですよね。
なので、結構自分の領域をはみ出して知識を取りに行かないと、本当に本質的なイシューっていうところにたどり着けない可能性すらあるんですよね。ここが非常に難しいところだったりします。
でも、少なくともまずこのイシューから始めるように書いてある良いイシューの3条件、この辺りはフレームワークとして問題を渡されたときに必ずチェックする3項目みたいなふうに覚えておくといいんじゃないのかなと思っています。
ちなみに、さっき話したなんちゃってイシューなのかどうかみたいな話で言うと、私は以前、グロービスさんのMBAではないけれども、マネジメントスクールでいくつかの科目をとって、その中にクリティカルシンキングというのがあったんですよね。
これ、一番初めにやらないといけないコースっていう感じに設定されているんです。このクリティカルシンキングっていうのがまさに、イシューから始めようとほぼ同じ話をやるんですね。
実際のケースというか、現場でこういう問題が起きていますみたいな問題が出されて、そこでどういうふうに考えるかっていうことをトレーニングしていくんですけれども、その中で教えてもらったことの一つに、イシューに対して本当にっていう問いを持ちなさいということなんですね。
27:21
トゥルーかどうか、問題が本当に良いイシューなんですかっていう問いの一つとして、本当にっていう言葉を出されていたので、まさにそれも同じことなのかなというふうに考えています。
エンジニアの現場で起きがちな具体的な例を2つぐらい話したいなと思っていてですね。
一つは、さっきも少し触れたんですけれども、生産性っていうものを、これがよくエンジニアリング組織のイシューに設定されがちだと思うんですよ。生産性を上げるみたいなことが。
この生産性を上げるだけで言われると、非常に抽象的な問題設定というか、イシューなので、本当に問題なのかどうかっていうのが、それ単体では答えられないですよね。
なので、それだけではあまり良いイシューじゃないと言えるのかなと思っています。どうでしょう?聞いている皆さんも、この生産性に関して取り組んだことがあるんじゃないのかなと思うんですが、
なんかちょっと陥りがちな、良くない方の例というのを、これ全然僕の過去の経験ではないんですが、こういうのってあるだろうなっていう感じでお話ししてみると、仮に生産性を上げるというイシューがエンジニアリング組織の最重要テーマとして設定されました。
ってなった時に、エンジニアリングマネージャーである私や皆さんが、こう考える気がするんですよね。陥りがちな方ですよ。
最近、ちゃんと計測してやろうというのが流行っているというか、良いプラクティスとされているので、その中にフォーキーズとかありますよね。
なので、生産性といえばまずフォーキーズ、これを測ることから始めるべきだと思っちゃう気がするんですよ。
フォーキーズは測らなきゃいけないので、じゃあ測る仕組み、今ちゃんと計測なんだろうな、そういう数値が取れてないGitHubのいろんなものとか、取れてないんであればまずそれを取れるようにして何か通路を入れましょうとか、
取れたものを可視化しないといけないのでダッシュボードを作りましょうとか、そういうふうになってきます。その辺がまず具体的なアクションとして出てきたりだとか。
30:09
じゃあ一定数字が取れた後にそれを基に生産性を上げるっていうのはその数字を改善していくということなので、何かKPIを設定すると思うんですよね。
デプロイの数を上げていくとか、そんなようなものを数値的な目標に落とし込んでいったりします。
そうしていくとKPIに対してどういうふうにしたら数字が上がっていくのかっていうことを考え始めると思うんですよね。
プルリクのレビューにすごく時間がかかっているので、それをもうちょっと効率よくやれるようにしようということで、
最近だとAIがサポートしてくれるようなものもあったりするので、そういうのを入れましょうだとか、
あとはコーディング規約とか、そういうものをきちんと整備しにいって、レビューでコーディング規約的なものっていうのはレビューで議論しないというか、
そういうことで時間を短縮していくとか、そういうようなアクションみたいなのが出てくるんじゃないのかなとかありますよね。
そんな感じで、その辺をやるとKPIに設定しているデプロイの数とか、そういうのが増えましたとかなるかもしれませんよね。
それって一応生産性が上がったと言えるのかもしれません。
ただですね、この話で問わなければいけないのは、生産性を上げなさいと。
生産性が課題にされたときに何のことを言ってるのかっていうのって今全然誰も問うてないんですよね。
生産性って何ですかっていうこと。
今先ほど話したストーリーは、暗黙的にアウトプットの量みたいなところイコール生産性だとして、それを上げるというか、
もしくはアウトプットの量というか、もう4 keysっていうものが最初からソリューションとして頭にあって、
それを改善することが生産性を上げるんだっていうふうに、赤髄反射的にソリューションを思いついちゃってて、
もうそれをやることだというふうに解釈してしまっていたということのようにも思えるわけです。
ただ、生産性が課題になってるときの状況ってもっといろいろあるはずなんですよね。
33:06
そもそも生産性って開発、エンジニアリングにかけてるコストに対して出てくる価値の総量というか、
そういうものが割合が大きくなってるというか、いうことだったりしますよね。
かけてるコスト自体が問題となる場合もあると思うんですよ。
それは人のコスト、人件費みたいな話でもあるし、もしくは人じゃないところですね。
システムのランニングコストみたいなところ。
こういうところをどういうふうにこれを会計的に捉えるのかっていう側面もありますが、
ソフトウェアエンジニアリングのコストというふうに捉えるとしたときに、
なんかサーバーのクラウドのコストがすごいかかってんだよね、作れるものに対して。
っていうときには、もうそっちのことを指して生産性が良くないと経営者は言ってるみたいなことがあるかもしれませんよね。
だったりだとか。
あとは、先ほど話したストーリー、フォーキーズみたいなところだと、やっぱり作るスピードというかいうところに一定関係してるので、
作るのが遅いっていうような系統の問題のことを指摘されているのであれば、
フォーキーズはある程度フィットするメトリクスかもしれませんが、
とはいえ、じゃあいきなりフォーキーズに飛びつけばいいかというと、
やっぱりもっとちゃんと問題自体を深掘る必要があるんですよ。
どこが一番問題に対して大きな影響力を持っている要素となっているのか。
例えば現場によってはエンジニアのスキルがちょっと足りてないんですよねということで、
なかなかアウトプットに結びついてないっていうこともあるかもしれませんし、
そこは問題じゃないとしても別の問題。
例えばコードレビューできる人が一人しかいなくて、
その人がボトルネックになっちゃってコードレビュー待ちがすごい発生してるとか、
これも本当によくある問題ですよね。
エンジニアのほうはコードレビューとかうまく回してても、
仕様の確認だとかそういうところでプロダクトマネージャーだったりだとか
ステークホルダーと確認しないと最終的にデプロイ、
プルリクを完了してリリースしていけないっていうことがあって、
そこの確認待ちがすごく多かったり長かったりして、
ボトルネックになっているというケースだとか、
もしくはエンジニアリングの中だけで単純にCIの待ち時間が長くて、
なかなかデプロイしていけないみたいな話かもしれませんし、
そういうあたりもあるんですよね。
そこのあたりをきちんと見極めて何が問題なのかっていうところを
36:02
きちんと掘っていく必要があると思います。
あと、生産性っていったときに何でしょうね、
作るスキルだとか、ボトルネックもないみたいな状況だとしても、
そもそも作って出したものがお客様の欲しかったものじゃないみたいなことって
やっぱりあるわけですよね。
これってエンジニアの責任じゃないみたいに思われるかもしれませんけれども、
やっぱり最近どちらかというと、
作るものに対してもストリームアライドで
オーナーシップをきちんと持ってやっていこうっていうような流れがあるのかなと思ってまして、
そういうふうに見たときにやっぱり最終的に
お客様が求めているものを提供するというところまで責任を持つ人があるわけですよね。
っていったときに、それがアウトプットだとすると、
一生懸命早く上手に作ったとしても、
それがお客様が求めているものと違いました。
また作り直さないといけないっていうのは、やっぱり生産性が悪いわけですよ。
デプロイの回数とかはすごくうまく回ってたとしても、
最終的に届けるべき相手に対しては、
届いている価値は大きくなっていないということですよね。
この辺りのどれを今課題とされているのか、
もしくはどれか一つではないかもしれないですよね。
複数発生していて、どの辺りが今の時点では最も影響が大きいのかとか、
もしくは単にイシューを見極めるという段階ではないかもしれませんが、
そういう複合的に発生しているときに、
どういう順番でこのイシューと戦っていくのが最適なのかっていう
イシューだったりもするかもしれないですよね。
こんなふうに生産性という話一つを取っても、
イシューをきちんと見極めるということがめちゃくちゃ大事なのかなと思っています。
なので僕が強調したいのは、いろいろやっぱり可視化して、
計測してそれを良くしていくみたいなものが、
そういうのが大事なフェーズにある会社さんがあることもわかっていますけれども、
それが生産性という課題を解決する銀の弾丸じゃ当然ないわけですよ。
なので、生産性という言葉が出たからといって、
フォーキーズだったり、そういう開発を早くするというか、
そういうソリューションにすぐ頭を引っ張られるということに自覚的になる必要があって、
39:08
そうではなくて、生産性とは何ぞやというか、
言葉の定義という話よりも、今この会社の中で問題視されているのは、
生産性ではない言葉で言ったら何になるのか、
というところをきちんと自分で必要な人と話したり、情報を集めたりして見極めていく。
ここが最も重要なアクションになるわけですよ。
ということで、これが僕の言いたいイシューを見極めるという活動の具体例みたいな話なのかなと思っています。
今、生産性を例にしてお話ししたので、
なんとなく僕の言いたいことが伝わってるのかなとも思ったりするんですが、
似たような話で、例えば技術的不採とかもこういうのが起こりがちな話なんですよね。
ここも多くは話さないんですけれど、技術的不採みたいなものがどうだろう。
これもちょっと違う側面があるんだけれども、
イシューというか問題に設定されたとしても、やっぱりその中身って何なのっていうところは、
もっといろいろ細かく分解して、本当の問題、技術的不採という言葉を使わずに表現できる個々の問題に分解して、
それを優先順位付けするというか、自分たちの中ではどれが本当にどういう問題を引き起こしているのかっていう言語化までしていくことによって、
今何をやるべきなのかっていうのがクリアになっていくと思うんですよね。
そのイシューから始めることができるというので、技術的不採という言葉だけですぐにその問題に飛びついて、
ソリューションはこれだ、とにかく技術的不採を減らしていくみたいな、また何か可視化するようなものを入れて、
それを減らしていくみたいなことをし始めると、本来何が問題だったのかっていうのは見えなくなっちゃうので、
きちんとまず何が問題なのかっていうのを見るっていうことを癖をつけるっていうことが大事かなと思っています。
最後に少し補足で触れておくと、
この散々しっかり見極めようという話を今しましたし、
何なら見極めるときに少し自分が見えている範囲の外のことまで知ったり情報を取りに行ったりしないと、
本当の良いイシューっていうものを見つけられない、到達できない可能性もあるとお話ししました。
42:02
ここは実は何というかちょっと難しい問題をはらんでいて、
原則良いイシューを見つけることは大事だと思っています。
ただし会社の状況だったりだとかいろいろなものを考えたときに、
仮に本質的な良いイシューを見つけられた、それがエンジニアリング組織の中だけではないところに本質的なイシューというのがあって、
何なら会社全体だとか営業のほうとか巻き込んで変えていかないといけないみたいな。
それをやれば確実に良くなりそうなんだけれども、そういう問題が見つかったとします。
でも、じゃあそれを今すぐやりましょうって会社全体で慣れるかどうかはまたちょっと別の問題なんですよね。
やっぱり影響範囲が大きくなると、本当に会社の生き死人に関わるようなことで、
今その問題によって会社がまさに危機に瀕しているっていうことであれば、
もう社長なり経営層なりでそれに対して意思決定をしてアクションしていくっていうことができるかもしれませんけれども、
問題がエンジニアリングの中だったり結果だったりっていうところ、影響範囲でいうとそこ。
ただし問題の原因まで見ていくと、エンジニアリングの外側との関係の中で起きているみたいな、
こういうちょっと微妙なサイズのイシューの時とかがあったりするんですよ。
そうすると前社で見ると、そのイシューって確かに問題は問題で何とかしたいんだけれども、
エンジニアリングの外側まではみ出して動かすにはちょっと今すぐじゃないよっていうことがやっぱり出てきたりするわけですよね。
そうするとエンジニアリングサイドからした時には、本当にそれを今すぐやってほしいんだけれど、できないなんだかなってなっちゃうわけです。
でもこれはやっぱり会社の判断として、そういう時は一旦受け入れるしかなかったりするんですよね、どうしても。
そこで諦めちゃうというか、この会社全然わかってないとか、そういう気持ちも芽生えてくることもあるんですけれども、
やっぱり会社全体の判断っていうのは一定経営者だったりがバランスよく見てされてるものだと基本的には思うので、
それはそれで尊重しなければならなくて、とはいえエンジニアリングの中で大きな問題になっているのであれば、
一旦その大きな影響範囲になってしまうイシューは横に置いといて、
それの次ぐらいにいい感じに効きそうなイシュー、エンジニアリングの中だけで実行に落とし込めるイシューっていうところに設定し直すという考え方も必要なのかなと思ってます。
45:13
この辺りが非常に難しいと言いますか、自分だけじゃないですね、エンジニアたちも含めてその気持ちの持っていき方とかいうところもうまくできないと、
何なら会社と経営者たちと対立構造みたいなのができちゃって、別の問題が起きちゃうみたいなことにもなっちゃうので、
何でもかんでも経営だったり外の意見を受け入れろっていう話をしているわけではないんですけれども、
いろいろそういった全体的なことの理解も踏まえて、今じゃないと自分も納得できるっていうことがあると思うので、
その時にはイシューの設定の仕方を変えるっていうオプション、自分の最善ではないけれども、今はこれがベターというか、ある意味今やるならこれがベストというようなやり方っていうところに落とし込めるっていうことも必要だったりするので、
これはなかなか組織の中での動きっていう話なので、ちょっとまた別次元になってくるんですけれども、聞いてらっしゃる方の中のエンジニアリングマネージャーの方であれば、
割とこういう状況って発生するんじゃないのかなと思うので、最後に一つそういったお話もさせていただきました。
というわけで、今日はイシューから始めようという本について簡単に紹介して、あとそこから私が強調したいところというか、みたいな話しました。
本当にこの本大事というか、そもそもこの問題解決、課題解決っていうことって、これこそ結構汎用性の高い、銀の弾丸とまでは言わないけれども、
社会人として、ビジネスパーソンとして仕事をしていく上で、めちゃくちゃ生きるスキルだと僕自身は思っていて、
例えば何回か前のポッドキャストでもお話ししたんですが、マネージャーとして何を勉強したらいいかっていうときにも、まずこの問題解決スキルっていうところを挙げていたりするので、
それがこの本に書かれているということだったりしますので、機会があったら皆さんこの本を読んでみていただきたいなと思っています。
さて、この番組では、感想や質問、お悩み相談をお待ちしております。
エンジニアリングの現場で遭遇するあらゆるトピックについて、番組詳細欄にあるお便りフォームよりお気軽にご投稿ください。
ツイッターではハッシュタグEM問題集をつけてツイートしてください。EMはアルファベット、問題集は漢字でお願いします。
そしてApple PodcastやSpotifyのポッドキャストではレビューもできますので、こちらにも感想を書いてもらえると嬉しいです。
48:06
お相手は株式会社カブクスタイル、COO兼CTOの後藤秀典でした。
