TechDesk運営に導入したアナログ的手法とは
目次[非表示]
- 1.はじめに
- 2.Kanban方式とは
- 3.Kanban方式の導入・運用とその背景
- 4.終わりに
はじめに
ネットワンパートナーズ株式会社（以下、当社又はNOPという）のお客様であるパートナー様からの技術問い合わせ（以下、チケットという）は、“TechDesk” と呼ばれる技術チームで調査・回答を行っています。チケットの対応は、製品・技術分野と要求スキルレベル、担当するパートナー様などによって違いはありますが、基本、担当者一人が到着順に、かつ複数を同時並行で進めて行く形を採っています。現在、年間約4,000件のチケットがあり、件数は増加傾向で、完了まで長期化するものもあり、同時並行数も増やさざるを得ません。
TechDeskの運用リード（運営側）である筆者としては、チケットの総処理数を増やしてパートナー様に遅滞無く回答するために、技術者一人ひとりの負荷と状況を把握して、可能な者には担当するチケットを積み増したいと考えています。そのための管理手法として、2024年度の上期に試行導入していた “Kanban （かんばん）” 方式を同年度の下期から全面導入しました。ただし、専用アプリを導入してスマートに行うのではなく、既存ツールを使った極めてアナログ的な方法です。ちょっと恥ずかしくもありますが、期待していた導入効果が得られていますので、ここに紹介したいと思います。
Kanban方式とは
Kanban方式は、一般にトヨタ生産方式のジャストインタイム（JIT）の生産システムとして知られていますが、ここではそれに由来するソフトウェア開発方法のことを指しています。日本語版のウィキペディアに「かんばん (ソフトウェア開発)」の記事がありますので、そちらをご参照ください。
かんばん (ソフトウェア開発) - Wikipedia
Kanban方式は、TODOリストを拡張したようなものです。TODOリストの例を図1に示します。
図1 TODOリストの例
なお、このTODOリストは、付箋紙の貼り付け位置による「重要度と緊急度」の表現と、タスクの「分割」について拡張しています。
Kanban方式では、TODOリストの考えを踏襲して、次のところを拡張しています。
- タスクの状態を表すステップ列を、TODOリストよりも細分化する
- ステップ列ごとに置ける仕掛中タスク（Work In Process： WIP）の数に制限を設ける
- 後工程が前工程からタスクを持ってくる（これをPULLという）ことで進行する
- 次の列にタスクの移動を許可するための完了基準を明文化する
- WIP制限に引っ掛かって進行が止まったら、真っ先にWIP制限の解除に注力する
→後工程でWIP制限の上限までカードがあるので、前工程からPULL出来ない
後工程でのWIP制限を全てのメンバーが関与して解決し、進行を再開させるという考え方
Kanban方式では、TODOリストに相当するものをボードと呼んでいます。
実のところ、Kanban方式は物理的・アナログ的に運用するのが良いそうです。全メンバーが集まるプロジェクト室があるならば、壁一杯の大きな紙にタスク状態の列を区切る線を引いてボードとし、タスクを書いた付箋紙を該当する列に貼り付け、進捗に合わせて移動していきます。毎日、始業のときに全メンバーはKanbanのボードの前に集まって、ごく短時間の全体会議(Daily Stand-Up Meeting）を行い、タスクの進行状況や問題などを相談します。もしWIP制限に引っ掛かって進行が停止したタスクがあり、プロジェクト全体の進捗に遅滞があるならば、この場でWIP制限の解除に向けて全メンバーで協議します。
Kanban方式は、予定した期日に、予算内で高品質な価値を顧客に提供するためのシンプルなアプローチです。ソフトウェア開発に留まらず、ほかの組織活動及び個人活動の進捗管理にも活用することが出来ます。筆者としては、「個人活動の進捗管理にも活用出来る」という点に着目したのでした。
Kanban方式の導入・運用とその背景
■ボードの説明
最初におことわりですが、前述のとおり、TechDeskのプロジェクト室（もしあれば）にボードを1枚貼って、全ての担当者がそこにカードを貼っていくスタイルが理想的です。しかし、現在はリモートワークが中心なので、オンラインツールに頼らざるを得ません。
TechDeskで使用しているボード（説明用イメージ）を図2に示します。担当者は、自分専用のボードを1枚ずつ持って、チケットの進捗を管理します。
図2 TechDeskで使用しているボード（説明用イメージ）
まずボードのステップ列について説明します。ステップ列名は、ソフトウェア開発向けに通常使われているオリジナルのボードの名称を残したかったので、その名称の後にTechDeskの運用向けの名称をかっこ書きで追加しています。ステップ列には作業中と完了のサブステップがあり、当該ステップの処理が「作業中」であるか「完了」しているのかを区別しています。「完了」に置いてよい条件を明文化（定義）したものが完了基準です。また、サブステップのうち「追跡」と「待機」は、オリジナルのボードから拡張したものです。
- バックログ（到着）
未着手・未整理なものを置く（自分の山札）。基本、1カードで1チケットである。 - 分析（調査準備）
質問の確認中のものを「作業中」に、完了したものを「完了」に置く。完了基準は、「質問の内容と意図を理解して調査のための最小限の情報を揃えた」である。1チケットに複数の質問が含まれていて別々に回答することが望ましい場合には、タスク（カード）を複数に分割して良い。 - 実装（調査）
質問の調査中のものを「作業中」に、完了したものを「完了」に置く。完了基準は、「質問の回答とその裏付け（メーカーの文書・回答など）を得た」である。質問の調査中に不明点があってパートナー様に問い合わせしているものは「追跡」に置く。 - 検証（回答）
質問の回答作成中のものを「作業中」に、回答してクローズ待ちのものを「待機」に置く。パートナー様からクローズ連絡があった、又はサイレントクローズ* したものを「完了」に置く。完了基準は、「チケットをクローズした（サイレントクローズを含む）」である。
サイレントクローズ： 最終回答から5営業日以上が経過し、当社からその旨をご連絡した後にクローズすること（ご要望によって、再度オープンすることが出来る）
ステップ列名の下にあるかっこ内の数字はWIP制限であり、現在 “4” を設定しています。ステップ列中のカード数は、WIP制限を超えてはなりません。ただし、グレーに塗ってあるサブステップにあるカードは、担当者の手から作業が（一時的に）離れているものであり、WIP制限に含めません。つまり、白いステップ列にあるカードが、当社/担当者の回答責任のあるものであり（これを「NOPボール」と呼ぶ）、これを一目で分かるようにしています。
■ボードの操作と運用
ボードの操作と運用は、PowerPointで描画したボード（ファイル）をファイル共有サービス（BOX）の共有フォルダに置き、それをPowerPoint Onlineで担当者と運営側で共同編集するという、当社のIT環境で用意されているツールの寄せ集め、極めて原始的かつアナログ的な手段に頼っています。ボードのPowerPointでの作りについて少し説明すると、ステップ列の枠線、名称、WIP制限及び完了基準はスライドマスターに、カードは図形（四角）をスライドに、それぞれ描画しています。これは、担当者のスライドでの編集作業の邪魔にならないようにするための配慮です。
担当者は、チケットの進捗に合わせてカードをバックログ（到着）から検証（回答）/完了までのステップ列をリアルタイムに移動していきます。チケットをクローズして、検証（回答）/完了に置かれたカードは、毎朝の始業時に運営側がボードから剥がしてスライドの2枚目に貼り付けます（これを「剥がし」と呼ぶ）。
さて、世の中にはKanban方式の専用アプリが各種リリースされているのに、なぜTechDeskの運営に採用しなかったのかという疑問があると思います。それは、①専用アプリの機能が目的に対していま一つである、②比較的小規模で多様な雇用形態の担当者ワークグループにはコストと運用が合わない、③導入が試行・様子見の延長にある（見送りを含む） などから、いきなり専用アプリの導入は適切でないと判断したからです。
■カードの説明
前述のとおり、カードはPowerPointの四角図形であり、そこに担当（名前）とチケット番号のほか、カードをステップ列に移動した日付を記入します。カードと記入項目を図3に示します。
図3 カードと記入項目
チケット対応は個人作業なので、取ったチケットに直ぐ着手する場合には、カードをバックログ（到着）、分析（調査準備）の列をスキップして、実装（調査）/作業中の列にカードを置くのが現実的です。そのときには、スキップした項目の日付は空白のままで良いことにしています。
カード（四角図形）にはデフォルト（標準）の大きさがありますが、都合、多少大きくしてコメントを記入することは自由に行ってもらっています。 またTechDeskでは、歴史的な経緯からチケット管理システムに「技術支援サイト」と「NOP TECH INFO」の2つを運用しているので、それぞれのチケットでカードの色を分けています。カードの色分けについてはこのほかに、パートナー様、製品群、難易度などによって色と濃度を変える改良案も検討中です。
■なぜKanban方式を導入するのか
一通り、Kanban方式の説明が終わったところで、なぜKanban方式を導入するのかについて触れておきたいと思います。
パートナー様から到着した新規チケットは、チケット管理システムでいわば「山札」に積まれ、担当者は、そこから到着順かつ担当者の製品・技術スキル領域で自主的に取っていきます（山札方式）。また毎朝の「チケット警察」の活動によって、山札に取り忘れ・取り残しになっているチケットの監視と着手要請の通知（グループチャットによる）を行っています。
山札にチケットが滞留すれば、運営側は担当者を指名してチケットを担当させますが、このとき担当者の手隙き具合いを見て判断したいところです。しかし、チケット管理システムでは、チケット処理の全体のサマリ（マクロ視点）とチケットの個の内容（ミクロ視点）を見ることは容易ですが、担当者ごとのチケット数とその処理段階（メゾ視点）をひと目見て分かるように可視化すること（それも管理者と担当者が同じもので）は困難です。それを補完するために定例会議（週次、現在は隔週）では、各担当者に担当チケット数とNOPボール数、及び負荷状況（私見による5段階）を報告してもらっていますが、リアルタイム性に欠けること、チケットの処理段階の状況が不明なことから、「いま時点」を判断する材料としては不足がありました。
今回採用したKanban方式では、BOXのビュー画面からPowerPointのファイルを開くことなく全ての担当者のボードを迅速に閲覧出来るので、いま時点で手隙きの者を見付けて指名することが可能です。
■ボードの実例
担当者の一人、花子さん（仮名）のある日ある時点のボードを図4に示します。
図4 花子さんのボードの例
都合、チケット番号は一部をマスクしてあります。ボードの左下の角においてある2枚は、カードのテンプレートです（空カード）。花子さんは、カードに簡単なコメントを記入してチケット番号と合わせてチケット管理をしています。
運営側でも、花子さん以外の担当者でも、このボードをひと目見れば、この時点で花子さんのチケット８件（全てのカードの枚数）であり、そのうちNOPボールはグレーに塗ってある列にある計3件をを引いた5件であることが分かります。そして、このボードの読み解きは、次のようになります。
- 実装（調査）/作業中の列の3件は回答のための情報収集中であり、実装（調査）/追跡の列の1件はパートナー様から不明点の回答があれば直ぐに実装（調査）/作業中の列に移動して情報収集に入ると見られます。
もしそうなると、実装（調査）の列（作業中＋完了）は4件になり、WIP制限の上限に達します。 - 分析（調査準備）/作業中の列の1件は、チケットの内容の読み解き中なので、順次、実装（調査）/作業中の列に移動するでしょう。しかし前項での説明のように、実装（調査） の列がWIP制限の上限になっていれば、ここから1件以上、検証（回答）の列に移動しない限り、分析（調査準備）の列から進めることは出来ません（WIP制限の違反）。
- バックログ（到着）のステップ列の1件は、未着手ながら受付済みです。こちらも、順次、分析（調査準備）/作業中の列に移動すると見られます。
以上から、運営側は花子さんにいま相応の負荷があると判断出来ます。よって、札山の滞留チケットを指名して取らせるのは、別の者にしようという判断が出来ます。
■導入の効果
ボードには、いま時点のチケットの処理状況が、担当者の説明が不要なほど明確に表示されています。Kanban方式の導入当初に、まずは全ての担当者に各自の現況を記入してもらったボードを眺めると、①特定の担当者の頑張り過ぎ（チケットの抱え込み）、②クローズ待ちチケットの滞留・放置 が目に付きました。①項はWIP制限を適用すること、②項はサイレントクローズを積極的に行うことで、それぞれ順次解決出来ました。すなわち、ボードには真にアクティブなチケット（カード）だけが置かれて、すっきりした状態になったということです。
また、①項の逆で、あまり頑張っていない担当者も居て、それが如実にボードで表示されてしまいます。しかし、運営側が毎朝全てのボードを点検していること（剥がし作業）と、担当者が誰のボードでも閲覧が可能であるということが、「自分ももう少し頑張らないといけないかも」という社会的促進（人に見られている意識）を誘発して、自主的に頑張り出す姿が散見されました。
具体的な数は差し控えさせていただきますが、Kanban方式の導入によって、山札に滞留しているチケット数が削減され、チケットのスループット増加と処理加速がなされ、パートナー様の顧客満足度の向上につながったと自負しています。加えて、当チームのマネージャーの気苦労も減ったことでしょう。
終わりに
ICT機器、それも魅力的で競争力のある製品は高度な機能を持っているので、メーカーの公開ドキュメントだけで機能の仕様・実装、並びに設定方法の全てを理解することはなかなか困難です。ましてや動作については、実機で検証してみなければ（メーカーでさえも）分からないところがあります。一般の家電品であってもメーカー及び販売店ではお客様相談窓口を設けているので、ICT機器でプリセールス・ポストセールスともにサポート無しにするというのは土台無理な話です。逆に言えば、ICT機器のサポートに対する十分な体制とスキルを保有する販売代理店こそが、パートナー様から選んでいただけるものと確信しています。
しかし、サポートに対して無限のリソースを投入することは不可能なので、限られたリソースで効率良く運営していくため方法論が必要です。今回導入したKanban方式は、この目的のためにかなり合致したものだと考えています。また、方法論を導入して業務プロセス・フローの問題解決を図る筈が、いつの間にか専用アプリの導入にすり替わってしまうことが多々あります。筆者はその点を戒める意味を含めて、極めて原始的かつアナログ的な手法を採用する、もっというと紙と鉛筆による業務改善の建て付けを考えることも必要だと考えています。
もとより、Kanban方式は筆者がひょんなことで知って興味を持ち、文献学習を通じてTechDeskの運営に使えそうだなと思い付いたことがきっかけでした。筆者もICT技術者の端くれであると自負していますが、技術者としては製品・技術の分野だけでなく、運営・方法論の領域も日頃から興味と感心を持つことが必要であると思った次第でした。
アイキャッチの写真：
当社イベント（サイン集めスタンプラリー）の商品であるチョコレートをKanbanボードのカードに見立てて配置してみました。
関連記事
