Engineering Manager になってから身に沁みた12のアイデアと言葉 part2

2019/12 にこんな記事を書きました。

kths.hatenablog.com

あれから一年たち、日々積み上げた新しいアイデアをみなさんとも共有したいと思います。

システム操作性スコア

私が勤めるスタディストでは、一部のサービスがマイクロサービスとして稼働しています。また、それ以外にも稼働している別プロダクトがあったりと、徐々に組織の管理対象となるサービスの数が増えつつあります。また、今後もその数は増加していくことが予想できます。

2020/12/26に発売されたばかりの書籍『モノリスからマイクロサービスへ』では、マイクロサービスが引き起こす可能性のある痛みの一例として、孤児サービスという言葉が登場します。これは文字通り、所有権や責任を負う人がいなくなってしまったサービスのことで、孤児サービスに対するトラブルシューティングは困難になることが予想されます。単に一部機能の停止で済めばマシですが、セキュリティインシデントにつながる可能性もあるでしょう。

…では組織として、孤児サービスを生まないためにどうすればよいか？という話なんですが、本書ではフィナンシャル・タイムズ社が採用している「システム操作性スコア」という概念が紹介されています。

サービスを運用しやすくするにはサービスとそのチームが実行すべき特定の事柄があるというのが、システム操作性スコアの考え方だ。システム操作性スコアには、チームがレジストリに正しい情報を提供したことを確認することから、サービスに適切なヘルスチェックが行われることを確認することまで含まれる。これらの計算されたスコアによって、チームは修正が必要なものがあるかどうかを一目で確認できるようになっている。

同社では、社内にあるマイクロサービスのシステム操作性スコアをみわたす社内ツールBiz Opsというものを運用し、孤児サービスを生まないよう工夫しているそうです。

SRE の文脈でも、Production Readiness Check（Prduction環境にリリースしてもよいか？のレビューステップをはさむことで、システムの信頼性を制御するプラクティス）の考えがありますが、それをリリース時点のスナップショットとして機能させるだけでなく、継続的なスコアとして扱うアイデアのように思えました。

参考書籍：『モノリスからマイクロサービスへ』

モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド

MVP（Minimum Viable Product）の核となる考えは、はやく実用最小限の機能を出すことではない

『リーン・スタートアップ』が出版されてからというもの、MVP（Minimum Viable Product）という言葉が色々な場面で叫ばれるようになりました。その際に、多くの人は暗黙的に「実用最小限の機能をはやく出すことにフォーカスしよう」と言いたいように思えます。（あくまでも私の観測範囲内では、ですが。）

しかし、MVPにとって本当に大切なことは、学習であり、そのための実験です。学習の過程を手薄にして、実用最小限 "だと思われる" 機能をはやくリリースし続けたとしても、数年後には使われない機能の山が築き上げられているかもしれません。そういった背景から『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』の著者Melissa Perriは、MVPを「学習のための最小の労力」と定義しているそうです。

MVPの核を実用最小限の機能をはやくリリースすること…と理解してしまうと、機能をつくることばかりに集中してしまう、ビルドトラップに陥ります。そんなことを見つめ直させてくれる一冊。

参考書籍：『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』

プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける

（余談）私が数年前に、「リーンローンチパッド」（リーンスタートアップの核となる「顧客開発モデル」を提唱したスタンフォード大学Steve Blank氏が開発したプログラム）に参加した当時を思い返すと、顧客理解をはじめとした学習のプロセスに重きを置かれていて、少しわずらわしく感じたような記憶があります。ですが、あのときの自分の状態や感情こそ、まさにビルドトラップに陥っていたのだろうな、と今なら思えます。

Strategic vs. Tactical Programming

先ほど紹介した、ビルドトラップに陥らないようにする考え方は、そのままソフトウェア開発のフェーズでも似たようなことが言えます。

『A Philosophy of Software Design』では、ソフトウェア開発において重要な哲学が多く紹介されていますが、中でも私の気に入った考えの一つに「Strategic vs. Tactical Programming」というものがあります。Tactical Programmingはとにかく動くソフトウェアを開発することに意識をむけるアプローチ、Strategic Programmingは設計をよりよくすることに重きをおいたアプローチです。Strategic Programmingは短期的にはより多くの時間を要しますが、そのために要した時間や完成したコードは、資産として徐々に積み上がり、中長期で、より早く変更することを可能とします。一方でTactical Programmingのアプローチを続けると、皆さんご存知の技術的負債として我々を徐々に苦しめることになります。

Most programmers approach software development with a mindset I call tactical programming. In the tactical approach, your main focus is to get something working, such as a new feature or a bug fix.

（中略）

The most important thing is the long-term structure of the system. Most of the code in any system is written by extending the existing code base, so your most important job as a developer is to facilitate those future extensions. Thus, you should not think of “working code” as your primary goal, though of course your code must work. Your primary goal must be to produce a great design, which also happens to work. This is strategic programming.

機能開発の意思決定をただはやくすることに集中してしまうビルドトラップもあれば、機能をとにかくはやくつくることに囚われるビルドトラップもあることがよくわかります。

参考書籍：『A Philosophy of Software Design』

A Philosophy of Software Design

余談ですが、この両者のアプローチをみたときに、「でもFacebookは "Move fast and break things" と言っているじゃないか」と思われた方もいるのではないでしょうか。（読みながら、私はそう思っていました。事業としてはやく成長するために、ときに近視眼的な動き方をする必要もあるのではないだろうか、と。）『A Philosophy of Software Design』では、まさにこのFacebookがどうチームの意識を変えたか？また、そもそもTactical Programmingのアプローチをすることをどう解釈すべきか？といった考えについても紹介されているので、続きが読みたい方はぜひ本書をお買い求めください。

知識ポートフォリオ

みんなだいすき『達人プログラマー』の第二版が昨年11月に発売されました。達人プログラマーでは個のプログラマーとして、どう熟達していくかについて多くの示唆に富んだ考えが共有されていますが、達人のチームがどうあるべきか？についても言及されています。その中でも私のお気に入りのアイデアが、チームの活動を「知識ポートフォリオの充実に向けて計画する」というものです。

知識ポートフォリオは、金融ポートフォリオのように知識を組むというアイデアです。

1. 真面目な投資家は習慣的に定期的な投資を行います。
2. 分散投資は長期的な成功の鍵です。
3. 頭の良い投資家は、堅実な投資と、ハイリスクでハイリターンな投資でポートフォリオのバランスをとっています。
4. 投資家は利益を最大化にするべく、安く書い、高く売ろうとします。
5. ポートフォリオは定期的に見直して再分配するべきです。

この考え方は個人の生存戦略としても大切ですが、チームとしても実践することができます。チームの活動をポートフォリオ的に捉え、将来にむけた知識獲得の時間を投資できているか？を見直すとよいでしょう。

参考書籍：『達人プログラマー(第2版): 熟達に向けたあなたの旅』

達人プログラマー(第2版): 熟達に向けたあなたの旅

昨年、以下の記事にて取材いただいた際に、「パワポカラオケ」という取り組みをやっていることについて紹介しましたが、これも知識ポートフォリオの一つなのだろうな、と自分で納得しました。

重要さが増すサービスの「信頼性」を高めるためにSREエンジニアたちが続ける挑戦：CodeZine（コードジン）

マネジメント人材指向

マッキンゼー・アンド・カンパニー社が1997-2000年にかけて行った、マネジメント人材の獲得・育成に関する調査・研究の成果をまとめた書籍『ウォー・フォー・タレント』によると、「マネジメント人材指向こそ経営層の要件」だといいます。本書著者は調査を行う以前、「高業績の企業と平均的な業績をあげている企業とでは、優れた人事プロセスの有無が差分だろう」と予測していましたが、蓋を開けてみると、人事プロセスには両者で大きく差がなく「マネジメント人材指向が組織に根付いているかどうか」が両者を分かつポイントだったとのこと。

マネジメント人材指向とは、「あらゆるレベルの業務に優秀な人材を揃えることが、他社よりも業績を上げるための方策である」という、確固たる信念です。そして、そのためにはマネジメント人材の獲得や育成を人事部に任せるのではなく、すべてのリーダーが自分の仕事としてマネジメント人材と向き合う必要性について本書では述べられています。これには採用だけでなく、育成・確保（その人に留まってもらうこと）なんかも含まれます。

今や多くの企業で、現場で採用を主導していくことは当たり前になりつつあるように感じていますが、その後の育成や確保については手探りの会社も多いのではないでしょうか。『ウォー・フォー・タレント』では、マネジメント人材の育成に取り組む際の心構えだったり、人材管理の選択と集中といった考え方についても様々な企業の事例をもとに紹介されています。

参考書籍：『ウォー・フォー・タレント』

ウォー・フォー・タレント ― 人材育成競争 (Harvard Business School Press)

システムとして自分を扱う

『最難関のリーダーシップ』によると、世の中には技術的問題と適応課題があるといいます。前者は複雑で重要な場合もあるものの、すでに解決策がわかっていて既存知識で対処可能なもの。後者は人々の物事の見方（優先事項、信念、習慣、忠誠心など）を変えなければ対処できない問題です。また、この両者は常に明確に区別できるわけではなく混ざり合っている状態であることが大半だと筆者はいいます。

そして適応課題に対処するには、人々の物事の見方を変える必要性がありますが、その中に自分が変革対象として含まれる場合があります。

そのとき俯瞰して全体最適な行動をとるためにはシステムとしての自分を理解することが大切です。いつも経験にもとづく直感だけで意思決定をしていては、自分自身の直感によって方向性を見失うことがあるからです。

システムとして自分を扱うには、自分の中に多くのアイデンティティが存在することを認めることが重要だと著者は説きます。自分の中には複数の自分がいて、一つの自己で成り立っているわけではないということです。

「今の私にとって、ある特定の忠誠心や価値観が最も重要であるこの状況においては、これが自分だ」というように状況に応じて使い分けるのではなく、単に「これが自分だ」と言えたら、自分にとって（また介入を行っているシステムにとって）ずいぶん簡単なことだろう。しかし、今の自分だけでなく、時間とともに自分がどのように変化していくのかも含めて自分を形づくっている複雑さを理解すれば、組織で効果的に変革をリードする選択肢がより多く得られるのだ。

チームや組織をリードする際に、自分が周囲に対してどう振る舞うべきか、について書いている書籍は多いですが、自分自身もその対象として扱う著者の考えは、私にとっては納得感のあるものでした。

参考書籍：『最難関のリーダーシップ』

最難関のリーダーシップ ― 変革をやり遂げる意志とスキル

力の防御的な行使と力の懲罰的な行使

問題を解決する際に、どうしても対話の機会が生まれない・その余裕をすぐさま確保できない場面では、何かしらの力を行使する必要に迫られるかもしれません。しかし力の行使の仕方を間違えると、事態をより悪化させてしまう可能性があることは頭に入れておくべきでしょう。

　「力の防御的な行使」は、被害あるいは不正を防ぐことが目的だ。「力の懲罰的な行使」は、悪事と思われる行為をはたらいた個人に苦痛を与えることが目的だ。子どもが道路に駆け出したときにケガを防ぐためにつかむのは、防御的な行動である。一方、懲罰的に力を使う場合は肉体的な攻撃あるいは心理的な攻撃というかたちをとるだろう。たとえば子どもをぴしゃりと叩いたり、「どうしてそんなバカなまねをする！恥ずかしいと思わないの！」などと叱責したりする。

　力を防御的に使う場合は、相手の命あるいは権利だけに意識が集中し、相手に対して、あるいは相手のふるまいに対して評価を下してはいない。通りに駆け出そうとした子どもを非難したり責めたりはしないのだ。

私がすきな『メリットの法則　行動分析学・実践編』という書籍でも、行動分析学における好子と嫌子（メリット・デメリットのこと）の行使について言及があり、嫌子を利用した弱化（アメとムチの「ムチ」に相当するもの）には「行動自体を減らしてしまう」「何も新しいことを教えたことにならない」「一時的に効果があるが持続しない」といった副作用があることが記されています。この言及からも、力の懲罰的な行使を原則的に使用しない大切さがよくわかりますね。

参考書籍：『ＮＶＣ　人と人との関係にいのちを吹き込む法　新版』

ＮＶＣ　人と人との関係にいのちを吹き込む法　新版 (日本経済新聞出版)

いいアイデアといいスタッフ、どちらが大切か

ウォルト・ディズニー・アニメーション・スタジオ及び、ピクサー・アニメーション・スタジオの社長であるエド・キャットムル著『ピクサー流 創造するちから』にて、「いいアイデアといいスタッフ、どちらが大切か」という問いに対する考えが述べられています。

私にしてみれば、答えは歴然としている。アイデアは人が考えるものだ。だからアイデアよりも人のほうが大事だ。

また、単に良い人材が集まっているだけでなく、人同士の相互作用もあわせて大切であることも忘れてはいけないでしょう。

この教訓は重要だから繰り返そう。アイデアをきちんとかたちにするには、第一にいいチ ームを用意する必要がある、優秀な人材が必要だと言うのは簡単だし、実際に必要なのだが、本当に重要なのはそうした人同士の相互作用だ。どんなに頭のいい人たちでも相性が悪ければ無能なチームになる 。したがって、チームを構成する個人の才能ではなく、チームとしてのパフォーマンスに注目したほうがいい。メンバ ーが互いを補完し合うのがよいチームだ。当たり前のように聞こえるかもしれないが、私の経験から言って、けっして当たり前ではない、重要な原則がある。いいアイデアよりも、適切な人材と適切な化学反応を得ることのほうが重要なのだ。

言うは易く行うは難しですが、チームとして成果を出すことを探求し続けたいものです。

参考書籍：『ピクサー流 創造するちから』

ピクサー流　創造するちから

フィードバックが時に逆効果となる

みなさんの会社でも、社員の業績評価の一貫で、何かしらのフィードバックを行うことが推奨されているのではないでしょうか。しかし、よかれと思い、行ったフィードバックが、時に逆効果となってしまうこともあります。

本稿の筆者の一人クルーガーは、二〇年以上前に、フィードバックがもたらす効果に関する実験六〇七件を分析したところ、三八％のケースでパフォーマンスの低下を招いていることを発見した。これは評価内容が肯定的か否定的かに関係なく、主に「そのフィードバックによって対象者の自己認識が脅かされる」場合に起きていた。

フィードバックの提供（たとえ肯定的なものでも）がしばしば逆効果に働く理由の一つは、「監督して判断を下すのは、上司だ」ということを示唆するからだ。それによって、部下はストレスを感じて防御的になる場合があり、そうなれば他者の視点を受け入れにくくなる。

さて、ではフィードバックを行わずに、単に傾聴だけすればよいのか？というと、そうではありません。

業績評価に話を戻そう。もちろん私たちは、フィードバックをやめて、ただ傾聴すべきだと主張しているわけではない。それより、まずは自身の体験を語る部下の言葉に耳を傾けることで、彼らは心理的安全性を感じて身構えなくなり、フィードバックがもっと生産的になるだろうということだ。

フィードバックを行う場では一方通行にならないことが大切で、なおかつ、まずは傾聴することの大切さを示している言及ですね。

参考書籍：『ハーバード・ビジネス・レビュー マインドフル・リスニング』

ハーバード・ビジネス・レビュー[ＥＩシリーズ] マインドフル・リスニング

いかなる情動にも、一貫した反応は存在しない

古典的情動理論では、人は怒っているときには顔が赤くなる…といったように、特定の情動を特定の動きのパターンに見出しますが、この考え方は近年見直されてきています。『情動はこうしてつくられる――脳の隠れた働きと構成主義的情動理論』によると、情動についての一貫した反応は存在しないといいます。

被験者の誰もが、「腹が立つ（angry）」「悲しい（sad）」「怖い（afraid）」などの情動に関連する用語で自分の感情を伝えようとしたのだが、それらの用語は必ずしも同じ意味では使われていなかった。悲しさと怖れを質の異なる情動として経験するなど、きめ細かな区別をする被験者もいた。しかしその一方、「最低に感じる（Ifeelcrappy）」（あるいはより科学的に言えば「不快感を覚える（Ifeelunpleasant）」）という意味を伝えるのに、「悲しい」「怖い」「不安な（anxious）」「落ち込んだ（depressed）」などの用語を十把一絡げにして使う被験者もいた。同じことは、幸福（happiness）、落ち着き（calmness）、自尊心（pride）などの快い情動にも当てはまった。こうして七〇〇人のアメリカ人を対象に実験したあと、われわれは、自己の情動経験を区別するあり方が、人によって著しく異なることを発見した。

マネージャーのお仕事は、人とコミュニケーションする機会が多い傾向にあると思いますが、つい話しながら相手の感情を何かしらの反応から読み取ろうとしてしまったり、あたかも自分が相手の情動を理解できていると思いこんだり、そういったステレオタイプに囚われないよう気をつけねば…と思い直させられました。

参考書籍：『情動はこうしてつくられる――脳の隠れた働きと構成主義的情動理論』

情動はこうしてつくられる――脳の隠れた働きと構成主義的情動理論

組織における個人は、自分のチームやサイロの心地よさのなかでいちばん簡単に完了できる作業を優先する

昨年発売された『みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた』は、「手法としてのアジャイル」と「マインドセットとしてのアジャイル」の違いについて言及している名著です。本書では、マインドセットとしてのアジャイルを実践するにあたって、組織に存在する重力について解説しています。その中のひとつが、「組織における個人は、自分のチームやサイロの心地よさのなかでいちばん簡単に完了できる作業を優先する」というものです。

どんな企業でも、社内でのコラボレーションを促進したい意識があるかと思いますが、それが難しいのは、こういった組織内の重力が存在しているからだといえます。重力の存在を意識しつつ、「報告と批評の文化」から「協調的でアジャイルな文化」にするための転換を行っていく必要性について本書では説かれています。

参考書籍：『みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた』

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

フィナンシャル・タイムズ紙アメリカ版の編集長が記した『サイロ・エフェクト　高度専門化社会の罠』という書籍では、Facebookが、どのようにサイロ化を防いでいるか？について述べられているので、ご興味ある方はこちらもぜひご一読を！

人が変わっていくことを理解する

任天堂の元社長、岩田聡 氏について記した『岩田さん: 岩田聡はこんなことを話していた。』に、岩田さんが社員全員と1on1を実施している背景について書かれた箇所があります。

岩田さんのような方でも「面談してはじめてわかったことがものすごく多かった」とお話されているのが、とても印象的でした。そして岩田さんが社員との面談をしている理由については、次のように記されています。

わたしは、自分がどんな会社で働きたいかというと、「ボスがちゃんと自分のことをわかってくれる会社」や「ボスが自分のしあわせを考えてくれる会社」であってほしいと思ったんですね。

そして、わたしは「人は全員違う。そしてどんどん変わる」と思っています。もちろん、変わらない人もたくさんいます。でも、人が変わっていくんだということを理解しないリーダーの下では、わたしは働きたくないと思ったんです。

自分が変わったら、それをちゃんとわかってくれるボスの下で働きたい。だから、自分も社員のことをいつもわかっていたい。それが面談をはじめた動機です。たいへんだけど、自分の得るものも多いなとわかりました。

近年、急速に1on1が注目されているように思えますが、やはり大切なことは相手を理解しようと思いやる気持ちなのだと改めて実感させられた一文でした。

参考書籍：『岩田さん: 岩田聡はこんなことを話していた。』

岩田さん: 岩田聡はこんなことを話していた。 (ほぼ日ブックス)

1on1に限りませんが、何事も当たり前になってくると、つい人間として大切にしたい、こういった価値観や考えをおざなりにしてしまいがちです。岩田さんのように、常に相手に対する想像力をもって、コミュニケーションを続けることを目指したいものです。そんな私の些細な決意表明をしたところで、本ブログを締めくくりたいと思います。 約10,000字の長文を最後までお読みいただき、ありがとうございました。

おまけ

本記事で紹介した書籍を読むきっかけとなったブログを共有します。みなさんの今後の情報収集の一助となれば。

• 2018年振り返り | Taichi Nakashima
• VPoEとしてこの3年間を振り返って - エムスリーテックブログ