「無人化システム」を駆逐する組織マネジメントとエンジニアリング
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。
恐怖の無人化システム
「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。
無人化とはなにか
無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。
ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。
無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。
無人化システムとはなにか
システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでいます。
無人化システムは「誰も詳細は知らないが、なぜか動いているシステム」です。人知れず勝手に動いてくれれば誰も困らないはずですが、実際には次のようなシチュエーションで問題になります。
- 障害やエラーが発生し、正常にシステムが機能しなくなる
- 周辺状況の変化に伴い、仕様変更が発生する
誰も詳細を知らないので、このような問題が発生してもどうにもなりません。だって知らんし。
無人化システムの技術的なツラさ
残念ながら弊社では無人化システムがいくつも誕生してしまい、エンジニアを大いに苦しめてきました。システムによって技術的な課題は異なりますが、いくつか例を紹介しましょう。
- アプリケーションのソースコードがまったくバージョン管理されていない
- 秘伝のタレが継ぎ足され続けて再構築不能なサーバ
- ひとつのサーバに責務の異なるアプリケーションが相乗りしている
- システムの目的が不明で、現在正しく動いているのか判別不能
- バージョンアップされていないOS・ミドルウェア
- テストなし・CIなし・監視なし・ドキュメントなし・デプロイ方法不明・システム構成不明
- システムを構築した人は退職済みで、一切の進化が止まっている
アンチパターンの見本市みたいになってますが、システムによっては本当にヒドい有様でした[2]。もちろん構築当時はベストを尽くしたはずです。しかし実際にこのようなシステムを目の当たりにすると、正直関わりたくなくなります。
また我々の無人化システムは大半がAmazon Linuxで動いていました。Amazon Linuxといえば2020年12月31日にEOLを迎えます。よってEOLのまま動かし続けるか、マイグレーションするかを選択しないといけません。
関わりたくないですが、ほうっておくにはだいぶアレな状況に追い込まれました。ツラいです。しかし「技術的にツラい」という問題は、無人化システムの一側面でしかありません。
無人化システムは組織を腐らせる
無人化システムは単なる技術的な課題にとどまりません。実は組織の課題でもあり、放置すると組織を腐らせます。どのように組織が腐っていくのか考えてみましょう。
知見の消失
システムが無人化すると、システムに関するあらゆる知見が消失します。「なぜ存在するのか」「止まると誰が困るのか」「正しい挙動はなにか」といったことがすべて分からなくなります。
これはシステムの無人化によって直接引き起こされる認知しやすい問題です。知見の消失自体もツラいですが、それより厄介なのはこれが「あらゆる厄災の元凶になる」ことです。
組織的無関心
知見が消失してまず起きるのが「組織的無関心」です。組織に所属するすべての人が「そのシステムと自分は関係ない」と思いはじめます。自分には関係ないと全員が思い込むため、無人化システムは決して改善されません。
それどころか無人化システムに問題が起きても、自分には関係ないからと無視する人が出てきます。これは組織を急速に腐らせます。なぜなら「問題を無視する態度が蔓延する」からです。
この態度に悪意はありません。だって自分には関係ない話なんだから当然でしょう？我々は関係ないことに首をつっこむほどヒマではないのです。
善意の人への依存
無人化システムは普通のシステムと同程度には問題が発生します。そして問題を無視する態度が蔓延した組織では、問題に向き合う善意の人が損をします。
善意の人に依存して無人化システムのオモリを押し付けると、善意の人の組織へのエンゲージメントが暴落します。自分以外には誰も問題に向き合わず、仕方なく問題に対処してもたいして評価されない状況を想像しましょう。モチベーション低下や退職を誘発してもなにもおかしくありません。
「ごん、お前だったのか…」現象はこうして引き起こされます。
問題解決能力の低下
善意の人への依存にはさらなる副作用があります。短期的には問題が解決したように見えるのです。しかしその問題解決は「対処療法」になります。なぜなら善意の人にとって無人化システムは、本来自分の問題ではないためです。そのため根本解決されません。するとどうなるかといえば、水面下で問題がさらに悪化します。
また対処療法を繰り返すと、根本的な問題解決の先送りが常態化します。そうしていずれ組織の問題解決能力を超えるレベルまで問題が大きくなり、手がつけられなくなります。
善意というのは美しく、そこに疑問を抱いたり批判をしたりする人は普通いません。下手すると「越境」などという美麗字句でもてはやされます。善意というのは個人の行動としては素晴らしいです。それゆえに心地よく、油断するとつい依存してしまいます。しかし組織の持続性の観点からは危険なシグナルなのです。
不可能な意思決定
組織の問題解決能力を超えるレベルまで問題が悪化すると、もはや改善は不可能になります。影響範囲も不明で誰が困るのか分からないため、システムを捨てる決断すらできません。
こうなると「あらゆる意思決定ができない状態」に陥ります。システムの改善も廃止もできず、対処療法による現状維持が唯一の選択肢となります。
この状態までいくと、肩書が立派な人たちも「どうしたらいいんだ…」とか言い出して思考停止します。意思決定者が意思決定をしなくなるため、ますます解決の見込みがたたなくなります。
こうして組織内の少なくない人たちが、鈍い痛みを抱えるハメになります。しかしそれが癒えることは決してありません。
不可知の因果関係
対処療法のみが唯一の選択肢となったシステムはなにを引き起こすのでしょうか。たとえば無人化システムで謎の障害が発生し、連携先のシステムがエラーになったとしましょう。するとほとんど何も分からない状態で障害調査がスタートします。もちろんこの間、もともとやろうと思っていた仕事は一歩も進みません。エンドユーザ向けのステキな機能実装も、社内の業務改善もすべてストップします。
さらに悪いことに、無人化システムに関わる仕事は難易度が高いです。そのためハイスキルな人が駆り出されます。本来であればよりよい未来を作る仕事に注力してほしい人材が、過去の亡霊との戦いに時間を費やします。
すると機能実装のスピードが遅いとか、大胆なアクションが取れないとか、生産性が上がらないといった問題として表出します。しかし問題の根幹がどこにあるか、理解されることはほとんどありません。
原因から結果が出るまでに「時間的遅れ」が発生するため、そもそも関係があるように見えないのです。
俺の屍を越えてゆけ
弊社では以前から無人化システムが問題視されており、何度か改善を試みました。しかしそのことごとくが失敗しました。ここでは失敗事例をひとつ紹介しましょう。
2017年ごろに「無人化システムへエンジニアチームを割り当てる」という対策を実施しました。無人化しているならエンジニアを割り当てればいいじゃない、という素朴な発想です。この方針のキモは2つです。
- 障害対応を含めた運用をそのチームが担い、オーナーシップを持ってもらう
- エンジニアチーム内で自律的にシステムの改善サイクルを回してもらう
誰がどう見ても完璧なソリューションです。でも失敗しました。なにがいけなかったのでしょうか。深堀りします。
なんでオレらなの？
ある日突然「キミたちこのシステム担当ね」といわれた場面を想像しましょう。最初の反応は「なんでオレらなの？」です。ぜんぜん自分事になりません。自分たちが使っているわけでもなく、チームのミッションともたいして関連性がなければなおさらです。
エンジニアチーム割り当て作戦には暗黙の前提として、運用が大変なシステムの担当になれば、改善に動くはずだ！ という淡い期待がありました。もちろんそんなことはありませんでした。
触らぬ神に祟りなし
担当になったからといって、エンジニアチームが突然そのシステムに詳しくなるわけではありません。引き継ぎやドキュメントはなく、読みにくいコードとなぜか動いているシステムを渡されます。そんなシステムを渡されれば、問題が起きるまで放置するに決まっています。
これは誰の問題か
無人化システムの改善は、基本的に誰もやりたがらない仕事です。まずマネジメント層ではエンジニアチームを割り当てたあとは、なんのフォローもせずあとヨロシク状態になりました。次にエンジニアチームはただシステムを放置しました。
誰にも悪意はありませんでしたが、誰も真剣に問題と向き合いませんでした。この問題をなんとかしないとマズい！と当時いろいろな人が言っていましたが、実際には誰も行動しませんでした[3]。
問題を生み出す構造
失敗事例の根本的な誤りは、担当がいないのだから担当をつけよう！と短絡的に考えた点にあります。しかし無人化システムのような問題を解決するには、「問題を生み出す構造」に着目する必要があります。
では無人化システムにおいて、問題を生み出す構造とはなんでしょうか。それは「オーナーシップ」と「問題の矮小化」です。
オーナーシップと無人化レベル
無人化システムをよく観察すると、実は無人化レベルが2つあることに気づきます。
- オーナー
- 運用チーム
失敗事例では「運用する人がいないこと」を問題とみなし、運用チームを割り当てました。しかし「オーナーシップを持った人（＝オーナー）がいない」という問題を解決しなかったため、うまくいきませんでした。
オーナーシップを持った人がいないと、作ったシステムを維持するのか捨てるのか誰も判断しなくなります。運用チームがオーナーを兼任していれば問題ありませんが、そうでない場合は運用チームがなくなった瞬間に無人化します。
だれもオーナーシップを持っていないので、引き継ぎなどは行われません。単純に捨て置かれます。オーナーがいないシステムの行く末など、誰も知らぬ存ぜぬ我関せずです。
問題の矮小化による当事者意識の欠如
弊社ではエンジニア以外にも「技術的負債」という言葉が浸透しています。そのため無人化システムも技術的負債のひとつとみなされていました。つまり無人化システムは「エンジニアの問題」だと認知されていたのです。なんせ技術的負債です。
たしかにシステム運用の技術的な営みは専門知識が必要なため、エンジニアの問題といえます。しかしシステムによって恩恵を受けたり、システムがおかしくなって困るのはエンジニア以外の人も含まれます。
またもうひとつ忘れてはいけないのは、システム運用にはエンジニアの時間やスキルが必要という点です。システム運用に時間がかかればかかるほど、あるいは技術的難易度が高ければ高いほど、新機能開発などの事業活動は停滞します。つまりシステム運用は事業活動の「制約条件」であり、事業活動に携わるすべての人が影響を受けます。
あるべき姿を描く
ようやく問題の輪郭が見えてきました。ここまで読んだ人もそろそろウンザリしてきたことでしょう。しかしこの状況を変えるために一番大切なのは、ウンザリするこれらの問題を直視することです。前進するためにはどんなにツラくても一度現状を受け入れ、そのうえで知恵を絞る必要があります。
問題を直視したら前に進みましょう。まずは「あるべき姿」を描きます。無人化システムは複雑な問題です。ソリューションを場当たり的に実行してはいけません。あるべき姿から逆算して戦略的に挑みます。我々が描いたあるべき姿は次のとおりです。
組織としての持続可能性
一個人の善意に依存せず、組織としてシステムを持続可能にします。「組織として持続可能」とは次のような状態です。
- システムの価値を継続的にモニタリングする
- 価値のあるシステムはきちんとコストをかけて運用する
- ボランティアではなくチームのミッションとしてシステムを運用する
誰かがなんとかしてくれるだろう、という態度は改めます。問題の透明性を高め、全員が問題と向き合います。エンジニアだけでなく事業活動に携わるすべての人の献身が求められます。
ビジネス価値へのフォーカス
我々のミッションはあくまで世の中への価値提供です。システム運用はその手段です。そこで漠然とシステムを運用するのではなく、ビジネス的に価値あるものへフォーカスします。
これは同時に「すべてを100点で実行するのは不可能」という現実の受け入れを意味します。我々には限られた人員・時間・予算しかないため、すべてのシステムに同じレベルで投資はできません。そこでシステム運用への向き合い方を変えます。
- 価値の低いシステムは捨てる＝事業活動の制約条件を取り払う
- 価値の高いシステムの運用負荷を下げる＝事業活動の制約条件を軽減する
これまでのようにシステムの作りっぱなしは許容しません。ちゃんと運用するか捨てるかの二択です。
オーナーシップと権限
システムを正しく運用し続けるため、明示的にオーナーを置きます。誰もオーナーにならない場合、そのシステムは捨てます。
無人化システムは存在するだけで害悪を撒き散らすため、オーナーがいないなら潔く間引きます。そしてオーナーはシステムを維持するために必要な、すべての活動に責任を持ちます。たとえば次のような活動が含まれます。
- システムのビジネス価値とコストの可視化
- 新機能開発など、他の事業活動とのバランシング
- システム運用に必要な体制構築・予算獲得
当然すべてを一人でまかなう必要はありませんが、これらの実行には責任を持ちます。大変な責任ですが、同時に「システムを維持するか決断する」権限も持ちます。システムを維持するかどうかの決断はマネージャーや事業責任者には行わせません。
どれだけビジネス影響が大きかろうと、システムのオーナーが捨てる決断をしたら捨てます。もしこの決断に異議がある場合は、自らがオーナーとなって責任を引き受けます。責任を持たない人に口出しされるとオーナーシップが一気になくなるため、どんなに肩書が立派でも口出しさせません。
無人化システムと戦う組織マネジメント
あるべき姿を描いたら、具体的な活動に移ります。無人化システムを一人で解決するのは困難です。そこでまずは組織全体を動かすため、仕込みをしていきます。
おおまかには次の5つのステップで進めます。
- 全貌把握
- ステークホルダーの特定
- ビジネス価値の言語化
- 維持対象のシステムとオーナーの選出
- 体制構築
全貌把握
なにはともあれ最初に全貌を把握します。無人化システムは無人化しているだけあってステルス能力が高く、認知されていないシステムがいくつもあります。そのため無人化システムを洗い出し、一覧化します。
方法はいたって単純で、まともに管理されていないサーバへSSHして調査します。必要なのは気合と根性だけです。ただの力技なので誰でもできますが、一人でやるとメンタル的に消耗します。そこで自チームのメンバを巻き込み、モブで調査します。
弊社では筆者が所属するSREチームで実施しました。「なんかサーバ上で直接コードが編集されてるぞ」「なんでシンボリックリンクを毎日バックアップしてるんだ？」「秩序も良心もねぇなこのサーバ」などとツッコミを入れながらワイワイやります。多少口が悪くなるのはご愛嬌です。一人でやるとブチギレ必至な事案も、ツッコミ駆動で楽しくやります。よく分からないモノもたくさん発掘されますが、とにかくヒントになりそうなことは片っ端からメモります。
ステークホルダーの特定
無人化システムの一覧ができたら、関係ありそうな人にヒアリングしてまわります。誰がステークホルダーか分からないので、素朴に足で稼ぎます。ここでも必要なのは気合と根性です。
人がいっぱいいるSlackチャンネルで質問したり、歴が長い人にピンポイントで聞いたりと愚直にいきます。これを繰り返すと、ある程度ステークホルダーが絞り込めます。ちなみにここで発見したステークホルダーは、システムのオーナー候補になります。
また誰に聞いても本当になにも分からない、オーパーツのようなシステムも出てきます。そのようなシステムは静かに止めてみて、どこかから悲鳴が上がるか観察します。悲鳴が上がればその人がステークホルダーです。逆に無反応であれば、その時点でシステムの廃止が確定します。
ビジネス価値の言語化
ステークホルダーにはシステムのビジネス価値の言語化を依頼します。システム運用ではコストを気にする人が多いですが、一度忘れましょう。あくまでもシステムが「現在も価値を生み出しているか」を明確にします。
システムのビジネス価値は、たいてい誰もモニタリングしていません。あらためて言語化してみると、維持する価値なしと判断できるケースが出てきます。
価値を生み出している場合は、どのくらい価値を生み出しているか可能な限り具体的に表現します。システムのビジネス価値は、継続可否判断のインプットになります。
維持対象のシステムとオーナーの選出
ビジネス価値を言語化して、今後も必要になりそうなシステムを洗い出したらオーナーを選出します。オーナーは原則として運用するエンジニアではなく、システムの恩恵を受けている人が担います。
システム運用の継続可否は技術観点ではなく、あくまでビジネス観点で判断します。これによりシステム運用に直接携わらない人が自分事化できるよう誘導します。このあたりまで進むと、無人化システムは「組織的な問題」という共通認識が育まれていきます。
体制構築
一般的に体制構築はマネージャーの仕事です。そこでシステムのオーナーはビジネス価値をマネージャーに説明し、一緒に体制を検討します。体制検討はシステム運用以外にも大量のパラメータが存在するため、ここは知恵の絞りどころです。
次にオーナーは運用チームにもシステムのビジネス価値を説明し、共感を得る必要があります。単純に丸投げするとワークしないため、動機づけは必須です。
逆に運用チームが納得できない場合、システム運用を引き受けてはいけません。運用する価値がないと感じているなら、ノーを突きつけるのが運用チームの責任です。
このプロセスはかなり重要で、運用チームがオーナーシップをもつために欠かせません。うまくこなすのは難しいですが、オーナーシップは鍵になるため妥協できません。
無人化システムと戦うエンジニアリング
オーナーと運用チームが決まったら、ようやくエンジニアリングの出番です。無人化システムはすでに知見が失われており、まともに運用できません。そこで当面は「システムを運用可能な状態にすること」をエンジニアリングの目標とします。
運用可能な状態とはなにか
ところでシステムが「運用可能な状態」とはどういう状態でしょうか。たとえば次のような状態でしょう。
- システムの存在理由が明確なこと
- ビジネス価値が明確なこと
- オーナーとステークホルダーが明確なこと
- ビジネス的な影響範囲とシステム的な影響範囲が明確なこと
- システム構成が明確なこと
- システムの正しい挙動が明確なこと
- 誰でもデプロイ可能なこと
- コード変更時にデグレを検知できること
- ステージング環境があること
- いつでも再構築できること
- 障害を検知できること
- トラブルシューティングができること
- 残存リスクが明確なこと
無人化システムの場合、これらはだいたい満たされていません。困りましたね。
現在位置を知る
あらためて我々が抱えている無人化システムを見つめなおすと、次のような特徴がありました。
- 大半のOSはAmazon Linuxで、ミドルウェアを含めてバージョンアップされていない
- Infrastructure as Codeという概念は存在せず、再構築は不可能
- 大半のシステムはバッチアプリケーション
- 単一のサーバに複数のアプリケーションが相乗り
- 本番環境のみでステージング環境なんて贅沢は許されていない
いろいろ問題はありますが、差し迫ったものとしてはAmazon LinuxのEOLがあります。OSがEOLになっているシステムを、運用可能な状態と言い張るのは少し難しいでしょう。そこでシステム移行を実施します。そしてシステム移行を通して、システムを運用可能な状態にしていきます。
システム移行戦略
理論上は各運用チームが好きなようにシステム移行を実施して構いません。しかしバラバラに動くと非効率です。そこで全体の移行戦略をたてます。そしてそれをふまえて、各システムを個別に移行します。
まず今後の継続的な運用を考えると、素のEC2を運用するのはしんどいです。そもそもサーバを運用したくありません。またステージング環境もほしいです。そこで次のような方針で、移行先を構築します。
- アプリケーションをすべてDocker化
- Dockerコンテナの実行環境はECS Fargate
- インフラはすべてTerraformで実装し、ステージング環境も構築
アプリケーション開発者にはインフラが不得手なメンバもいるため、SREチームが全面的にサポートします。システム移行に先立ちSREチームがECSクラスタを構築し、ジョブスケジューラの細かい調整をしておきます。
一方でアプリケーション開発者は個々のシステムの調査を進め、Dockerfileより上のレイヤの実装に注力します。なおSREチームの役割については別のメンバが記事にしているので、そちらもご覧ください。
システム移行の手引き
ECSクラスタが用意されているとはいえ、システム移行に伴いやるべきことはたくさんあります。またチームによってもスキルセットが異なります。そこで簡単な「システム移行の手引き」を用意しました。長くなるので詳細は書きませんが、せっかくなので概要だけ紹介します。
- 現状把握
- システムの存在理由・ビジネス価値・ステークホルダーを明確にする
- システムのユースケース・影響範囲・システム構成を明確にする
- システムの要件整理
- システムの正しい挙動を把握する
- 通信要件・扱うデータの機密レベル・使用しているデータストアなどを把握する
- インフラ構築
- 通信要件などをふまえてインフラを微調整する
- Terraformで本番環境・ステージング環境を構築する
- アプリケーション修正
- Dockerfileを作成し、Dockerイメージをビルドできるようにする
- OSやミドルウェアのバージョンが古すぎてビルドできない場合はバージョンアップする
- バージョンアップに伴いアプリケーションが動かなくなったら、動くように修正する
- CI/CD
- GitHub ActionsやCircleCIでDockerイメージのビルドを自動化する
- 必要ならデプロイを自動化する
- 移行
- 移行手順・切り戻し手順を作成する
- 影響を最小化するよう、移行前にステークホルダーと認識をあわせる
- 移行作業を実施する
もちろん手引きがあっても困りごとは発生するので、その際は都度相談してもらいます。特にインフラ周りの調整は、SREチームと相談しながら進めます。
システム移行の実施
漠然とシステム移行をしましょう！という方針を立てても、なかなか進捗しないものです。そこで外圧を利用します。我々の場合はAmazon LinuxのEOLという大きな武器があります。これに全力で乗っかり、EOLと同じ2020年12月をデッドラインにしました。
また確実にやりきるため、「EOL以降はAmazon Linuxのサーバは止めます（ニッコリ」という死の宣告も忘れません[4]。これでシステム移行をするか、捨てるかの二択になります。
もうここまで進めばあとは観念してやるだけです。個々のシステム移行については、特別な工夫はありません。ひとつひとつ愚直に実施します。なおシステム移行の苦労話は別のメンバが記事にしているので、そちらもご覧ください。
成果と今後の課題
個々のシステム移行でもなんやかんやありましたが、2020年11月末にはおおむね完了しました。またシステム移行と並行して、システムの廃止もしました。当初は大小30個ぐらいのシステムがありましたが、四分の一ぐらいは捨て去りました。
改善ポイント
システム移行によって改善したポイントをいくつかあげましょう。
- すべてのアプリケーションのソースコードをバージョン管理
- DockerやTerraformによるInfrastructure as Codeを徹底し、再構築不能なEC2をほぼ駆逐[5]
- アプリケーションのDocker化に伴い、アプリケーション間の依存関係を最小化
- GitHub ActionsやCircleCIによるCI/CDを多くのシステムで導入
- システム導入の背景・システム構成・運用における注意点などを形式知化
かなりモダンなシステムになりました。他にもDependabotによる自動バージョンアップの導入や、アラート通知の整備も少しずつ進んでいます。こうやって書いてみると当たり前のことばかり並んでいますが、当たり前を実践できるのは、本当に尊いです。
また組織マネジメントの観点では、次のような状態になりました。
- 各システムへ明示的にオーナーと運用チームを配置
- オーナーと運用チームのミッションにシステム運用を組み込み
- システムのビジネス価値を言語化
- 事業戦略のパラメータにシステム運用を考慮ポイントとして追加
活動をはじめる前に比べると、はるかにまともな状態といえます。
残されたもの
システムによって残課題のレベルはバラバラですが、やれることはまだまだあります。
- テストコードがないためカジュアルにOS・ミドルウェアをバージョンアップできない
- 監視レベルがシステムによってバラついている
- Ubuntuベースのシステムで手つかずのものが少数残っている
しかし技術的な課題はかなり具体的であり、ある意味やればいいだけなので楽な部類です。一方で組織マネジメントはこれからが勝負です。
- 継続的にシステムのビジナス価値を確認
- オーナー不在のシステムが生まれていないかモニタリング
- オーナーや運用チームへの継続的な動機づけ
- 運用チームが過負荷に陥らないように業務のバランシング
組織的な課題を検出する仕組みはほとんど自動化できていないため、楽に運用する方法の模索も必要でしょう。
楽屋裏コーナー：やりながら考えていたこと
本記事も一区切りついたので、ここからは個人的に考えていたことをツラツラと並べておきます。
ボトムアップで組織を動かす
無人化システムを駆逐する活動は問題の強大さとは裏腹に、ほとんど武器がない状態でのスタートを余儀なくされました。活動開始時点での状況は次のとおりです。
- 無人化システムの数・難易度・ビジネス価値・ステークホルダーはすべて不明
- 無人化システムを実装した人のほとんどは退職済みで、知見はキレイにロスト済み
- この活動を推進するために必要な体制・予算・権限はゼロ
- 改善に必要なコスト・改善した場合の効果は予測不可
- マネジメント層や経営層に課題意識はあっても具体的なアクションはなし
- 他人が作ったシステムをなんとかするという活動の特性上、他者への動機づけは極めて困難
- すでに何度も改善の試みは失敗しており、成功率は低い
冷静に書き並べてみると引きますね。ネガティブ要素はいくらでも出てきますが、ポジティブな要素はほぼありません。唯一のポジティブ要素は失敗して当然の活動なので、成功へのプレッシャーが全然ないことぐらいです。今ふりかえるとこんな問題に手を出すなど正気の沙汰ではありませんが、まぁ正気じゃなかったんでしょう[6]。
正気を失ってのスタートですが、実際の活動はかなり戦略的に進めました。一人で戦う気はサラサラなかったので、どうやって組織全体を巻き込むかは注意深く設計しました。
- 事業責任者や部門長・マネージャーなど、組織の意思決定者を最初にたらし込む
- 体制検討や予算検討のタイミングで、無人化システムの対応をシレッとねじ込む
- プロダクトオーナーが管理している施策スケジュールに無人化システムの対応をねじ込む
- 筆者およびマネージャーをエスカレーション先にして、困りごとを相談できる体制を確立する
- エンジニアが不安にならないよう、エンジニアへ説明する前におおまかな技術戦略を立てておく
活動が本格化してからひっくり返されると100%頓挫するので、「事業運営・組織運営の意思決定者→ビジネスサイドのメンバ→エンジニア」の順番でコミュニケーションしました。また絵に描いた餅とならないように体制検討や予算検討にも適宜介入し、実行可能な環境づくりに苦心しました。
このあたりの活動は予算や権限のある立場の人（CTOとか）が主導すると、スピーディに実行できる可能性もありますが、筆者自身は現場の一エンジニアなので時間をかけてゆっくり進めました。
ちなみにたらし込んだりねじ込んだりとサラッと書いてありますが、実践はそこそこ大変です。実践のコツはあまりうまく言語化できませんが、泥臭い部分は全部自分で引き受けて、あとはそれまでの信頼貯金を使ってなんとかしました。
経験則的にはボトムアップで組織を動かす場合、最初に自分が一番しんどい部分を拾うと、うまくまわる可能性が比較的高いです。
モチベーションコントロール
この活動をはじめるにあたって、自分が燃え尽きないようにメチャクチャ注意を払いました。この手の活動は「なんでオレがやらないといけないのか」「オレのせいじゃねぇだろ」「やりたくねー」のようなネガティブな感情を何度も抱くことになります[7]。
先人への敬意は大切ですが、そんな正論だけでネガティブな感情は消滅しません。無人化システムとの戦いだけではクサクサしてしまうので、業務時間の20%以上をこの活動に使わないよう配慮しました。どうせ組織を動かすのに時間がかかるので、あせらずいくことを最初から決めていました。
また最初の半年ぐらいは周囲への巻き込みを最小限に抑え、ほとんど一人で進めました。サーバの調査やヒアリングには他の人も関わっていますが、問題分析・組織戦略立案・技術戦略立案はだいたい一人でやりました。これは意図的です。
この活動はテーマがテーマなので、あんまり楽しくありません。つまりいつ投げ出したくなるか分かりません。そんなわけであまりにもツラくなったら、何ごともなかったかのようにシレッと投げ出せるようにしておいたのです。
最悪自分は逃げればいいですが、盛大に最初から周囲の人を巻き込むと、万が一の場合に申し訳がたちません。そこでもし自分が投げ出した場合にも、周囲への影響が最小限になるよう注意を払いました。逆に組織へ広げるタイミングでは自分がいなくても進むよう、お膳立てをすべて済ませておきました。結果的には投げ出しませんでしたが、自分の逃亡を前提に進めたことは精神衛生上よかったです。
捨てる文化
無人化システム駆逐の目的は表向き「システムを運用可能な状態にすること」でした。しかし裏テーマとして、組織文化の変革も視野に入れていました。
弊社はよくいえば新しいことに挑戦しやすい会社ですが、一方で「やったらやりっぱなし」という悪癖を兼ね備えていました。そしてこのやりっぱなし文化で一番割りを食っていたのがエンジニアです。そこで個人的にどうしても根付かせたかったのは「捨てる文化」です。
価値あるものを作るため、たくさん試行錯誤するのはよいことです。一方で試行錯誤のスピードを維持するには、価値の低いものを捨てる必要があります。
ところが我々には作ったものを捨てる文化がありませんでした。むしろどこに影響が出るか分からないため「捨てるのが怖い」というありさまでした。そこでこの活動ではことあるごとに「捨てましょう！」というメッセージを発信し、いらないシステムはためらわずに捨てました。組織として捨てることに慣れれば、少しずつ捨てることにためらいがなくなるだろうという算段です。
もちろん文化がそう簡単に変わるわけがなく、今も道半ばです。本当に捨てる文化を定着させるにはあと数年必要でしょう。しかし体感値としては、機能削減やシステムの廃止がしやすい雰囲気になってきています。
戦略は大きく、行動は小さく
無人化システムのような複雑な問題は、理解を深めれば深めるほど「コレどーすんだ？」と途方に暮れます。やみくもに突撃すると討ち死にするため、問題分析と戦略立案には相当時間を使いました。
ただし考えるばかりで行動が伴わないとなにも進みません。そのため戦略立案と並行して、自チームでは改善活動をチマチマ進めました。チームと一緒に進めることで、机上では分からない問題の把握と解決策の模索に役立てました。
組織を大きく動かすと軌道修正が大変です。そこで事前に小さく検証し、その知見を投入して戦略の精度を高めました。このあたりはアーキテクチャ設計前のPoCに近いです。一発でうまくいくわけがないので、あとから変えるのが難しいポイントを重点的に確認します。
もちろん組織全体が動き出したあとは、状況確認やヒアリングをして細かくチューニングします。このあたりもアーキテクチャ設計を開発中に調整するのと考え方は一緒です。
名前がなければ視えない
「ジョシュアツリーの法則」をご存知でしょうか。ノンデザイナーズ・デザインブックに出てくる話です。詳細は本を読むかググっていただきたいのですが、かいつまんで書くと「人は名前がない概念を認知できない」という考え方です。逆に名前を知ってしまえば、それが見えるようになるのです。
これは組織を動かすうえでかなり役立ちます。問題が見えてしまえば、あとは攻略法を一緒に考えるだけですみます。
そこでこの活動をはじめるにあたり、積極的に「無人化」「無人化システム」というキーワードを使いました。この言葉は筆者の造語ではなく、もともと一部エンジニアが使っていた社内ミームです。社内の人への説明やドキュメントの執筆では、一貫してこの言葉を使用しました。すると徐々に認知度があがり、完全に組織内のユビキタス言語になりました。
今ではエンジニアだけでなく、プロダクトオーナーや事業責任者もフツーに使う言葉となっています。最近はキックオフなどで使う事業戦略の資料にも登場しはじめました。ただのミームからずいぶん出世したものです。
まとめ
本記事では「無人化システム」の駆逐活動について紹介しました。
- 誰も知らないがなぜか動いているシステムを無人化システムと呼ぶ
- 無人化システムには組織を腐らせる厄介な特性がある
- 無人化システムを駆逐するには組織マネジメントとエンジニアリングのあわせ技が必要
- 無人化システムの問題は複雑で強大なので戦略的に攻略する
- 無人化システムと戦うのは本当に骨が折れる
戦ってみての感想としては、本当にマジでムチャクチャ大変です。
どう考えても属人化しているうちに手を打ったほうが100倍楽です。むしろ属人化バンザイです。あるいは技術で殴れるサイズのうちに、技術で殴っておくのも有効でしょう。問題が多すぎるというのはそれだけで心を折ります。技術的には可能でもメンタル的に不可能な問題がこの世にはあります。
一方ですでに似たような状況に追い込まれている人もいるでしょう。もしそういう人がいれば、この記事がなにかのヒントになれば嬉しいです。焦ってはいけません。その状況はあなたのせいではないのです。力を抜いて戦いましょう。
どうしても疲れてしまったら、逃亡したって構いません。大切なのは自分の人生です。
あとがき
一人ではじめた活動ですが、以前よりまともな状態になったのは協力してくれた人たちのおかげです。特にシステム移行が本格化してからは、ほとんど筆者が動かなくても周りが自律的に進めてくれました。システム移行を担当したエンジニアは苦労も多かったでしょう。おつかれさまでした。
最後にみんなへ圧倒的感謝を伝えて本記事の結びとします。本当にありがとうございました。運用はこれからも続くけどね！
参考文献
-
一応フォローしておくと、直近5年ぐらいで作られたシステムははるかにまともです。ホントだよ。 ↩︎
-
他人事のように書きましたが、これには筆者も含まれることを告白しなければフェアではありません。筆者自身もマズいとは感じていましたが、一方で関わるのも正直イヤでした。 ↩︎
-
EOL後もそのまま運用する選択肢もありますが、最初から例外を許すと甘えてしまうので、あえてこのようなコミュニケーションを取りました。どうしてもこのスケジュールに乗らないシステムについては、個別に相談をしています。本当に問答無用で捨てるほど鬼畜ではありません。ホントだよ。 ↩︎
-
年明け早々に退役予定のサーバがあり、それだけ残っています。 ↩︎
-
もう少し真面目に書くと、無人化システムがトラブった尻拭いをする機会が何度もあり、カチンときたので駆逐することに決めました。怒り駆動でなんとかするアレです。 ↩︎
-
自分ではじめておいて勝手な話ですが、こうなることはやる前から確信していました。実際何度も思いました（笑） ↩︎
Discussion