うぇるそふぃあ ~35歳リーマンの生活収支改善ブログ~

某IT会社で勤める35歳の企画系ヌルリーマンの日常。日々が退屈で、面白いことを失ってしまった僕に「楽しさ」と「驚き」を。自分がテクノロジーやガジェットが好きなのでそれ系の記事が多めになると思います。

「エンジニア」として悩んだと思った時に何度でも読みたい本「エンジニアリング組織論への招待」

今年一番感動した本です。
「エンジニアリング組織論への招待」(by 広木大地氏)

ちょっとだけ真面目な話をさせてほしい。

自分が20代を某通信系企業で過ごしてきて、一番印象に残っている上司の言葉が

「俺たちはビジネスエンジニアであれ」

である。

大手企業で現場もあまりない。個人の中に技術スキルもほとんどない。若手のころからやることと言えば、会議資料や稟議書作成。

それなのに部署の名前はいっちょ前に「技術部」。周りから仕事は何ですか?と言われれば「エンジニアです」と答えるしかない。

そんな自分の中での矛盾を解消してくれた言葉が上記の「ビジネスエンジニア」という言葉である。
ビジネスエンジニアとは何か?結局その上司から明確な回答が与えられることはなかったが、本書とメッセージは通底したように思う。

 

本書もエンジニアリングを対象としている一方で、技術そのものについてはほとんど触れない。

 

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

なぜなら、本書の対象としているエンジニアリング=不確実性を減少することであり、本質的に不確実なものは未来と他人の2つに尽きるからである。

 

未来については、プロジェクトマネジメントとアジャイルプロダクトマネジメントを紹介しながら話が進んでいきます。
プロジェクトマネジメントとは、決まったゴールに向けてチームのリソースを配分し、適切なスケジュールでプロジェクトを効率的に終わらせるための手法であるのに対して、アジャイルプロダクトマネジメントは、決まっていない(不確実性の高い)環境下でチームのリソースを配分し、ゴール自体を実験的に変化させ、環境への適応を図りながら、プロダクトを改善させる手法であると解説している。

具体的な手法として、スプリントを繰り返していくこと、生産性指標としてヴェロシティなどがあげられること、学習をしHow自体を改善していくことが挙げられている。

もう一つの他人については、1対1のコミュニケーションで有効なメンタリングのための技術を紹介しています。

 

メンタリングのポイント

  1. 傾聴を行い、相手が話しやすい環境を提供すること
  2. 問題を明確にし、本人が解決策を考えられるための問い
  3. 心理的に安全な環境を提供すること
  4. SMART(具体性のあり、フィードバックのできる)な行動をとらせること

そして、組織として発生しがちな部署間のやり取りや経営層との認識のギャップを「技術的負債」という言葉を基に説明しています。

特に、設計とは「何かを効率的に処理するために変化させる部分を変化させられるようにし、逆に変化させる必要がない部分を固定し、効率化する」ものである。そのため、変化させる必要がないという判断のもと、固定させたものを変化させる必要が生じたときに技術的負債が発生すると書いている。

逆に、これらの設計がビジネスの状況に適切に機能している場合「アーキテクチャ」と呼ばれ、ビジネスに対して好影響を与える。

そのため、これらの技術的負債が発生しないように要件を考えること、逆に発生しているときにそのインパクトを適切に伝えるようにコミュニケーションをとることがエンジニアのやるべきことであると説いている。

 

正直、一章一章が名著で何度でも読みたいと思える本でした。
かつての上司が語るビジネスエンジニアもまさに、本書の問う「不確実性を適切に対処し、技術をハンドリングするエンジニア」という意味合いだったはずで、彼が背中で教えてくれたものを言語化してくれる書籍でした。

 

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング