読んだ：『伊藤直也氏が語る、マネジメントで本当に大事なのは「問題にフォーカスする」である理由 』

先日、こちらの記事を読みました。
codeiq.jp

ここ二年間の自分と重なる部分が多く、自分に足りなかったところを振り返るきっかけとなりました。

自分とかぶっているところ

私自身は二年と少し前、異動になり、ある開発チームのリーダーになりました。それから、メンバーが「本業」である開発に専念できるような組織づくりをし、技術的負債を解決していくための開発を行ってきました。
一企業のCTOである伊藤さんとは、任されている範囲も責任もまるで違うわけですが、レイヤーは異なるもの、

はじめ組織、そして本丸の技術的負債の解消へ

という流れに共感を抱きました。

技術的負債の解消に対して自分が足りなかったこと

まず自分に足りていなかったこと。

まず行ったのは問題を正しく把握すること。既存の実装と仕様を読んで分析。はやる気持ちを抑えてコードを1カ月ぐらいかけて読み込みました。

私の場合、既存のプロダクトに対する理解／分析にかけたパワーが圧倒的に足りなかったようです。
必死に既存のコードを読んだつもりでいましたが、1ヶ月なんてとんでもなく、せいぜい1週間程度。それも細切れの時間しか使えていなかったように思えます。
結局、自分が読んでいたのは担当プロダクトの一部分。しかも、本当に細かいところまで読み込めていたわけでもなかったため、いざ実装に入ってみると知らない仕様がボロボロ出てきたり、影響範囲の認識が誤っていて後から後から修正対象が広がっていく、ということが起きてしまいました。

そしてもう一点はこちら。

そして、マーチン・ファウラーの著書「エンタープライズ アプリケーションアーキテクチャパターン」で書かれている構造と一休のアーキテクチャと比較し、それをヒントに問題の構造を整理して言語化することを行いました。

私の中には、比較するべき「お手本」がありませんでした。
既存のプロダクトに対するIssueは見極めていたつもりでしたし、それを解決する、「あるべき設計」も自分の中にはあるつもりでした。
ですが所詮それは、独りよがりの、「ぼくのかんがえたさいきょうのアーキテクチャ」止まりだったのだと思います。
それがとんでもなく正解から離れていたとは思いませんが、自分の勉強不足は否めません。

また、自身が勉強不足であるのであれば、こういったときこそ周りの人のもっている知識に頼るべき…　だったのですが、積極的にそういったこともしませんでした。

結局、新しいものを作る以前に、現在がどうであるかを正しく理解し、そこに潜んでいる問題を正しく把握する、　そして自分たちが「開発者」として作るべきものを正しく見極める、といったことが全くできていないまま見切り発車し、その後多くの混乱を招くことになってしまったのだと気付かされました。

心理的安全性と責任はセットで考えなければならない

もう一点。記事の順序と前後しますが、この言葉もはっとさせられた言葉です。
実はここ半年程、自身のチームの成長に対して、行き詰まりを感じていました。メンバーの成長ややり甲斐を私がうまく引き出せていない…　と思うようになっていたのです。

私が異動した直後のチームは、運用が多くてメンバーが疲弊していたり、ただ言われた実装を淡々としていて技術的な挑戦があまり見られなかったり、　と、エンジニアとして「おもしろくない」環境であるように見えました。
そこで、まずは組織的改革的な方法で運用を減らしたり、ひたすら技術的なチャレンジを組み込めることを見せてみたり　ということをまず行いました。
メンバーの「心理的安全性」をはじめに確保するという点で、このアプローチ自体は正しかったと思います。

ですが、その後のステップがあまり良くなかった。

個々のメンバーに「自ら何をすべきか考え」てもらい、そしてそれをチームとして「議論」する、ということをしたかったのですが、そういったチームになっていくためのアプローチが弱く、気がつけば、私がやりたいことをやってもらうチーム　になってしまっていたかもしれません（少し極端すぎる言い方ですが）。

もともとはそういった組織を目指していたはずだったのですが、気づけば目の前の問題にばかり追われ、まさに

大事な問題について考えるのが大変だから、ついつい目の前の雑用にばかり目がいってしまう。そして長く大事な問題から目を背け続けていると、事業やプロダクトがわからなくなる。

この状態に陥っていた感がありました。