ピクスタが取り組むIT監査のための課題承認フローでのBacklog活用事例
Backlog導入前の課題
上場に向けてIT監査の承認フローがボトルネックとなっている。未承認項目の発生を防止できる仕組みが必要
Backlog導入後の効果
Backlogのカスタム属性で承認項目を必須にすることで、未承認項目を0件にできた。GitHubやChatworkとのAPI連携で手動の確認作業を自動化して業務効率化を実現。
仕様や画面は現行バージョンと異なる可能性があります。
Backlogの最新版についてはこちらからご確認ください。
ピクスタ株式会社では、クリエイティブプラットフォーム「PIXTA」の開発業務に加えて全社的にBacklogを利用しています。さらに、IT監査のための課題承認フローの作成にもBacklogを活用しています。カスタム属性やAPIを用いて漏れのない承認フローをどのように構築しているのか、IT監査のご担当者にお話をお伺いしました。
―――貴社の事業概要について教えてください。
プラットフォーム本部 開発部 部長 星直史(ほしなおし)氏:PIXTAは3030万点以上の高品質の画像素材(写真やイラスト)や音楽素材を売買できる、クリエイティブプラットフォームです。現在は日本語、英語と中国語(繁体字・簡体字)、タイ語、韓国語と6言語に対応しています。
―――Backlogを使っている業務内容やプロジェクトについて教えてください。
Backlogは2010年から利用しています。開発タスクの管理をメインに、営業、サポート、マーケティング、コンテンツ制作、バックオフィス、広報まで全社的に利用されています。また、国内だけでなく、ベトナム、台湾、タイ、韓国など海外拠点のタスク管理にも活用されています。
特に利用されているのは、自社サービス「PIXTA」の開発プロジェクトの管理ですね。
―――Cacooもお使いいただいているみたいですね。
Cacooは2013年から利用しています。図を描画できるツールを探していたときに、Backlog経由でヌーラボがCacooも開発していることがきっかけでした。
AWSアイコンが充実していたことに加えて、手書き用のモックやUML図などの描画のしやすさも決め手でした。現在はネットワーク図やシステム概念図など、インフラのサーバー構成図の作成の際に利用されていて、アカウント所持者のほとんどがインフラ開発者もしくは、全社的なシステム構成を把握しているリーダーです。
CacooはBacklogとは違って、全員が利用している訳では無いのですが、開発者がビジネス職のメンバーにネットワークの複雑な構成を伝える際の説明資料として利用しています。
目次
口頭での作業依頼+個人のタスク管理をBacklogに集約。ノウハウの横展開と精度の高い優先度決めを実現
―――ピクスタ様は日本とベトナムに開発拠点を置いています。具体的にどのような開発業務で活用されているのでしょうか?
弊社の開発フローは、タスクの発生元が国内か国外かで分かれます。国内の場合は日本の開発チームによってプロジェクトが進められますが、海外拠点の場合はベトナムの開発チームによってプロジェクトが進められます。
開発課題の管理の仕方について、例えば機能を実装する場合は、機能名で親課題が立てられます。そして、機能に付随する細かい作業は、日本のディレクターやベトナムのブリッジエンジニアが子課題に分解しています。それと同じタイミングでプランニングと呼ばれる、ディレクターと開発者による作業のすり合わせがされ、開発が実行されます。
―――Backlogを導入する前はどのように開発業務のタスク管理をされていましたか?
ビジネス職のメンバーから開発者に口頭で仕事が依頼されることが多く、個人でメモをしてタスク管理をしていました。例えば「SQLでxxデータを出してください」という指示がビジネスメンバーから発生する、というパターンですね。口頭依頼+個人管理で作業を進めてしまうと、誰が何をやっているのかが見え辛く、作業ログも残せないので情報やノウハウを横展開できなかったんです。
―――導入後は課題は解決できましたか?
はい。Backlogを導入したことで2つ効果があったと感じています。
1つ目は「作業ログを残すことでノウハウを横展開できる」
2つ目は「タスクの優先順位決めができるようになった」という効果です。
以前は、個人で管理されていたタスクですが、Backlogに課題登録をして、開発メンバーとビジネスメンバーに共有できるように管理したことで、誰がどのタスクに取り掛かっているのかが明確になりました。さらに、重要度を数値に置き換えることで、より現実的で建設的に作業に取り組めるようになりました。
他のツールも検討しましたが、ビジネス職メンバーもすぐに操作できて開発者もタスク管理として使えるツールとなるとBacklogが最適だと感じました。
―――タスクの優先順位はどのように決めていますか?
タスクの優先度は週次会議で決めています。Backlogには課題の優先度を低中高で切り替えられる機能がありますが、カスタム属性も併用してインテジャー(整数)を入力し、さらに細かく優先順位を決めています。
入力する数値の定義については、あまり厳格なルールは設けていません。「どの課題を優先するのか」に焦点をおいて、個人の入れたい数字を入れています。例えば、ひとによっては1000や1万などを入れているひともいますね(笑)。要は数字の大小で優先度を決めています。
カスタム属性で優先度を数値化しておくことで、従業員がいくら増えても、Backlogを見ればタスクの種類や優先度が決まっているので、何に一番注力すべきなのか把握しやすいのが特長です。ピクスタ上場時のIT監査をBacklogがサポート!カスタム属性で承認項目の確認を必須に
―――ピクスタ様では上場時のIT監査でBacklogを使われたそうですが、どのようなフローでチェックをしているのでしょうか?
ピクスタでのIT監査の目的は「ピクスタは規律を守ってウェブサイト制作をしています」ということを伝えるものです。IT監査の対象になるタスクは事前承認と事後承認で分けられています。具体的には以下の3つのチェック項目で分類されています。
- 1.事前承認(会社に悪影響が無いかをチェック)
- 2.動作確認*(ユーザーに悪影響が無いかをチェック)
- 3.完了確認*(ウェブサイトに承認内容が反映されているかのチェック)
*2.動作確認と3.完了確認は「事後承認」にまとめています。
事前承認は、開発部長から承認を得なければならない、IT監査のなかでも重要度が高いフローです。具体的には、会計に関係することや、購入金額、クリエイターへの支払いなどが挙げられますね。判断時に必ず第三者の目を通すことができる仕組みにしています。
一方で「事後承認」にまとめられる動作確認と完了確認は事前承認よりも重要度が高くないフローです。例えば、トップページのアイキャッチ画像を変更するなど、失敗してもサービスのみに影響があって、監査の部分ではそこまで影響がないものです。
―――そうなんですね。Backlogを用いて課題の承認をするフローはどのように作られているのでしょうか?
1つの機能を実装する際に必要な承認項目は5つなので、カスタム属性を使って各承認項目を作成しています。
具体的なフローとしては、まずIT監査の対象となるタスクをディレクターがBacklogに課題登録します。その際に部門長に承認依頼をします。次に、開発部長の承認を得て、開発者が機能を実装します。その後、レビュー依頼と動作確認の依頼を同時に進めて、承認を得たら起票者が課題を完了をするというフローです。
―――BacklogをIT監査で使用する前と後ではどのような効果がありましたか?
5つの承認項目をBacklogの必須属性にしたことで、未承認項目を0にする仕組みを作れました。
Backlogを用いたIT監査の承認フローが完成するまでは、部門長承認でうまく連携が取れておらず、監査の判定結果もあまり良く無いものでした。上場を目指す上で大きなボトルネックとなっていたので、Backlogで承認フローを明確にできたことは大きな成果だと感じています。
APIを活用してGitHubやチャットワークとも連携。未承認課題を確実に洗い出し
―――未承認項目0にするための仕組み作りについて詳しくお伺いして良いですか?
実はAPIを用いてBacklogとGitHub、コミュニケーションツールのチャットワークを連携しています。
GitHubはすべての作業ログがBacklogに集約されるような仕組みです。具体的には、開発者がGithubにコミットをするとGitHubのWebhookを使って、Backlogに証跡が残るようになっています。IT監査では開発の一連の作業を提出する必要があります。そこで、一連の作業をBacklogに記録して、最終的にマスターにマージして課題を完了しています。
開発者はGitHubにプッシュをするだけで作業内容がBacklogに自動で同期されますし、監査法人もBacklogの情報だけ確認すれば良いので、双方にとってメリットがあります。
チャットワークはBacklog上で未対応になっている完了確認や各承認のアラートを「承認ルーム」という専用のトピックに投稿しています。1週間で膨大な量の承認項目が発生しますが、このトピックを確認すれば、未承認や完了確認漏れを防ぐことができます。
―――BacklogをIT監査で利用することのメリットはありますか?
実は他のツールも検討しましたが、インターフェースが技術的な側面が強く、承認フローに入っているビジネス職のメンバーだと使いづらいと感じたため断念しました。もし、承認フローに非エンジニアのメンバーが入っている場合は、Backlogが最適だと思います。
他にも、BacklogはAPIが公開されていたり、カスタム属性が使えたりするので、自社の業務フローに沿って柔軟に利用できるのも魅力だと感じています。
―――今後のBacklogの活用計画を教えてください。
IT監査の承認フロー業務の効率化をもっと進めていきたいですね。例えば、BacklogのIDとChatworkのIDを紐づけることで、承認が必要な課題が起票されたと同時に担当者に自動で通知するといった取り組みです。
他にも、手動でもらっているレビュー承認と動作確認承認も効率化したいです。GitHubでマージされたタイミングでBacklogのカスタム属性で承認済みにしたり、実際にマスターにマージしたら処理済みにしたり。例えば動作確認環境をクローズしたとき、もしくは完全にリリースが終わったときに、自動で課題番号を拾ってきて、Backlogのステータスを完了することができるといったことです。
まだまだやれることはたくさんあると思いますね。
—— ありがとうございました!
(番外編)実は、今回の取材はBacklogの拡張機能「backlog_benri」を開発してくださった海馬沢さんのご紹介で実現しました。
海馬沢さんからのコメント:
「Backlogベンリ」という拡張機能を以前作りました。開発した背景には、ChatworkなどでBacklogの課題キーが送られてきたときにリンク先に飛べないのがもどかしいと感じたことがきっかけでした。「Backlogベンリ」をお使いのブラウザに拡張機能として追加すると、課題キーを選択して右クリックするだけで課題先に飛べるようになっています。
この拡張機能も大変”ベンリ”なので、ぜひみなさまお試しください:)
※掲載内容は取材当時のものです。