目次
はじめに
こんにちは、ヌーラボの池です。ビジネスチャットツール Typetalk の開発をしています。
さて、先日ビジネスチャットツールの Typetalk はフロントのフレームワークを AngularJS から Angularバージョン2以降(以下、Angular2系という) へと移行しました。その際、発生したタスクが複雑な依存関係を持っていました。そのため、チームメンバーが次に着手すべきタスクを瞬時に判断するのが困難になっていました。今回はそういったタスクの依存関係を Backlog と Google スプレッドシートと Google Apps Script を使って整理し、次に着手すべきタスクが一目でわかるようにしたのでその事例を紹介します。
タスクの依存関係が把握しづらい問題について
AngularJS の移行作業では各チームメンバーに割り振るタスクを、コード内に現れる”コンポーネント”という単位で分割して Backlog に登録していました。あるコンポーネントは、その内部で別のコンポーネントを使用していたりします。コンポーネントの移行作業は、そのコンポーネントの内部で使っているコンポーネントが全て Angular2系 に移行されていたら初めて着手できます。当初、メンバーが次に行うタスクを選ぶ際、該当するコンポーネントのコードを確認し、その内部で使用しているコンポーネントが全て移行済みかどうかを確認しなければなりませんでした。該当するコンポーネントの中で1つでも移行前のコンポーネントがあれば別のタスクを選び直す必要があり、なかなか今着手できるタスクを見つけ出すことができない状態でした。
タスクの依存関係の分析
今回の場合、各タスクの依存関係は以下のようなイメージです。赤丸が未着手のタスク、青丸が完了しているタスク、矢印は 依存元 → 依存先 を表しています。
今回すぐ見つけられるようにしたいタスクは、”依存先のタスクが全て完了している未着手のタスク”です。緑の破線で囲ったものが該当します。これらをすぐに見分けられるようにしていきます。
最終的な形
最終的に以下のような表があれば、すぐに次に着手できる課題がわかります。
着手可能なタスクを見つける際、「課題ステータス」が”未対応”で「移行前の依存先数」が0になっているものを探します。スプレッドシートのフィルタ機能で「課題ステータス」が”未対応”だけを表示し、並べ替え機能で「移行前の依存先数」の昇順に表示するようにすると、何も考えずとも一番上の行の課題が着手可能と見なせます。この表は Backlog 上で課題ステータスを更新すると自動で更新されるようにします。
最終的な表を作成する過程
前述の表を作成するには以下の手順を踏みます。追って1つ1つ説明させていただきます。
- Backlog 上の課題の情報をそのまま出力した表を用意し自動更新
- 依存関係を一覧化した表を用意
- 依存関係を一覧化した表に移行前/移行済 の状態を付与
- 課題ごとに移行前の依存先課題の合計をとった表を作る
1. Backlog 上の課題の情報をそのまま出力した表を用意し自動更新
Backlog API を Google Apps Script から呼び出し、Backlog 上の課題情報をそのまま出力した表を作成します。スクリプトを数分おき、またはスプレッドシートを開いた時などに自動実行するトリガーを設定して最新に保たれるようにします。
イメージ
やり方やコード例は Qiita の記事として書いているのでそちらをご参照ください。
Qiita – Backlogの課題情報をGoogleスプレッドシートに一括出力・自動更新
以降、この表を「Backlog API から取得した課題情報」と呼びます。
2. 依存関係を一覧化した表を用意
依存関係を一覧化した表を用意します。以下のように少なくとも依存元と依存先の課題キーが一覧化できていればそれを元に集計可能です。
イメージ
そのデータをどうやって作るのか
Angular に限った話になってしまいますが、コンポーネントの依存関係は、コンポーネントのテンプレート(HTML)の中で、以下のように現れます。
<div> <app-child-a></app-child-a> ←依存先のコンポーネント </div> <span> <app-child-b></app-child-b><app-child-a> ←依存先のコンポーネント </span>
Angular のコンポーネントはHTMLのタグと同じように表記し先頭にアプリケーション固有のプレフィックス(例えば”app-”)がついています。今回はこれを以下のようなコマンドで検索し、データを作りました。
$ git grep -o -E app\-[a-zA-Z\-]+ -- path/to/components/*.html | sort | uniq # 出力例 path/to/components/foo.component.html:app-child-a path/to/components/foo.component.html:app-child-b path/to/components/foo.component.html:app-child-c path/to/components/bar.component.html:app-child-a path/to/components/bar.component.html:app-child-b path/to/components/bar.component.html:app-child-c path/to/components/baz.component.html:app-child-a path/to/components/baz.component.html:app-child-b path/to/components/baz.component.html:app-child-c
出力例のように“<依存元コンポーネントのテンプレートファイル名>:<依存先のコンポーネントのタグ名>”というように出力されるので、このデータを整形、変換して課題キーと対応付ければ課題の依存関係のデータを作れます。
3. 依存関係を一覧化した表に移行前/移行済 の状態を付与
依存関係を一覧化した表、依存先の課題のステータスを調を元に移行済みかどうかを判断します。課題キーを元に VLOOKUP 関数をつかって「Backlog API から取得した課題情報」表から課題ステータスを参照し、”完了”だった場合は移行済みとみなします。
イメージ
課題ごとに移行前の依存先の合計をとった表を作る
4. 課題ごとに移行前の依存先の合計をとった表を作る
最後に、課題ごとに移行前の依存先の課題の合計をとった表を作れば最終的な表の完成です。
COUNTIFS 関数を使って課題ごとに、「依存関係」表の「移行済み」列の値が”No”の合計を求めます。課題ステータスは「Backlog API から取得した課題情報」表から VLOOKUP 関数で取得できます。
イメージ
