00:01
エンジニアストーリー by Qiita
日本最大級のエンジニアコミュニティ、Qiita プロダクトマネージャーの清野俊文です。
この番組では、日本で活躍するエンジニアをゲストに迎え、
キャリアやモチベーションの話を深掘りしながら、エンジニアの皆さんに役立つヒントを発信していきます。
今回のテーマは、広木大地さんと考える技術戦略です。
はい、技術戦略について今回もいろいろ語っていきたいなと思います。
はい、ゲストにはですね、前回に続いて株式会社レクター代表取締役で、
一般社団法人日本CTO協会理事の広木大地さんにお越しいただきます。
はい、広木さんに今日もいろいろお話を伺ってきたらなと思います。
本日のゲストを紹介します。
レクター代表取締役で、CTO協会理事の広木大地さんです。
広木です。よろしくお願いします。
はい、よろしくお願いします。
はい、これまで広木さんとエンジニアとマネージャーのキャリアや、
組織作りとキャリア設計についてお話ししてきました。
今回は技術戦略についてお話ししていきたいと思います。
はい、ではまずですね、技術戦略について早速いろいろお話ししていきたいなと思うんですが、
そもそも技術戦略っていうのがどういうものなのかとか、
どういう概念なのかみたいなところを最初お伺いしてもいいですか。
はい、僕が技術戦略って言葉を使って発信することはそんなに多くないと思うので、
多分その技術戦略って何ですかって言われたら何ですかって感じで問いを返しちゃうかもしれないんですけど、
そもそも戦略っていう言葉について比較的誤解があるというか、
蔓延している部分はあると思っていて、
なんかよく出てくる文脈で、うち戦略はないんだよみたいな話で、
なんかちょっとこうネガティブな言い回しで、
戦略はないんだけどどうしたらいいでしょうかみたいな感じの話で、
まあ時々聞きません?聞きます?
そういったものを、じゃあその人の考える戦略って何なんだろうって聞いてみると、
何なんですかねみたいな感じもあったりすると思うんですよね。
そもそもの戦略というのは、
なんか困難な目標を達成するための筋道というか、
その筋道というか仮説。
つまりこういう生き方をすれば、
この難しい目標というのは達成できるんじゃないかっていう、
いくつかの考えられる仮説のことを戦略と言いますと。
難しくなければ戦略はまず必要ないんですね。
簡単にこのまま生きでやれば何とかなりますだったら、
実はその戦略というか、
持ってもあった戦略はいらなくて、
今の通り頑張りますみたいな感じになると思うんです。
もっと言うと、なんかめちゃめちゃ資源があって、
全方位に張って勝負できるよっていう超強いところだったら、
03:03
勝つために資源を集中させる箇所が必要ないから、
戦略っていうのは全方位に銃弾爆撃すればいいっていう話になるから、
負けようがない戦略になります。
戦略っていうのの成立条件は弱者であり、
困難な目標を達成するっていう前提条件があって成り立ちます。
なので自分が今捉えてる目標とそのギャップがあって、
そこに対する道筋を照らすもの、
そしてそのための何か仮説のステップのことを戦略って呼んで、
それのテクノロジーにおいての何らかの解を技術戦略だと言うと思うんですね。
そう捉え直すと課題をどう捉えて、
どこに資源を集中させて、
どういう仮説に基づいているかっていう話ができると、
技術戦略っていうのは基本的には言葉としては成り立つ。
これってややこしいことだから、
それを現場が本当は求めてるっていうことって多いかっていうと、
実は多くなくて、
どちらかというと日々やってる業務の意味付けをしっかりと理解したいとか、
なぜこのことをやらずにこれをやっているのかっていうのを、
ちゃんと自分の中で腹落ちしたいっていう時に、
それの戦略がないっていう表現に置き換わっているだけで、
戦略がないって言った時の話はどちらかというと説明が不足しているとか、
あるいはその人にあなたがやってることは大事なことなんだよっていう説明が、
あまりできてないっていう時の方が多くて、
その2つのケースは分けなきゃいけないなと、
基本的には考えています。
もし自分たちが弱者だと、
そしてその弱者なりに戦っていく方法をやろうとしたら、
何かを捨てて何かに集中するっていう話になって、
実は現場の人にとってとかって、
ちょっと息苦しかったり辛かったりする決断になることが多いんですね。
っていうのは資源の選択と集中をよりクリアにしてはっきりして、
全方位じゃないところからよりビビットに描いていくと。
これをじゃあやろうってなったら、
普通は嫌だなって現場の人は、
これもあるかもしれないじゃん、
あれもあるかもしれないじゃんっていうところから、
デボるっていう選択をしたときに、
初めてより戦略ってクリアになるので、
ただクリアにしなくてもいいときっていうのはあるわけですよ。
つまり両方張っといたらこうなりますとか。
そうじゃない戦略をはっきりさせるっていうことについて、
そんなに望んでないことも多いんじゃないかなっていうのは、
僕の観測している範囲では実はあって、
このテーマについて掘り下げて話していくときに、
意外と戦略ってはっきりすると、
それはそれで何かやめたくなったりすることもありますよみたいな、
06:02
そういうのはちょっとまず前提として伝えておいたほうがいいんじゃないかなって思いました。
なるほど、まさにでも戦略っていうふうなお話をしたとき、
よく言われるのがリソースをまさにどこに集中させるかっていうところが、
本来の戦略の言葉の定義みたいなところあると思うので、
まさに会社としての技術戦略っていう話をしたら、
何を犠牲にするのかって話になるんだろうなってまさにお話聞いてて感じました。
今そのお話聞いている中で感じたのが、
よくそこら辺で議論に上がりやすいのが、
技術的塞いとかそういうものに対しての、
まさにリソースをどのくらい割くかって話のところって、
よく議論として話題に上がりやすいなと思っていて、
今のスピードとか何か事業としての成長ってところを実現するために、
その技術的なところを犠牲にしているみたいな状態に対して、
どう次の段階とか経営観点とか、
戦略っていうところに観点で考えていくべきなのかみたいなところで何かあったりしますか。
技術的塞いっていうフレーズに関しては、
キータの記事とかでも書いているので、
ぜひ読んでいただけるといいなと思っています。
これもややこしい言葉で、
細かいところで言えば、
自分が使いたいライブラリーじゃないものを使っているとか、
読みにくいコードがある。
この読みにくいコードがあるっていうのも、
とりわけ全体の開発者体験であるとか、
そういうものに関わるわけではないんだけど、
ちょっと古い部分があるとか、
そういうところから実際にかなりレガシーなシステムになってしまっていて、
これを仮に売却しようと思ったときにも、
ちょっとDDの段階でこけてしまうよねとか、
あるいはセキュリティ上問題があって、
いつかリスクが顕在化するよねとか、
そういう激しいものまで多々ある中で、
塞いっていう言葉っていうのが、
僕がブレーメンの音楽体の化け物みたいなもんだっていう話をしていて、
ブレーメンの音楽体って、
動物たちが家に入った強盗とかを追い出すために、
何匹も重なって自分たちの影を化け物のように見せたっていう話だと思うんですけど、
でも蓋を開けてみると、
彼らは一匹一匹の動物が重なっただけでしたっていう、
こういう話なんですが、
実は技術的不細も、
ちゃんと詳細を見ていくと、
一個一個は単なる実装されてない非機能要件上の課題なんですね。
これが積み重なってしまったことによって、
とても大きな怪物のように見えていて、
それを何とかせねばならないのだっていう、
コミュニケーションの議論の中に吸い込まれてしまって、
なんだかわからないけど不細と呼ばれているから、
これはダメなんだという主張する人々に対して、
09:00
不細だったらば、
利子がどのぐらいなのかによって、
低い利子の不細というのは借りておいたほうが、
事業経営上いいじゃないか。
じゃあ不細は借りておこうみたいな。
もともとのウォード・カニンガンの定義とかに関しても、
同じように借りれるんだったら借りといたらいいんじゃないに近いニュアンスで、
それを放置しとくと日も札もいかなくなっちゃうことがあるから、
自覚的にやろうねというニュアンスのほうが強かったものが、
より今のビジネスというかソフトウェアに対しての不満を
全て吸収していくような言葉になってしまったというのが、
技術的不細という言葉の結構不幸なところだなと僕自身は思っていて、
蓋を開けてみたら一個一個対処していけばいいじゃんという話でしかないものを、
化け物であったり不細というメタファーを使って、
しかもそれの説明不足も相まって、
対処すべきかそうじゃないかという判断ができないと。
ソフトウェアというのはそもそもこの一番難しい部分というのが、
ソフトウェア技術者以外に中身がどうなっているかということが見えにくい、
見えないという不可視性という非対称性があって、
経営者の人とか他の人が中身分からないと、
分からないけどこう言ってるんだからきっとこうなんだろうという話になりますと。
ソフトウェアビジネスとかソフトウェアを作っていくことの難しさって、
コンポーネントを組み合わせていく形にしても、
必ずどこか今までになかったものを作らなきゃいけないから、
ソフトウェアって複雑なものなんですよ。
というのは普通ビル建てようと思ったら、
1個目のビル建てて2個目のビル建てようと思ったら、
似たようなところとか出てくるわけじゃないですか。
繰り返しになる部分も出てくるんですよ。
3階と4階は同じだねとか、
5階と6階は同じだねってなると思うんですけど、
ソフトウェアは一度作ったものは基本的にはコピーできちゃうんですよ。
ということは必ずどんな今までの人類の構造物よりも複雑になる宿命を追ってるんですね。
その宿命を追ってるものが中身が見えないんですよ、経営者にとって。
これってすごい不幸なことじゃないですか。
しかもメンテナンスもできないし中身もわからないし、
しかもそれに対する建物だったらこのぐらい建ってきたなって見たらわかる。
だけどソフトウェアだと80%できてますって言って、
ビルだったらまださら地なのに8割できてますって言ったら嘘だなってわかるわけですよ。
だけどソフトウェアの場合8割できてますがさら地に見えることがあるわけですね。
でもそれでもそういう作り方をしちゃうとよくないよっていうのが
例えばアジャイルでちゃんと動くものを見せようみたいな話っていうのは
動く単位で作るっていうことの重要性を言ってたりするのは
まずその不可視性に向き合うっていう話でもあったりして、
12:01
その技術的不採点はまさに見えないアーキテクチャ的な負の側面のこと。
アーキテクチャ的なポジティブな側面っていうのは拡張性があったりとか
セキュアであったりとかっていう要素は見えない要素なんですね。
見えない良い側面と見えない悪い側面っていうその2つの対比があって
それって対処していけばいいっちゃいいだけの話なんですよ、見えてると。
見えてないと化け物化するっていう話があって
見えて評価できれば大体の物事っていうのは
それを定量的な意思決定のもとを行うことはできるわけじゃないですか。
だけどそれがないからコミュニケーション上の論争になる
不安に感じていてこのままじゃ良くない感じがする。
なぜなら何かやれてないことが積み上がっていてレールズのバージョンも古いし
なんだか昔のジェムのメンテナンスも終わりそうだしこのままでいいんだろうか
という不安感に対してそれを正しく評価できる状態になっていないから
優先順位を上げようがない。上げようがない中で
何とかしてくれっていう不満だけが残ります。
だから対処できづらいんですね。
だけどそこに関して一定の割合を返済していこうよもそうだし
一つのガイドラインとしてこの範囲内で対応していこうよとか
ちゃんとリスクを評価してその上で優先順位を決めて対処していこうよってことが
中身はある程度見えるようになりながらとか見せるようにしながらできていけば
単なる要件を消化していく話と変わらないはずなんですね。
そこの可視化がうまく作用していない時にここが問題になる話で
何か不才のメタファーであるとかを極端に言い過ぎるのは
僕は誤解の元だなと思っていて
技術的な戦略に関してもこれが本当に良い借り入れなのか
悪い借り入れなのかっていうのは利子率によるわけですよ。
この利子率が悪い借り入れなのかの評価っていうのが
本当はしなきゃいけないだけの話なんだけど
そうじゃなくて単純にこれが不才だからっていう二言論で
技術の戦略を語るっていうことがあまり筋の良い話じゃないなと思っていて
その言葉が気持ち良すぎるんですよ。
言葉としては技術的不才という言葉が。
なのであたかも経営的な言葉を使っているかのような錯覚に用いられる
すごくちょうど良い言葉っていうのが技術的不才の本性であるっていうのが
僕の捉え方です。
なるほどありがとうございます。
じゃあそもそも技術的不才はこうなんですかね
戦略の議論のテーブルにも載ってない状態に近いって感じなんですかね。
15:00
さっき今の話で言うと。
そうですね議論のテーブルに載せられるだけの材料が可視化できているときには
多分その順当に処理されている。
可視化できていなくてたまにたまって大きな問題になって人が辞め始めて
そしてニッチもサッチもいかなくなってから技術的不才があるんです。
さあどうしましょうっていう風に技術的不才と呼ばれる現象は存在するんだけれども
技術的不才になるものは存在しないんです。
ここが問題の捉え方の重要な点でつまり不可視性によって
コミュニケーションが正常に行われず正しく評価されて
アセスメントされなかった結果放置されてしまった課題が一定のティッピングポイントを超えてから
何らかの形で可視化されるという現象を経て技術的不才現象と呼ばれることが起こるだけなんですよ。
こう捉えないと問題の対処するタイミングが間違いなく遅れるんです。
技術的不才は非機能要件として0から1に積み上がった瞬間
技術的不才かもしれなくなる複雑性の発露というのがあるはずなんですよ。
この複雑性の発露は順当に利子を一定編載し続けるように
定期的に返していけばいいだけの話なんですよ。
それを正しく評価して。
そしたらある時点まで見えないなんてことはないはずなんですよ。
見えてるから対処し続けてる。
だけどそれを見えないから優先順位を下げるとか
価値が正しく評価されないから
それは仮入れだといって別のことを優先するっていうことの
程度が行き過ぎてしまうと溜まり続けるわけじゃないですか。
この溜まり続けるって構造がなければ単なる非機能要件なんですよ。
だけど溜まり続けちゃうと。
もっと巨大なのは一度開発したシステムに関しては
ナレッジとしては例えば外注の場合もそうかもしれないし
自分たちでもそうかもしれないけど
たくさんの人が入っていってわーっと作って
完成したってシステムのメンテナンスって
すごい少ない人数でやるってこともあるわけじゃないですか。
そうするともともとソフトウェアの中身について
深く知ってる人たちがみんないなくなってしまって
保守に引き継いでる人っていうのが
なんとなくしかわからない人が
なんとなくおっかなびっくり直してるみたいな現象って起こるわけですよ。
そうするとわからない領域が増えるんですよね。
そうすると無理くりに機能を足したりとか
なんかしてるうちにいつしか
暗黙地だったものが全部消えてしまって
気づいたらなんともできないぐらい複雑なものになってしまった
みたいなことが起きてしまう。
これも技術的不再現象を加速させる動きで
見えてれば単なる引きの要件が
18:01
雪だるま式にたまり
それに対して可視化できないまま
他の原因によって可視化される。
これが問題であって
技術戦略の議論に
もし載せられるぐらい可視化していたら
もう問題の半分は解決できてますよ。
なぜなら見えないことそのものが問題だから。
っていう話ですね。
なるほど。理解しました。ありがとうございます。
今のお話の中でいうと
やっぱり可視化っていうところをしていくことが
すごい重要かなと思ったんですけど
やっぱりその可視化をしていくのって
いわゆるエンジニアリングマネージャーもそうだと思いますし
たぶん現場のエンジニアだったりもすると思うんですけど
そこをいわゆる戦略っていうところの概念を考えているのが
多分経営者だったりすると思うので
そこのコミュニケーションをどううまくやっていくべきなのかな
みたいなのはそこもそこで結構悩んでらっしゃる方もいそうだったので
ちょっとお伺いしてみたいんですけどいかがですか。
IT・インターネット業界に強い転職アプリ
Greenは今話題のテック企業、プロダクト開発、DX案件など
Greenだけの良質な求人を数多く揃えています。
正式応募前に企業の中の人とカジュアル面談ができるので
仕事内容やメンバーのことをしっかり理解した後に先行に進めます。
カジュアルに始める転職活動にGreenをご活用ください。
そうですね。途中の議論と前回と同じような話になるかもしれないんですけど
一番はそのエンジニア自身も経営者になっていくことだと思うんですよね。
よりその肌感覚を持って評価できる人がいたらば
このことは問題になりにくいわけですと。
だけどそしてその人がその人の経営人の中で
これは信頼関係を持って技術的不採の問題に一定の対処をしたいですと。
そうしなければこういうリスクがありますと。
なのでそこにフォーカスさせてください。
いいよって話になれば自然とそこの意思は伝わるわけじゃないですか。
だけど現実そうなってない。
つまり何か優先順位を変えるっていうことの提案をし
それを受け入れてもらうだけの信頼ポイントを得られていないみたいな
いうふうになってしまった時に
より技術的不採現象っていうのは加速しやすくて
信頼ポイントを得てないから
いやいやお前この間のプロジェクトだって着地させることできなかったじゃないかとか
コストはすごいかかってるんだけども何とかならないのか
いやいやそういうもんなんですよとか
そうじゃないんですよとか
このコミュニケーションがうまくいかないまんま
うまくいかないって言っても何かやらせてくれないしな
よし辞めるかなんて言って辞めちゃいましたと。
辞めちゃった後に引き継いだ人たちは結構ひどいんですよなんて
21:01
ひどいから何とかしたいんですよって言って
いやそんなこと言ってた気もするけど本当だったんだみたいな感じになって
じゃあ直そうかみたいな。
でもその時には何か前任者はいないから
前任者を悪く言っちゃってもいいかなみたいなムードがあって
前任者はちゃんとやらなかったからみたいな感じになってたりして
より理解が進まずまたその後任の人もシステムを
セカンドシステム症候群と言われるものがあって
1個目のシステムはうまくいかなかったのは
これこれこういう理由があるから
理想的なシステムをこういう風に作っていけば生産性上がるんだって言って
今までPHPで書いてたけど別の言語で書き直そう
今ラストが流行ってるからラストで書こうなんて言って書き始めてたら
なんか2年経っても出来上がらなくて
あれ出来上がらないなみたいな
でその人もリリースはしたけど
リリースはして一段落したから
辞めようって言って辞めてしまった
そういうことを連鎖して
技術的不在現象っていうのに裸感覚を持たない中
経営に立ち向かうという状況が起きてしまうのは
経営者にとって純粋に不幸な要素があるなと
それはもう一つが
もう少し経営に伝わる言葉でコミュニケーションできたらいいのにな
っていうところにもよるし
もう少し話聞いてあげてもいいのになって思う
この間を取り持つっていう仕事っていうのは比較的よくやっていて
その評価そのもの
エンジニアの評価そのものっていうのは
言い方としては若干偏りがあるかもしれないけど
概ね真実で
だからそのために一定割合対象をしなきゃいけないと
だけど全部作り直さなきゃいけないかっていうと
一部作り直し始めるところから始めないといけないから
この落としどころとしては
この拡張性が望まれている
ビジネスの方向的に拡張が望まれている場所から中心に
アーキテクチャしていって
そこをスケーラブルにしていくことの方が
先行投資としては大事だし
そのために機能開発を一部止めてでも
そういったアーキテクチャをしていくフェーズっていうのは
少なくともPMFしてたら
他社にも結構ジレードしてありますよっていう話を言って
じゃあその計画立てようかとか
そのための三段立てようかみたいなところを
サポートしていくとかっていうのは
よくあるというか
そんな感じですかね
ありがとうございます
ある意味でエンジニアだったり
いわゆるエンジニアリングマネージャーみたいな人たちも
経営とか戦略っていう文脈で
そういういわゆる機能要件みたいなところを
改善していくことの価値とか
リターンっていうのが何なのかみたいなところが
言語化はできていけると
より建設的な議論には
すなやかっていきやすいみたいな感じなんですかね
24:00
ありがとうございます
最後に
リスナーに向けてメッセージをいただければなと思うんですが
何かあればお願いします
そうですね
Kiita 使ってください
ありがとうございます
あとそうですね
僕は
そのアウトプットして
Kiita でアウトプットをしたりすることで
いろんな人にいろんな考えを知ってもらったりとか
論点を成立するための
糸口になってくれたらなと思ってアウトプットして
それがいろんな人に読んでもらえてっていう
いいサイクルの中にいさせてもらってるなと思っていて
そういうフィードバックの良いループっていうのの中に
飛び込めるいい媒体だと思うんで
世の中に還元していくっていうことを
ソフトウェアに限らず
何でもしていくっていうことを意識してると
いつか自分にも返ってくるし
いい話なんじゃないかなと思うんで
ぜひアウトプット活動とか
できるといいのかなと思ってます
ありがとうございます
ひろきさん3回にわたりありがとうございました
最後に何かお知らせありましたらお願いします
EMFM というボッドキャストをやっています
なので皆さんボッドキャスト聞いてらっしゃると思うんで
ぜひサブスクライブお願いします
ありがとうございます
今日は本当にありがとうございました
とても僕自身学びの多い時間になりました
ぜひまたご機会あれば
こうやってお話できたらなと思うので
またお待ちしております
ありがとうございました
ありがとうございました
ひろきさんとは前回は
エンジニア組織とキャリア設計について
そして前々回は
エンジニアとマネージャーのキャリアについて
お話ししていますので
ぜひこちらのエピソードもお聞きください
さてこの番組では
感想や質問、リクエストなどお待ちしております
番組詳細欄にあるリンクより
お気軽にご投稿ください
ツイッターでは
ハッシュタグエンジニアストーリーをつけて
ツイートしてください
そしてアップルポッドキャストや
スポティファイのポッドキャストでは
レビューもできますので
こちらにも感想を書いてもらえると嬉しいです
Kiita株式会社は
エンジニアを最高に幸せにするというミッションの下
エンジニアに関する知識を記録
共有するためのサービスKiita
エンジニアと企業のマッチングサービスKiitaJobs
社内向け情報共有サービスKiitaチームを運営しています
ぜひカタカナで
Kiitaと検索してチェックしてみてください
お相手はKiitaプロダクトマネージャーの
清野俊文でした
