こんにちは。データ・AI戦略部 SREチームの小野です。普段は部内のシステムに対し、SRE推進活動を行っています。直近では、データエンジニアと協力してデータ基盤周りの改善に取り組んでいます。
<SREの主な仕事>
- IaC化(Terraform/Terraform Cloud Business)の導入・推進
- SLI/SLOの導入・推進
- ポストモーテムの導入・推進
- アプリケーションデプロイ基盤の導入・推進
- ツールやAPIの設計・開発
- インフラ設計・開発・運用
- トイル削除・システムの自動化
- データ基盤改善
一般的なSREエンジニアは、インフラ関連の業務が中心になると思います。しかし、データ・AI戦略部のSREチームは、開発を含めた幅広い仕事をします。やりたいことがあり、手をあげればそれを後押ししてくれる雰囲気の職場です。
今回は、SREエンジニアである私が、組織改善プロジェクトを立ち上げた話をお伝えします。「SREエンジニアなのに組織改善?」と思われるかもしれませんが、組織作りに悩まれている人の参考になれば嬉しいです。
<この記事を読む価値>
- どの組織でもおこりえる一般的な問題について知ることができる
- 解決にむけてどのようにアプローチしたのか知ることができる
- うまくいったこと、いかなかったことを知ることができる
<目次>
組織の課題
コロナによりリモートワークが普及し対面での会話が減る一方で、Slackなどのテキストコミュニケーションやオンラインミーティングが増加しました。これにより「業務上のやりとりのほとんどがシステム上でおこなわれる」など私たちの働き方は大きく変わりました。
便利になったと感じる一方で、次のような課題も感じていないでしょうか。
- メンバー交代による引継ぎリスク
- タスクやナレッジの属人化
- コミュニケーションロス
リモートワークでは、10秒でおわるようなちょっとした確認でもSlackや会議システムを通してコミュニケーションをとる必要があります。それを面倒に感じ、コミュニケーションをとらなくなった人もいるのではないでしょうか。コミュニケーションがロスするとタスクやナレッジの属人化が進んだり、人事異動などでメンバーが交代する際、中途半端にタスクが引き継がれてしまうリスクがあります。
これらの課題は、私の所属する組織で実際におこったことです。しかし、「どの組織でも一般的におこりえる問題」だと考えています。
SREの観点
これらの課題は、システムの安定稼働や信頼性向上に責任を持つSREの観点からも悩みの種になっています。なぜならSREを推進するためには、システムだけではなく、「メンバーや組織がうまく機能している状態」が望ましいからです。
例えば、組織が次の状態だったケースを考えてみましょう。
この図は、先ほど例にあげた「一般的な組織の課題」を見える化したものです。メンバー間のコミュニケーションロスは、お互いに何をやっているかわからない状態をつくりだします。この状態になると各自がバラバラな方法で業務を行うことになり、属人化の加速やメンバー交代による知見の喪失につながります。その結果、エラーが多発するシステムが出来上がったり、運用ドキュメントが整備されないなどの問題がおこります。
この状態では、SREを推進してもあまり成果は望めません。SREを推進するには、システムだけではなく人との信頼関係も大切であるとしみじみ感じます。
問題分析
メンバーの交代、タスクやナレッジの属人化、コミュニケーションロス。これらの問題はどのようなアプローチで解決すれば良いのでしょうか? 「コミュニケーションをもっと密にして!」とメンバーにお願いしてまわるしかないのでしょうか。SREエンジニアとしては「仕組み」で解決したいところです。
そこで、このような課題が発生する組織の構造(仕事の進め方)に着目するため、次の図を書いてみました。
このような組織を「縦割りの組織構造」と呼ぶことにします。縦割りの組織構造では、タスクをチームではなく、個人で処理します。つまり、個人で完結するタスクが多くなるため、他メンバーとのコミュニケーションが最低限でもタスクを完了させることができます。素早くタスクが完了するというメリットはありますが、タスクやナレッジの共有をしないため、属人化が進みます。また、メンバー間で目指す方向性がバラバラになり、まとまりのない組織になります。
もちろん全ての組織が縦割りの組織構造になっているわけではないと思いますが、原因がわからない場合は、「構造」に着目するのも一つの手だと考えています。
課題解決へのアプローチ
縦割りの組織構造が課題の原因であると仮定した場合、この構造を変える必要があります。そこで以下の組織構造を考えました。
この組織構造を「DAO型組織構造」と呼ぶことにします。DAOとは「Data AI Organization(データ・AI組織)」の略で、私たちの組織の名前が「データ・AI戦略部」なので、それに合わせた名前にしました。ちなみに「ダオ」とよびます。
DAOは、データ・AI戦略部をサービス化したプロダクトの名前です。つまり、私たちは「組織そのものをシステム開発に落としこんで組織構造を改善する」取り組みをスタートしました。それが組織改善プロジェクトの全容です。「そんなことができるの?」という声が聞こえてきそうですが、この考え方にはいくつかのメリットがあります。
- 組織のあらゆる仕組みや業務を機能として捉えることができる
- 機能化することで問題点の把握、改善などのPDCAサイクルを回せる
- 各メンバーの成果がDAOの成長に繋がる
「組織」という言葉はフワッとしていると感じたことはないでしょうか。 何を持って組織というのか、どこからどこまでが組織なのか、その輪郭は常にぼやけています。しかし、DAOとしてサービス(プロダクト)化してしまえば、その輪郭がはっきりし、「DAOを成長させる」という目標でメンバーの方向性を一致させることが可能になります。
組織改善プロジェクトのはじまり
DAOをつくるために、以下のことに取り組みました。
- ビジョンをつくる
- 計画を立てる
- メンバーに共有する
順を追って説明します。
ビジョンをつくる
最初にビジョンをつくりました。私たちデータ・AI戦略部の組織目標は、「事業部に対し専門性に基づく支援を行い、全社的なデータ・AI活用をリード・推進する」であるため、DAOを次のように定義しました。
※ DAOの定義はあくまでイメージであり、実際の組織方針とは異なります
「こんなものをつくりたい」という最終イメージが固まるとやるべき作業が明確になります。
計画を立てる
ビジョンの次は計画を立てました。DAOはこれまでに取り組んだことのない施策であったため、試運転期と拡張期に分けて計画を立てることにしました。何事もまずは小さくはじめてみることがベストプラクティスです。
スケジュールは次の通りです。
2ヶ月間のスプリントを回して開発するスケジュールにしました。プロジェクトを始める前は「2ヶ月間は長いかも」と心配しましたが、いざ始まってみるとちょうどよい期間でした。新しい施策に対してメンバーの慣れが必要だったためです。ちなみに、この記事を書いている2023年8月時点では、DAOに必要な基本機能はほとんどつくり終えることができました。
メンバーに共有する
業務改善プロジェクトにおいて一番大変だったことは、メンバーにDAOを共有することでした。共有会を開きましたが「データ・AI戦略部をサービス化する? どういうこと?」、「なんでそんなことをするの?」、「やりたいことがよくわかりません」などメンバーからは疑問の声があがりました。
組織をサービス(プロダクト)化するという施策は、発案者である私自身も取り組んだことのない施策であったため、メンバーにやりたいことを正確に伝えられませんでした。イメージを持ってもらうため、前述のビジョンや今後の成長戦略、ロードマップなどをつくり、メンバーと何度もディスカッションをかさねました。
上の図はDAOの成長イメージ、下の図はDAOのロードマップです。
※ あくまでイメージであり、実際の組織方針とは異なります
また、データ・AI戦略部にはチームが4つありますが、そのうちの2チーム(SREチーム、データエンジニアチーム)で始めることにしました。スモールステップで結果を出しつつ、組織のサービス(プロダクト)化のノウハウをためる必要があったためです。人数を絞ることで共有コストを減らし生産性をあげることもできました。
開発方針決め
「組織をサービス(プロダクト)化する」についてもう少し詳しく説明したいと思います。世の中にはたくさんの開発手法がありますが、たいていは以下のフローをなぞるのではないでしょうか。
- 要件を定義する
- 仕様を検討する
- 開発をする
- テストあるいは動作確認をする
- リリースをする
これらの工程をソフトウェアのみならず、「組織上の全てのイベントに対して行う」ことで組織をサービス(プロダクト)化しようと考えました。全てのイベントとは開発はもちろん、定例、ミーティング、ドキュメント作成など、一見開発とは関係のないイベントに関してもその対象とします。
組織を分解する
組織を運営する上で、発生するイベントを分類してみます。
- コミュニティ — 業務を円滑に行うために必要なこと
- 定例
- タスク管理
- ドキュメント作成
- ミーティング(ディスカッション)
- ふりかえり
- インフラ — システムが稼働する場所
- AWSやGCPなどのクラウドインフラ
- New RelicやPager Dutyなどの監視サービス
- TerraformやTerraform Cloud BusinessなどのIaC
- システム —データやAIなどユーザに価値を届ける部分
- データ基盤やアプリケーションデプロイ基盤
- AIプロダクト
- APIや管理画面
インフラやシステムについては、これまでのソフトウェア開発と同様に開発します。ここで注目したいのが、コミュニティに分類されたイベントに対しても「機能」とみなすことです。
わかりやすいように組織をコンポーネント化した図を用意しました。
※ 各コンポーネントの意味は割愛します
日々の業務は、「インフラ機能」上で「コミュニティ機能」を利用し、叶えたい「システム機能」を実現していく流れになります。このようにそれぞれのイベントを「機能」として捉えることで、組織を「サービス(プロダクト)」としてみなせるようになると考えました。
ツールを選定する
DAO開発を行うための技術選定について少しお話しします。
まず、インフラ機能に関してですが、Terraform Cloud Business(以下、TFCB)をインフラ基盤としました。TFCBの詳しい話は「TerraformとTerraform Cloud Businessを導入してインフラ環境の構築・運用を改善してみた」を参照してください。
現在、HashiCorp Japan社と協力してTFCBによるインフラ基盤の標準化にチャレンジしており、以下のパイプラインの実現を目指してインフラ整備を進めています。TFCBはDAOを支える土台になるため、今後も積極的に活用したいと思います。
システム機能については、特に語ることはありません。これまで通り各チームがPythonやGo言語、その他の技術を使って要件を形にしていきます。今後は、それらをDAOの機能として取り込んでいく予定です。
最後にコミュニティ機能ですが、以下のツールを使うことに決めました。ツールの利用方法はこの後説明します。
- Confluence — 仕様書記載場所
- JIRA — タスクを格納する場所
DAO開発の進め方
ここからは、実際にDAO開発の進め方について話していきます。
業務フローを定義する
DAO開発では、最初に業務フローを定義しました。
業務フローを定めることで、元々の課題であった「メンバーの交代による引継ぎリスク」、「タスクやナレッジの属人化」、「コミュニケーションロス」を解消することにつなげました。
- 定例会 — メンバーのタスクの進捗、新たな課題の確認
- JIRAタスク — メンバーのタスクの見える化、メンバー交代問題の改善
- Design Docs — 業務上で知り得た情報の出力先、属人化の改善
- ディスカッション — コミュニケーションの改善
- グランドデザイン & 運用ドキュメント & スキル管理 — ドキュメント運用
- ふりかえり会 — DAO開発全般に関してのふりかえり
業務フローの「定例会」や「Design Docs」などもDAOの機能として、Confluence上で管理しています。
機能群に表示されている項目がDAOの機能になります。定例やDesign Docsのような一見ソフトウェアと関連がなさそうなイベントも要件の洗い出し、設計、実装、リリースの流れにのせて、日々アップデートしています。
タスクの見える化の取り組み
DAO開発では、メンバーのタスクの見える化に注力しています。これまでは、メンバーのタスクは個人で管理していましたが、JIRAにDAO開発用のProjectをつくり、全てのタスクをそこで管理することにしました。
JIRAとConfluenceは連携することができ、JIRAマクロを使うことでメンバーに割り振られたJIRAのタスクをConfluence上に表示させることができます。この取り組みにより、各メンバーのタスクの内容、進捗具合、タスク量などを可視化することができました。
加えて、似た内容のタスクを特定のメンバーに固定せず、未対応メンバーに割り振ることで、メンバー交代が発生してもスムーズに引継ぎが行えるように配慮しています。
ドキュメント整備の取り組み
DAO開発は、ドキュメント整備を徹底しています。「ドキュメントから始まり、ドキュメントで終わる」そんなイメージで業務フローを構築しています。特に新しい取り組みとして、グランドデザインとDesing Docsなどのドキュメント作成ルールを定めました。
「こうありたい」というビジョンを定め、そこから組織の現在の状態をギャップとしてJIRAにタスク登録します。そこからDesign Docsやグランドデザインなどのドキュメントを作成していくイメージです。
Design Docsには、システムの要件、設計、注意事項など「業務上で知り得た全ての知見」を記入します。
タスクの完了後、Design Docsの内容をグランドデザインに反映します。これにより「ドキュメントが常に最新の状態になる」ように工夫しています。
グランドデザインやDesign Docs以外にも様々な種類の資料がありますが、管理がむずかしくならないように用途ごとに記載場所を定めて管理するようにしました。ドキュメント反映時にはメンバーに共有するルールにしているので、リアルタイムに引継ぎが行われます。
コミュニケーション改善の取り組み
コミュニケーション改善の取り組みとして、ディスカッション(会話の提供)機能を取り入れました。複数メンバーで仕様の検討をしたり、レビューをしたりする場として活用しています。普段話さなかったメンバーとも会話する機会が増え、コミュニケーションが改善してきたように感じます。
また、ディスカッション時には議事録(Confluence)を書くようにしており、そのフォーマットはなるべくシンプルにし、ディスカッションの目的をはっきりさせるように工夫しました。
DAO開発フローを定義する
業務フローはチーム内での業務の進め方を表していますが、組織のサービス(プロダクト)化のイメージをより明確に掴んでもらえるよう、全体的なDAO開発フローもお伝えします。
組織を運営する上で発生するコミュニティ、インフラ、システムの3つのイベントは一つの例外もなくDAO開発フローによって課題の精査からリリースまでの各工程に流されます。そして2ヶ月に一度ふりかえり会を行い、「実装した施策(機能)が必要だったか」判断する場を設けています。このように組織をソフトウェア開発フローにのせることが可能となり、その結果、組織のサービス(プロダクト)化が成立しました。
組織改善プロジェクトの感想
DAOとSREは親和性が高いと感じています。SREエンジニアの責務は、サービスやプロダクトの信頼性向上を図ることです。そのために、システム全体を把握してボトルネックの発見やトイルの削除、システムの自動化・効率化を推進する必要があります。
ただし、「メンバーの交代による引継ぎリスク」、「タスクやナレッジの属人化」、「コミュニケーションロス」といった課題が発生している状態ではチーム内あるいはチーム間でサイロが生まれるため、SRE推進のハードルが上がります。
しかし、DAOにより組織上のすべてのイベントが機能化されるので、新たに課題が発生した場合でも該当する機能を修正して対処できるようになり、それが「DAOが成長した」という結果につながります。DAOの成長は所属するメンバー全員のメリットになるため、メンバーも協力し合うようになります。協力関係のある組織では、SRE推進活動もやりやすいです。
プロジェクトを進める上での注意点は、あまり熱くなりすぎないことだと思います。DAO化を急ぐあまり、ディスカッション時にメンバーと衝突することもありました。組織は様々な考え方を持っているメンバーで構成されています。キャリア、年齢、性別、出身地など同じ人は一人としていません。「みんな違って当たり前」だという認識を頭の片隅に入れておかないとプロジェクトを円滑に進めることは難しいです。また、ディスカッションを重ねることは大切ですが、時には物事を前に押し進める勇気も必要だと感じました。
今後のビジョン
DAOはデータ・AI戦略部をサービス(プロダクト)化したものであるため、ユーザに利用してもらう必要があります。そのために今後は他組織へDAOの提供を開始し、組織目標である「事業部に対し専門性に基づく支援を行い、全社的なデータ・AI活用をリード・推進する」を実現したいと考えています。
直近では、ヘルプデスク機能をDAOに実装する計画を立てています。この機能で、外部から様々な依頼を一元的に受け付ける体制が構築できる予定です。
そのあとは、ChatGPTなどの新しい技術を取り入れつつ、DAOの機能をアップデートしていき、ぐるなびにとってなくてはならないサービス(プロダクト)に成長させていきたいです。
おわりに
リモートワークが普及するにつれ、これまで当たり前だった働き方が見直されるタイミングが来たと個人的に考えています。
オンプレからクラウドへの移行、TFCBのようなSaaSサービスの普及、ChatGPTによるAI活用の汎用化など技術革新もおきています。正直なところ、将来何が必要となるか検討もつきません。そんな変化の激しい時代だからこそ組織をサービス(プロダクト)とみなし、ソフトウェアをアップデートするように時代に合わせて柔軟に変えていける組織にできたらとても面白いと思います。
ここまでお読みいただき、ありがとうございました。
