ugo's 読書感想文

読んだ本のまとめや学んだことを書いていきます。

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

エンジニアリング組織論への招待を読んだので、学びをまとめておこうと思います。

概要

前回の記事に引き続き、エンジニアという立場から見た、マネージングや組織論というところで基礎を作るためにまずはがむしゃらなインプットをしようということで相談したところ、当書を紹介していただいたので読み始めたのがスタートでした。

300ページもの本でボリュームもあり読み応えがある本でした。 今回は、全くの無知という訳ではなく、前回の本であるエンジニアリングマネージャーのしごとを読んでいた事もあり、多少被る知識の部分があったということで、読みやすい部分もあれば、アジャイル開発、スクラムなど体制の話も盛り込まれていた事もあり、少し調べながら読む必要がある部分もあったので、良い負荷がかかったインプットができたと思います。

1回読んだだけでは噛み砕けていない部分もあるので、期間を空けてもう1回軽く通しで読んでみるなどをしてみようかと思います。

当書を通して得る概念

エンジニアリングとは、「不確実性を解消すること」です。

不確実性というのは、抽象度の高い事柄であり、人が不安に感じる根源のこと。 不安に感じる要因としては、未知のものに対して無意識にでも恐怖を感じるという人間の本能からきており、「避けたいもの」という認識が働く事柄。

この不確実性が高い状態のことをエントロピーが高い状態と言います。 逆に少しでも不確実性が低くなると、エントロピーが低い状態に近づくという感じです。

このエントロピーを下げていく工程をエンジニアリングと言い、そのための手法が全体を通していろんな観点から、いろんな手法が書かれています。

構成

1~4章では、5章に向かって下地を固めていくという構成になっています。

1章では、全ての前提の知識となる事柄に触れ 2章で相手との対話について触れ 3章ではチームでの取り組みについての手法や歴史について触れ 4章ではその手法を使ってチームへの作用の解説 という構成になっています。

5章で組織という大きな枠組みの中でどのような問題が存在していて、どのように不確実性の解消をしていくのかを紹介しています。

用語ピックアップ

経験主義と仮説主義

不確実性という問題を解決をするためには、思考のリファクタリングが必要です。 その手法として以下のものがあります。

経験主義

情報を得るために、行動を起こしてその結果から問題解決に向かう手法

仮説主義

問題に対して、少ない情報から全体像を想定し、その像を確認するで問題解決に向かう手法

4つのイドラ

https://studyhacker.net/columns/omoikomi-dasshutsu

認知の歪み

ネガティブな感情により生まれる思考 以下のような、個々人の持つ印象や感情による歪曲された認知

ゼロイチ思考

「常に」「全部」「決して」といった断定的な思い込み 中間にあるグラデーションを認識できない思考

一般化

小さい事例をあたかも全体の事例のように認識し 一般化させてしまうことにより、大きな問題へと発展させてしまう思考

これはレッテル貼りへ発展し、一般化させた結果 当てはまる人はこうであるに違いないといった決めつけが発生する。 こういったところから認知の歪みが発生する。

すべき思考

Should構文で考えてしまう思考。 〜すべき、〜であるべき などの固定観念から自分自身を追い詰めてしまう思考。

選択的注目

朝の占いなどで、ラッキーカラーを知った時にその色のものがよく目に入る現象のネガティブバージョン。 人に対して、一度ネガティブな印象を持つと、その人が何をしてもネガティブに捉えてしまうという認識。

結論の飛躍

例えば、既読スルーするつもりがなかった相手に対して、 ネガティブな思い込みをすることによって発生する認知の歪み。

環境不確実性

行動と観察に生じる不確実性の種類 「未来」という不確実性からくる不安が生まれる。 未来が近づき、現実に近づくにつれて確実なものへと変化していく。

通信不確実性

コミュニケーションに生じる不確実性の種類 「他人」という、自分がコントロールできないものに対する不確実性。 自分が伝えたことを100%認識してもらう事は不可能であると同時に、 どれくらいの理解度なのかを押し測る事も不可能であることから不安が生じる。

不安への対処法

不確実なところから、不安な事柄へと発展します。 そして人には、不安なものへの恐怖がありそれを避ける傾向があります。 これをタスクベースで落とし込むと、不確実性の高いタスクに対して恐怖を感じることになります。 結果として、確実性の高いタスクを優先的に行おうとしてしまう傾向が現れます。 これによって不確実性なタスクが最後に残り、スケジュールギリギリになって不確実なものが残り、見積りとズレてしまうという事象が発生してしまいます。

この現象を回避するために、不確実性の高いタスクを優先的に行うことでエントロピーを高めることで不安を解消するようにするのが良いです。

アジャイル

ここで、アジャイルウォーターフォールの話が出てきます。 ソフトウェアの開発ではよくウォーターフォール開発があげられますが、アジャイル開発での成功確率の方が高いそうです。

プロジェクト初期に関しては、まだエントロピーがかなり高い状態で始まります。 その状態でプロジェクトを最後まで構想し作り始め、最後の最後に結局顧客のニーズと異なるものができてしまったという事例が多くなってしまうのがウォーターフォールでの開発。

対して、アジャイルであれば、マーケットフィットを模索しながらになるため、小まめの調整を行う事が多いことから、大きく失敗するということをなくし、コストを最小限に抑えることができるという点でアジャイルの方が成功率が高いということになります。

プロジェクトマネジメントとプロダクトマネジメント

まず、マネジメントの言葉の定義として 対象となるものの資源・資産・リスクを管理し、効果を最大化する とあります。

プロジェクトマネジメントに当てはめると 「対象となるプロジェクトの資源・資産・リスクを管理し、効果を最大化する」 プロダクトマネジメントだと 「対象となるプロダクトの資源・資産・リスクを管理し、効果を最大化する」 となります。

プロジェクトは、はじめと終わりがあり、終わりに向けて取り組むのに対し プロダクトは、はじめはあれど終わらないようにすることが目的となってきます。 その点で、不安となる要素が変わってきます。

ウォーターフォールアジャイル

上記によって、ウォーターフォールが悪というような形になってしまっていましたがそういう訳ではないです。 どちらが良いというにはまず、この二つを比べるために、この二つが同等の性質のものとして捉える必要があります。 そうすると、この二つの不安要素である不確実性のスコープを見比べる必要があります。

ウォーターフォールで生み出される不確実性 - 方法不確実性 - 目的不確実性 アジャイルなチームで生み出される不確実性 - 方法不確実性 - 通信不確実性 - 目的不確実性

上記の通り、アジャイルが持つ不確実性は、ウォーターフォールが持つ不確実性のスコープを包含しています。 それぞれが不確実性の解消の目的が異なるため(プロジェクトとプロダクト)、比べられるものではないのです。 具体的に落とし込むと、「何を作るか考える人」と「どう作るか考える人」との対立が発生してしまうのです。 それによって引き起こされる認知の歪みにより、通信不確実が方法不確実へ発展してしまうことがありえます。

組織化

セルフマスタリー

まず、チームとして理想の形態というのは各々が「セルフマスタリー」状態になることです。 つまり、自分で目標に向かって行動できているという確信が持てていることになります。 未来の自分が今の自分をメンタリングしているような状態になることが良い状態になります。 将来の目標がハッキリしていて、すでに道筋が見えていて、そこに向かって行動している状態ですね。

SECIモデル

Socialization(共同化) Externalization(表出化) Combination(連結化) Internalization(内面化) の構成から成るモデル。

問題意識への暗黙知から形式知への浸透が広まっていくモデル。 明文化されていない知識を「暗黙知」といいます。 逆に明文化されている知識を「形式知」といいます。 この暗黙知と広めていくことが組織の発展に繋がります。

例えば、自分達が見落としがちな問題に対して、 見落とさないようなルールを作って実践していく中で、メンバーの中での暗黙のルールとなる。 そうしているうちにルールにしなくとも、組織内で同じ問題に対する対応の意識というのが浸透することで、 また新たな問題へ目を向けられるようになるといった好循環を作る事ができるのである。

自分のチームでもこれは実践していて、定期的にエラー通知の結果をチーム全員で確認し、対応をどうするかと言った話し合いをし形骸化しがちな問題に対して意識を向けるという流れができて、組織全体へと広まっていくというような循環を作っていっています。

しかし、これには時間もかかるし、根気のいることなので実施するにはそれなりの覚悟が必要なので 効果が出るまで粘り強く広めていく必要がありそうです。

技術負債

技術的負債がないプロダクトは存在しないと言われるほど、プロダクト開発にはつきもので これに対処するには、経営層と非経営層とでの情報の非対称性が存在する。

これについても、負債についての可視化と、工数やコストといった観点で不確実性を解消する必要がある。 可視化については、ソースコードの複雑性の証明(if分岐の数など)、コードの依存関係の証明、バージョン管理などによる誰がいつどこを触ったかなどの証跡などの証明によって可視化する事で経営層への認識を伝えることへの助けになります。

さらに、お互いの認識を共通のものにするために「ユビキタス言語」を作成したり、経営層がどういう戦略を考えているかの透明化をすることで、それをアーキテクチャに当てはめるという逆コンウェイ作戦といった手法を取る事を検討できます。

また、ビジネスフェーズに合わせて、アーキテクチャの再設計(モノシリックからAPI化であったり、マイクロサービス化といった)を行うことで、いかにしてコストを減らすための技術負債を少なくするかといった戦略を考えていくこともできます。

まとめ

当書を通して、かなり自分の中で組織やマネジメントという面の知識の糧になったと思います。 他にも - アジャイルの誤解 - アジャイル経営学に取り込まれていた時の歴史 - スクラムによるタスク管理と計測 - 認知の歪み、通信不確実性に対する対処法 などなど、非常に参考になる事柄が多く書かれており、また他の本を読んで知識や実践を通した上で、もう一度読みたい本だと思いました。

今、恐らく組織論という不確実性を抱えている自分のような人がターゲットになっているような本だと思うので、同じような境遇な人は是非一度手に取ってみて欲しいです。

エンジニアリングマネージャーの仕事

エンジニアリングマネージャー(以降、EM)のしごとを読んだので、総括していこうと思います。

経緯

エンジニアとして仕事をするにあたって、 EMの仕事を知っておくことで相互作用を起こすような働きができたらと思ったところが始まりでした。

現在自分はEMではなく、EMとしての知識はほぼ0なので、知識だけでも少し詰め込まねばというところでググったところ ドンピシャなタイトルのこの本が出てきたので読み始めました。

どうせ読むならメモ代わりに、自分が参考になりそうなところを書いていこうと思ったのでピックアップして記事を書くことにしました。

読んでみて

感覚的に分かっていた事は言語化されていて、 半信半疑だったものは明確になりました。

自分は全然知識がなかったので どういったことをマネージャーが行うのか どういう考え方が必要なのか などが断片的なものでしか見聞きしていなかったので 知っているものも含めて体系的に知る事ができたのは良かったと思います。

教育や独学で学んできたエンジニアリングと違って、EMは事前の学習などがない状態で就任する人が多いです。

何をしたらいいのか、どんな問題が待ち構えているのか、どのように解決していくのかというのが未知の状態で進むことが多く、 この本で事前にある程度事前学習できたら、少しでもそのキャリアを諦めないように進めるような道標が詰め込まれている本になっています。

ただ、マネージャーとしてすでに経験のある人にとっては既知の情報が多いかと思うので、あくまでこれから就任すると言う人や、就任直後の人向けの内容になっているのではないかなと思います。

要所ポイント

マネージャーのアウトプット

本書の中で一貫して使われる言葉です。

マネージャーのアウトプット = 自分のチームのアウトプット + 自分が影響を与えた他のチームのアウトプット

1on1

マネージャー就任時にまずやらないといけないこと、かつ継続して行っていく必要のある最重要事項です。 何より情報が必要な仕事であるため、1on1から情報を集めていく必要があります。 情報というのは

  • チームメンバーの考えや感情、性格
  • プロジェクトの進行状況、ボトルネックとなっている部分、プロジェクトの文化
  • 上司が持つ「組織の中での自分の役割」

こうした情報を週に1度、1on1を設定し、通して集めていき、適用していくことが理想となります。 就任直後や、入社直後のマネージャーはプロジェクトの状態が全く頭にない状態でスタートするため、情報収集のため、この辺りから始めるのが良いです。

上司との1on1

上司との1on1では、上司から言われる前の行動によって、より成長の機会を増やすことに繋がります。 - 組織内で1階層上がったレベルでの懸念事項について話す - 他のチームへの状況の確認ができ、アドバイスをする機会を得ることで、上司を助けることができる - 自分の興味が現在の業務の範囲外にもあるということを伝える などなどができます。

自分の状況、関心を伝える上で、週次の1on1の前に30分程度サマリーを作成する時間を設けるのは良い方法です。 その中に、(前回からの)進捗、問題、問題へのアプローチ、メンバーの状況を書き連ねておくのが良いです。 終わったら上司に送るなどをしておくと良いです。

ナッジング

EMとしての自分の観点を提供することで決定に影響を与えること。 意思決定を下すわけではなくても、決定に影響を与えることができるため、 自由に意見ができる時はその事を念頭に置いておく必要があります。

委譲

タスクの責任を他人に委譲することを指します。 委譲には、アンチパターンが2つあります。 - 委譲できてないパターン - 丸投げパターン

委譲できていないパターン

優秀なエンジニアからEMになった時になりがちなパターン。 自分がやった方が早いであったり、精度を高められるという点から、重要な部分は自分でやってしまうという状況。 これにより、中途半端な委譲によって仕事の品質が下がりイライラしたり、メンバーも信頼されていないと感じることに繋がります。 イライラしたからといって、スタッフに委譲したタスクを取り戻すようなことをする事も良くないことです。

丸投げパターン

逆に、委譲し切ってしまい、タスクの存在すら忘れてしまうパターン。 これによって、タスクの状況も忘れられ、品質の管理もされないため、品質が保証されず期限も守られないということになり、お互いに良くない状況に繋がります。

説明責任

上記のような極端なパターンがアンチパターンになるため、バランスを取る必要があります。 そこで出てくるのが説明責任になります。 説明責任とは、タスクを求められる品質で完了させる責任を持つということ。 EMとしては、この説明責任を持ち続ける事が理想となります。

対となる言葉に、実行責任があります。 タスクを実際に自分で行うことです。 実行責任は、スタッフに委ねられるものになり、スタッフにとってチャレンジングなくらい委譲されるものであるべきです。 そうすることで、スタッフも挑戦し、成長することで、一緒に成し遂げられるようになります。

欲求の階層

上昇思考の強い人は今の仕事をより良くしようと思っています。 エンジニアのスタッフの人たちもそのように感じることが多いです。 その人たちにEMの立場からできることとして、マズローの欲求階層に当てはめて考えることができます。

  • 生理的欲求: 自分がしたことへの適性な給与が欲しい

  • 安全欲求: 安定安全な労働環境が欲しい

  • 所属の欲求: チームや上司といい関係を築きたい

    • EMができること: ・自分とスタッフと組織をうまくつなぎ、チームが大きな何かの一部であると感じられるようにする。
  • 承認欲求: 自分がしたことへの評価を公式・非公式双方でしてもらいたい

    • EMができること: ・賞賛と批判を通して、確実に評価する。 ・スタッフのレベルに合わせて職位と責任を持たせる ・スタッフが自信を深め能力向上できるように指導と誘導
  • 自己実現欲求: 継続的にスキルの向上のため挑戦していきたい。次のキャリアがあるというのを実感したい。

    • EMができること: ・トレーニングやカンファレンスへの参加を通して、新しいスキルを学ぶための機会の提供 ・スタッフが選ぶ方法で問題解決への自由を与える

最近接領域

学習者が「好奇心」に任せて上達することができるのが理想の形になります。 最近接領域とは、タスクの難易度の一つの領域を意味するもので、以下の三つの領域に分けられます。 - 学習者が支援なしにできるタスク - 学習者が支援ありでできるタスク (ここが最近接領域) - 学習者が支援ありでもできないタスク

この最近接領域のタスクを行うためには 「タスクの完成を支援する豊富な知識を有する適任者」 の存在が必要です。

タスクレベルで言うと、難易度の高いものに対してはペアプロなどを通してやってみるのもオススメされています。 これによって、ジュニアな人はプログラミングスキルが向上し、シニアな人はメンタリングのスキルが向上します。

キャリアレベルで言うと、自分の目指す最終ゴールに対して、いきなりそこに向かうのではなく、ステップ形式でサブゴールを決めて、順序に沿ってレベルアップしようという考えを取り入れます。

例えば 「国際的なカンファレンスで話す」という目標に対し -> そのレベルで講演するのに必要な話すスキル -> 国際的なカンファレンスで興味を引けるプロジェクトに取り組む といったゴールを用意し、最終的な国際的なカンファレンスで話すことを実現するということです。

大聖堂とバザール

このモデルのイメージに近いものは、トップダウンボトムアップに近しいものを想像してもらうのが良いかと思います。

個人レベル

大聖堂モデルとバザールモデルは個人レベルでも当然当てはまる考え方で 大聖堂モデルのような考えの人もいれば、バザールモデルのような考えの人もいます。 ただ、そこに良いも悪いもなく、個々人の考え方によって、マネージャーとして適切な委譲、与える機会、働く環境を考える必要があります。

大聖堂

プロジェクトの保守管理は、長いプロジェクトになればなるほど、初期に関わっていたメンバーやコアなメンバーによって意思決定が行われ、他の意見などの雑音を少ない状態で、しっかりと管理されているような状態です。

エキスパート気質なところが多く、深く学ぶことを得意とし、深く学ぶまで新しいものに手を出さないようなタイプです。 自分がエキスパートとなった領域を他の人に伝えることで恩恵をもたらし、楽しみます。

バザール

プロジェクトの保守管理は変化が起こるものとして捉え、その中でバグが出たとしても多くのコントリビュータによって、即座に対応できるという考えの元、管理する状態。その方がメンバーのモチベーションも高まるとされている。

多くの新しいものを試したがります。それに伴って、プロトタイプなども構築しては捨てるというような試行を繰り返すことが好きなタイプです。大聖堂モデルとは違って、変化を好むタイプなので、長期に渡るプロジェクトというよりは定期的に考えが異なるようなプロジェクトへの機会を持たせるのが良いです。

機密情報

当然ですが、情報の共有には非常に慎重になる必要があります。 1on1を通して話したこと、たまたま立ち会った立ち話で聞こえてきた話、組織の決定について 全てにおいて誰にどのタイミングで伝えるか、もしくは伝えない方がいいのかといったことについては細心の注意が必要になります。

これも三つの領域に分けて考えると分かりやすいです。 - 完全機密: 1on1などの関係ある特定の人以外には知られてはいけない情報。 - 密閉箱: 存在は知っているが、詳細は知るべきではないこと。(例えば、給与テーブルなどは誰もが知っているが、個人の給与については知られてはいけない) - 解放箱: みんなに知られるべき、知られても良い情報

PIP

この概念は、日本にはないものだったので少し衝撃的だったため書こうと思いました。 人が去っていくことは、避けられないことであり、受け入れるしかないことではあるのですが それにも2つの原因があります。 - 自発的な離職 - 不本意な離職

になります。 前者は説明がなくても理解はできるかもしれないですが、後者については日本においてあまり意識しないこともあり、想像し難いものかもしれないです。 PIPは、Performance Improve Plan の略で、不本意な離職の際に行われるものです。

パフォーマンスの悪いスタッフに対して、改善提案を行い、改善が見られなかった場合に解雇や契約解除ということにすることを意味します。 しかし、これは最終手段なので、あらゆる他の手段で改善を試みて、改善が見られなかった場合に行われるものになります。

PIPを行うにもいくつか注意を払う必要があります。 PIPの内容では、その人がなぜPIPの対象になってしまったか、いつまでPIP期間となるかなどが記載されるのは当然ですが、どうなったら改善されたかということの記載と、その改善はその人にとって無理難題なものではないことが明確になっていることが重要になります。

まとめ

自分にとって特に重要そうな箇所についてピックアップしてメモとして書いたものですが それ以外にも参考になる内容が多く、入門としても良い本だと思いました。

将来EMとしての道に進むかどうかは別として考え方を知っておくのは 誰にとっても損にはならないと思うので、時間に余裕があって考え方に幅を広げたいと思う方は読んでみても良いかと思います。