おうさまのみみはロバのみみ

ネット上での木の洞

最近のエモい話し

最近やたらとエモいマネジメントの話しを聞いたり読んだりすることがあったんだけど結局のところどれにも共通するよね?ってことがあったので書いておこうと思った次第。

  • 問題の本質を理解する
  • 課題の見える化
  • 問題の振り返り

ぼくはマネジメントにすごく実績があるというわけではないのでここで書いてる内容はすごく頭でっかちなことなのだろうと思う。 ただどの書籍や資料、あるいは講演などを聞いたり見たりしてもこの3つは言葉は違えどどれにも共通しているように思う。

本来の課題の本質が「プロダクトの質を向上させる」であるはずがテストコードを書けばいいんでしょ?コードレビューすればいいんでしょ?であったり 問題がどこにあるのか?を検討しないままとりあえず会議して無駄にみんなの時間を奪ってしまっていたり やることいっぱいすぎて整理できてないけどスケジュールは変わりません!みたいなことだったり。

だいたいのプロジェクトで炎上する、あるいは炎上しそうになった際に偉大な先人はまず 「問題の本質がどこにあるかを検討」 それを「チーム全体で共有するために見える化」 「今何をしなくてはいけないのか?あるいはなにをすべきでないのか?」を明確化して乗り切っているっぽい。 これらは手法や経緯は違っていてもだいたい共通している。

もちろん資料からだけでは意味がないのだろうと思うけどぼくらはどうにもイディオムに視点がいきがちだ。 コードレビューをしないといけない、テストコードを書かないといけない、Githubを使わないといけないなどなど…。

それらは確かに打開をしてくれる可能性があるが問題の本質はそこにあるか?と言われると疑わしいことがある。 OSO2017で「レガシーとは当たり前だという思考そのものである」といったような発言があった。 これらは無意識だから気づくことが非常に難しく、そのため改善案を提示しても提示された側は「こんなことは当たり前なのだ」と思っているため芳しい返答が返ってこない… だいたいそのようなことを言っていたと思う。

speakerdeck.com

この資料で「何故本来そうあるべきものがなっていないのか?そうならなかったのは何故か?」という問いを突き詰めろと伊藤直也さんも言っていたがこれは恐らく明日から、あるいは今からでも使える話しなのだろうと思う。 「この問題はこうだったから当時そうしたくてもできなかった」という気づきを得ることが出来る、そしてその問題はいまでは簡単に解決できるものなのかもしれない。 だからこそ、振り返りが必要であり、見える化が重要なのだと感じる。

だいぶ文章がとっちらかってきたが眠いし雑にまとめてしまおうと思う。

詰まるところぼくたちは真面目にシャローワーク(誰にでも出来て専門性のない作業)に従事しすぎているのだと思う。 マネジメントの本質はそこではなくて問題の本質を露わにし、どのように解決していくかを決め、その結果を振り返るところにあるのだと最近思うようになった。 その結果の一部として同僚や部下などの人を管理する工程が入ることがあるということなのだと。 マネジメントそのものには人を管理する工程は必須ではない、というのがぼくの最近の気づきだ。

実際のところそれが正しいかどうかは知らないがマネジメント=人材管理な印象を強く受けていたぼくにはちょっと新鮮でもっと早くに気づかないといけないことだったと最近反省している。

以上、最近のエモい話しでした。