DevOps カルチャーというコスト -- DevOps は QCD のトレードオフを破壊したのか？

DevOps は QCD を破壊した？

2020年デブサミの登壇発表「質とスピード」が話題に上がってから日本のソフトウェア産業で一つのパラダイムシフトが発生したと考えている。つまり、ソフトウェア産業において、従来のQCDは成り立たなくなったというものだ。その発表の大きな論拠になっているものは2014年に開始され、その後も毎年更新され続ける DORA リサーチだ。この研究が注目された理由は、DevOps カルチャーを高度に推進するエリート企業はそうでない企業に比べて、圧倒的に速いスピードで新機能をリリースするのに、障害発生が少ない点である。つまり、従来のスピードを優先すると品質が下がるという常識を否定しているのである。加えて、DevOpsのプラクティスは自動化を前提としたものがあ多い。つまり、スピードと品質を両立しながら、コストも削減ができることを意味する。これは、つまり伝統的なQCDのトレードオフの破壊である。

State of DevOps より: エリートと低グループのパフォーマンス差分

筆者も実際、ソフトウェア開発におけるQCDのトレードオフは破壊しうると信じるようになった。その上で、ここ数年はDevOps変革を推進してきた。しかしその過程で分かったことは、これは言う方簡単ではないということである。そして、その理由は、DevOpsカルチャーの醸成こそが最大の難題であるからである。つまり、DevOpsカルチャーの醸成そのものがコストであり、そのコストは意外に大きいということである。

DevOpsカルチャー醸成のコスト

DevOpsカルチャーの醸成が難しい理由は、主に三つある。

一つ目は、その本質を捉えるのが難しいからだ。これを確かめるには、あなたの同僚に「DevOpsとは何か？」と質問してみるといい。ほとんどの同僚は、DevOpsパイプラインやCI/CDといった表面的な仕組みについて語るか、あまり要領を得ない回答をすると思う。実際、普遍的な定義がある訳ではないので、その回答内容をみるとその人の理解度と視点がよく分かる。ちなみに自分は、「毎日のようにリリースを行い、かつ障害や不具合を最小化するために、ソフトウェア開発と運用を統合した様々な方法を組み合わせたもの」と答える。これが正解なのかは未だに分かっていないが、自分はそういう視点で見ている。

DevOps のプラクティスとカルチャーの関連

二つ目は、DevOpsが戦略としてのキラーパスの性質を持っているからである。戦略のキラーパスは、ストーリーとしての競争戦略において楠木教授が紹介しているものである。キラーパスとは、競合が戦略の一部を真似ただけでは逆効果を発揮する性質のことを言う。端的に言うと、表面だけパクると自爆すると言うことだ。

例えば洗練された CI/CD が整っていないのに、頻繁なリリースのみを真似たとしよう。チームはリリース作業だけでてんてこまいになり、頻繁にバグを引き、本番障害が頻発するだろう。チームが単体テストの重要性を理解せず、第三者によるE2E/UIテストに依存していたとしよう。そのバランスを見直さずテストの自動化のみを推進した場合、少しの仕様変更でもハイメンテナンスなSeleniumテストケースを頻繁に修正することになる。むしろマニュアルテストより効率が下がるかもしれない。

三つ目に、DevOpsは現場からトップまで全員の理解を必要とする。もしIT経営のトップが昔ながらソフトウェア開発パラダイムを持っていたとしよう。「毎日リリースしましょう。そうすれば一回のリリースのリスクを小さくすることができます」とでも言おうものなら異端扱いされることだろう。一度、重大障害が起きればリリースの頻度を下げ、重厚な変更管理プロセスと沢山のチェックリストを用意するように指示がくることだろう。DevOpsのプラクティスと真逆の方向にアクセルを踏んでしまうのである。逆に、トップマネジメントがDevOpsカルチャー推進の音頭をとったとしよう。開発の現場が、ソフトウェアのテストをするのはQA部門の仕事だと思っているとしたら、一向にテストの自動化は進まないだろう。DevOpsの重要な前提である自動化テストが上手くいかなければ、変革は掛け声だけに終わるだろう。

DevOps 変革が難しいエンタープライズ

こうした課題は特に、DXを推進しているような企業では難しい。これらの企業では、デジタルネイティブ企業とは異なり、ITシステムを自分達で作る代わりに、ベンダーから買ってくることに慣れている。そして、ベンダーベースのソフトウェア開発は、DevOpsのプラクティスの真逆を行っている。厳重な変更管理をして、半年に一回にメジャーリリースをまとめ、ソフトウェアの開発が完了してからテストベンダーを大量に雇って手動で試験をこなすことに慣れきっているのである。こうした組織カルチャーの変革をするのは一大事業だ。

こうした理由で、DevOps変革は困難を伴う。品質とスピードを両立すると言うことはとても魅力的であるが、その裏側にはカルチャーを変えるという大きなコストが潜んでいるのである。そして、カルチャーの変革コストは投資承認がおりれば簡単に支払えるものではない。トップから現場までの粘り強く働きかけ、実践を通じて時間をかけて変えていくしかない。

経営科学が示している通り、企業文化というのは移植が最も困難な強みである。それゆえにこの強みを構築した企業は、競合に対して強い優位性を持つだろう。そうした DevOps 変革をトップから現場まで粘り強く働きかけて、変革を推進できる人材は、一騎当千の価値を持つのではないかと筆者は考えている。DevOps推進の鍵は変革のためのコストを認識し、そのコストを粘り強く支払うことなのだと思う。

参考

www.devops-research.com

なぜマニュアルテストは、まずうまく行きそして失敗するのか

本日は、なぜマニュアルテストはまず上手く行きそして失敗するのか、自分の考えていることを書いてみたいと思う。　

ソフトウェアテストの自動化は常識である。優れたエンジニアは自ら優れたテストを書き、その結果として優れた品質を担保し続ける。一方で、テスト実装を推進できていないプロジェクトに遭遇することもある。こうしたプロジェクトは、大抵何れかのフェーズで必ず品質問題に直面する。こうしたプロジェクトの軌道を修正するベストな方法は何であろうか。

マニュアルテストのはじまり

テスト自動化を推進できない理由の典型例が「新規案件に忙しすぎてテスト自動化を推進する工数がとれない」というものである。TDD 論者がこの説明を聞いたときに「忙しいからテストができないのではなくて、テストを自動化しないから忙しいのだ」と答える様子は想像に難くない。だがここでは、あえてこの議論には深く触れず、こうしたプロジェクトがどういう道のりをたどるのかを考えてみる。

開発者がテストを実装する時間がないという理由を聞いたマネジメントは、たいてい外部のテストチームにその品質管理を頼る。開発チームから上がってくる品質が信用に足らないから、テストチームは念入りに検査をしてくれと言った具合だ。

マニュアルテストの罠

マニュアルテストの怖いところは、ある一定の規模までは機能してしまうことである。以下の図に示すとおり、ある一定の範囲で障害を最小化できるスイートスポットが存在する。

リリースにあたって障害が多発する場合、おそらくリリースの頻度を下げて品質を担保しようとするだろう。変更をまとめてバッチサイズを大きくすることで、回帰試験の回数を減らして工数を抑える。そして、品証の時間を十分とることでしっかり準備しようという考え方だ。実際この戦略はある一定の規模まではうまくいく。

しかし、あるタイミングで破綻する。なぜなら一回の変更のサイズが増えれば増えるほど、システムの複雑性が指数関数的に増えるからである。2 つのシステムが相互にやり取りするシステムと、3 つのシステムが相互にやり取りするシステムの複雑性は線形比例にならない。リンクの数が指数的に増えるからである。

バッチサイズを大きくすることで確かに回帰テストの回数は減る。だがシステムの複雑さが加速度的に上がるため、より多くのバグが埋め込まれ、より発見が難しくなる。つまり、過去の成功体験にならって人員増強や試験期間の延長をしても対処ができなくなるのである。

罠から抜け出す

テストの自動化や CI/CD の利点は、工数やコスト削減の削減ではない。バッチサイズの最小化である。優れた IT 組織はこれをよく熟知しているため、テストの自動化と CI/CD に十分な投資を行っている。大きなプロダクトであればあるほど、小さく変更して頻繁にリリースする。そうすることでバグの埋め込みを防ぐのである。

ではマニュアルテストの罠にはまってしまったプロジェクトはどうするべきだろうか。残念ながら答えは一つしかないと思う。自動化を推進してバッチサイズを小さくしていくしかない。自動化に反対する人まずいない。問題は自動化が整うまでの暫定的処置を関係者と合意することだ。自動化を推進する間も開発を止めない方法を求められることもあるだろう。だが結局の所銀の弾丸はないのである。

罠から抜け出すには優れたリーダーシップが必要である。チームがあるべきテストの姿を推進するための工数を確保するために開発チームのリーダーは動かなければならない。ステークホルダーとコミュニケーションをし、ときにメンバーを守り、ひたすらに自動化を推進することが結果的に製品の成功への近道となるのである。

英文記事:

yuichi-murata.medium.com

チームビルディングの新常識！好きなプログラミング言語を議論せよ

自分が議論を投げかけたのに、チームが静まり返ってしまって気まずい思いをした事はないだろうか。アフターコロナの世界になってチーム・ビルディングの形も大きく変わってきている。特に、リモート・ミーティングで上のような局面に当たる機会が増えたのではないかと思う。

この記事では、エンジニアリング・チームのミーティングや日々のやり取りを盛り上げ、楽しく仕事をするにはどうしたら良いか語ってみたいと思う。

自転車置き場効果 - くだらない事は盛り上がる

自転車置き場効果という心理学の用語がある。正式にはパーキンソンの凡俗法則と呼ばれているものである。簡単に言うと、人間は「くだらない議論ほど盛り上がる」と言うものだ。

例えば、ある会議室で原子力発電所の建設費用の見積もりを議論したとしよう。殆どの参加者は黙ってしまう。だが、職場に自転車置き場を設置するべきかと議題を投げかけると、みんなが活発に発言をする。自分にとって身近な問題であるし、責任も伴わないからだ。

エンジニアには度々盛り上がるトピックというものがある。例えば、あなたの好きなテキスト・エディターは何ですか、あなたの好きな Linux ディストリビューションは何ですかと言った議論だ。これは、ほとんど趣味嗜好としか言えないような議論に陥るがとにかく盛り上がる。それは、トピックが「くだらない」からである。

チーム・ビルディング・イベントでくだらない議論をする

最近、あるチーム・ビルディング・イベントに参加したのだが、これがとても盛り上がった。この組織の四半期目標、経営理念、戦略といったトピックの代わりに全員参加のくだらない議論を行なったのである (無論まじめな話も別セッションで実施した)。

参加者はスライドの QR コードを読み取って投票に参加する。そしてその投票結果がリアルタイムにスライドに表示される。その質問の内容はというと、「もしオフィス移転をするならどこが良いと思いますか」「あなたが働いてみたい他の部署はどこですか」といった他愛もないものであった。エンジニア向けには「あなたの好きなプログラミング言語は何ですか」という質問がなされた。普段業務で使っていない言語がトップにあがり、これは大きく盛り上がった。

くだらない話でチームを盛り上げよう

リモートワークが主体となって以前よりもずっと雑談の機会が減ってしまったのではないかと思う。そんな時は「好きなプログラミング言語」の話をしてみよう。なんなら「嫌いなプログラミング言語」の悪口でも構わない。個人の趣味嗜好によって議論が白熱することだろう。そうした議論は普段の業務と直接関わらないから、意見が割れようと尾を引かない。

くだらない議論によってエンジンのかかったチームは、本題のビジネスにおいても闊達な議論をするようになるだろう。

英文記事: yuichi-murata.medium.com

技術負債は大きな石だと思えばうまくいく

技術負債に対する取り組みは、エンジニアリングにあたって最も活発に議論されるトピックである。この記事では、技術負債に取り組むために如何に工数を確保するかについて、自分の考えを述べたいと思う。

技術負債？とにかく新機能を実装してよ

エンジニアの最も大きな不満の一つは、ビジネスが技術負債への取り組みを理解してくれないことである。ステークホルダーやプロダクトマネージャーは、さらなるビジネスの発展のために次から次へと新しいビジネスや機能のアイディアを持ち込んでくる。あるいは、特定のお客様の不満へ対処するために、緊急の機能改修を要求してくるかもしれない。

「設計の変更が必要なのは分かった。でも、それ今じゃないとだめかな？いまがビジネスにとって大事な時期なんだ。」 理由は様々かもしれない。だが、このようなフレーズでリファクタリングや改善策の実施を押し返されてしまった経験はないだろうか。

もちろん時と場合によって、技術的な負債を増やして前に進むべき時もある。大大的に告知されてしまったリリース日を守るために設計を妥協したり、放っておくとお客様の信頼を大きく損なうような重大なバグ修正を優先することは至極まっとうである。

しかし、意思決定には慎重にならなければいけない。ビジネスにおいて重要でない時は存在しないからだ。最初から自動化テストを実装しておいたほうが、結果的に早くシステムをリリースできる。このように適切な取り組みは、最終的なゴールへの到達を早める。結局は急がば回れということである。エンジニアはこれを理解していているが、ステークホルダーはこれを理解できないことがある。であれば、技術負債への取り組みを推進するのは「エンジニアの責任」である。それが何れ問題になることが分かっているのだとすれば、プロフェッショナルとして、あなたは何としてもそれを推進する責任がある。ピーター・ドラッガーが述べている通り「知りながら害をなすな」ということである。決して「技術負債返済の理解をしてくれない」と嘆いてはいけない。

大きな石ころを先に詰める

とはいえ、一般に理解してもらうことが難しいこの取組をどのように推進すればよいだろうか。スティーブン・コビー博士の著書「最優先事項」からそのヒントを得ることができる。技術的な負債への取り組みは大きな石ころだと思えば良い。

これは彼の講座の講師の話である。その講師は瓶を取り出して、「この中にいくつの石がはいるでしょう」といって瓶の中に石を詰め込み始めた。瓶がいっぱいになったところで、「さてこの瓶はもういっぱいでしょうか」と生徒たちに訪ねた。生徒たちがうなずくと、彼は砂のはいった袋をとりだした。「さてこの瓶はもういっぱいでしょうか」。生徒たちは「いいや」と答えた。

この講師の話は優先事項を以下にスケジュールに組み込むかについて分かりやすい比喩を使って説明している。要するに大事な仕事は先に「瓶」に入れておくことだ。

瓶がいっぱいになってから「すいません、このリファクタリングをしたいので少し砂を避けてください」などと言ってはうまくいくはずがない。まず石を詰めておいて、そこから砂を入れるようにしよう。新規の開発計画を立てるときには、関連するシステムの設計見直しや追加のテストの実装といった技術負債返済のための工数をまず計上しておき、それから新しい機能の実装の工数を積むのである。

大きい石ころについて話すべきか

ここで一つ議論のあるポイントが有る。それは「大きい石ころ」について話すべきか否かである。瓶の中には大きな石ころが詰まっている。だが砂を詰めたあとの瓶の外側からはそうした大きな石ころは見えない。ただの砂のつまった瓶である。我々はこの大きな石ころについて話すべきだろうか。

Martin Fowler の著書 Refactoring からこの言葉を引用したい。

Of course, many managers and customer don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell!

もしステークホルダーが技術に理解ある人であれば黙る必要はないかもしれない。だが、そうした判断ができないようなのであれば大きな石ころについて「話すべきではない」。話した結果、こうした取り組みを実施できず、結果的にソフトウェアの品質を下げてデリバリーを遅くするのであれば、あなたはプロジェクトの成功にたいして裏切ったことになる。無闇に話さないことも一つのプロフェッショナリズムだと思う。見た目には砂がいっぱいの瓶をみて皆が納得してくれるのならば、それでいいではないか。結果的にはそれがプロジェクトの成功のためになるのであれば、あなたはプロジェクトの成功にたいして誠実なのだから。

そのためにも、大きな石ころの管理には注意を払う必要がある。石ころが瓶に入らなくなるほど大きくなるまで放っておいたり、大きな石ころだけで瓶をいっぱいにしてはいけない。砂がほとんど入らない瓶をみてステークホルダーは怪訝な顔をすることだろう。そうなる前に、継続的に、したたかに大きな石ころを瓶に詰めるのは、プロフェッショナルのエンジニアとしての大事な責任である。

英文記事:

yuichi-murata.medium.com

お前はクビだ！優れた技術リードが持つべきひとつの条件

今日は技術が持つべき、ひとつの条件について、自分の考えを話したいと思う。それは「ある特定の人物」をクビにする能力である。

金持ちはますます金持ちになる

資本主義社会に対する一つの批判は、金持ちがますます金持ちになることである。金持ちは自分の資本を用いて割の良い商売を行い、更に儲ける。貧乏人は、誰にでもできる割の悪い商売にありつく。こうした貧富の差は度が過ぎると社会が不安定になり、社会が上手くいかなくなる原因となる。「世界はシステムで動く」の著者ドネラ・メドウズは、これを自己強化ループの典型例として紹介している。つまり、問題は時を経て次第に加速していくのである。

これは金銭的資本に限った話ではない。技術者の経験にも同じ理屈が当てはまる。経験豊富なエンジニアはその知識を活用して難しい問題の解決にあたる。その過程で更に多くの経験と知識をつけていく。その仕事ぶりを聞きつけた人たちが、更に挑戦的な仕事を持ち込んでくる。こうして、優秀なエンジニアはますます優秀になっていく。

一人勝ちはチームをダメにする

個人のキャリア作りという観点でこれは良いことである。一方、チームづくりという観点では少し慎重になる必要がある。一人勝ちはチームをダメにするからだ。

自分には今でも尊敬するシニア・エンジニアがいる。信じられないレベルで広い範囲の経験を持ち、深い知識を持つ。障害が起きれば豊富な経験に基づく直感で素早く被疑箇所にあたりをつけ、常人には考えをつかないような創造的な打ち手で問題を解決してしまう。

チームは高い成果を上げ続けた。だが、チームは彼が離れるタイミングになって、大きな問題を抱えた。次を担う人材が十分に育っていなかったのである。それは、彼がありとあらゆる問題を解決してしまっていたからである。次を担う世代が十分に経験を積んでいなかったのである。

自分は彼から二つの大切なことを学んだ。一つはエンジニアとしての知識と経験で、それはいまの自分の血肉になっている。もう一つは、自分がチームにとってかけがえのない存在にはなってはいけないということだ。

優れた技術リードの条件

自分の考える、優れた技術リードが持つべきたったひとつの条件、それは「自分をクビにする能力」である。自分の手柄を積極的に手放し、後進のために機会を作る。そして、自分をクビにする。この言葉を三年ほど前、エンジニアリング・リーダーシップの勉強会で聞いた。その強烈な言葉が脳裏に焼き付き、常日頃から意識するようになった。

自分はこの言葉を意識して仕事をするようになり、新しいチームを作っては何度も自分をクビにした。それは勇気がいることでもあった。来年には飯の種がなくなってしまうかもしれないからだ。また、「これは失敗するかもしれない」という不確実な状況において、大胆に仕事を任せなければならない局面もあった。仮に失敗したとしても、責任をとり全力で支援をしなければならない。大失態をやらかして、頭を下げて回ったこともある。

だが、不思議なもので、チームが経験を積み自走する状況になると、自然とより大きな機会に恵まれるのである。またそうした大きな機会に見舞われた時、自信を持って今の現場を離れることができるのだ。すでにそこにはチームがいるのだから。

ウォルト・ディズニーの CEO であるロバート・アイガーはこう言っている。

優れたリーダーシップとは代わりのきかない存在になることではない。他の人を助けて、あなたの代わりになるよう支援することだ。彼らを意思決定に参加させ、彼らが身につけるべきスキルを特定し、身につけるのを支援しよう。そして、彼らが何故次のステップに行くことができないのか、時に正直に話す必要がある。

あなたをクビにしよう。それが結果的にあなたの次のキャリアを作るのだ。

英文記事:

厳格なリリース管理は悪か？

皆さんの組織ではどの様にリリース管理を行っているだろうか。変更承認委員会 (Chanve Advisory Board) のような厳格なリリース承認プロセスを通して実施しているだろうか。現場の裁量でリリース計画を立て、関係者に周知すればリリースできるだろうか。それとも、プロセスなどなく気の向くままにリリースをしているだろうか。

この記事では、あるべきリリース管理について、自分なりの考え方を話したいと思う。

CAB の予期せぬ副作用

ここで一つ非常に物議を醸し出すデータを提示したいと思う。CAB による厳格なリリース管理は、リリースの成功率に寄与しない。むしろ、障害発生時の復旧を遅くしてしまうというものである。

Nicole Forsgren らの書籍 Accelerate (邦題: Lean と DevOps の科学) では2014~2017 年にかけて実施された 23,000 件に渡る膨大な調査に基づき、システムのリリースに関して高いパフォーマンスを上げる組織と低いパフォーマンスに甘んじる組織について述べている。その中で著者らは以下の様に述べている。

We investigated further the case of approval by an external body to see if this practice correlated with stability. We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate.

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

これは厳格なリリース管理プロセスを運用している組織にとっては耳の痛い話だ。意味がないどころではない。逆効果というのである。これはどうしたことだろうか。

現場は変更を知っている

これはよく考えれば分かる話だ。現場は変更を知っている。変更がどこに影響しうるのか、そのリスクがどの程度か、正確に判断できるのは誰だろうか。第三者だろうか、それとも開発に携わった現場だろうか。答えは自明である。

一昔前のドラマから有名なフレーズを借りてくるのならば「変更は会議室で作られるのではない。現場で作られる」のである。どんなに賢い人材を配置したところで、現場に勝る判断をするのは本来難しいはずなのである。

変更管理は厳格であるべきだ。ただし現場の知恵によって

自分は、変更がうまく行っている組織とそうでない組織の両方で働いた経験がある。

変更がうまく行っている組織では、現場の知恵と力強いリーダーシップによって変更が実施されていた。リリース手順は厳しくピア・レビューで確認される。リスクの高い DDL は事前に DBA を巻き込み、変更手順の確認や実施時間の調整などが行われる。変更はまずカナリアにリリースされ、完全に自動化されたテストを実施し問題がないことが確認される。そして、問題がなければ本番環境にブルー・グリーンデプロイがなされる。100%ではないものの、リリースが失敗することは頻繁ではなかった。それ故に、事前にリリース計画を周知しておけば文句を言われることはなかった。

変更がうまく行っていない組織では、現場で変更とリスクをきちんと評価することができず、度々障害を引き起こしていた。他のシステムへの影響や依存関係を把握しないままリリースをしたり、重要な商売の途中でリスクの高い変更をして障害を引き起こしていた。次第に重厚な統制プロセスが求められていった。問題は、カナリア環境で実施される自動テストではなく、しばしば顧客からのクレームという形で検知された。

以上の経験を基にした自分の持論は以下の通りである。変更管理は厳格であるべきだ。ただし現場の知恵によって。

変更管理をビジネスやマネジメントから委任してもらうには信頼が必要になる。現場はリスク・コントロールや安全に変更を実施するための技術的な仕組みをリードし、信頼を勝ち取る必要がある。エンジニアとしての知恵と力量が試されるところである。もしこうした信頼を勝ち取ることができれば、組織は安定したリリースを実施し、障害が発生したとしても素早く復旧することができるだろう。加えて、継続的に新しい価値を顧客に提供できるようになるだろう。

原文:

yuichi-murata.medium.com

なぜアーキテクトは難しいのか

ひょんなことからアーキテクト職として本格的に働くことになって、早くも1年と少しが経った。まだまだ勉強することばかりだが、一つ分かったことがある。 アーキテクトというのはやはり難しい。そして、それはアーキテクトとしての意思決定が文脈的だからである。

文脈の中に生きる意思決定

例えば、以下のような状況下での意思決定を考えてみる。あなたは新しい Web サービスを立ち上げることになった。そのための技術選定とアーキテクチャ設計を行っている。 そのサービスは著名なインフルエンサーとのコラボレーションを基軸にしていて、インフルエンサーが SNS 上で集客を行うと、突発的にリクエストが集中することが予測されていた。 一方で、なにもない時に定常的なトラフィックはそれほど想定されていない。必要なときにしなやかに、素早くシステムをスケールアウトする必要がある。ビジネスロジックはそれ程難しくない。サービスから得られる収益は限られており、如何にコスト効率よくサーバープロセスを処理するかが鍵になる。

この要件を技術的観点から見たときに、あなたは突発的な負荷が発生しても素早くスケールアウトし、少ないサーバーリソースで動作する Golang を選択するかもしれない。技術的観点だけを見れば悪くないチョイスだろう。

だが、話はそう簡単ではない。あなたの組織はすでに別の大規模サービスを運用している。その大規模サービスは Java で運用されており、組織にはその知見が蓄積されている。運用効率化をするための各種ツールも整っている。Golang でシステムを構築した場合これらの組織的なバックアップは皆無だ。こうした組織的な側面に目を向けると、技術的にはナンセンスだとしても Java を選んだほうがよいという意思決定をするかもしれない。

ここであなたは、さらに別の観点として人材開発に目を向けてみる。あなたは定期的に複数のエンジニアと行った 1-on-1 ミーティングを持っている。多くの中堅エンジニアたちが新しいチャレンジに飢えていた。「いいかげん新しい技術スタックやチャレンジをしてみたい」と複数のエンジニアが口々に言っていたことを思い出す。Java を選定することは無難にシステムを運用する上でプラスかもしれない。しかしその代わりに、従来の技術選定に飽き飽きしたエンジニアが退職届を提出してくるかもしれない。彼らは最近趣味で Golang を勉強しており、もしここで Golang を業務採用すれば、技術的好奇心に駆られ、寝食を忘れて新規サービスの立ち上げに邁進してくれるかもしれない。

ここに上げたとおり、アーキテクチャの意思決定には技術的妥当性やビジネス要件の他にも、様々な文脈が存在する。文脈がことなれば最良の意思決定も最悪になりうるのである。 これがアーキテクトの仕事が難しい所以であると思う。技術的知識に精通するだけはなく、組織の置かれた状況、ビジネスのフェーズ、過去の経験も俯瞰的に捉え、その文脈の中で最高の解を見いださなければならない。

文脈をつたえる大切さ

以上の理由から、アーキテクチャ上の意思決定をするにあたってはその置かれた文脈を伝えることが大事だ。もしこの文脈を伝えずに意思決定をしているとどうなるだろう。

「あのアーキテクトはたしかに優秀かもしれないけど、言っていることは訳がわからない。この間は Java だといっていたのに、今回は Golang だという言う。一貫性がないじゃないか」

こんな調子の文句を聞くことがある。これは文脈を伝えていないからであると思う。

エンジニアとアーキテクチャの議論をしていると、しばしば、というか頻繁に意見が対立する。アーキテクチャの議論が難しいのは、それが大抵の場合、お互いに間違っていないからである。ある文脈に根ざして考えればその意思決定はたいてい合理的なのである。それ故に、文脈を適切にとらえコミュニケーションする力が大事である。文脈を適切なストーリーとして言語化し、相手に伝えることによってなぜその意思決定が今我々のおかれた状況下で最も合理的なのか、初めて理解してもらうことができるのである。

アーキテクトは優れた技術者であると同時に、優れたストーリー・テラーである必要があるのだと思う。

原文記事: yuichi-murata.medium.com