DevOpsを目指すKDDI株式会社–運用本部マネージャー大桃氏が語るBacklogを使った情報共有と進捗管理の効率化
Backlog導入前の課題
プロジェクト関係者が社内外ともに多く、情報共有がうまくいかない
Backlog導入後の効果
進捗管理や情報共有に費やしていたコストが0に。部署をまたいだプロジェクトでスムーズな業務連携ができた
KDDI株式会社は、開発部と運用部が密な連携を取ってDevOps的な組織を実現できるように、Backlogを共通の基盤ツールとして利用しています。「メールからBacklogに移行したことで、情報管理や共有に費やしていた時間的コストが0になった」と語るのは、運用本部の大桃辰也（おおもも たつや）さん。情報共有と業務効率化を目的とした Backlog 事例 をお伺いしました。
―――貴社の事業概要について教えてください。
プラットフォーム開発本部 アジャイル開発センター アジャイル開発3グループ 課長補佐 大橋衛（以下、大橋）：KDDI株式会社は日本の通信事業を支える電気通信事者として、「パーソナル」、「バリュー」「ビジネス」「グローバル」の4事業を展開しています。パーソナル事業は、au携帯やauひかりに代表されているような一般消費者の方に近い部分です。バリュー事業はau WALLETやau周りのコンテンツが該当します。ビジネス事業は、法人のお客様向けにモバイル端末やNWソリューション、クラウド型サービスなど多様なソリューションを提供しています。グローバル事業は、ミャンマーやモンゴル等のアジア地区での個人のお客様向け通信サービスや、法人のお客様向けのデータセンターを核としたICTソリューションを展開しています。
KDDIは、国内通信事業の成長、au経済圏の最大化、グローバル事業拡大を事業戦略として掲げています。特にau経済圏の拡大を達成するために、お客様の体験価値の向上を全社で取り組んでいます。
―――大橋さんと大桃さんが所属している開発部と運用部の役割についてご説明いただけますか？
大橋：私が所属するプラットフォーム開発本部アジャイル開発センターでは、パーソナル事業とバリュー事業に分類される新規のサービスやシステムを日々開発しています。運用本部と連携してプロジェクトを進めることも多いです。
運用本部 サーバーオペレーションセンター プラットォームG マネージャー 大桃辰也（以下、大桃）：私が所属する運用本部は、KDDIのサービス基盤となるネットワークや様々なサービス用システムの維持が主な仕事です。パーソナル事業、バリュー事業、ビジネス事業のシステムの運用保守や基地局の維持など当社のコア事業を支えています。
運用本部は、新たな取り組みとして開発と運用が二人三脚となる「DevOps」的な組織を目指して、改革を進めています。そうした背景もあり、開発と運用がより密に連携を強化する必要があるため、共通の基盤ツールとしてBacklogで一部のプロジェクトを管理しています。また、ウェブサイトで使うページの作成依頼を企画部からもらう場所としてもBacklogを使っています。
運用本部は、開発と運用が二人三脚となる「DevOps」的な組織を目指し、企画、開発と運用が密なコミュニケーションを取れるようにしていると語る。
目次
企画部と開発部と運用部、3部門のコラボレーションワークのためにBacklogを共通の基盤ツールとして活用
―――開発や企画など部署を超えてプロジェクトを管理するためにBacklogを利用されているのですね。具体的にどのようなプロジェクトを進めているのですか？
大桃：BacklogはKDDIの4事業を含めた会社全体のウェブサイトの運用管理を目的にして利用しています。以前は、メールを使っていたのですが、企画、開発、運用など部署をまたいでいるため登場人物が多く、課題の管理や情報共有に対応しきれませんでした。
―――メールでのタスク管理で起きていた問題について具体的に教えてもらえますか？
大橋：メールは様々な用途で使えるという利点がありますが、一方で情報が雑多になりやすいです。本当にアクセスしたい情報が埋没してしまって届かない、事の経緯を追いきれないということが頻繁に起きていました。最新の資料がどのメールに添付されているのか見つけるもの大変でした。Backlogは課題ごとにタスクを分けて進められるので、過去の経緯も追いやすいですし、最新版のファイルも見つけやすい。メール文化との大きな違いはそこだと思います。
大桃：メールでありがちなのが、当初の主題（タスク）から別の主題（タスク）へ話が流れて当初の主題（タスク）が完了したのかわからなくなるということ。Backlogは課題が完了したのか未完了なのか明確にわかるし、管理しやすいですね。
大橋：過去の経緯を簡単に共有できるので、プロジェクトメンバーの入れ替えがある時に情報共有がしやすい点でも利便性の高さを感じます。
大桃：そうですね。人事異動が半期単位であるので、その時に前任者が仕事をどのように進めていたのかなど、Backlogをみれば業務の引き継ぎが簡単にできます。
―――なるほど。プロジェクトはどのように立てていますか？
大桃：メールからBacklogを導入した経緯としては、コンテンツの企画の方からBacklogを使ってタスク管理をすると効率的にできるという話をもちかけられたのがきっかけです。製品紹介のためのウェブサイトのコンテンツを作成するコンテンツベンダーからBacklog上で、コンテンツ確認のご連絡をいただいて、それを弊社の方で確認して、ウェブサイトに反映するということをしていました。
1つの新規ウェブサイトが立ち上がる時にプロジェクトを立ち上げています。サイトの各コンテンツは、課題を立てて管理しています。大きいサイトでは複数プロジェクトで管理することもあります。各プロジェクトの参加メンバーは、社内外の関係者が多く、だいたい30から70名ほどになります。
メールではできなかった「資料を作ってその場で即共有」を実現！情報管理や共有に費やしていた時間的コストが0に。
―――メールからBacklogでプロジェクト管理をするようになったことで業務の効率化が進んだ事例などありますか？
大桃：プロジェクトの進捗共有に費やす時間が減りました。今までは進捗を共有する際に資料を必ず作成して、その資料を誰に配るかを考えて、フォルダを作って、メールに貼り付けて送信。そこから質問に回答していく、という工程を踏んでいました。Backlogは極端な話「資料を作ったらその場で共有」ができます。各自が自由に共有できるし、コミュニケーションもその場で完結します。
極端な話、資料を作るのを除くとしたら管理や共有に費やすコストはほぼゼロになりました。情報共有のためだけに時間を作ることも無くなりました。
大橋：たまにメールで情報共有をすると「信じられない。こんなことをやっていたのか！」と思うこともあります（笑）。Backlogに代表される「チケットドリブン」による情報共有の文化は、もはや我々の業務では欠かせないものになっています。
Backlogを導入したことで、メールでの進捗共有で起きていた煩雑な工程を大幅に削減できた。
Backlogを導入したことで、メールでの進捗共有で起きていた煩雑な工程を大幅に削減できた。
―――進捗の管理や情報共有という面で、他にも変化したことはありましたか？
大桃：自社ウェブサイトの制作を依頼している、外部のコンテンツベンダーの進捗が管理しやすくなりました。案件が多く、常時、30から40社とやりとりをしています。社内での情報は自社サーバーで共有できますが、社外のベンダーだとそうはいきません。表計算ソフトで進捗を管理して、そのファイルをメールに添付していましたがファイルサイズが大きくて送れないという問題が起きていました。担当者の変更も多いので、アカウントを管理するのも大変でした。Backlogに移行してからは、これらの悩みはすべて解決しましたね。
他にも、外部のベンダーが主導するインフラ構築の仕様管理にもBacklogを活用しています。私が担当しているウェブサーバーは、どのコンテンツを載せるのかで設定が変わるため、コンテンツの内容を企画部の担当者から細かくヒアリングして、アクセス負荷を想定した上でインフラの条件を整理します。企画とコンテンツベンダー、インフラベンダーと、登場人物が多いため密なコミュニケーションが重要なので、Backlogを活用しています。
定型業務はBacklogイシューテンプレートで一括管理！課題の重複や漏れの防止も
―――外部ベンダーや社内の部署など、登場人物が多いプロジェクトのタスクをもれなく管理するために工夫していることはありますか？
大桃：期限や担当者が決まっている定型業務は「Backlogイシューテンプレート」を使って、課題を一括登録しています。プロジェクトが始まる段階で必要なタスクを洗い出します。だいたい15、16件ほどの課題をエクセルに書き出して一括登録をしています。新規ドメインの立ち上げや新規のキャンペーンページ作成など、インフラ環境の構築が定型化されている業務で活用しています。一度エクセルに書き出しておけば、再利用できるので便利ですし、課題の漏れがなくなりました。
期限や担当者が決まっている定型業務を「Backlogイシューテンプレート」を使って、一括登録することで業務の効率化を実現している。
大橋：SSLの証明書の手配など、他部署の対応が発生することが多いプロジェクトは、いつまでに対応してもらうかなど期限を明確にする必要があります。ただ、枝葉にあたる作業であることが多いので、リリース前に「あれやったっけ？」ということも起きやすい。なので、課題を一括登録する時は、必要なさそうだけど念のため確認をしたいタスクも入れ込んでもらうこともあります。登録したタイミングで完了する課題も多いのですが、チーム内で「この課題は対応する必要がない」ということを認識できるので良いと思います。
―――課題の重複や漏れは減りましたか？
大桃：減りましたね。課題の登録漏れがリリースの1週間前に発生して、駆け込み案件として他部署に対応してもらうということが以前はよく起きていたのですが、それが無くなりました。
―――今後のBacklogの活用計画を教えてください。
大桃：基本的な使い方は現状のやり方を維持したいと思います。SaaS版とオンプレミス版の両方でBacklogを使っているのですが、ソースコードの管理をSaaS版だけでなく、オンプレミス版でも広めて、BacklogのGitをもっと活用していきたいですね。あとは、BacklogのwikiでCacooの図を自動で展開できるので、ヌーラボのサービスを併用して情報共有の効率化を進めていきたいですね。
※BacklogだけでなくCacooも導入している同社。Cacoo事例「au電子マネー「au WALLET」のインフラ構成図にCacooを活用--KDDIアジャイル開発センターの大橋氏が語るCacooの魅力」をお届けしています！
※掲載内容は取材当時のものです。