目的

Japan Container Days v18.12で改めて見直すコンテナベースで作るメリットというテーマで発表する機会をいただきました。当該発表のなかでインフラアーキテクト視点部分について本記事で補足します。

記述の流れ

基本的にスライドの流れにそって、補足事項をつらつらと挙げていきます。
なので体系的には整理されてない点についてご注意ください。

本記事内のインフラアーキテクトの定義

制度の概要：システムアーキテクト試験によると、情報システム開発におけるシステムアーキテクトとは以下のような役割を担う人を表すようです。

1.情報システム戦略を具体化するために、全体最適の観点から、対象とする情報システムの構造を設計する。

2. 全体システム化計画及び個別システム化構想・計画を具体化するために、対象とする情報システムの開発に必要となる要件を分析、整理し、取りまとめる。

3. 対象とする情報システムの要件を実現する最適なシステム方式を設計する。

4. 要件及び設計されたシステム方式に基づいて、要求された品質を満足する ソフトウェアの設計・開発、テスト、運用及び保守についての検討を行い、 対象とする情報システムを開発する。なお、ネットワーク、データベースなどの固有技術については、必要に応じて専門家の支援を受ける。

5. 対象とする情報システム及びその効果を評価する。

インフラアーキテクトはこの定義をベースに以下のような役割を担う人を表します。

1. プロダクトの全体最適の観点からプロダクトの動作環境の選定と設計
2. プロダクト実現に向けてのインフラの要件を実現可能な形への取りまとめ
3. プロダクトに対して要求される品質を満足するためのシステム構成の設計・テスト・保守について検討・開発を行う

一部、システムアーキテクトには記載されているものの、インフラアーキテクトには記載されていないものがあるとは思いますが、それはシステム全体ではなくインフラ領域に絞ったアーキテクトにあるためとお考えください。

これらの内容をもう少し噛み砕いて説明すると以下のようになります。

1. オンプレかクラウドか、パブリッククラウドならば、どのパブリッククラウドを利用するか、そのクラウドのうちのどのサービスを利用するかを選定する
2. ビジネス的に要求される要件(機能・非機能)についてシステム的な用語に置き換え、実現困難なものについては適切な落とし所を定義する
3. 2.で定義した要件を確実に満足するためのサーバ・ミドルウェアの構成、CI/CD、インフラの保守について検討・開発を行う

ざっくりとまとめると、プロダクトを構成するアプリケーションロジックコードの記述以外は大小はあれど基本的にすべて関わると考えてもらって構いません。

技術的なチャレンジの必要性

下に示すスライドでは、新しい技術にチャレンジすること前提で当日は話をしました。なぜ、新しい技術にチャレンジすることが必要なのかについてここでは説明しておきたいと思います。

技術的なチャレンジの必要性について以下の２つの観点から解説します。

1. 技術的に守りに入りすぎることのリスク
2. ホーソン効果の活用による労働生産性の向上

ただしここで述べている技術とは特定のOSSといった観点の技術に限らず、
システム・プロダクト開発の進め方といったプロセス技術も含めます。

技術的に守りに入りすぎることのリスク

技術的に守りに入りすぎることのリスクは主に2つに分類することができます。

1. 既存の技術に固執することによるリスク
2. 新しい技術への取り組みを行わないことによるリスク

前者については、既存の技術の深堀をすすめた場合に伴うリスクです。収穫逓減の法則に基づき投入した労力に対して得られる技術的利潤(＝生産性や品質の向上)は減少していきます。従って、投入する資源(人・時間・資金)が一定ラインを超えるタイミングでそのまま投資を続けるよりは新しい技術に投資の重心を移したほうが、技術的利潤の総量はより大きなものになります。

後者は、既存技術から新しい技術へと本格的に投資の向け先を変えるに際して種まきができていない状態を指します。

候補は多々あるため、個々のエンジニアまたは個々の小規模チームで小さな形で様々な技術に対するトライ＆エラーが積極的に行われるほど絞り込みの対象となる技術の候補は増えます。この場合、最終的な選定の結果はより(ビジネスまたは、テクノロジー面の)利潤の大きなものになる可能性が高くなります。

また、このような形での絞り込みを行うからこそ、組織として大規模な投資に値するかといった判断が客観的に可能になります。(これらの絞り込みを20%ルールなどを用いて業務として行うのか、エンジニア個人の自助活動として行うのかといった点は、組織の運営方針の問題となるので本記事ではスコープ外とします。)ただし、ここで述べた絞り込みは書籍や先行事例を通じた調査、外部有識者からの知見の移転などを通じて効率を高めることは可能です。

したがって、絞り込みの精度を上げるには個々のエンジニアが新規技術を調査、学習することの奨励、小規模なチームで明確な仮説を持った上で小さな形での検証と失敗を奨励することが組織文化として必要になります。

特に可能な限り小規模かつ検証可能な形での失敗をプラスに評価することが重要です。(経験を積んでいる人、例えばエンジニアリングマネージャが、
メンバーの1 on 1 ミーティングなどを通じて基本的な勘違いや見落としがないかといったことを確認することは必要かと思います)

このような活動がない場合、組織として次の技術への取り組みを本格的に
組織として大規模に時間と資金を投入しようとなった際に候補が多すぎ、
致命的な誤りを招く可能性が高いと思います。

このような観点から、既存の技術への投資を見直しつつ、さらに技術面での利潤(生産性、品質の向上)を得るために組織としての新規技術への取り組みを継続することはエンジアリング組織としての競争優位を保ち続ける上では重要なことであると言えます。

ホーソン効果の活用による労働生産性の向上

ピープルウェアにもあるとおり、ホーソン効果を上手く活用することで生産性の向上を狙うことができます。これは単純に技術的な面で改善というよりは個々のエンジニアのモチベーションを高めるための工夫です。

"労働者の周囲や上司の関心を高めることが、物理的要因以上に労働生産性の改善効果がある"というのがホーソン効果です。

既存の標準化された技術・手法とはあえて異なるものを採ることを宣言し、周囲がどのような観点で当該チームやエンジニアにたいして着目すべきかを明確にすることを通じて周囲の関心を高めることで、生産性の改善効果を狙います。

また、事前にどのような点に着目すべきかを明確にすることで、周囲が当該チーム、エンジニアを評価する際にどのような観点で評価すべきかを明確化しやすいといったエクスキューズ的な意味合いを持たせることも狙っています。

技術的なチャレンジについて必要性のまとめ

ここまでで、ざっくりと技術的なチャレンジの必要性について述べてきました。技術的なチャレンジを継続的に進めることの必要性は、端的に述べると
"継続的にエンジニアリングを担う組織としての競争力を維持するため"と"エンジニアが適度な刺激を受けながらモチベーションを高く保って開発に取り組むため"の2点に最終的には集約できると言えます。

フォロワーであることは問題ではない

いきなり全部盛りの問題点については当日お話したとおり、

・組織に当該領域の技術経験
・当該領域技術を受け入れる組織文化面の醸成

ができていない状態で導入しても摩擦を生むばかりで効果が上がりづらい(逆効果になる可能性すらある)という点があります。したがって摩擦を最小にしつつ、可能な限り早くステップを登っていくための方法を考えていく必要があります。

せいぜい登れるステップは1回につき技術領域ごとワンステップです。(どれくらいの頻度でステップを登れるかはチームとして投入可能なエンジニアリングパワーやどれくらいの頻度でイテレーションを回しているかなどに依存すると思います)

これは、複数の技術をまとめて導入すると特定の技術による効果を理解することが困難になるからです。
具体的には、得られたメリットがどのテクノロジーの導入に伴ったものなのかが不明瞭になります。

必要性のないテクノロジーについてはスルーする判断は絶対に必要です。インフラレイヤーにおけるテクノロジーやツールの採否判断をするのは**インフラアーキテクトの責務です。また、先々を見据えての登り方のルートを選定することもインフラアーキテクトの役割だと思います。

こういった段差は個人で超えることは可能ですが、組織(大小の規模はありますが)として考えたときにあまりに先に進みすぎると、純粋に技術的な部分だけでなく文化面でも後続組織がキャッチアップすることが困難になってきます。

したがって現時点で組織内に存在するのテクノロジー面のアセット、文化を踏まえた上でいち段階上を狙うことがベターになってきます。
(ただしショック療法的に圧倒的成果で殴りつけるといったことを意図するのであれば別です)

いち段階ずつしか登れないとしても先行に追いつくことができないかというとそんなことはありません。

これはすでに登る方向がある程度整備されているためです。先行している組織をベンチマークとする限りは少なくとも同じところまではより短い時間で登ることができるはずです。(ただしこれは技術や文化に限った話であり、組織として投入可能な資金などによって必ずしも同じ状況を実現できるとは限らないことを理解してください。また、他の登り方を探索する場合はこのルールにはあてはまらないことは大前提です)

絶対に業界内で一位を目指さねばならないコアコンピタンスとなる領域以外であれば、このようにフォロワー戦略を戦略として予め選択することもありだと思います。(個人的には最初はフォロワーでも最後は先行者として切り開く側に回りたい心持ちで取り組んではいますが)

先行する組織は逆に収穫逓減の法則のように当該のテクノロジー領域における成長は強烈なイノベーションがない限りは鈍化するため、後追いで完全に追いつくことはできなくとも近いレベルまでは粘り強く取り組むことでたどり着くことが可能なはずです。

テクノロジー視点だけで判断しない目標・目的で判断

このスライドで特に述べたかったのはエンジニアだからといって判断の軸は
エンジニアリングやテクノロジーの範囲に閉じるものではないという点です。

ITエンジニアはビジネスをテクノロジーを用いて牽引することを主なロールとして担うため、リスクとなるとテクノロジー面に着目しがちです。しかし、目的はあくまでもビジネスの成功であるため、ビジネスの成功(ビジネス面のリスクの低減・排除)のためにはテクノロジー面でのリスクをある程度飲む必要があります。ビジネス・テクノロジー面のリスクを判断して決断する(または組織、プロジェクトの上位層に判断を仰ぐためのテクノロジー面の情報をインプットする)こともアーキテクトの役割だと思います。

組織の成熟度に応じたテクノロジー選定

ここでどうしても言いたかったことは、特に前者の赤字です。組織の成熟度に応じて最適な技術スタックは異なります。つまり、組織のテクノロジーおよび、文化面の成熟度に合わせて最も効果(≒ビジネス成果)の上がる技術スタックは異なるということです。

なんとなくのイメージを武器・兵器ベースで考えてみました。

利用するテクノロジーの段階が低すぎても組織の成熟度を活かせなくなるのは当然ですが、逆に利用しているテクノロジーの段階が高すぎても組織の成熟度が低すぎ当該技術の適正な利用方法を理解できず成果が上がらないということです。

テクノロジーの選定に際して、組織の成熟度に応じて最も効果(≒ビジネス成果)の挙がるテクノロジースタックを考え、選定するのはアーキテクトの責務
だと思います。

まとめ

ここまででインフラアーキテクトの責務についてざっくりと述べてきました。このような点に基づいて諸々の判断するのがベターなのかなと思っています。残りの2領域については一緒に発表をした仲間が何か書いてくれるはず...