駆け出しエンジニアリングマネージャーの苦しみ

はじめましてkaibaと申します。
小さめのスタートアップで働いてみたくなり、2018/4に小さな不動産ベンチャーに転職しました。
「おいどんに管理職は無理でごわす！　技術で食っていくぞ！」 と長らく思っていたのですが、
気づいたらエンジニアリングマネージャーをやるようになりました。

新米エンジニアリングマネージャーが、当然一筋縄では行かずもがき苦しみながら進んでいる、という話をします。
(なので、あまり学びはないかもしれません…)

自己紹介

• 技術も好きだけど、ものづくりのほうが好き！　土日もプログラムを書きます！
• プログラムだけじゃなく電子工作や3DCGや絵画や料理にも興味がある
• それ故、できれば全部自分でやりたく、カバー範囲が広いが深い知識はない
• 言語や手段にはあまりこだわりはなく、最良の手段を選びたい
• より多くの人に喜んでもらいたい。無駄なものは作りたくないし、仕様の段階から一緒に最良を追い求めたい。
• 犬派で本人も犬のようなやつで、素直で愚直で裏がない。嘘をついたり、裏をかいたりするのは苦手。内緒話も陰口も苦手。
• 愚直で空気が読めず人に嫌われることはぼちぼちあるけど、人を嫌うのは稀。
• 真面目で社畜体質。
• 人が怒ったり言い争ったりすることにトラウマがあり、その場面では異常な緊張感を感じてしまう。
• 教育や勉強会も好き。

だいぶ犬っぽい感じ。
どうりで犬と相性がいいわけだ…。

どんな仕事？　どんな人がエンジニアリングマネージャに向いてる？

僕が所属するのはまだまだ小さなスタートアップですので、手を動かしたりもしていて、正直どんな仕事なのかよくわかっていません。
超ざっくり言うと「エンジニアの組織づくり」が仕事でしょうか。

良い組織やマネージャのことを考えると、社会人1年目の時にお世話になったマネージャを思い出します。

• 温和でなんでも相談にのってくれて受け止めてくれた
• 自分が一番つらいのに客先からメンバを守ってくれた
• 新人の僕に仕事を任せてくれた
• そして生まれた糞コードをきれいに作り直して見せてくれた
• 未経験の技術でも挑戦させてくれた
• 技術好きで最新技術にも詳しい
• 時には論理的に叱る。いきなり責めない。
• メンバからの信頼を得ている

本当に感謝しかありません。きっとこんな人がマネージャに向いているのでしょう。
僕は犬のようなやつなので、機微に対する心遣いが苦手で、こうはなれそうにありません。
僕はマネジメントを早々に諦め、技術だけで食っていくつもりでいました。

マネジメントはスキルである

受託ではなく、自社のサービスをやってみたくなり、上記の会社を離れ、上場間近のスタートアップにジョインしました。
スタートアップは僕にはすごくマッチしました。
エンジニアも仕様検討に混ざることができ、最善を選択するのに尽力できるのが最高に楽しい！
技術的にも強いメンバーが多くて、僕は生き生きと仕事を楽しみました。

仕事が手に馴染んで来たあと、子会社に出向し開発リーダー職を勧められました。
性格的に向いていないと思っていたので、乗り気ではなかったのですが、
「マネジメントはスキルであり、性格的なものが全てではないからやってみては？」と。
「スキル」と言われると技術屋には滾るものがあります。
10冊もの本を渡されつつ、挑戦することにしました。

全部は読めなかったのですが、一番強く記憶に残った本は「人を動かす」です。
この本は仰々しいタイトルですがわかりやすいタイトルにすると「人に興味を持って、人と仲良くして、仕事を円滑に進めよう」です。
言い争いが嫌いな僕にはすごくフィットし、星さんからこのまま定価で買い取らせてくれ！と言ったら、文庫版があるからあげるよ、とそのままいただきました。
今後も僕のバイブルになるでしょう。
最良には程遠い結果となりましたが、まずまずの手応えが得られました。

どんな苦しみがあり、どうしているか

今はより小さなスタートアップでエンジニアリングマネージャをしております。

人と自分は違う

当たり前ですが、人と自分は違うものです。
特にエンジニアは特徴的な方も多いです。
時にはイラついてしまうこともありましたが、人を動かすにあるとおり、
人に興味を持ち、何を大切に考えており、何がしたいのかを理解しようと努めています。

プログラムかけない & 全部自分でやりたがる

これはマネージャ職の問題というよりは個人的な問題かもしれません。
小さなスタートアップですから、手も動かします。
しかし、思ったより進まず、成果を出していない気持ちが生まれ、罪悪感が生まれてしまいました。
自分の全部自分でやりたがる性格もあいまって、ついつい仕事を抱えてしまい、単一障害点になってしまいました。
今は以下を心がけています。

• トラブル対応時は協力を仰ぐ
• 興味を持ってやってくれそうな人に振る
• エンジニアリングに集中できるようにするための作業をやらせてもらう
• 予め手を動かす系の仕事を抱えすぎない

会社やプロダクトと喧嘩しない

だいたいどこに行っても悪寒のするようなクソ設計、クソコードに出会うものです。
罵詈雑言をぶちまけたくなりますが、モチベーションが下がるだけで何も生みません。
「限られたリソースで当時できることをやったのだ。僕たちが少しづつ良くしていくしかない」
ということを共有するのを心がけています。

会社に合う人を採用する

採用もエンジニアリングマネージャの重要な仕事です。
有名な企業であればさておき、無名のスタートアップでは人事にまさせっきりではエンジニアの採用は難しくなってきました。
スーパーハッカーが雇えたとしても、会社に合う人を採用できないとお互い不幸になります。
技術力も重要ですが、会社に合う人を採用しています。

終わりに

この役職が向いているのかどうなのか、まだ手探りな状態でして、
適任者が来たら席を譲る心構えもありますが、
俺たちの戦いはまだ始まったばかりだ！
kaiba先生の次回作にご期待下さい！

この記事は、 Engineering Manager Advent Calendar 2018 の3日目のエントリーです。

また、同名のタイトルで、 Scrum Fest Osaka 2019 の プロポーザルを提出させていただいております。
https://confengine.com/scrum-fest-osaka-2019/proposal/8574/managerengineer

当日の発表は、この記事をベースとさせていただきますが、また発表のタイミングで色々とアップデートもあると思いますし、全然ちゃう内容になることもあるかも…?

以下のアジェンダで書いてみようと思います。

• 前提
• 仮説
• 検証
  • Management 3.0
  • 見える化
  • タスクはPull
  • モブプログラミング
  • 任せる領域
  • 自身も含めてエンゲージメントを高める
• まとめ

前提

私がどういった組織とチームに所属しており、役割を担い、組織の運営、チームの運営にどう関わってきたか、あまり詳細に書くことはできないので、ざっくり概要だけ書きます。

• 組織の責任者
• プロジェクトと組織の枠組みは別
• 組織のメンバーは、別々のプロジェクトチームに所属している
• 私が所属しているプロジェクトは、社員のみで構成されているわけではない
• 開発拠点は一箇所で全員その場にいる(リモートはいない)
• 組織のマネジメントと、プロジェクトのマネジメントが求められていた
• プロジェクトはスクラムチーム
• わたしは、スクラムマスターではなく、Developer
• 組織の責任者であり、プロジェクトの進捗について部分的に責任を担っていた
  • 部分的というのは、プロジェクトは巨大で、全体的な進捗を私の関わる部分だけでコントロールできる範囲になかったことからそういう表現にしている

まとめると…

私の役割としては、プロジェクトを進捗させ、プロダクトを世に出すため、開発を進めることだった。

いかに、自身の責任範囲において、進捗を出し、速く確実に成果を出し、プロダクトをローンチするのかといったことに取り組んでいた。

ある程度の権限をいただいていたので、私が開発してもしなくても、進捗さえ出れば良いという状況であり、手段については、問われない状況だった。
そのうえで、私はエンジニアでありたいがゆえに、組織とプロジェクトを推進しながら、自身もエンジニアとして手を動かし続けるには、どうすれば良いのか、といったあたりで、もがきトライした経験からの抜粋を書きます。

仮説

「自己組織化チームであれば、人や進捗を管理することなく、自身もエンジニアリングをしながら、結果も出せるのではないか。」
という仮説を立てた。

自己組織化チーム

改めて、自己組織化チームという言葉について、 InfoQでは、次のように紹介されている。

自己組織化チームとは何か？

真のチームは価値のあるミッション，明確な境界，自己管理と安定のための権限を備えていることを見てきました。チームの自己組織化はチームメンバの類似性と相違性の微妙なバランスの上に作られるということ，自己組織化には明確な境界とサポートするコンテキストが必要であること，自己組織化は分散管理，継続的な対応，創発的構造，フィードバック，復元力といったもので特徴付けられている，ということも分かりました。そして最後に，自己組織化には長い時間が必要なことも理解しました。

この結論だけを読んでもちんぷんかんぷんですが…きちんと最初から読めばなんとなく分かった気がします。

とはいえ、私が今回書きたいポイントとしては、ここで述べられている全てではなく、次のポイントにしぼって実施してきたことを挙げたいと思います。

自己組織化には明確な境界とサポートするコンテキストが必要であること

検証

以下の要素を検証した。

Management3.0

Management3.0を説明するときは、いつも必ず、1.0,2.0と追って説明することで、どういったものかピンと来やすいなーと思いますので、書きます。

Management 1.0

トップダウン式で、少数の人が権限を持っているタイプの組織の運営方法です。
つまりマイクロマネジメントです。ヒエラルキーの下にいる人たちは責任がほとんどなく、いい仕事をしようというモチベーションがありません。
このとき、「マネジメントとしては間違ったことをしている」状態になってしまいます。
しかし、残念ながら世界でもっとも広く普及しているマネジメント方法です。

Management 2.0

Management 1.0という古いシステムに、作業効率と従業員のモチベーションを上げるための、大量の活動を追加した状態のことです。
こちらもトップダウン・アプローチに変わりはありません。
そして残念ながら度々間違ったアプローチを適用している「正しいことを間違った方法でやっている」状態とされます。

Management 3.0

ヒエラルキーではなくネットワークが権限を持っていることを要件としたリーダーシップとマネジメントの概念です。
参加者全員が協調することによって、効率が良くなり、ビジネス・ゴールを達成することだけでなく、自己組織化を通して、高い内発的動機付けができ、皆さんが笑顔になります。
組織システムとして「正しいことをしている」状態とされます。

ぱっと、1.0->2.0->3.0と順に読むと、3.0は直感的に良い状態と定義されており、ここでも自己組織化というキーワードが出てきております。

さらに、InfoQで、 スクラムとManagement 3.0 という記事が掲載されており、この中で、次のような特徴に重きを置いていると紹介されています。

1. 能力を開発する: マネージャはチームメンバが目標を達成するための能力開発を支援しなければならない。困難な課題に取り組む機会を提供することが，社員の能力レベルの向上に役立つ。
2. 構造を拡大する: チームメンバ内のコミュニケーションやコラボレーションを向上するための構造を作り上げる。
3. すべてを向上する: メンバ，チーム，組織は継続的に改善し，失敗の回避に注力する必要がある。継続的な改善。
4. 精力的にする: マネージャはメンバのモチベーション向上を支援して，彼らが創造的かつ活動的であることを評価するべきだ。
5. チームに権限を与える: マネジメントはチームの自己組織化をサポートし，意思決定を行う権限を与える。
6. 制約を整える: 自己組織化のためには，システム内部が境界によって囲まれている必要がある。境界を置くことが，自己組織化を価値へと向かわせる。

以上の中から私が取り上げたいのは、 チームへの権限の提供 と、 境界の確保 です。

チームへの権限の提供

チームを自己組織化するため、権限の提供は欠かせないと考えており、そのために境界を確保して、その範囲において、自身の判断、管理のもと、遂行して良いよという確約を提供することを意識して取り組んでおりました。

そのことを念頭に置いたうえでの具体的な行動として、以下が挙げられます。

• 見える化
• タスクはPull
• モブプログラミング
• 任せる領域

見える化

チームの状況をチームのメンバーも含めて、見える状態になっていることは、自分たちが、全体の進捗においてとか、プロジェクトの方針においてとか、世の中、プロダクトの市場価値など、あらゆる視座において、とても重要だと考えます。

スクラムのスプリントという約束された範囲において、自分たちの制御可能な領域があり、そのステータスがどのようになっているか、自分たちも見えており、いつでも説明できる状態にしておくことは、とても重要です。

そのためのプラクティスとして、スプリントプランニング、カンバン、バーンダウンチャート、ニコニコカレンダー、デイリースタンドアップといったスクラムやアジャイルのプラクティスがとても相性が良く、うまく運用することが自分たちのステータスを理解するのに役立ちます。

そして、毎日、ステータスを確認しておりますから、いつでも聞かれたら報告できます。

デイリースタンドアップは、いわゆる朝会ですが、毎日、司会を当番で回します。
チームリーダーのような立場の方が朝会を司会すると、その人に向かって報告をするようになりがちです。
朝会を当番にすると、質問が一方向に集中せず、空中に浮く形になります。
それを一回放置してみると、だれかれと分かっている人が話し出します。
強制的に誰かに発言を促すのではなく、黙る勇気を持つことも時に必要です。
肩に力の入った責任感の強いチームリーダーは、チームが困っていると自分がなんとかしないとと積極的な行動を取りますが、時にはその行動を取らない勇気を持ち、問題をそのまま空中に浮かべてみると、意外な活躍をする人が出てくるかもしれません。
デイリースタンドアップで、毎日、そういった工夫を投入していくと、それぞれがチームへのコンピテンシーを産み、チームのステータスを把握し、自分ごととして、周りに説明できるぐらい見えるような状況を作れると考えます。

タスクはPull

タスクをPushすると、状況を把握しないと、投げっぱなしになってしまいます。投げっぱなしはよくありません。

タスクを投げたら、どうなっているか聞くといった常にこちらからの働きかけが必要となりますから、基本は、Pullをしてもらいます。
どんどん、空中に浮いているタスクを取っていってもらいます。

タスクを空中に浮かすためには、スクラムのリファインメントやスプリントプランニングで、タスクのWhy、What、Howについて、議論が成されており、サイズ感についても共通認識にいたっていることが重要です。
中にはスキルや経験が足らず、認識レベルが低い方もいると思います。
そういった場合は、ペアプロ、モブプロなどを取り入れて、次のスプリントにおける共通認識のレベルを上げていくことが重要です。
自己組織化チームは一日にして成らず、継続的な改善と取り組みをトライし続けることが必要です。
積極的にPullするための共通認識の醸成のために、今はできていなくても、レベルを上げ続けるため、いまのスプリントで分かっている人、分かっていない人で協力して、タスクを進めていくことで、認識の輪が広がり、チーム全体のレベルが底上げされていくはずです。

モブプログラミング

先に触れていますが、チームの共通認識のレベルを上げていくことに、とても役立ちます。
また、自身が取っている行動について、安心感を得られます。
相互に取り組んでいることを良い意味で監視し合い、安心してスプリントを過ごすことができます。

モブプログラミングを取り入れなかった場合、各個人の進捗について、デイリースタンドアップでチームリーダー的なロールの人に向かって報告をしていただく必要があります。

取り入れた場合は、報告していただく必要はなく、チームの誰かが分かっている状態を作ることができます。
結果的に終わったかどうかだけを把握することで事足ります。

モブプログラミングから得られる効果は、数えるとまだ他にもありますが、今回の中では共通認識レベルの向上から、次回からのスプリントでタスクをPullできるようになっていくことや、良い意味での相互監視により、自己組織化が進み、チームの中でこの人なら安心して任せられるヒーロー的な存在をどんどん排出していける流れが組めたりするあたりを取り上げます。

任せる領域

タスクをPullして、モブプログラミンをしながら、スプリントを何度か繰り返していると、自然と、この件については、この人といったお任せできる領域がでてきます。
その領域を持っている人を軸に置いたタスクの進め方がパターン化されてくると、周りの人がその人に弟子入りして、免許皆伝となり、次からはその人が軸となって…といった良い流れを作ることができます。
そういった観測も、モブプログラミングなら、いつでも自身が参加することができますから、状況を見て、この人に一度任せられるかもといった観測と、チーム自身からの発言をベースにして、構成していくことができます。
状況によっては、時間を短縮してなんとか仕上げたいといった特急的なタスクのときに、だれか個人でタスクを仕上げていただき、その人しか知らないという状況ができることもあるかと思います。
その場合でも、新に弟子入り制度を設けて、ペアプロ、モブプロを活用して、次の引き継ぐ人、免許皆伝となる者を作っていくことで、その人しか知らない単一障害点を防いでいく働きかけができます。

自身も含めてエンゲージメントを高める

ここまでの取り組みを通して、自身が組込まれていてもいなくても、自走するような流れを蒸留することができれば、自身もその流れに乗り、タスクを積極的にPullしていきます。

そうすることで、自身もエンジニアリングしながら、弟子を取ったり、弟子入りしたり、モブの一員でドライバしたりと、めくるめくエンジニアリング活動を継続することができます。

ただし、全体を俯瞰する視座を忘れてはいけません。

自走しているとはいえ、仕組みが健全であるかどうか、計測し続ける取り組みは必要です。

この俯瞰の視座は、チームの中で没頭すると見逃しがちですから、スクラムのふりかえりを効果的に計測とフィードバックの場として取り組みましょう。
仕組みを見直す観点の話題も定期的に取り入れながら、仕組みとしてトライを検討していく動きも必要と考えます。

まとめ

書きはじめると、とりとめもなく、あまり整理されていない書きっぷりに、自身も驚きと反省をしております…

まとめると、自身はEngineerでありたいと言っても状況が許さないManagementを求められる場合、可能な限りチームが自走して自身のManagement対象がシステムに向くようになり、メンテナンスを定期的に施す状態を作ることで、エンジニアリングに集中できる環境を作ることは可能です。

それをどこまで続けられるかは、プロジェクトやプロダクトの状況や成長などフェーズによって受け入れられないことも、充分ありえます。
とはいえ、そこにチャレンジせず、漫然と今まで通りのマジメントを続けていてもだめで、Managemenにエンジニアリングを注入して、自身を保ち続ける取り組みにチャレンジすることは、とても大事だと思います。

以上です。

この記事は、Engineering Manager Advent Calendar 2018の06日目のエントリーです。

• Engineering Manager Advent Calendar 2018

2016年某月からリーダー相当となり、さらに2018年04月から半年間、開発チームのマネージャとしてやってきた。しかしやり続けても成果を出す自信も、そもそもこれがやりたいことなのかという疑問もあったことと、なによりちょうどよくそれを託すに値する人がリファラル採用によって獲得できそうということが偶然にも重なり、マネジメントをやめたいと経営者に伝えたのが2018年10月。

そしていま現在、件の人にマネジメントしていただいており、これが機能していて、これがマネジメントなのかということを感じている。振り返るに自分には何が足りなかったか、マネジメントとは具体的になにをすることだったのか、ということを書きたい。

以下に

• [すべきだったこと] 僕ができなかったこと
• [もたらされたこと] 新マネージャが導入してくれたこと

として書いていく。

[すべきだったこと]いまチームがどの状態にあるかを知る

マネジメントに期待される事柄とは「チームをよりよくする」ことで、「企業の成長に寄与する」ことなのだと思う。ここでは後者は自明という点で無視する。前者の「チームをよりよくする」というところで考える。

「よりよくする」というからには「現在チームはどうであるか」ということを知らなくてはならない。
このとき主観的な状態、たとえば「技術的負債が……」などという ある程度認知されたつかいやすいそれっぽい言葉 が飛び交う状態はよくない。本当にチームとして知りたいのは「システムAの処理Bが非常に理解困難で改修すべきか運用でカバーするか、どちらがビジネスとして優先度が高いか」ということである。

つまりは 計測しよう ということだ。僕自身これができなかった。

[もたらされたこと]具体的な計測

大雑把でもいい。今現在チームのリソースがどのように割かれているかを知る必要がある。

• 開発
• 保守/運用
• その他

という(たとえ大雑把であっても)はじめの一歩としてのメンバーそれぞれの工数計測が必要だった。ひいてはこの計測結果がプロダクト維持に必要なリソースということになる。

• プロダクトの維持/成長のために、チームとして強化/補充すべき点はどこか

をまず知らねばならない。これはプロダクトそのものの健康診断とも言える。このあとになにを成すにせよ、チームの基準値はこの値になる。数値がよくなれば嬉しいし、悪くなれば別の方策を取る。この判断材料としての 計測が重要だと理解した。

[すべきだったこと]開発チーム内の構造/責務を明確にする

いびつな組織構造が同じ顔をしてシステム構造を制約する、というのがコンウェイの法則の警鐘点だと考える。開発チームの立ち位置、およびそれを管理するマネジメント職においても同じことが言える。

あとから考えるに僕には 制約をそのまま継承して改善しようとするという性質があるようで、本質から遠ざかったことをやっていたのだと考える。コンウェイの法則的に述べれば「いびつな組織構造を助長させている」と言えるよう思う。

組織構造は

Dev
|-- Prod-A(期待のプロダクト/比較的整理されている)
`-- Prod-B(売上主要/かなりレガシー)

となっていた。このときマネジメント職として期待される立ち位置は Dev に、メンバーは Prod-{A,B} にアサインされるべきである。また Dev に位置するマネジメント職は Prod-{A,B}の開発状況/進捗を理解していなければならない。これは当然であろう。

しかし僕の立ち位置は

• Prod-B のリーダー、およびインフラ担当としての立ち位置
• Devのマネジメント職としての立ち位置

であり、Prod-Aへの関与を最小限(というかほぼない)としていた。

また Dev という部署単位で企画されたことが部署に恩恵を与えた実感に乏しかったし、そもそも企画の数そのものが少なかった。

• 技術ブロクの開設
• 技術カンファレンスへのスポンサード

端的に言うと開発チームとして機能しておらず、また開発チームとして機能しているように見えても散発的であり積み上がっていく実感に乏しかった。

[もたらされたこと] 開発チームとしてのつながりとマネジメント職の独立

• プロダクトごとに閉じない、開発チームとしての技術要素の標準化計画
  • Prod-A において新規基盤開発で知見を得る
  • 上記知見を Prod-B へ横展開して可能な部分で切り出し改善する
• 週1回の開発チームとしてのMTG
  • タスク管理ツールの移行化計画
  • Prod-A Prod-Bを超えた進捗の共有
  • 技術要素の標準化 につながっていく期待

僕自身は上記の時間をとったことがなかった。先述した Prod-Aへの関与を最小化したことに起因する。そもそもMTGが嫌いというのと、抱えている問題が違うということからコミュニケーションコストが高いと考えたこともある。しかしそれは 管理ではなく結局のところ属人性を助長したに過ぎない。これは 「いびつな組織構造を助長させている」の具体的事例だ。

[すべきだったこと]開発チームと関連部署(ビジネス側、CS側)との責務を明確にする

たとえば Prod-Bにおいて責務は非常に曖昧なものだった。端的に申せば最終作業者にしわ寄せがくる構造といえる。2016年当初からこの点を非常に危惧しており、そして危惧すればするほど自身の開発リソースが食われるということを感じていた。その一方で危惧を改善する行動が継続せず(これもまた)散発的に終わることがほとんどだった。包み隠さず申せば「実りよりも混沌をもたらすただ声の大きい細かい人」というのが、実態だったのではなかろうか。

[もたらされたこと] 開発への希望/要望の交通整理

• 希望/要望管理ツールの統一化
  • 過去利用ツールは(ツールの問題というよりは運用上の問題で)大変使いにくい状態だった
  • 過去の濫造されたタスクがあり、「2018年10月においてこのタスクは重要なの？」という精査が全くなされていない状態だった
• 希望/要望の現時点での洗い出し
  • 2018年10月現在で必要なもの
  • 重要度の設定
  • それぞれに担当者をアサイン
• ツールを管理する交通整理者のアサイン
  • 当該担当者同士のMTGによる少人数でのビジネス的意思決定

それぞれの部署のインターフェースをきちんと定義して、責務を切り分けることに成功したように実感している。これには感謝しかない。

[本当に必要だったこと] なにかを決めなければならない

最後に根本として必要だと感じていることを述べる。それは 決めなければならないということである。決めなければならないというのが僕自身本当に苦手で、なぜ苦手かといえばその決断に 他者が影響するからである。
そもそも本当に僕が苦手なのは 他者に何かをやってくれとお願いすることである。「嫌だなあ」という相手に「必要なことだから」と伝えることが本当に苦手だ。なぜなら「嫌ならしょうがないよな」と考えるからである。

この点を踏まえると僕はいつまでたっても「いい兄貴問題」の中にいたに過ぎない。

• 局所最適化するから「いい兄貴問題」に陥る - 違反ヒントはありません

過去に書いたこのレベルから一切進歩していないということを感じている次第である。その一方でだからといってどうだということを考えるわけではない。単に向いていなかったという言葉ですませたい。

[これからできること/本当にやりたかったこと] 得意領域でプロダクトの改善を行う/マネジメントを後押しする

思うに僕のやりたかったことは

• 得意領域でプロダクトの改善を 自らの手で行う

に尽きるのだと思う。コードを書きたい、ITインフラを整備してよりクラウドネイティブにしたいなどなどを誰かに任せたいなどと言えない。この思いを抱えたままマネジメント職を両立させるのは、少なくとも僕には無理だと感じた。ので退いた次第である。

その一方でITエンジニア(というより一社員)として思うことは

• わたしたちは管理されたくないわけではない。「正しく管理されたい」だけなのだ

ということである。新しく入社された方とマネジメント職を交代し、先述した内容の数々を実施していただいたいまこそその実感がある。この状態を維持強化していきたいと強く感じ、そのためにできることはなにか探していきたい。

序文

このエントリーは Engineering Manager AdventCalendar 2018 の 11日目の記事になります。

筆者とエンジニアリングマネジメントの関わり

現在、サーバサイドエンジニアのエンジニアリングマネージャという肩書きでエンジニアリングマネージャをしています。
現職ではエンジニアリングマネージャはピープルマネジメント中心とした役職です。
前職でもエンジニアのマネジメントするポジションで、技術に関する部分のプロダクトマネジメント、プロジェクトマネジメント、ピープルマネジメントなどの全ての責任を持っており、チームに居るエンジニア全体をマネジメントしていました。

前職では２つの事業立ち上げと既存事業の途中から参加した３つの事業での開発マネジメントに順番に携わっていました。
今は大きな組織の中で数名のエンジニアを担当するエンジニアリングマネージャをやっています。

このようなエンジニアマネジメントのポジションに就いてから4年半ほどが経ちます。
ゼロイチでチーム文化から作るところや成果が出なくてスケジュールギリギリで走り続けたり、長く運営されたチームに入り文化変革をしたりなど、いくつかの入り方でチームに入り、自分の得た知識をいくつもチーム内で実践してみたりしてきました。

最初の頃はスクラムなどのアジャイル開発の知識もなんとなくはありましたが、長くマネージャ職を続けていった時に、完全にマネジメントに振り切って勉強しようと考えてから２年程度が過ぎました。
その切り替わりの時期で感じた、マネジメントのスキルを勉強して習得することを意識しながら、よく区分けされるマネジメントについて書こうと考えました。

今回は技術のエンジニア側から既存マネジメントが組み合わされたものを見ると、どのような観点で対応する必要があるのかの考えを書いています。

想定読者

エンジニアリング x マネジメント に興味がある人
片方ではなくて、両方同等に知識として欲しいと思う人

エンジニアリング x マネジメント

マネジメントを学ぶ習慣のないエンジニアではエンジニアリング + マネジメント (エンジニアが足しているだけ) になっていて、それはエンジニアの力の最大化にはならないと思っています。

マネジメントとエンジニアリングは掛け算の関係であり、最終的に完成するプロダクトを何倍にもする力があると信じています。
エンジニアリング x マネジメント (掛け算)にすることで、その価値を作り上げられるエンジニアは楽しく喜びを得られると共に最大のパフォーマンスを発揮すると信じています。

エンジニアの技術を持っているからこそ出来るマネジメントが全てのマネジメントの中に存在していると考えていて、いくつかの領域のマネジメントの考えを書いてみました。

今回の領域は

• プロダクトマネジメント
• プロジェクトマネジメント
• ピープルマネジメント

についてそれぞれの観点で書いてみました。

プロダクトマネジメント x エンジニアリング

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

プロダクトを何を作るかを決める作業になります。つまり作るべきものの目標そのものを決めるマネジメントです。
理想だけでは目標は達成できないため、ビジョンからリソース(人・モノ・金)を考えて実現性のある機能提供の目標を作ります。

高速で移動がしたい！と考えたときにF1カーを作るべきか、軽自動車を作るべきかはその時によります。
軽自動車のコストでF1カーは作れないので、そのバランスを見極めることこそプロダクトをマネジメントすることです。

プロダクトマネジメント x エンジニアリングとは

実現性の部分でより精緻な審査が出来るのはエンジニアだけです。
仕様を聞いた時に実装するべきデータフローが瞬時に浮かぶ技術のレベルが必要になります。
また、実現する実装方法についてアイデアマンである必要もあります。

価値 > コスト → 本当のコストがわかるのはエンジニアだけ

提供スピードが早いほど価値を大きく出来る。
しかし、実装コストは技術が分かる人間にしかわからないので、エンジニアがマネジメントする必要がある領域。

実現したいことのコアな価値がどこにあるのかを理解して、技術的にコストが低く長期的に安定出来る実装はどのようなものかを考えながら提案する必要がある。

つまり、早く届けられるかどうかによって、価値の優先順が変わるはずなのです。
技術を知らないプロダクトマネージャだけで優先順を最終決定出来るケースはないと思います。
それが出来るのは定常的な慣れた技術であるときだけです。新しい技術や新しい設計が必要なときには必ずエンジニアの力が必要だと思います。
そのエンジニアの確認をしないマネジメントでは通常では到達不能な目標をプロジェクトマネジメントをする時に圧倒的な軋轢が発生することになるはずです。

技術的負債のコントロール

技術的負債がプロダクトに与える影響度を測ることが出来るのもエンジニアだけです。
プロダクトマネージャに言われるがままに作るエンジニアはマネージャではないと思います。
中長期のプロダクトのシステム内のバランスを考えながら技術的負債をコントロールすべきです。
エンジニアにとってシステムのアーキテクチャデザインや構成、品質こそがプロダクトのはずです。
それは プロダクトマネジメント x エンジニアリング が必要な領域です。

プロジェクトマネジメント x エンジニアリング

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

作るべき機能をどのようなスケジュールで作って実行するかをマネジメントします。
簡単に言えばプロダクトマネジメントの時に決めた目標を達成するというものにフォーカスしたマネジメントです。

クリティカルパスの並び順を整理したり、全体量を把握しながら進めたりするだけで効率が上がるものです。
コミュニケーションを促進したり、認識を合わせるためのツールやフレームワークなどもあります。

プロジェクトマネジメント x エンジニアリングとは

機能の工数の積み上げだけでは実はアプリケーションは完成しません。
特にサーバサイドの技術が多い場合にはPMが出す機能スケジュールとは別のスケジュールを持つ必要があります。

エンジニアにしか見えない非機能要件や開発環境の作成、たくさんの機能の基盤となる部分の実装などの工数を加味したスケジュールを作り出して、プロジェクトのスケジュールとシンクロしながら開発のスケジュールをマネジメントする必要があります。

パーキンソンの法則

大きくバッファを持つ方法でスケジュールリスクに対応する方法もありますが、本質的ではないと思っています。
それは自分で技術を見積もることが出来ない、またはタスクを洗い出す事ができないという技術力不足に対応するための手段に過ぎないと思うからです。
単純にバッファだけ積まれたスケジュールはパーキンソンの法則(夏休みの宿題を最終日にすべてこなすなど)に沿って、スケジュールの時間をすべて使うことになってしまうと思います。

不確実性のコーン

技術が高く、かつプロジェクトマネジメント力があるならば、もっと本質的な技術リスクを見積もることが出来ると思います。
本当に技術リスクが高い機能と、今まで得た技術を使うことだけで実現できる機能では、スケジュール上の日数は同じでも、不確実性へのリスクは大きく違います。
不確実性のコーンは不確実なリスクに対して早期に手を付けて、不確実性を減らすことによって収束していくもです。
分からないからと言って手を付けていなければ、不確実性のコーンは収束することはなく、スケジュールの延期を余儀なくされます。

何が不確実であるかはプロダクトマネージャはもちろん分かりません。プロダクトマネージャには全ての機能が不確実に見えていることでしょう。技術がわかるリードエンジニアだからこそ、実現性に対する実装リスクの濃淡が機能の仕様から見えるのです。

マーケットや経営の判断の動きを見ながらスケジューリングする

提供価値が他の機能よりも上であっても、不透明な技術のものはタスクとして優先順位が上げづらいです。
見通しが明るい機能の方が提供価値が低くても実装を先にしてしまうのです。
１人のメンバーであるエンジニアの多くはマーケットにおける機能の価値を理解するだけの十分なマーケット知識を備えていません。
マネジメントするにはそれらを捉えて、スケジュールに落とし込む必要があります。

本当に対応すべきタスクが何かをコントロールし、リスクについての不確実性を考慮に入れたタスク優先度、スケジュール順、アサインなどは、とても高いレベルの技術とマネジメント力を要すると思われます。

緊急ではない重要な仕事

締め切りやバグなどの緊急事態になったときにのみ不確実なリスクに対応しているようではプロジェクトマネジメントが出来ているとは言えないと考えます。エンジニアの技術力を活かしてこそ プロジェクトマネジメント x エンジニアリング のマネジメントになりえるはずです。

スクラムベーシックなエンジニア理想とスケジュールベースなFIXスケージュールの現実

締切の自由さや機能の削減の余裕があるならば、スクラム等で実行されているバックログリファインメントやスプリントバックログで解決出来ます。
しかし、スケジュールをFIXさせたい、機能もFIXさせたい要件が強いときには現在のスクラムフレームワークでしっかりとエンジニア側が必要な作業について洗い出す力やリスクを見積もり、バッファの誤差を減らし、技術的なリスクがクリティカルパスにならないようにタスクの着手を優先する勇気を持ちならがカンバンのチケットを取る戦略が必要です。

自由にカンバンからチケットを取るだけでは上手くいかないのも当然です。マネジメントされていないのですから。
そして、それは真のアジャイルではないと思います。
スケジュールがFIXしていても、アジャイルであることは出来ると考えています。
それはウォータフォールとは別のものです。

ピープルマネジメント x エンジニアリング

ピープルマネジメントとは

個々の働く人へのマインドに関わるマネジメントになります。
その人の価値観や求める働き方、その人のパフォーマンスを最大に発揮させることや中長期のキャリアを考えます。

ピープルマネジメント x エンジニアリングとは

エンジニアリングを行うのは当然エンジニアになります。
エンジニアの技術を理解しない人に対して、エンジニアはどれだけ技術の話を出来るのでしょうか？ 通常は難しいでしょう。
毎日技術を駆使し、技術を勉強し、技術で成長しているのに、その話が出来ない人にあなたの成長や成果を説明できるでしょうか？ 現在の課題を相談できるでしょうか？ 将来を相談できるでしょうか？

エンジニアの技術とマネジメントの知識があるからこそ
・ 困っている技術の相談
・ エンジニアのキャリアの相談
・ あなたの技術力の評価
を話が出来ると思います。

それだけでピープルマネジメント x エンジニアリングの価値があります。

目標管理と評価

ピープルマネジメントのスキルで言えば、目標設定やキャリア、パフォーマンスの最大化などがあります。

MBO、OKR、KPI、KGI
色々な指標や個人の目標の立て方があります。
OKRを１つとっても、上手くやれるOKRとやれないOKRがあります。
タイトルだけOKRにしても、OKRではないのです。必要なのはOKRの観点といくつかの要素が守られているかという事です。
ただブレイクダウンするだけでは上手くいかない。ゴールツリーのような考え方や伝え方も重要になります。

会社がどの方向にビジョンを持っているかを理解していなければエンジニアの目標を導けないですし、会社のビジョンに対してキャッシュフローや事業計画を理解しなければ、その実効性がただの理想なのか、硬い目標なのかわかりません。そこまで理解してエンジニアの目標を作る必要があります。硬い目標ならMUST目標で立てなければならないですし、理想目標ならばビジョン目標としてモチベーションを作る必要があります。そこに技術を掛け算して目標を提案する必要があるかと思います。

会社の経営の理解が浅ければ、プロジェクトマネジメントのスケジュールに振り回された目標設定のみになり短期的なものしか見えなくなってしまう。本当のその人のパフォーマンスや成長性を考えた目標を考えれるようになりたいところです。

評価

評価の方法もどんな会社も頭を悩ませ、試行錯誤しているところになります。
この項目については定型的なパターンはあまりなく、事例ベースが多い気がします。

弊社はPeer Reviewを採用しており、自分を評価して欲しい人の複数から評価コメントを受けて、上長が最終決定しています。

環境作成

組織文化の浸透や福利厚生も含めて働くひとの環境作成が必要になります。
PCのスペックやモニタ、机や椅子、開発の時に使うツールなど、自由に揃えたり、良いものを使える方がエンジニアは当然うれしいですし、効率も上がると思います。
最近ではエンジニアのコアタイム勤務によるフレックスやリモート開発も増えているように感じます。

そのような環境そのものを変革することは会社の文化もありますが、進めるための上手さも必要です。

最小単位の個人と最大単位の組織をマネジメント

ピープルマネジメントは個人にフォーカスする部分と組織そのものにフォーカスする部分があり、ターゲットの大小の差が大きいので非常に難しい部分のマネジメントのように思います。

この記事を見ている人はきっとエンジニアリングを勉強してきた。そしてマネジメントの興味、知識がある

あなたがエンジニアならばエンジニアリング技術を学んできたと思う。
エンジニアという職業があなたをエンジニアにしたわけではないと思う。
エンジニアと名乗るために勉強した事があるはずです。

マネジメントのフレームワークや技術

エンジニアがそうであったのと同じようにマネージャになったならマネジメントが出来るようになるわけではない。
マネジメントも多くのフレームワークや手法があります。

あなたはオレオレフレームワークばかりを作るエンジニアと一緒に働きたいだろうか？
センスが群を抜いていればRuby on Railsのようなフレームワークを作ってしまうかもしれないが、ほとんどのケースがそうではないことを知っていると思う。

コピペではない、活用をすること

事例ばかりみてそれを適応するのも、ちょっと違うかなと思います。
StackOverFlowに載っている解決方法のコードを意味もわからずコピペするだけで上手く動いたけど、根本が違っていることもあると思います。

もちろん、最初の一歩はそこから始まるとは思います。しかし、本当に使いこなすには、その一行一行に何の意味や意図があるかを理解することの方が大切です。

ふりかえりでKPTをやっているときに、KPTをやっていればチームが良くなるわけではないです。
KPTで解決できる問題や課題の観点でKPTが使われているときにだけ効果を発揮するんです。

このように、技術は意味があって使われているので、その適応範囲は自分で考える必要があります。

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

僕はマネジメントの勉強をしなければ 真のエンジニアリングマネージャ にはなれないと考えています。

残念ながら僕は凡人なので、センスよくマネジメントを実行することはなかなか出来ませんでした。
だからこそマネジメントの手法を学び、上手く実行できるようになるまで実践をしようとしています。
使いこなすまでにはまだまだ練習が必要です。

GoFのデザインパターンを覚えても、使いこなすまでには時間がかかります。
それまではデザインパターン厨になってしまう時期はあるかもしれないです。でも、やるしかない。
マネジメントも同じです。コーチングの本を１冊読んだからと言って、コーチング出来るわけではないです。

エンジニアリングを掛け算する

色々なマネジメント単体の知識がエンジニアリングと掛け算されることになると思います。
それは今あるマネジメントフレームワークをベースにしながらエンジニア向けにカスタマイズしながら使うことになるような気がします。もちろん、開発向けに作られたアジャイル開発系のフレームワークなどはそのまま利用できます。

さまざまなマネジメント領域

様々なものをマネジメントするために色々なマネジメント分野の勉強が必要と思います。

• プロダクトマネジメント
• プロジェクトマネジメント
• ピープルマネジメント

それぞれにたくさんの考えや事例、本などがあります。
さまざまな考え方や手法が存在しています。
上では３つにまとめていますが、この３つがとてつもなく深くて広い、、、。

また、この枠に当てはまらないマネジメント技術も、もちろん沢山あります。

レピュテーションマネジメントでは会社の評判をマネジメントする話ですが、その観点をエンジニアに照らし合わせ、外に表現されづらいエンジニアのスキルや貢献をどう表現することで評判としてアピールするかをエンジニアリングと掛け算することで考えたりもできます。

ゾーンマネジメントは経営におけるグロース事業と新規事業などのフェーズごとに組織や観点、ルールを分けてマネジメントをする手法ですが、その観点はエンジニアリングに於いても同様に存在すると感じました。
技術的負債に対する投資の考え方もこのようなフェーズによって違います。

このようにどんなマネジメントに関してもエンジニアリングを掛け算することで活用できる面があるのではと考えています。

いくつかの手法の紹介

今回の３つのマネジメントに関するいくつかの手法に関するキーワードはこちらの過去記事にもあります。
現在と少し考えが違う部分があるのですが、参考になるかもしれません。
エンジニアの次のステップの勉強法２ - 技術の別の道への活かし方

終わりに

いろいろ書きましたが、ぶっちゃけエンジニアが良い感じに働けるようにすることがマネージャの仕事で、それ以外の目標はないと思います。
今回書いた勉強することについても１つの考えや手段に過ぎない。
色々なマネジメントの技術を学んで真のエンジニアリングマネージャを目指したい！

エンジニアが楽しく開発できる環境を作る。エンジニアリングマネージャの責務はそれだけ！
みんなで頑張ってエンジニアにとって最高のやりがいある環境を作りましょ！

この記事は、Engineering Manager Advent Calendar 2018の17日目のエントリーです。

はじめに

まず、以下がざっくり私が現在置かれている状況です。

• SIerで新規プロダクト開発のPO兼スクラムマスター
• スタートアップでプロダクトチームのリーダー

いずれも試行錯誤で日々失敗の連続を繰り返してる真っ最中です。
そんな中でも常に意識していることがあります。
それが良いチームとは何か、そして良いチームであり続けるために何が必要かです。

この記事では、良いチームとは何か、そして良いチームであり続けるために何が必要かについて自分なりに考えていることを書いてきます。

チームとは

まずはチームについて考えていきます。
個人的には「いま話題の「心理的安全性」について、本気出して科学的に分かりやすく説明してみた」にある以下引用部分が非常にしっくり来ています。

「チームとは、人々が互いに新しいアイディアを生み出したり、互いに答えを見つけたり、互いに問題を解決したり、するための活動である。」(2012, Edmondson)

これが、チームが「動詞：チーミングだ！」と彼女が主張する、その意味です。

つまり、チームとはチーミングする集団であり、さらにこのチーミングを自分なりの言葉にすると、互いに成長し続け、常により良い成果を挙げ続けることと考えています。
よって、チームとは互いに成長し続け、より良い成果を挙げ続けることが出来る集団と考えています。

次項以降で、互いに成長し続け、より良い成果を挙げ続けることが出来る集団をもう少し深掘りしてみます。

成果とは

前項ではチームを互いに成長し続け、より良い成果を挙げ続けることが出来る集団としました。

次に成果とは何か、ここについて考えてみます。

「成果(セイカ)とは - コトバンク」を見ると、

あることをして得られたよい結果

こう書かれています。
ではよい結果とは何でしょう？
短期的に見れば利益が上がることもよい結果でしょうし、働く人が幸せになることが中長期的に利益に繋がればそれもよい結果だと思います。
非常に定量化することが難しく、一言では言い表すことが難しいものです。

またしても「いま話題の「心理的安全性」について、本気出して科学的に分かりやすく説明してみた」の引用になりますが、

過去の成功事例や、偉い人の書いたマニュアル通りにやればオールオッケーなチーム(実行志向のチーム)は減っていて、「不確実性と難度の高い挑戦」が求められるようなチーム(学習志向のチーム)が、増えてきているのではないでしょうか。

上記を自分なりの言葉にすると、中長期的に何が成果になるのか以前にも増してわからなくなっているです。

こうなってくるともはや一般的な成果を何かしらの言葉で一括りにすることは無理なので、組織ごとにOKR、KPI、KGI等色々な数値をもとに成果を定量化しているという流れになっていると捉えています。

また、組織ごとに成果を定量化したとしても、それは常に変動していくものであり、都度見直していく必要があるものとも考えています。

つまり、成果とは

• 画一的なものでない
• 流動的なものである

の2点が言えると考えており、自分なりの言葉にまとめると現時点で最良と思われる結果の指標であると考えています。

チームであるためには

チームの話に戻ります。
前項ではチームを互いに成長し続け、より良い成果を挙げ続けることが出来る集団としました。

より良い成果を挙げ続けることが出来なければそれはチームではないわけですが、上記に記載した通り成果とは組織ごとに個別に決めていく必要があります。
つまり、チームであり続けるためには何らかの方法で成果を定量化し続けていかなければならないと考えています。

ではどのように成果を定量化していけば良いのか？
こちらについてはあまりにも範囲が広すぎるのですが、少なくとも観点のひとつとして、メンバーが成長し続けているかを含める必要があると考えています。
もちろん成長した結果が組織に貢献していなければ組織としては意味がないわけですが、さきほど成果を現時点で最良と思われる結果の指標とした通り、何が組織にとって貢献になるのかさえ可変的で不明瞭になっていきていると考えています。
ここまで来ると、成果とは何かを常に考え続ける必要はあるにしても、少なくともメンバーが成長し続けていればそれは成果の一つとして捉えて良いのではないかという答えが自分の中で出てきます。

つまり、メンバーが成長し続け、成果とは何かを常に考え続けることがチームであるための条件だと考えています。

メンバーが成長し続けるためには

前項では前項ではメンバーが成長し続け、成果とは何かを常に考え続けることがチームであるための条件としました。

とすると、メンバーが成長し続けているかを見る必要があるので、本項ではそこについて考えていきます。

まず、成長とは何か？
「成長(せいちょう)とは - コトバンク」

生物が卵から成体へと刻々と変化している間に，大きさ，重量を増していく現象。もちろん一時的な水分の添加などによる変化は意味しない。この間，細胞の増殖を伴う。この現象において形態の変化を伴うが，その点を主眼点としてみる場合は発生という。生長とも書き，使い分けは明確でない。また発育という語との区別も一応のものである。

こう書いてあります。
わかりづらいですが、これを自分なりの言葉にすると、何かしらがインクリメントされるです。
これでもまだふんわりしているので、何かしらをいくつか列挙していきます。

• プログラミングスキルが向上した
• 設計力が向上した
• 業務スピードが向上した
• 高い視座で考えられるようになった
• 今まで悩んでいたことが解決された
• 他のメンバーに言えなかったことが言えるようになった
• etc...

少し挙げるだけでも非常に多岐に渡り、それぞれ個別に見ればある程度定量化することは出来ますが、これらの指標を全て定量化して成長を判断するのは非常に難しいと考えています。
そうなると、自分自身で成長出来たと実感出来たかが重要になってくると考えています。

では、どうすれば自分自身で成長出来たと実感出来たかを測ることが出来るのか？
私なりの答えは振り返りに尽きます。

何かしらがインクリメントされたかどうかを測るためには、過去と今を比較することが不可欠で、そのためのツールとして振り返りは最も強力で唯一のツールだと考えています。

その振り返りにも種類がありますが、個人的に行っているのは

• 日々の日報で1日を振り返る
• スプリントレトロスペクティブで個人、チームとしてのKPTを振り返る
• 1on1で個人だけでは気付けない部分を振り返る。

の3つです。
3つ以外でも振り返りの方法はたくさんあると思いますが、方法はともかく短いサイクルで振り返ることが重要だと考えています。
人間は非常に忘れやすい生き物だと思うので、感覚が広がれば広がるほど過去のことを忘れてしまいます。
そうなると過去と今を比較がしづらくなってきてしまいます。
もちろん短すぎると成長の実感があまり出来ず振り返りの効果が薄れてしまいますが、いずれにしても振り返りを行わない限りメンバーの成長を測ることは出来ないと思います。

よって、短いサイクルで振り返りを行うことがメンバーが成長し続けるために必要がことだと考えています。

良いチームとは

前項では短いサイクルで振り返りを行うことがメンバーが成長チームであるための条件としました。

前項まででチームであるために何が必要かを考えたので、本項ではその先にある良いチームとは何かについて考えていきます。

しつこいようですが、良いとはどのようなことを指すのか、「良い - コトバンク」を見ると、

人の行動・性質や事物の状態などが水準を超えているさま。

こう書かれています。
つまり良いとは何かと比較して、その比較対象より優れている状態と考えています。

ここで、良いチームについて改めて考えてみます。

• 良い
  • 何かと比較して、その比較対象より優れている
• チーム
  • 互いに成長し続け、より良い成果を挙げ続けることが出来る集団

上記がそれぞれの解釈なので、チームに対して何かしら比較対象を設け、それと比較した結果優れていれば良いチームであると言うことが出来ます。

では何を比較対象とすれば良いのか？
私の中の答えはチームの成長度合いです。

まず、成果について、画一的でなく流動的なものとしました。
そして、その成果はチームの構成要素のひとつであるため、チーム自身も画一的なものにはなり得ないとすることが出来ると考えています。
とすると、比較対象を外部にすることには無理があり、チーム内部で何かしらを比較する必要が出てきます。
次に、チームであるためには成長し続けている必要があるため、以前と今の力の比較は良いかどうかよりも手前の話になります。
外部と比較出来ず、以前と今のチームの力とも比較出来ないとなると、残るは成長度合いしか思い浮かぶものがありませんでした。

つまり、私の中で、良いチームとは、成長し続けるだけでなく、成長度合いを指数関数的に伸ばしていけるチームであると考えています。

良いチームであり続けるためには

画もなく文字ばかりになってしまいましたがそろそろ終盤です。

前項では、良いチームを成長し続けるだけでなく、成長度合いを指数関数的に伸ばしていけるチームとしました。

本項ではどうすれば成長度合いを指数関数的に伸ばしていけるチームになれるのか、またあり続けられるのかについて考えていきます。

指数関数的に伸ばしていくためにどうすれば良いのかを考える上では、「エクスポネンシャル思考」が非常に参考になりました。

上記書籍を簡潔にまとめることは非常に難しいのですが、私なりに指数関数的に伸ばしていくために必要な要素を簡潔にまとめると、

• 常に今を疑う
• ムーンショットな目標を掲げる
• あえて曖昧にする勇気を持つ
• 外部の人を積極的に活用する
• 目先のことにとにかく熱中する
• 素早く実行し、小さな失敗を繰り返す

このあたりがポイントになると考えています。

上記ポイントのそれぞれを自分なりにチームの活動に置き換えると、

• 常に今を疑う
  • 「普通は」「常識的に」「当たり前に」という言葉を絶対に使わない
• ムーンショットな目標を掲げる
  • 「出来ない言い訳」よりも「どうすれば出来るか」を真っ先に考える
• あえて曖昧にする勇気を持つ
  • ジョブディスクリプションだけに囚われない
• 外部の人を積極的に活用する
  • 人の入れ替えだけでなく、ハンガーフライト等の交流で常に新しい風を入れていく
• 目先のことにとにかく熱中する
  • やることとやらないことを明確にする
• 素早く実行し、小さな失敗を繰り返す
  • 短いサイクルでスプリントを回す

このようになりました。

つまり、これらのことを達成することが出来れば、成長度合いも指数関数的に伸ばしていくことが出来るのはないかと考えています。

前項までは自分なりに一言でまとめてきましたが、本項の良いチームであり続けるためにはを一言でまとめることはできないため、上記をまとめとさせて頂きます。

まとめ

ひたすら文字だけの投稿になってしまったので、一応各項をまとめておきます。

チームとは

互いに成長し続け、より良い成果を挙げ続けることが出来る集団

成果とは

現時点で最良と思われる結果の指標

チームであるためには

メンバーが成長し続け、成果とは何かを常に考え続ける

メンバーが成長し続けるためには

短いサイクルで振り返りを行う

良いチームとは

成長し続けるだけでなく、成長度合いを指数関数的に伸ばしていけるチーム

良いチームであり続けるためには

• 「普通は」「常識的に」「当たり前に」という言葉を絶対に使わない
• 「出来ない言い訳」よりも「どうすれば出来るか」を真っ先に考える
• ジョブディスクリプションだけに囚われない
• 人の入れ替えだけでなく、ハンガーフライト等の交流で常に新しい風を入れていく
• やることとやらないことを明確にする
• 短いサイクルでスプリントを回す

さいごに

自分なりに普段からなんとなく考えていたテーマでしたが、ここまで言語化して考える機会は今までありませんでした。
言語化したとは言ってもまだまだわかりづらく、間違っているところも多々あると思います。
ここはおかしい ここは間違っている 等ありましたらぜひご意見頂けますと幸いです🙇

良いチームを成長し続けるだけでなく、成長度合いを指数関数的に伸ばしていけるチームとしましたが、自分自身も指数関数的に成長していくという強い想いを胸に、平成最後の残り数日を、精一杯生きていきたいと思います。

こんにちは。 mixi AI ロボットチーム の開発マネージャーをしているインコです。
この記事は Engineering Manager Advent Calendar 2018 の18日目の記事です。

この記事では褒める組織を作った話をします。

私の環境

環境が違えばマネジメントの方針も変わります。
ここでは私の環境を書きます。

• mixi という Web 企業の、研究開発からハードウェアまで関わる新規事業
  • まだ製品は出ていないフェーズ
• 私
  • 開発チームのマネージャ
  • 企画やデザインを含む事業全体のスクラムマスター（上記と兼ねている時点で良い SM ではない！）
  • 実装・研究とマネジメントそれぞれ半々
• スクラム開発
• 上司から大きめの裁量をもらっている
• 機械学習の研究寄り人材からハードウェアエンジニアまで多様なメンバー

問題：研究からハードまで扱うチームの情報共有

多様なメンバー

さて、環境にも書いたとおり私のチームは多様な人材がいます。

• ディープラーニング(もしくは End to End 学習)主義者
• 元ベイジアン今ディープラーニングな転向者
• 自然言語処理er (ディープでない)
• インフラ+サーバーエンジニア
• メーカーからやってきたハードウェアエンジニア
• ニューラルネット大好きエンジニア(インコ)

ざっと眺めるだけでそれぞれ全く違う言語を喋ってそうです。

技会

私達のチームには２つの特徴があります。

• 研究開発： 研究では広さより深さが必要です。各人が自分の専門を深く掘っていく必要があります。
• 新規事業： 新規事業ではチーム全員が同じ方向を向いてゴールを共有しながら進む必要があります。そうしないと空中分解します。

上のメンバーの多様性と合わせて、チーム内のコミュニケーションを意図的に増やしていかないと各人が自分の領域に閉じこもってしまいやすい性質の事業です。

そこでチームでは初期の頃から技術的知見共有会、略して技会という会を毎週開き、そこでは自由に技術系のネタを話せるようにしています。

ネタは業務上の共有（新しく作ったモジュールの説明だとか機械学習の知見）のような真面目なものから、特に業務に関係ないけど面白かった論文のシェアやデモ、俺の好きなアルゴリズムなどなんでも OK です。
毎回開催時に「今日ネタある人〜？」と聞いて適当に話します。

褒める・感謝する

技会（やその他いろんな会議）をファシリテーションするにあたって気をつけていることがあります。

発表してくれたことをまず感謝すること。褒めること。盛り上がること。

いちばん大事なのは、相手の話に興味を持つことと、それを素直に口に出すことです。
「めっちゃ面白いですね！」といった直球なものはもちろん、「〜〜はどうなってるんでしょうね」みたいな質問も内容への興味を持ってるんだよという姿勢を明確に出すようにします。言い方の例を出すと繕っているような印象になってしまいますが、思ったことを口にちゃんと出すのはとても大事なことです。

私の哲学ですが、「知らないことを恥じる」よりも「知らないことを知ってる人がいて面白い」という感覚を持つことが重要と考えています。知らないことを恥じて勉強するのは良いことですが、その気持が強いと知らないことを人は隠そうとしてしまします。知らないことを開示して、単純にそれを教えてくれたことに感謝しましょう。より知識が増えたらそれをまたチームに還元していきましょう。

褒めることは難しい

褒めるという行為は難しいです。
関係が悪化してしまうと、褒めることは自分を下だと認めることと感じてしまったり、逆に上から目線と感じさせる事になったりしてしまうこともあります。
関係がニュートラルなうちから素直に相手を尊重する文化を作り、育てて行くことが大事だと思っています。

また、上に書いたような事を明示的に伝えて賛同してくれるメンバーを作るのも大事です。
チームで褒める文化の価値を伝えたり、1on1などでそういう行動を取ってくれるメンバーに感謝を伝えたりしています。

褒める文化で起こること

Engineering Manager Advent Calendar でも重要なキーワードになっている「心理安全性」の高い組織ができます。

私のチームでは以下のようなことが起こっています。

• マウンティングしなくなる
  • 私はマウンティングは防衛本能のようなものだと思っています。他人に否定されないための防衛。
  • 褒める文化の中では、まず最初に自分が受け入れられるところから始まるので防衛の必要性が下がります
  • （ただし、これはもしかしたら元々マウンティングとったりしなさそうな人を採用してるからかもしれません）
• 自分を開示しやすくなる
  • いろいろな話が共有されやすくなります
    • 自分の好きなもの
    • 今作ってるもので決めかねているところ
    • etc.
• 他人や他分野に興味を持つようになる
  • 話す方も聞く方も楽しげになってくるので、自然と他分野に興味がわきます
  • よくわからない怖い世界が、専門じゃないけどなんとなく聞いて知ってる世界くらいになります
  • また他人に対する敬意も生まれます
  • これがT型人材を育てやすい環境を作っていきます
• 建設的な議論の土台になる
  • 浅くはあっても言葉や知識の共通部分ができるため、議論をしやすくなります
  • 肯定的なコミュニケーションを定期的に行っているため心理安全性がたかまり、建設的な対立する意見も言いやすくなります
    • といってもここは個人差があり、真っ向から異論を言いにくい人もいます
    • そういうところは1on1でケアしましょう

スケジュールの都合で開催されないこともありますが、これまで1年以上だいたい毎週技会は開催されていて、話す人がいなくてスキップとなったことはおそらく無い（あっても1,2回？）という高い継続率で運用されています。

課題点

課題点というほどではありませんが、人はそれぞれ発信したいタイプの人もいればそうでない人もいるので、発表者が偏る傾向はあります。
発信はしたくないというタイプの人に無理やり話させるのは良くないですが、発信したいけれども自信が無いという人に対してファシリテーションなどでうまく話をふるのをやっていかないとと思っています。

最後に

マサカリを投げ合う殺伐とした現場もエンジニアの一つの理想形かとは思いますが、私は肯定と相手への興味がベースになっている文化を広めていきたいと思っています。
ポエミーな感じになってしまい恐縮ですが、褒める組織が増えることを願っています。

この記事はEngineering Manager Advent Calendar 2018の12/21日の記事です。

これまでの記事を読んでいると同じことを考えている方がいたり参考になる記事も多く学びの多い年末となりました。

はじめに

RettyでVP of Engineeringをやってるkosakoです。

Rettyではこの一年開発組織における課題発見とその解決に向けて様々な取り組みを行ってきました。

課題を洗い出して、課題感が高くかつ解決しやすいものから優先的に取り組んできましたが、一方でどのように組織を設計していくのか？といったことを考えるようになりました。

まだ自分の中でも明確な答えは出ていないのですが現時点での考えを整理してみたいと思います。

よくある課題

プロダクトを作って運用を続けると必然的に技術負債が増えていきますが、今後どのように取り組んでいくか？いつのタイミングでどう解決するのか？といったことはよく議論にあがります。

また過去に作ったプロダクトがあるが運用責任者がいなかったり、オーナーのいない機能やツールなど宙に浮いた責務問題などもよく見かける課題だと思います。

その他にもエンジニアのhuman managementはエンジニアがやったほうがよいということがよく言われますが、やりたがるエンジニアがいなかったり、いても人数が足りなくて一人に負荷が集中するといったこともよく聞く話です。

役割を作る

開発組織において、様々な役割は存在しており

• CTO
• VP of Engineering
• Engineering Manager
• Product Manager
• Tech Lead

などがあります。

その他にもシニアタイトルやアーキテクト、リードエンジニアなどもありその定義も明確なものではなく、なんとなくのイメージはあるものの組織に合わせて定義されるものだったりすると思います。

ここで、この課題を解決する役割の人はTech Leadがあっているようだといったことをしていくと短期的には課題が解決されたりしますが別の課題が出てきます。

似たような役割がふえてしまい結局責務が曖昧になってしまったり、役割ではなく役職になってしまい責務はないのに肩書がある人がふえてしまったり、一つのことに複数の責任者がいることになってしまったり(指揮系統の混乱)、役割を担える人数が足りずにチームをまたいだ兼務の人が増えすぎてしまったりといったことなどが考えられるかと思います。

もちろん組織の規模により必要な役割は増えていきやすいものですが、基本はできるだけシンプルに保つほうがよいはずです。

必要なことは組織やチームで必要な責務を明確にすること、そしてその責務を果たす人がちゃんといることです。

そのためには役割はできるだけシンプルにしてある程度抽象的な役割にしておき、実際の責務をだれにどう割り振るかはそのチームごとに決定するほうがよいと考えています。

その決定事項をjob descriptionとしてチームで共有するといったことなども有用だと思います。

ちなみにどうしても担える人がいない責務はチーム外にアウトソースする選択肢を持つといったこともありでしょう。

では様々な役割がある中でどのような役割を設置すればいいのでしょうか？

それを考えるにはエンジニアや開発だけを見るのではなく組織全体を見ながら考えることが必要になってきます。

事業部制組織と機能別組織

組織の形の話をするときによく出てくるのがこの2つになります。

事業部制組織

事業部制組織はプロダクトや顧客といった単位で事業を区切って組織を作る構造です。

区切り方はサービスごとだったり、toC・toBといった顧客のタイプだったり、営業組織などでは関東や関西といったエリアごとになったりします。

WEBサービスの開発ではにおいては、アプリチーム、検索チームといった形が一般的でしょうか。
そのチームの中にチームリーダー、デザイナー、エンジニアなど様々な職種の人間で構成されます。

メリットは意思決定がチームに与えられるためスピードが早く、全員がチームの目標に向かえるためモチベーションも高い傾向にあります。

デメリットとしてはチーム関連系が弱くなり全社でのノウハウ共有や共通化といったことが問題になりやすいといったものがあります。

機能別組織

機能別組織はR&D、エンジニアチーム、デザイナーチームといった機能別だったり職種別で組織を作る構造になります。

メリットとしては知識の共有が進み専門性が高めていけるところだったり、効率性を非常に高めることができます。

デメリットとしては最終的なプロダクトに対する意識が低くなりやすかったり、職種をまたいだ連携がやりにくくなったりするといったものがあります。

また、意思決定までのラインが長くなりがちで問題が起こったときに各部門だけで意思決定できなくなってしまうといったことも問題になります。

マトリクス組織

それぞれにメリット・デメリットがあるわけですが、スタートアップにおいては基本事業部制をとっているところが多いと思います。

理由はいろいろあると思いますが、不確実性が高い状態においては、意思決定までのコミュニケーションパスが少なく調整コストが低い事業部制が有利になります。

一方で、技術負債の蓄積などによりサービスのフルリニューアルや基盤の統一化といったことをが必要になった時に理解が得られにくい、決断できないといった課題を抱えてるケースも多く見られます。

そこで機能と事業の両方の軸を取り入れたのがマトリクス組織となります。

事業部制と機能別のいいところどりをしようとして導入される形態ですが、もちろん銀の弾丸ではありません。

完全に権限が同じだとうまくいかない例が多く、一人に二人のbossがつくことになるため信頼関係がより強くなった方に嫉妬が生まれるといったことも起きやすくなります。

基本的にはマネジメントの難易度が高く難しい形態であり、調整コストも高くなりがちです。

したがって何を優先するべきかを考えた上で権限、責務の差をつけるようにしたほうが難易度は下がると思います。

• プロダクトの成長やマーケットフィットが優先事項の場合は事業部を強くする
• 高度な技術の開発や基盤の構築が優先事項の場合は機能部門を強くする

今の自分たちに必要な組織デザインとは?

では結局どのようなカタチにすればいいのでしょうか?

エンジニアだけ見てあるべき論で役職や役割を設定してしまうと既存の組織デザインとコンフリクトすることもあり、対立構造になってしまうリスクがあります。

今が間違ってるとかあるべき論が正しいとかではなく、現在の組織がどのような意図をもってデザインされているのか?それが事業フェーズや組織の成長によってリファクタリングが必要なフェーズに来ているかどうかといった視点で考えてみる事が重要ではないかと思います。

またエンジニア組織が事業においてどのような役割になっていて、解決するべき課題はなにかといったことを考えて変えていかなければ、実情にそぐわなくなってしまう危険性があるので注意したいところです。

過去現在未来何を重要と設定してきてどう変化していくのかという観点から、全体の組織デザインを考えること。そして今と未来が繋がるように移行プランも考えながら実行していくことが重要ではないでしょうか。

これはEngineering Manager Advent Calendar 2018 22日目の記事です。
(遅刻しました、ごめんなさいごめんなさいごめんなさい。)

とあるIT企業で、エンジニアのチームのマネージャーをやっています。¹

スロースターターかつスローモーなもので、10年以上マネージャーをやってきて、ようやくここ数年、自分なりのマネジメントのやり方に自信とか確信とかいうようなものができてきました。それまでは、上司や先任のマネージャーにダメを出されて自信がぐらぐらすることが多かったように思います。自信をぐらぐらさせながらも続けてきたことが結果になって表れるのを何度も経験したことと、同じ考えでマネジメントをやっている方々が自分以外にもたくさんおられることを最近知ったことで、「あ、俺、意外と間違ってなかったじゃん」と思えるようになってきた次第です。
そんな私の自分なりのやり方、意識してこころがけてきたことを、初めて文字にしてみました。EM Advent Calendar を書いている方々/読んでいる方々にとっては、あたりまえのことも多いかと思いますが、ご笑覧いただければ幸いです。

1. チームを心理的安全性の高い場にするために

マネージャーになった当初から (当時は「心理的安全性」という言葉はありませんでしたしそんな高尚なことを考えていたわけでもなく) 妙に気をつかった堅苦しいコミュニケーションをするのもされるのも嫌いで、私とチームのメンバーとの間もメンバー同士の間も、言いたいことをフランクに言い合える間柄にしたいと思っていました。そうなるように、と言うよりも、そうならなさそうで嫌なので避けていたことがこんな感じです。

上下関係にしない。 (「部下」「上司」という言葉を使わない、役職で呼んでもらわない)

辞令が出たその日に「課長って呼ぶの禁止な」と宣言しました。「部下」「上司」という言葉を使うのもやめました。

自分のダメなところも隠さず晒す。

私が、マネージャーとしてどころか社会人としてどうよっていうくらいのダメっぷり ─ 期限を守れないとか…このエントリみたいに ─ なもので、隠そうにも隠しようがなかったというのがほんとのところです。

叱らない、提案する。人前ではやらない。
否定しない、なにごとも一旦は「共感」する。

自分が「上司」からやられてモチベがだだ下がりになったことが反面教師になりました。

褒めない、感謝する。みんなの前でやる。

お気づきかと思いますが、アルフレッド・アドラーの受け売りです。これはごく最近知って、変えました。

2. チームを自律的組織にするために

「自律的な組織にしましょう」とは昔も良く言われていたのですが、そのわりには、いちばんダメ出しを食らって自信がぐらぐらしたのがこのあたり、指示しないこと、決定・決断しないことでした。

指示しない、提案・アドバイスする。
決断・決定しない、チームに任せる。チームの決断・決定は無条件に支持し責任をとる。

私が、適時的確に、指示したり決断したりできるほど有能ではなかったってだけです。 その代わりというか、私にでもできることは「ケツを持つ」ことくらいだと思ってそこは徹底しました。

情報は原則オープン。アクセスを制限しない。

どうも日本人は (って主語大きすぎかもですが)、原則「非公開」例外的に「公開」なことが多くて不満だったことの裏返しです。ただし、制限はしてませんが、積極的に共有できているかというと、なかなか大変でまだまだできているとは言えません。

思いを、ありたい姿を語る。常に、何度も。

「マネージャーは組織のビジョンをチームのビジョンにブレークダウンしてチームに伝えるべし」みたいなことをよく言われますが、そう簡単に伝わりゃ苦労はしません。組織の/チームのビジョンを自分の「思い」まで消化/昇華して、何度も何度も「あー、また言ってるよ」と言われるくらいまで、ことあるごとに語らないと伝わらないよなと、これだけは長年やっていたおかげで、実感しました。

3. 人を活かす

得意がない人はいない、だめな人もいない。全力で得意を見つける。
問題行動は「場」が原因、場を改善して解決する。
問題の原因は人ではない、コト。

このへんも昔からなんとなく思っていたことですが、ここ数年の実体験で確信に変わってきました。 得意なことが見つかったり、場が (心理的安全性が高いとかに) 変わるだけで、人って変わります。 ただし、得意なことを見つけたり、安全な場で心を丸腰にして動けるようになるまでに、年単位の時間はかかります。

得意をメンバー間で相互補完する。不得意を無理に改善させない。
多様性を全面的に肯定する (得意不得意、性格、考え方、働き方、etc)

学生のときは「不得意科目の点数を伸ばしなさい」とよく言われたものですが、それは得意科目には100点満点という上限があったからなんですね。でも社会に出たら満点も上限もありませんから得意なことは伸ばし放題、不得意を改善するよりも、本人にとってもチームにとってもはるかにお得だと思うのです。

4. サーバント リーダーシップ

これも、言葉を知らないころから、自信はないながらもなんとなくそのように行動していました。最初は Simon Sinek だったと思いますが、この考え方を知って膝を打ちました。その後、前述のアドラーやロッシェル・カップさんなど、いろいろな方の知見で

「信用」ではなく「信頼」する (無条件に信じる)。性善説に立つ。
チームとメンバーを守る盾になる。

5. 技術

技術力では、チームメンバーにはまだ負けないぞ、と思っています。もちろん、技術のディテールや実践経験でチームメンバーを上回るのは難しいですが、自分の知識・知見を常にアップデートして、チームが技術で困ったとき・悩んだときには一緒に悩めるように、高い視点と広い視野は維持し続けたいと思っています。

チームに高い視点と広い視野を提供する。
悩むときは一緒に悩む

私のこういう「こころがけ」がどれだけ奏功しているかは検証できていませんが、今のところチームは、私が年寄りゆえに研修や啓蒙などの業務に引っ張って行かれてなんだかんだで1週間くらいオフィスに顔を出せなくても何の問題もなく(?)回っているし、親子に近いくらい年齢の離れたメンバー同士が相互に教え・教えられしているし、いい感じに回っていると思います。でも実は私には見えていない問題を抱えているかもしれないし、近い将来何かをきっかけにおかしくなり始めるかもしれない。この「こころがけ」は、EM Meetup や EM.FM や、ここ集まったみなさんの知見も参考にさせていただきながら、アップデートし続けていかないといかんと思っています。

このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。

はじめに

拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。

この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。

しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。

拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。

本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで働く力学が同質のものであることを示しながら、技術的負債現象が引き起こる機序をより高い解像度で理解するための一つの考察です。

そして、このテーマはエンジニアリング組織論への招待の第6章の一部になる構想だったのですが、一定の難解さと説明の煩雑さがあるため割愛しました。

アーキテクチャってなんだろう

アーキテクチャという言葉はわかるようでわからない曖昧な言葉です。建築やソフトウェアにおける「構造」をさしていて、何らかの基礎となる仕組みや大まかな形、”つくり”を意味しているように思われます。

ですが、アーキテクチャにはどのような目的があり、どのような性質があるのかと問われると非常にやっかいで理解しづらいものです。

ここでは、法学者のローレンスレッシグの定義をうまく採用して、理解を深めていきたいと思います。彼は「CODE―インターネットの合法・違法・プライバシー 」において人間の行動を制約するもの（権力）の１種類として「アーキテクチャ」をあげました。

その中で、「ある選択肢を選びやすくする」「ある行動が不快になるようにする」という性質を環境に与えることで、人々が自発的・自律的に特定の行動を促すようにするものを「アーキテクチャ」と呼びました。それらは社会のそこかしこに、あるいは卑近にWebサービスの中にもあるものです。

たとえば、Amazonのレコメンドシステムはユーザーに対して以前購入したものと同じような書籍を購入しやすくすることで、より消費をすることを促すようになります。

たとえば、公園や高速道路の下に置かれた排除型ベンチや排除型アートと呼ばれるものは、公園で眠るホームレスを寄せ付けにくく、行政の手間を下げるように作られており、批判を浴びることになりました。

たとえば、Ruby on RailsなどWeb Application Frameworkは、Webサービスを作りやすくする代わりに、様々な制約を課します。このような制約を遵守する限りにおいて、特定の種類のサービスを作りやすくしています。

このように「しやすさ・しにくさ」を提供し、「ある方向に」人々を導く構造のことをアーキテクチャとして理解すると曖昧だった言葉が少しだけクリアになりました。

では、この定義によるとシステム全体をめぐるアーキテクチャは果たして、ソフトウェアアーキテクチャだけなのでしょうか？

たとえば、「ビヨンドソフトウェアアーキテクチャ」においては、ビジネスやユーザーの振る舞いに対するアーキテクチャを『マーケテクチャ（Market + Architecture）』とよび、いま風にいうのであれば、プロダクトマネージャの仕事を『マーケテクト』と呼びました。

同じように、ソフトウェアを描くチームと技術的な市場変化に対してのアーキテクチャを『ターキテクチャ(Tech + Architecture)』と呼び、今風にいうのであればエンジニアリングマネージャやテックリードの役割のことを『ターキテクト』と呼びました。

これらの区別は非常に重要な示唆です。アーキテクチャというとどうしても「技術上の話」だけだと捉えてしまいがちなのですが、そこには「導かれる人々」がいて、「導かれる方向」が存在するのです。そして、どちらもその意味ではアーキテクチャには違いないのです。

これらはUXの文脈や認知心理学の文脈で言うところの「アフォーダンス」と言う概念もまたアーキテクチャと類似する概念だと言えます。つまり、何かをしやすく、あるいはしにくくする誘発性をどのように理解するかということです。

デザインつまり設計という概念がアーキテクチャと切っても切れない理由はこのあたりにありそうです。

「エンジニアリング組織論への招待」においても、何かをしやすく・しにくくするもの、そして見えない坂道のように知らず知らずに人を一方向に動かすものが組織に働いていることを言及しました。

このような視点で見ると、あるシステムの中には：

• ビジネスのアーキテクチャ
• ソフトウェアのアーキテクチャ
• デザインのアーキテクチャ
• 組織のアーキテクチャ

など複数のアーキテクチャが混在しているように思えます。

選択肢と権力と依存

誰かが「何かをしやすく・何かをしにくくする」ということについて考えるのであれば、「選ぶ」と言うことについて考えてみる必要があるでしょう。社会交換理論や権力依存論を援用しながら「選ぶ」こととアーキテクチャについて考えてみましょう。

私がたとえば、今日の夕食を考えるとして、

• 近所のラーメン屋
• 遠くの高級火鍋

という選択肢があるとしましょう。

このとき、すごく寒い日であれば、火鍋という選択肢はとても魅力的に移ります。しかし、寒い中を移動する必要があります。さらに高級店なので値段も高いのです。近くのラーメン屋であれば、手軽でリーズナブルです。そこそこ体も暖かくなるでしょう。

このような状況の中で、たとえばUberEatsのような宅配サービスが登場し、しかもキャンペーン中であったため、格安で遠くの火鍋が自宅に届けられることになったとします。宅配サービスでは近所のラーメン屋は選べませんでした。これより価格と距離という２つの選択を妨げるアーキテクチャが変更され、私は火鍋を食べることを自然と選ぶようになりました。

このように選択肢の優先順位が変わったり、他の選択肢が見えなくなったりすることで、個人の自由意志で選んでいるはずが、知らず知らずに選ば"される"ようになってしまいました。

さて、その後、私は高級火鍋を頻繁に食べるようになります。体も温まり味も美味しいので、値段はともかく食べたいと思うようになりました。このようなおり、宅配サービスはキャンペーンが終わり値上げをするようになります。いつの間にか火鍋の刺激に慣れてしまった自分は、値段が上がったとしても宅配サービスを利用するようになっていきました。これはある種の依存です。

実は、この依存というものは、ソフトウェア設計においても非常に重要な概念であるだけでなく、アーキテクチャと選択肢の関係を考えるためにも重要な概念なのです。

アーキテクチャが何か１つの方向に人々を導く背景には、「見えない力」が働くからです。そしてそれは、「選ぶ側」から「選ばれる側」に対して働くことになります。

言い換えるなら、「選択肢を持たないもの」は、「選択肢を持つもの」よりも理不尽な目に遭いやすいということです。このような力のことを「権力」と言います。

たとえば、絶世の美男美女との恋愛を考えてみましょう。彼ら/彼女らにとってパートナーの選択肢は無数にいます。そのため、多少のわがままも許されるでしょう。かぐや姫のストーリーなどまさにそのようなものです。

たとえば、DVを行う夫がいる妻を考えてみましょう。女性の経済的自立が難しい社会や離婚が社会的に是認されていない社会においては、残念なことにその夫が唯一の選択肢に見えます。その結果、理不尽な暴力に晒されやすく、権力の影響を受けやすくなってしまうのです。

たとえば、現在のエンジニアの求職状況を見てみましょう。ソフトウェアエンジニアは、平均求人倍率が8倍程度あり、都内で働く優秀なWebエンジニアであれば10倍~20倍は超えるでしょう。このような状況では、求職者は『選ぶ側』になります。そのため、権力は求職者に宿ります。結果的に待遇や環境はよくなっていくことになります。最近の働き方改革などのムーブメントはこのような求人が増えてきたことと無関係ではないでしょう。

一方、求人倍率の低い時代、また労働流動性の低い時代であれば、会社に従業員が尽くすといったロイヤリティを求めることがあります。これは、「権力」が会社側に存在しているからだと理解することができます。

このようにして、「選択肢を豊富に持つ側」から「選択肢を持たない側」に対して何らかの力学、「権力」が働くことになるのです。

これにより、権力を持つ側は、持たない側に対して、望まない理不尽な選択肢を選ばせることができてしまいます。このような望まない理不尽を受け入れざるを得ないような状態を「依存」といいます。

もし、別によい選択肢を持っていれば、また別の選択肢を提供する仕組みがあれば、依存は発生しません。ブラック企業に勤めている人であっても、他の条件のいい転職先があれば（そしてあることに気がつければ）、理不尽を受け入れることなく転職していくでしょう。理不尽な暴力に苦しむ女性も、経済的自立や助けを求める手段があれば、依存から逃れることができるでしょう。

一方、選択肢が他にない、つまりは交換不能な依存関係のことをソフトウェアにおいては、「結合」と呼びます。理不尽は結合から生まれるのです。

このようなとりうる選択肢（オプション）の不均衡が、社会的な意味での「依存」と「権力」を生み出します。社会的な関係性の明晰な記述に過ぎないソフトウェアアーキテクチャにおいてもこの関係は成り立つのは当然のことだと言えます。

あるシステムを作る時、そのパーツを交換可能で「他に選択肢がある」ように維持するということはアーキテクチャを考える上で重要な視点です。たとえば、GoFのストラテジーパターンなどをつかって、複雑なアルゴリズムや処理をコンポジションによってあとから差し替え可能に設計することは、あるパーツを交換可能に維持するための工夫の１つです。

これはテストを書くことやインタフェースに依存することも同じです。何かを良くするためには、異なるものに「交換できる」という条件が必要不可欠です。ユニットテストやインターフェースは、つまりはある用途を満たすコードを別のより良いコードに交換するために必要な条件です。

そのため、テスタビリティが高いコードは、疎結合になりやすいといった現象やDIコンテナを用いたコードがテストしやすいという現象が発生します。これらはどちらも交換可能であるということを維持し、結合に伴う権力の作用を避けることができるからです。

システムのコントローラビリティ

このような「交換可能である」がゆえに良いものにできるという関係性は、ソフトウェアの一部だけでなく、そのシステムをとりまく価値のすべてにおいて成り立ち得ます。

システムの一部や部分の「変化」を受け止めるためには、その変化に見合った一部または全部を交換する必要があります。しかし、交換可能な部分が少なければ少ないほど、コントロールが効かなくなります。

たとえば、20年前に作られて今なお現役で動いているシステムを考えてみましょう。

社内には誰も担当者や外部仕様すら正確に知っている人がいない、その上、ソースコードも管理されていない。自動テストもなく、受注側の企業の担当者もすでに離職している。こんなとき、このシステムを部分的に交換しようとするのはとても難しいことです。受注側もリスクの割に実入りが少なければ、あまり受けたい仕事ではないでしょう。このようになると、交換が非常に難しいシステムになります。

一方、同じ２０年間動いていても、社内の同じチームや近い位置に意思決定者もデザイナーもエンジニアもおり、頻繁に修正をかけながら、自動テストやサービスの分割、継続的デリバリーの進んでいるシステムであればどうでしょう。部分的な要求変化に対して、素早く高い生産性が出せるでしょう。

これは、システムの一部を常に別の選択肢へと「交換しやすいアーキテクチャ」を手に入れるために、マーケティング、チーム文化、セキュリティ、プロセス・プロジェクトマネジメント、ソフトウェア設計、テスト品質管理、運用監視、意思決定フローなどバリューチェーンの全てにおいて余分な依存や結合を排除してきたことから生まれる生産性です。

コントローラビリティの喪失とホールドアップ

ある取引関係において、「他に代替手段がない」ということから、理不尽な要求をうけてざるを得なくなってしまうことを経営学的にはホールドアップ状態といいます。このような状況では通常より高い料金を受け入れたり、理不尽な要求を飲んだりする必要があるため、避けなければならない事態です。

特定のベンダー製品に依存していて、別の製品に置き換える時に非常にコストがかかるため、その手段が取れないことを指して、「ベンダーロックイン」と表現することがあります。ホールドアップ状態というのは、ベンダーロックインと同一線上にある状態です。

システムの開発において、徐々に別の選択を選ぶコストが高くなっていき、最終的には全てを入れ替えなければならなくなるという現象を我々はよく知っています。それを技術的負債と呼ぶのです。技術的負債という現象をミクロに捉えるとソースコードレベルの理解を要求するものですが、マクロに捉えると、非常にありふれた経済現象なのです。

ある取引関係において、ホールドアップリスクを避けたければ、もっともシンプルな手段は、取引コストをゼロにする戦略が考えられます。それが内部化です。これはシステムにおいても同様です。

このようにある組織がシステムを持つ場合、より良くするためには、一部または全部をより良いものに交換するという選択を持つ必要があります。このシステムに対しての交換可能性（コントローラビリティ）は、大雑把には５つの段階が考えられます。

レベル１：制御不能レベル

どこで、どのように動いているのか、そして何を要求して何が満たされているのか、見当がつかない状態。担当者が丸投げした上に退職し、契約書も残っていないなど、信じられないかもしれませんがこのようなシステムは数多く存在します。

誤解をしないようにしたいのは、この制御不能レベルにあるソフトウェアのコードの品質が高いか低いかは関係がないということです。仮に非常に高い品質のエンジニアが書いたとしても、その企業がまったく理解していなかったら、どんなことが起こるのかわからない爆弾になってしまいます。

レベル２：外部仕様レベル

発注者が優秀で、要求事項がすべてドキュメントで残っており、最新に維持されています。そして、変更のたびに検収のプロセスを多重に動かしているため、「何を求めて」「何が出来上がったか」については、かなりコントロール下にあるというレベルです。

しかし、プロジェクトマネジメントの主体やソースコード、要件レベルの内部ドキュメントは、自社に存在しないという状態です。

これらの要求レベルのドキュメントがあれば、最悪、別のシステムとしてを作り直すのは至難の技ではありますが、不可能ではありません。しかし、システムの中身自体を理解しているのは特定の外部業者という状態です。このとき、ソフトウェアの大きさが大きくなればなるほど、全体を交換するのにコストが巨大になります。こういったことから、その外部業者を別の業者に交換することが徐々に難しくなってしまいます。

レベル３：ソースコードレベル

複数のベンダーまたは、フリーランサー、自社人材で編成されたチームによって、

• 要件レベルのドキュメント
• プロジェクトマネジメント
• ソースコードのバージョン管理
• デプロイ自動化
• モニタリング
• 開発プロセス

などがマネージされている状態です。

この状態であれば、ホールドアップリスクとして顕在化する前段階の、技術的負債に自社として気がつくことができます。そもそもレベル１、２では経営的危機として顕在化するまで、技術的負債の存在にすら気がつけないのです。

システムの内製化について取りざたされる時、たとえばSIやSESの業態で働く人々の品質問題として語られることが多いのですが、実際にはどの業態であっても優秀な人も優秀でない人もいます。

内製化とは、自社で何も理解していない状態でコアコンピタンスとなる事業のシステムのコントロール権を喪失してしまうことを避けるための手段に過ぎません。むしろ、事業のコアコンピタンスでないのであれば、外部業者を利用することは合理的な選択肢です。

カレー屋さんはお米は自分で作らず買ってきますが、カレールーは自分で作ったほうがいいでしょう。何が事業価値の源泉かを特定して、そこに資源を集中するのが経営の基本です。

レベル４：アーキテクチャレベル

レベル３の段階に加えて、ビジネスとシステムの両面の理解をもった人物が、次のような抽象的な構造をビジネスとシステムの中に見出し、アーキテクチャレベルでコントロールが効いている状態：

• 戦略的技術選定
• レイヤードアーキテクチャ
• コアドメインの抽出
• システムのセグリゲーション
• インフラ自動化・デプロイ自動化
• 継続的インテグレーション
• ソースコード品質のモニタリング
• コードレビューガイドライン
• プロジェクトマネジメントの成熟

これらが満たされていると、しばらく長い間システムはコントロールできているように見えます。実際には、卓越したアーキテクトの仕事がそのプロジェクトで一時的に機能していただけのケースに過ぎないかもしれないのです。

そのアーキテクトが退職してはじめて、彼がSPoF（単一障害点）であったことに気がつきます。交換不能な存在だった彼に対しての依存度が高くなってしまい、アンタッチャブルな存在になってしまったり、英雄的犠牲を彼に強いてしまったりということもままある話です。このような歪な関係のもと、システムが腐らずに済んでいる状態とも言えます。

レベル５：チーム文化レベル

最終段階のレベル５は、中長期にわたって、レベル４で実現する品質を維持したり、より良くしていくことができるチーム文化や組織風土のレベルでシステムをコントロールできている状態です。

• ADR(Architecture Decision Records)の記録
• TDD・モブプログラミング
• 機能横断型チーム・全体論的多様性
• 学習する組織
• 継続的デプロイメント
• トランクベースの開発
• 多能工・T型人材
• 進化的アーキテクチャ
• DevOps
• シフトレフト
• 心理的安全性の高さ

この状態になると、「システムが満たしたい目的」に対して、時代の変化や技術的背景の変化などがあっても、チームのレベルでそれを吸収し、より目的に合致したシステムに変更していくことができるようになります。事業も、ある瞬間のシステムのスナップショットを提供するのではなく、継続的に価値を提供するソフトウェアサービスを提供することになります。

つまり、よくできた買い切りのパッケージ製品がレベル４のシステムであれば、継続して改善されていくサブスクリプション型のSaaSがレベル５のシステムだと言えます。

その意味では、ソフトウェアサービスとは、ある機能を提供しているのではなく、継続的にその目的を果たしつづける組織やチーム文化を提供しているビジネスと言い換えることができるのです。

モダンアジャイルやDevOpsの潮流というのは、取るに足らない流行り廃りではなく、ビジネス環境がより継続的なソフトウェア価値の提供を求めるようになったというマーケットの変化に呼応したものなのです。

ハードウェアをソフトにしたものか、ウェットウェアをハードにしたものか

ソフトウェアシステムのコントローラビリティを上げていき、より良いものに交換可能な状態を維持しようとすると、自然とチーム内のコミュニケーションや文化といった無形の資産の蓄積が不可欠になってきます。

エンジニアリングマネージメントが注目を集めはじめた最大の理由は、ソフトウェアを作りっぱなしではなく、継続的に機能提供をしていくことの難しさと価値に対して、ソフトウェアとそれを作るチームというものを構築する必要性があったからと言えます。

多くの旧来的なソフトウェアの価値観は、ハードウェアの付随品として、設備投資と同じように提供できるものだと認識されていたように思います。つまり、ハードウェアを少し柔らかく変化させやすくしたものという理解がされているように思います。この世界観では、一度投資したら、ほぼほぼずっと使い続けられるものであるように見えます。

ですが、実際にソフトウェアサービスを提供している感触としては、ハードを柔らかくしたものではなく、チームやビジネス上の暗黙知として存在するウェットウェアをより明晰にハードにしたものだと見えています。この世界観では、継続的・持続的に提供するチームが、企業内部に入り込む形で作られるものであるように見えます。

変わりやすいもの/変わりにくいもの

ソフトウェアにしても、ビジネスにしてもその外的な条件から、「変わりやすいもの」と「変わりにくいもの」が存在します。たとえば、人類がうまい食べ物を必要としているということは、あと１００年くらいはそのままな気がします。でも、チーズダッカルビを食べたいと思うのは、ここ数年くらいのものでしょう。

ペースレイヤリング

このような変わりやすさと変わりにくさに注目して、それを建築の分野に取り入れたのが全地球カタログでも有名なスチュアートブランドでした。

彼は、「How Buildings Learn」の中で、ペースレイヤリングと呼ばれる概念を創出しました。それは建物の変化と時の流れがどのような関係を持つかを示したものです。

５つの階層が建物の変化には存在していて、変化のスピードがそれぞれ異なるということを

用地（Site）は、建物よりも長く永遠に近い期間持続するもの。そしてのその上に建物(Structure)が建てられて、数十年から数百年は持続する。外装(Skin)は10年程度で、リフォームされ、その中にあるキッチンやエアコンなどの設備は5,6年で老朽化していきます。どんな風に部屋を使うか(Space Plan)は1年や2年は同じだけど、日用品 (Stuff)は毎週変わったりします。

ここで重要なのは、依存は常に「変わりにくいもの」に対してのみ行われるということです。「変わりやすいもの」に「変わりにくいもの」が依存するようになると、全て丸ごと交換する必要が出てきます。

たとえば、部屋の中であれば、インテリアや日用品のラインナップと同じ周期で引っ越したり、建物を立て替えるような人はいません。でも、床色やインテリアに合わせて、日用品を選ぶことはあります。

不動産屋さんに言わせると、他の不満はなんとかできるけど、立地の不満だけはなんともできないことが多いから、まずは立地から決めていくことが多いそうです。これも一種のペースレイヤリングです。

ペースレイヤリングという考え方は、建築だけでなく、Webシステムにおける情報アーキテクチャやUXの5Sへと転用されていくことになります。

また詳しくは、「思想としてのペースレイヤリング」という大変素晴らしい記事がありましたので、こちらをご参照ください。

ソフトウェアにおけるペースレイヤリング

ソフトウェアにおけるペースレイヤリングとして有名なのは、ガートナーのSoR/SoE/SoIの議論です。システムの変動性に合わせて:

• SoR( System Of Record　 )
• SoE( System Of Engagement )
• SoI( System Of Innovation )

という三階層に分割でき、それぞれが異なる開発サイクルを持つという発想です。ガートナーの分類は、ここからさらに踏み込んで、開発プロセスや開発手段とが階層ごとに異なるやり方が適切であるといういささか我田引水がすぎる主張をしているきらいがあります。

しかし、ペースレイヤリングという観点をアーキテクチャに持ち込むのは非常に重要な論点だと思っています。むしろ、ペースレイヤリングの重要性が導かれるのは、その抽象性と依存という関係からです。

ソフトウェアの設計原則に、抽象依存の原則(ADP:Abstraction Dependency Principle )というものがあります。依存するならば、より抽象的なものに依存しろという原則です。

また、もう一つ重要な原則に、安定依存の原則(SDP:Stable Dependency Principle )というものがあります。依存するならば、安定しているものに依存しろという原則です。

たとえば、配列をソートする関数があったとします。このとき、利用する側は、ソートするという目的を果たせればいいので、ソートアルゴリズムはそこまで気にしません。より、抽象的なものに依存してコードを書くようにすれば、ソートのアルゴリズムが変わっても利用側のコードを変える必要はありません。

このように、より抽象的(より目的に近い）コードに依存し、より具体的（手段に近い）コードを交換可能にしておくことで、ソフトウェアは変化に強く設計できるようになります。逆に、特定の手段を変更するときに引っ張られて、広い範囲に影響してしまうと修正にたくさんの時間をようすることになります。

これは、抽象的な目的の方が変化しにくく、具体的な手段の方が変化しやすいという性質から導かれているのです。これは、クリーンアーキテクチャやオニオンアーキテクチャと呼ばれる階層型のアーキテクチャが生まれた機序と同じものです。

ですので、アーキテクチャ設計をする際には、変化しにくい部分を抽象構造として見つけ出し、それを抽出する必要があります。これが、コアドメインオブジェクトの抽出や蒸留と呼ばれるような設計上の重要な視点になります。

ビジネスアーキテクチャ：ゴール設定と抽象のはしご

さて、私たちがビジネスを組織やチームで行うとき、ミッションやビジョンを設定することがあるかと思います。あるいは、戦略を決めて、行動に落としていくというように、より不確実で、抽象的で複数の手段を取りうる「目的」から、より具体的で選択肢の少ない手段へと落としていくことでビジネスを展開していきます。

これらは、つまりはペースレイヤリングであり、ビジネスのアーキテクチャなのです。

たとえば、「世界を平和にする」というミッションがあったとします。これは、組織の存在理由なので、なかなか変化する事はないでしょう。しかし、これだけでは抽象的すぎて、どんなときに使ったら良いかわかりません。

これをさらに、数年後のビジョンを考えます。到達したいと思うある未来の状況をよりクリアに伝えるのがビジョンです。一緒にゴールのタイムマシンに乗り込むことがビジョンです。

その数年後のビジョンを達成するにはどうしたらいいのでしょう。より具体的な筋道を考えていく必要があります。この筋道、どんな道を通っていくかが戦略です。

その戦略を実現するための作戦があり、そしてそれが個々の行動へとつながっていきます。

しかし、これらは下の階層に行くほど、目的に対して、手段という関係なので、無数に選択肢が存在するため、変動しやすくなります。組織におけるゴール設定については、また別の記事で詳しく述べます。

いずれにせよ重要なのは、目的の方がより変わりにくく、手段の方がより変わりやすいという階層構造を持っている事です。

そして、目的に対して手段が交換可能でなければ、それは悪い依存として、組織の目的を果たして行くのに支障がててくるという事です。

アーキテクチャのフーリエ変換と不確実性の波

目的と手段、抽象と具体という階層構造における交換可能性がアーキテクチャと呼ばれるものの正体でした。交換しにくければ、それは理不尽な権力となって無駄を生み出します。

そして、これは、外的なマーケット環境に潜む不確実性から織り成されるものです。不確実性は波のようなものです。複数の激しい周波数成分の波とゆっくりとしか変化しない波があります。これらは、いつもは折り重なっているので、その１つ１つを抽出する事は難しいのですが、アーキテクトはこれらを見極め、段階的にこの構造を構築して行く必要があります。

これはあたかも、プリズムが白色光を七色に分解するようなもので、数学的にはフーリエ変換のようなものです。異なる周波数成分に分解し、レイヤリングすることで変化に対して必要最低限のアクションで対応できるようになります。

コンウェイの法則の成り立つ背景と相互作用

コンウェイの法則が成り立つ背景には、ビジネスとソフトウェアの２つアーキテクチャが同じ不確実性の波に向き合っていることがあります。そのため、意図せず類似する構造を持つようになるのです。

また、ビジネスのアーキテクチャに従属して、組織構造が作られるので、組織構造に合わせたソフトウェアの設計がされがちですし、ソフトウェアのアーキテクチャのつくりによって、実現しやすい仮説検証とそうでないものが決まってしまうため、ソフトウェアアーキテクチャに合わせて組織が作られることも起こりえます。

組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導けると思います。

また、その逆に優れたシステムの構造が、良い組織構造を生み出すことも起こり得ますし、同様に技術的負債が組織の悪しき硬直性を生み出すことも起こり得るのです。その意味で、組織とアーキテクチャには密接な相互関係があります。

これは、抽象と具体、目的と手段の構造が本質的に同じ１つの階層構造に同居しているはずだからです。にもかかわらず、アーキテクトとビジネスオーナーという情報が非対称である二人の頭の中にだけ存在していることが多いものなのです。

そのため、エンジニアリング組織論への招待では、技術的負債という言葉がそもそも取りざたされるのは、この情報の非対称性にこそあり、技術的負債現象自体に拘泥すると本質を見失うのではないかという論を展開したのです。

参考図書

• クリーンアーキテクチャ
• アジャイルソフトウェア開発の奥義
• 権力の予期理論
• How Buildings Learn
• 選択しないという選択
• 交換と権力―社会過程の弁証法社会学
• Hatch組織論

おわりに

結構、長い話を短く納めたので、わかりにくところが多いと思います。
補講をちょっとずつ足したいな。