製品の品質改善にも好影響！ システム開発でのワークフロー活用術

システム開発における不具合・要望対応は、多岐にわたる情報や作業工程の管理が煩雑になりがちな業務のひとつです。

バグ管理システム（BTS）や課題管理システム（ITS）といったツールも広く使われていますが、エイトレッドの開発部では、これらのツールにも採用されているチケット管理に、ワークフローを活用しています。

ワークフローの導入でどのようなメリットが得られたのでしょうか。

業務プロセス全体を管理。バグ管理システム（BTS）とワークフローの違い

エイトレッドでは、ソフトウェア製品およびクラウドサービスを提供していますが、これらの製品開発やシステムのバグの修正対応をしているのが開発部です。

製品を導入した顧客から報告されるバグに対して、実施すべき作業や修正すべきバグは一つひとつタスクとしてチケットを発行。

発行されたチケットに『担当アサイン』『作業中』『対応完了』『検証済』といったステータスを付与していくことで、作業工程を管理します。

バグ管理システム（BTS）や課題管理システム（ITS）で対応する開発現場もありますが、より細かな工程管理や業務フローの設定をするために、エイトレッドの開発部ではチケットをワークフローで管理しています。

顧客からバグの報告を受けたサポート部門は、開発チームに調査依頼を行います。

ワークフローシステムに登録済のチケットと突き合わせを行い、新規の不具合・要望であれば新たにチケットを作成。すでに同様のバグのチケットがあれば、登録済のチケットに追加報告があった旨を記入します。

↑新規チケット発行の申請画面

新規チケットはワークフロー上で『申請』し、5段階の承認フローに乗せます。

　「ワークフローでは、単純な対応状況だけでなく、調査や方針決定、レビューといった工程を含む業務プロセス全体を管理しています。これが、BTSとワークフローとの違いです」と開発部 杉岡弘一さん（以下杉岡）は語ります。

少人数の開発体制で、膨大な不具合情報の整理と対応の優先順位付けが課題に

エイトレッドの開発部門は約20人。現在は、プロダクトごとに月間20件弱のチケットを発行しています。当然、サポート部門から報告される不具合・要望は、もっと多く、毎月数十件の報告が上がってくる状況です。

ワークフロー導入前は、不具合・要望の報告が上がってくる度に、Excelの台帳へ記入していただけで、作業担当者のアサインも口頭やメールなどで行われていました。

そのため、対応が必要な不具合の総数や、それぞれの対応状況、担当者の作業進捗といった課題の全容が不明瞭でした。

「とにかく、膨大なチケットの処理に追われていました。少人数の開発体制でこの数の課題に対応するには、効率的に業務を回していかなければなりません。

そのためには、それぞれの不具合・要望に関する情報の整理、そして対応の優先順位付けが不可欠だと考えたのです」と杉岡は当時を振り返ります。

フォームの項目は集計性を重視。作業精度アップのためにレビュー工程も追加

ワークフローの開発では、チケットの管理項目の設定と承認フローの設計、それぞれに工夫が必要でした。

「既存の紙の申請書と承認プロセスをシステム化する場合に比べ、そもそも申請書式すらない業務をワークフロー化するのは難しいことでした」と杉岡は話します。

管理項目については、ワークフローを運用しながら年単位で見直し、最終的には、不具合・要望の詳細や対応方針、作業状況などの記録が、全4ページのチケット（不具合・要望管理シート）に集約される形になりました。

↑1ページ目：不具合・要望の概要。管理区分（不具合／要望）、優先度、機能分類、再現方法、見込み工数など

↑2ページ目：対応方針検討段階の記録。基本方針、達成条件、影響機能など

↑3ページ目：対応の記録。テストケース作成・修正記録、修正結果など

↑4ページ目：追加報告の記録

ポイントになったのは、目的に合わせて集計しやすい項目設定にすることでした。テキストを自由に記入できる項目ばかりだと、入力揺れが生じて集計しづらくなります。

「対応の優先度やステータス、バージョン、プログラム設計区分といった項目は、コンボボックスやチェックボックスから選択できるように。

また、不具合・要望の対象機能を記載する項目では、コード化した2段階の機能分類を入力するようにしました」と杉岡は解決策を語ります。

　一方、後者の承認フローについては、複数回のレビュー工程を挟んでいるのが大きな特徴です。

↑複数回のレビュー工程

「承認フローの流れるスピードと作業の精度はトレードオフ。

両者のバランスを取るコツとして、多くの工程をあとから削っていくよりも、最初はおおまかなプロセスを並べて、あとから必要な工程を足していったほうが、効率的なワークフローの設計がしやすくなります」と杉岡は続けます。

当初、単純に対応プロセスを並べただけの承認フローで運用していましたが、対応方針を決めたあと、第三者のチェックを経ずに開発が下流に流れていくと、リリース前のテスト段階で問題が判明し、大きな手戻りが発生するケースが出てきました。

そこで、担当者以外が対応方針をレビューする工程を要所で挟み込むようにしたのです。

ワークフローの副次的効果も見逃せない！ 品質管理や業績評価にデータを活用

ワークフローの導入により、不具合・要望対応に関わる一連の業務を見える化することに成功した開発部。

「製品の課題全般と各チケットの状況が整理されたことで、効率的で精緻な業務が可能になり、開発チーム内はもちろん、サポート部門とも情報共有しやすくなっています」と杉岡は言います。

さらに、最近では2つの新たな可能性も見えてきました。

1つ目は品質管理です。チケットのデータを集計し「どのような機能に不具合が多いのか」「どのような開発をしたときにミスが起きやすいのか」を分析して、製品の改善につなげる試みを始めています。

システム開発に限らず、例えば、多店舗展開している企業での改善要望管理などでも、同じような使い方ができるでしょう。

2つ目は、定量的な作業管理です。各メンバーのチケット対応数が一目瞭然になるため、業績評価にも活用できるのではないかと期待しています。

杉岡は最後に「複数の工程があり、複数のメンバーが関わる業務、すなわち、ほとんどの業務はワークフロー化できるというのが私の考えです。

試しに一度、現状の業務プロセスを図に表してみてください。そのプロセスは今、見える化できているでしょうか。少しでも引っかかるところがあれば、ワークフローを導入する意義があると思います」と語ってくれました。

使い続けるにつれて洗練され、今では開発部に欠かせないツールとなったワークフロー。他社で開発を経験したメンバーからは「ワークフローを使い始めてみると、意外とBTSよりも使いやすい」という声も聞かれます。

業務プロセスを改善できるだけでなく、さまざまな副次的な効果を得られる可能性があるのも、ワークフローの重要な側面のひとつだといえるのではないでしょうか。

株式会社エイトレッド　開発部
杉岡弘一