ソリューションアーキテクトの鈴木(@szk3)です。
事業ドメイン知識 + クラウドサービスの知識で、自社サービス開発をサポートする設計相談サービスとして「社内ソリューションアーキテクト」サービスという取り組みをスタートし、2017年から現在に至るまで3年以上にわたり運用してきました。
本エントリでは、この取り組みについて振り返り、まとめました。
サービスの成り立ちや考え方、どのように運用してきたのか？どんな変化があったのか？なぜクローズするのか？などなど。
自社でソリューションアーキテクトのような職種や役割を作っていこうと考えている方の参考になれば幸いです。
はじまり
コトのはじまりは、3年以上前、2017年4月に遡ります。
当時、主幹事業のAWS移行が概ね完了し、各部署の裁量で個別にAWSアカウントを運用し始めたタイミングでした。
自分たちでインフラリソースを自由にできるようになった反面、慣れないAWS上での設計に対する不安の声も同時に耳にするようになりました。 当時からAWSの情報量は膨大であり、選択肢の多さや制限事項の見落としなど、従来のサービス開発とは別のコストが発生するようなシーンも顕在化しつつありました。
もちろん、能動的にキャッチアップしマネージできる部署も存在しましたが、少ない人的リソースや挑戦的なサービス開発目標などで余裕が少なく、キャッチアップに少なからず時間がかかる部署もありました。
そこで、事業ドメイン知識とクラウド上での設計知識を効率よく伝達しつつ、設計や問題の切り分けをサポートすることで調査コストや設計の差し戻しコストを減らし、サービス開発効率に間接的に貢献しようと始めたサービスが、「社内ソリューションアーキテクト」サービスでした。
実際どうだったの？
どうやって相談するの？
JIRA(課題管理ツール)にチケットを切ってもらい、相談内容を書いてもらいます。
その後、30分から1時間程度のミーティングを設け、相談内容についてディスカッションした後に、議事ログや議事フォトをチケットで共有する。
たったこれだけです。
あれこれ仕組みを整えるより、やってみてから考えるという感じでスタートしましたが、 シンプルなやり方ゆえに、特に大きな変更が必要になることもなく、当初からのスタイルを今でも継続しています。
チケット自体は１回づつクローズしますが、ひきつづき相談したい場合は何度でも相談できるようにしています。
どれくらいの件数の相談を受けたの？
3年半くらいの間で、100件を超える相談に乗ってきました。 最も多い時でも1週間に2-3本のペースだったので、比較的緩いペースだったと思います。
どれくらいの工数掛けてるの？
相談は、あくまでも発生ベースのため、一概に月に何時間とかは出しにくいのですが、平均すると業務時間の10%程度が感覚値として近いと思っています。
何人でやってるの？
アーキテクトの体制は、自分一人で始めました。
もっと多様な視点で相談に乗れる体制にしたかったのと、特定のバイアスを避けるため、 設計に関心のある同僚を誘い、途中から約1年ほど2名体制で相談に乗っていました。
アーキテクト数名によるモブプロのような設計相談は、発散しきって収集できないように思われるかも知れませんが、 最終的には「やっぱりここだよね」という落ち着くべきところに落ち着くことが多かった気がします。
しかし、残念ながら、現在はまた一人体制になってしまいました。
相談範囲とか内容は？
当初は、AWSを主軸に相談に乗ってきましたが途中からGCP周りの相談も乗るようになり、現在はクラウドアーキテクトとして幅広い相談を受けています。
相談内容は重い相談から軽い相談まで様々で、相談者の目的や課題に対する優先度もバラバラです。
カテゴリとしてまとめるとすると、バッチの設計・実装相談、CI/CDの構築相談、クラウドでのストレージ選定、システムリプレイスの相談、新機能のフィジビリ相談、その他 のような感じになります。
また、クラウド周りのトラブルシューティングにも駆り出されることが多々あります。
どんなことに気をつけてきた？
意識してきたことはたくさんありますが、ひとつ選ぶとしたら「相談者の立ち位置を忘れない」ということです。
相談相手によって、ドメイン知識やクラウドの知識に差があることが当然なので、全員に対して同じスタンスではなく、相談者の目線で課題解決を一緒に考えるように心がけていました。
アーキテクトとしての理想系の回答は持ちつつも、一番重要なポイント（納期、リソース利用料、運用コスト、拡張性など）をすり合わせて、トレードオフとセットで押し付けない提案をするようにしていました。
あくまでも相談者の意見を深堀りし、選択肢を広げ、相談者の選択をサポートすることを提供価値として意識的に持つようにしています。
サービス設計と同じで、顧客(相談者)の目線に立つのが大事ですね。
なにか変わった？
個人的な変化としては、社内での認知が進み、クラウドというワードで想起してもらえるようになりました。
そのため、ありがたいことに、いろんなところからチャットで小さい雑相が飛んでくるようになったり、 海外カンファレンスなどにも参加させていただくような、新しい機会に恵まれるようになりました。
組織的な変化としては、残念ながら、目に見える大きな変化を生み出すことはできていないと思っています。
これは当初、個別相談対応を経てソリューションカタログを作成し、共有することでの効率化を提供価値として考えていましたが、実際にはカスタムされた相談は転用が難しいケースが多々あり、汎化しづらい問題がありました。
仮に相談時点のプラクティスをカタログ化したとしても、そのソリューションが賞味期限切れになる可能性を考慮すると、カタログのメンテナンスコストより「相談のタイミングでベストのものを一緒に考える」ことを重視していました。
しかし、この当時の判断は、完全に間違った判断だったと思います。なぜなら、カタログを実際に作ってないからです。 やってみた上でドキュメンテーションのコストがかかるなら判断のしようがありますが、机上の算盤で判断してしまったのが反省点です。
カタログの更新に責任を持ち、カタログを育てていったほうが組織に対する価値を提供できた可能性を考えると、「とにかくやってみる」をしなかったのは、今思うと反省すべき点になります。
相談内容にも変化がありました。
以前に比べ、クラウドの知識はコモディティ化してきており、一般的なユースケースはほぼ情報が出揃っています。 そのため、相談者が自身でベストプラクティスにたどり着きやすい世の中になり、特に相談に乗らなくても自身で解決できるケースが増えているように感じます。
また、時代はクラウドからコンテナの時代へと、アーキテクトの関心も変化していっています。 その流れに迎合し、アプリケーションの実行環境はコンテナ化を推奨し、社内のKubertnetesへの載せ替えをセットで提案するようになりました。
他にも、CI/CDなどに代表される便利な外部サービスが充実してきたこともあり、クラウド上で作るパターンと、外部サービスを使うパターンの比較の相談も増加しました。生産性向上のために外部サービスを積極的に使っていくことの敷居が下がり、それらサービスの知識や肌感も幅広く求められるようになりました。
まとめ
「社内ソリューションアーキテクト」サービスという取り組みを紹介しました。
いまさらですが、約3年前(2017年8月)にLT発表させていただいた社内ソリューションアーキテクトについての資料を公開しておきます。
www.slideshare.net
ここに書いてあるとおり、最終目標は「サービス提供先」への貢献にあると今でも思っており、その方向性は一貫してきました。
反省すべき点は多々ありますが、利用者からのアンケート結果では、自分でも驚くような高評価を頂くことができました。
じゃあ、なんで閉じるの？って話ですが。
現在、社内ではアーキテクトに特化した部署が出来たこともあり、組織単位で「アーキテクト活動」として相談に乗るような取り組みが始まりました。 「アーキテクト活動」は情報のストックにも重点を置いているため、これらが活性化することで自分が構想しつつ着手できてなかった知見のストックも促進されるのは大変喜ばしいことだと思っています。
また、アフリカのことわざで「早く行きたければ一人で進め、遠くまで行きたければ皆で進め」とあるように、スペシャリティと多様性が組織にとても重要だと考えています。ですが、今と同じやり方や延長線上には遠くに行くための道筋が描けなかったというのが、大きな理由になります。
そこで、もっと良い形を模索する中で、いままでの経験を生かし新しい価値提供体験を作るために、一度立ち止まることにしました。
約3年半続いた「社内ソリューションアーキテクト」サービスは、今月末でサービスとしての役割を終了させますが、自身のロールとしては引き続きクラウドアーキテクト、ソリューションアーキテクトとして活動していきます。
今後は、社内の技術的な相談に対して、また少し形を変えて取り組んで行くことになりそうなので、そちらの活動はまた別のエントリで紹介したいと思います。
自社でソリューションアーキテクトのような職種や役割を作っていこうと考えている方の参考になれば幸いです。
