97: 事業戦略上本当に解くべき課題を解くべき順番で解けるようになりたいな

Published on
December 16, 2022

概要

以下のツイート見て考えたことを話しました。

文字起こし

powered by whisper.cpp

皆さんこんばんは。カトッペFM第97回の配信です。 このポッドキャストはですね、僕ソフトウェアエンジニアのカトッペが日々仕事をする中で感じたり気づいたり考えたりしたことについてゆるーくお話しする番組です。 はい、今日はまた仕事終わりなんですけども、久々に大きめのプールリクエストを作って、コードを書いてプールリクエストを作って、レビュー依頼を投げて、金曜日の夜なので、今日はこれで終わりにしようかなと思っています。 ちょっと完全にあの休息モードに入る前に一言二言ポッドキャストで喋ってから休もうかなと思ったんで今収録しています。 今日話そうかなと思うのは、たまたま見かけたツイートなんですけど、 レイヤーXのCtunomatsumotoさんが2020年12月14日、今週の一昨日につぶやいてた内容が少し自分の胸に響くものだったので、それについて紹介しつつ何をそれに対して考えているのかっていうのを話してみたいと思うんですけど、 どんなツイートだったかというと、開発生産性を上げるためにデプロイ速度とかプールリクエストのリードタイムを短くするとか、そういうところから始めがちだけど、 そこを改善してもかなり局所在的になることが多くて、 やっぱり根っこから、例えば事業戦略から考えた時に本当に正しいことをやっているのかっていうところから考える必要がある。 そうしないとなかなか根本的な改善というか生産性アップって測れないよねっていう内容だったんですね。 もちろん、そういう細かいリードタイムの改善みたいなところも価値はあるものだと思うんですけど、 そもそも事業戦略に対して、それを実現するために必要な組織ができているのか、開発組織も含めてですね。 あるいは、その事業戦略を実現するためにあたって最適なシステムアーティスティクチャーだったり、開発基盤だったりというものが作られているのか、 みたいなことをすごく重視しなきゃいけなくて、 かつ、本当にプロダクトとか事業が未成熟な時って本当に何も分かっていない、不確実なものがたくさんあるという状況なんですけど、 その中で正しく解くべきじゃない問題を解いちゃうみたいな影響がものすごく大きいよ、みたいな話をしていて、 その正しい解き方でて、正しい順番で優先度を解く。 その優先度というものは事業戦略から落とし込んでいく、そういうことで決めていく、みたいな話をのついていたんですけど、 すごく自分ができていないことをすごく気づけたというか、 ついつい目の前の分かりやすい課題、 自分がエンジニアリングで考えられる解決策を考えられて実行できる課題から解決してそこを改善しようと思っちゃうんですけど、 もう少し全体的な視点で見たときに、それが果たして事業にとって会社にとって最適なアプローチであるかというのは、 全然違う話だなと思っていて、 そういうことがすごくできているときとできていないときのほうが多いかなというふうに自分自身は思ったんですね。 特に解くべき課題を本当に解き解いているのか、正しい問いを立てて正しい順番で解けているのかっていうところは、 本当にすごく間違えるとインパクトあるなって実感があって、 何だろうな、考えなくていいことを考える、議論しなくていいことを議論する、作らなくていいものを作る、改善しなくていいものを改善する、 ってものすごく無駄なことだと思うんですよね。 大きな会社でいろんなチームがあって、あると、例えば確実に前に進められている人たちと、 ちょっと解き方を間違えるっていう人たちがいたとしてもチームとして混ざっていたとしても、 なんとなく相殺できるというか、一定割合会社を正しく前に進められていたら、 ちょっと間違えてしまった人たちもリカバリしやすいみたいな、そういう状況があったりするのかなと思うんですけど、 会社がすごく小さかったり、プロダクトがまだ括弧である柱というか、事業の柱として成長していないケースで、 そういうことをやってしまうとものすごくインパクトが大きいなって思いました。 事業戦略上、必要のないものに紐づくものをいくら改善しても、それは本当に必要がないので、 局長的には改善できたと思って喜んだとしても、結果、どんどんどんどん全体視点につなげていくと、 何にも効いていない、何にもいい影響を与えられていないというふうになるんですよね。 例えば、今プロダクトを作っているんですけど、バグがあるとするじゃないですか。 バグの中にも、やるべきかやらないべきか、バグだからといって直すべきじゃないですし、 直すべきものについても優先度があると思っていて、 自分はよく当たり前、ありえない品質をなくすために必要な不具合修正なのか、 当たり前品質を達成するために必要な不具合修正なのか、 表なし品質を達成するために必要な不具合修正なのかというふうに分けて、 現時点でどこまでの水準でやっていくべきですかという話から、 まずはありえないものを達成していきましょう。それも最優先ですよね。 でも表なし的な不具合修正はやらない、もしくは優先度を下げましょうという話をするんですけど、 よくするんですね。 ただそれってプロダクトの世界でしか考えていなくて、 あるプロダクトを見た時に特定のターゲットユーザーの視点から、 これはありえない、当たり前、表なしだという感じしか見ていないんですけど、 やっぱりそのプロダクトが会社の事業とかにとってどういう意味があるのか、 会社の事業計画、事業戦略にあたってプロダクトがどういうふうに成長していく、進化していくべきだから、 目の前のタスクの優先順位はこうです、これはやらなくていい、これはめっちゃ早くやりましょう、 みたいなふうに考えられていないなって自分自身思ったんですね。 これはすごく一人で考えることじゃないと思うんですけど、 こうやって自分がもしかしたら事業戦略目線で、会社目線で考えられていないかもっていうふうに気づいたりとか、 危機感を持つことはすごく大事だと思っていて、 日々自分がやろうとしたり、他の人にこのタスクをお願いするっていう時に、 あれ本当にこのタスクでいいんだっけっていうふうな問いかけを自分自身、 あるいはチームに投げかけるっていうのはすごく大事だなと思いました。 トップダウンというか、最上段の事業戦略を全て精緻に決めきることも難しい、 いろんな仮説が混ざった状態の事業戦略だと思うので、 一度決めたものが必ず正しいかどうかわからないので、 それだけを信じる、本当にそれ一つ定めた目標、戦略だけを信じて、 それ以外の変化に適応できないようなやり方っていうのはあまりよろしくないと思うんですけど、 とはいえ変わる前提でしっかり戦略を立てて、 それが開発組織とかシステムアーキテクチャとか開発の進め方とか、 細かいタスクの優先順位とかやるやらないとか、 そこまで連続してつながっている状況、 常につながっている状況、そのつながりを日々の活動の中で少しずつアップデートしていく、 学びながら更新していくっていうことがすごく大事で、 そういうことをやれるようになりたいなって思いました。 そうですね。 はい。 今日もなんかすごいなりたいなというか願望の話なのかな、したと思うんですけど。 こういうことを意識しながら開発を進めていくことで、 自分もチームも少しずつ成熟していって、 より自然に意識せずに同じことができるような、 そういう状態になれるといいなと思いますね。 はい。そんな感じです。 じゃあ今日はこの辺りにしようと思います。 ここまで聞いてくださった方ありがとうございました。 それではまた。