この記事は 弥生 Advent Calendar 2021 の17日目の記事です。
弥生の川本です。開発本部でQAを担当しています。
昨年の 弥生 Advent Calendar 2020 でも17日目を担当したので、今年もゲン担ぎで同じ日を選択しました！テーマも昨年同様PowerBIよもやま話にしようかと直前まで考えていました。
が、弥生はここ最近、以前にも増して新しい技術やツールの導入が盛んでして。私もBacklog移行プロジェクトに参画して新しいタスク管理ツール導入に取り組んだので、今年はそのよもやま話を書くことにました。
（※Backlogはタスク管理機能を持ったプロジェクト管理ツールと記載した方が適切ですが、本記事内では便宜上タスク管理ツールと記載しています）
ちなみに、PowerBIと類似したサービスでAWSのQuickSightというサービスがありますが、そちらについて1日目にgarusanさんがQuickSightでかんたんに視覚化を寄稿されているので、BIツールに興味がある方はそちらもチェックして頂ければ幸いです。
～目次～
タスク管理ツールとは
読んで字の如くタスクを管理するツールです！
これだけだとヒンシュクを買うこと間違いなしなので、私なりの考えを述べさせて頂くと、「プロジェクトを遂行するために割り振られた担当業務の進捗や状況を見える化し、コントロールするためのツール」だと考えます。 （参考までにWikiの「タスク管理」の説明は以下リンクです）
一般的にはタスク管理は担当者一人ひとりの裁量に任されている要素も多く、「ちゃんと予定した期日までに計画通りに完了してくれれば良い」と考える方もいらっしゃるでしょう。
しかし、皆さんもこれまでに手痛い経験をしたことがあるように、全てのタスクが計画通りに進むなんてことはそうそうありません。
様々な事情（見積工数とのギャップ、その他の割り込み作業、解決に時間を要する課題に遭遇、等々…）によって、タスクは当初思い描いていた理想とはまったく異なる状況になることも多いですよね。
そのような状況をいち早くキャッチアップするための仕組みを提供してくれるのがタスク管理ツールであると思います。
とは言え、当然のことながら、タスク管理ツールを導入すればそれで万事OK！とはいきません。
ツールはあくまでツール。目的達成のための手段の一つでしかなく、結局はどのようにそのツールを運用するのかが重要です。
なぜBacklogに移行するのか
さて、上記の言い回しだと疑問に思われた方もいるでしょう。
タイトルにも記載した通り、弥生では「Trac」というタスク管理ツールをすでに運用しているのです。
しかも十数年に渡って活用してきた歴史があるので、弥生の開発においてTracの利用は「当たり前」という価値観が定着しています。
そんな「当たり前」を壊して、あえて別のツールに移行するのはなぜかと言うと、「プロジェクトを遂行するために割り振られた担当業務の進捗や状況を見える化し、コントロールする」ことがTracでは難しいケースが出てきたからです。
少し話題が逸れますが、弥生のプロダクトは技術の循環サイクルによって進化してきました。 以前はいわゆるデスクトップアプリケーション単体で独立していたものが、クラウドアプリケーションの台頭によって連携することが当たり前な時代になってきました。
そうなると当然ながらプロダクトを作るプロジェクトも単体で独立したものから、複数のプロジェクトが関わりあって一つの大きなサービスを作り上げるという形に変化していきます。 そしてTracの構成だと「複数のプロジェクトから割り振られた担当業務を確認しにくい」ため、いろいろと不都合が生じ始めたのです。
他にも細かい理由はいろいろありますが「複数のプロジェクトの横断的なタスク管理を自分で行えるようにする」、これが新ツールに移行した最も大きな理由です。
苦労したこと
新しいツールを導入するから皆使ってねー！で済めば話はかんたんですが、さすがにそういうわけにもいきませんね。 あらためて運用ルールを定めたり、困ったときのFAQを準備したり、いろいろやることがある中で、私がいちばん苦労したのはTracのデータをBacklogに移行するためのツール作成でした。
Backlogのヘルプセンターには、RedmineからBacklog、JiraからBacklogに移行するツールは公開されていたのですが、残念ながらTracからBacklogに移行するツールはない模様。
そんなわけで移行ツールの自作を決意し、担当として手を挙げました。
ただ正直言って私の見通しは甘かったですね・・・。Office製品のVBAマクロ作成の経験はありましたが、外部のAPIを使う際のイロハをわかっておらず何度も躓きました。
いくつか躓き事例を挙げると、
Backlogは設定する項目の値を内部的にIDで持っていて、しかもプロジェクトごとに値が異なる。Excelのセル代入のように単に登録したい値（文字列）を渡せば良いというものではない
・「そんなの当たり前じゃん！」と思われる方もいらっしゃるでしょう。でも私は関数リファレンスを確認するまで勘違いしていました。
・「まだ慌てる時間じゃない」と気持ちを落ち着けて、登録したい値の内部IDをプロジェクトごとに照合する関数を用意する方針に切り替えました。課題登録時にカスタム属性を指定するとエラーになる
・関数リファレンスにサンプルコードがないため、正しいリクエストパラメータの書き方がわからず検索しまくりました。
・蓋を開けてみれば難しいことはなく、リクエストパラメータに「&customField_{カスタム属性自体の内部ID}=登録したい値」を加えるだけでした。Tracのチケットの担当者と、Backlogの課題の担当者をどうやって紐づけるか
・それぞれのアカウント名が異なるので紐づけテーブルを別で用意することを考えていました。
・が、ある日Backlogの関数リファレンスを確認していたら、メールアドレスを取得できることに気づきました。天啓がおり、メールアドレスを照合することで無事解決。TracのWikiformat形式を、BacklogのMarkdown形式にどのように更新するか
・試行錯誤しましたが、「複数個の表」がある場合の変換ロジックを実現できませんでした。。。
・諦めて表の置き換えについては別のExcelアドインを用意しました。WikiFormat形式の表を一度Excelの表に置換し、Excelの表をMarkdownの表に置換するアドインで、ユーザー自身に更新を依頼しました。
いま思い返すとただの知識不足や思い込みもありますが、躓いた分だけ担当する前よりスキルや知識が向上したので、挑戦した甲斐があったなーと思っています。
そして、出来ることが増えてきたので、さらに欲が出てきました。
これから実現していきたいこと
一言でいえば、「プロジェクト管理ツールとタスク管理ツールの連携による業務効率化」を実現したいと考えています。
弥生ではプロジェクト管理ツールとして、Microsoft Project（通称MSP）を利用しています。このツールではいわゆるWBSを組み立ててプロジェクト全体の進捗を見える化します。
したがって、プロジェクト管理ツールとタスク管理ツールの関係性は、言わば親子関係みたいなもので、プロジェクト管理ツール上の最小単位であるタスクを、タスク管理ツールでもっと詳細なサブタスクに細分化して管理していく、といった運用が基本です。
つまり、プロジェクト管理ツール（MSP）で計画したタスクを、タスク管理ツール（Backlog）に登録していくことになるわけですね。
現行のMSPとTracの運用では、MSPで計画したタスクを主に手作業でTracに登録していました。
MSPを確認しながら、タスクのタイトルを記載して、担当者・開始日・終了日などの項目を埋め、1件1件Tracに登録していくのです。
また、もしもMSPの方でスケジュールを再計画した場合は、当然ながらタスク管理ツールの日付も見直す必要が出てきます。
このタスク管理ツールに登録する作業や日付を見直す作業は、TracからBacklogに移行しても残念ながら無くなりません。
そして、この作業には相応の時間が必要なので、以前からどうにかして効率化できないかなーと思っていたのです。
まだ検討段階ではありますが、移行ツール作成で得たノウハウを活用することで、プロジェクト管理ツール（MSP）から直接Backlogの課題を登録することや、再計画したプロジェクト管理ツール（MSP）の日付でBacklogの課題を自動更新する、といった業務効率化を実現できるのではないかと考えてワクワクしている今日この頃です。
お知らせ
弥生では一緒に働く仲間を募集しています！
チャレンジしたいことがあれば応援してくれる環境があるので、興味のある方はお気軽にお問い合わせください！
