エンジニアリング組織論への招待

少し時間ができたので、過去分も含めて読書感想文を挙げていきます。


はじめに

今回読んだ「エンジニアリング組織論への招待」は、非常にボリュームがあり、エンジニアが大切にすべきことのポイントが広範囲に押さえられていて、以前からに取り組んできたことの再認識や、改めて気づかされることなど、示唆に富む内容が多かった。一度読んで終わり、というのではなく、身近に置いておき、何かあれば開く、といった使い方が向いていると感じた。

それだけに、文章が饒舌・冗長で読みにくく、散漫とした印象も受ける点はもったいないと思う。もっとポイントを絞るか、表現を簡潔にしたほうがより読者に伝わるのでは、と感じた。

以下、各章ごとに思ったこと・感じたことを書いていく。

「Chapter 1 思考のリファクタリング

私はソフトウェアエンジニアであり、またエンジニアであることを誇りに思っている。では、エンジニアとは何か。漠然と、「IT技術を使って問題解決を行う」くらいに考えていたが、本書にある「エンジニアリングとは、不確実性を削減し、秩序を作る」という表現は、とてもしっくりきた。

文字で書くと簡単だが、これができないエンジニアは多い。私ももちろん完璧というわけにはいかないが、それでもそれなりに結果を残せるようになったのはなぜか、ということを考えてみた。大きな要素として考えられるのは、サポートのトラブル対応(いわゆるL2、L3の業務)をやっていたことにあるのではないかと思いいたった。

解決すべき問題は何なのか、足りない素材は何なのか、どこに落としどころを置けばよいのか、こういったことを考えて行動することは、本書にある「仮説と検証を通じて、不確実性を下げていく」過程と同等と言えよう。たいていは自分ひとりで解決することは難しいので、上司・同僚、他部門、代理店、お客様といった人たちとコミュニケーションしながら、先に進めなければならない。とても苦労したが、この経験が私のエンジニアとしての土台になっていることを、本書を読むことで改めて認識することができた。

「Chapter 2 メンタリングの技術」

本章は、重要視していたHRTや、先日受けた人間力強化の講習でも取り上げられていた傾聴・共感・アクノレッジメントなど、私も常日頃気を付けていることが多く書いてあった。その中でも、「メンティの成長を考えておらず、「相手の問題をあげつらう」という興奮・享楽に身をやつしているからにすぎません。」という一説はハッとさせられるものがあった。私の中で、時々そういった一面が顔を出すことがあるので、改めて注意しなければならないと気を引き締めた。

また、「自分自身が心地よくいられる思考の範囲や行動の範囲をコンフォートゾーン」という表現があるが、自分自身で意識しないとどうしてもコンフォートゾーンから出ないようになってしまいがちだ。私も以前、ある程度まで役職が上がると、どこか終着点を意識するようになっていたのだと思う。しかし、それは自身の成長を止めることとイコールである。

「Chapter 3 アジャイルなチームの原理」および「Chapter 4 学習するチームと不確実性マネジメント」

アジャイルに関しては、私はCSPO (認定スクラムプロダクトオーナー) の資格を持ってるので、復習という意味合いで読んだ。

以前、プロダクトオーナーとしてスクラム(アジャイルソフトウェア開発手法の1つ)の開発チームと開発プロジェクトに参画したことがあったが、そこで苦労したのは開発チームがプロジェクトスタート時にゴールを設定したインセプションデッキを捨てて、「スクラムのやり方に則ること」を目的としてしまったことである。スクラムは、そのやり方(フレームワーク)に則れば素晴らしいソフトウェアが開発できるわけではない。重要なのは開発チームのメンバーが真摯にお客様と向き合い、限られた時間の中で最適なソフトウェアを探り続けることである(マインド)。そのため、非常に短いイテレーションで検証を繰り返す。スクラムはそのための手法の1つにすぎないが、そこの認識がずれてしまったので、方向を補正するのに大変時間を取られてしまったし、最後はスクラムをやめようとまで思った。(実際にやめた。)

本書を読む中で、その経験を振り返ってみると、開発チームとのコミュニケーションが足りなかったのではないかと思った。当時、「スクラムのルールをよく知らないと発言できない」ような空気が作られていたのもよくなかった。本書でいう「アジャイル教条主義者」による開発チームの支配である。プロダクトオーナーとしては、スクラムマスター(開発チームのメンタリングやファシリテーション役)とコミュニケーションを取り、目的意識のズレと対立図式を解消すべきだったと思い至った。

もし今後スクラムの開発チームと一緒に仕事をする機会があれば、本書を携帯して取り組もうと思う。

「Chapter 5 技術組織の力学とアーキテクチャ

本章では、かなり開発組織寄りと思われる内容が多いが、OKRの箇所はどの部門でも通用する考え方だと思う。目標設定は定量的な項目を入れないと、不透明で考課者の胸三寸という印象が免れないが、数値設定にすると、とたんにノルマ感が出てしまい、味気のないものになってしまう。そこで、自身のミッションと、「何のために」という目的をしっかりと意識したうえで、数値設定することが良いと思った。