仕様や画面は現行バージョンと異なる可能性があります。
Backlogの最新版についてはこちらからご確認ください。
ヌーラボのアジャイル・ライダー長沢です。前回のブログではプロジェクトを構成する3つの要素のうちどれをコントロールするべきかについて考察しました。本記事では、成果物をツールで管理する方法と、課題管理ツールとバージョン管理ツールについてわかりやすく解説します。
目次
前回のおさらい
前回のブログではプロジェクトを構成する「人・行動・成果」の3つの要素のうち、どれをコントロールするべきかについて考察しました。
ソーシャルネットワークで反響をウォッチしたところ、賛否両論とまで議論が白熱した様子は見受けられませんでしたが、私の元には概ね賛同のフィードバックが集まりました。あなた自身やあなたの現場で見直しができたり、考えをすり合わせるきっかけになったりしたら本望です。
私は「できるだけ現場で考えてほしい」というスタンスでいるので、敢えて明確な正解は出しません。このやり方が罪だというなら、全部背負ってやる！（仮面ライダー555／乾巧風に）そういう覚悟で書いています。
今回は「ツール」がテーマ
さて、前回の終わりに予告したように、今回は3要素のうちの「成果」と「行動」を見るためにどのようにツールを活用していくと良いのか、またツールで「成果」をコントロールするとどうなるのかを見ていきます。
ソフトウェア開発で使う「ツール」は多岐に渡ります。
今回は、2つのツールの分類に絞って話を展開します。実はこのコアとも言うべきところを理解しないと他のツールを活用するのが難しくなってしまったり、正当に評価ができなくなったりします。
その2つの分類とは、以下です。
- 課題管理ツール
- バージョン管理ツール
課題管理ツールはBacklogが代表的です。「プロジェクト管理ツール」と置き換えても良いです。
バージョン管理ツールは、ソフトウェア開発で用いられるGitをはじめとした分散バージョン管理システム (DVCS) や、Subversionなどの集中バージョン管理システムです。業務よりな表現をするならば「版管理」です。
📝コラム「非技術職にも広がっているソフトウェア開発の手法」
『えー、ソフトウェア開発のツールなの？』と思われた方は、時代に乗り遅れつつあるのかもしれません！今や、営業や経営者がコードを書く、または、見る必要がある時代です。また、就業規則や内規、要件定義などもマークダウンなどの記法を用いてテキストベースで記述し、それらをレビューしたり、マージしたりしている企業も増えてきています。ソフトウェア開発の現場でもぜひマスターしたい技術のひとつです。
バージョン管理ツールで成果物を管理する
成果物はその業務の最終的なアウトプットになります。
ドキュメントやソースコードを成果物として扱うことが多く、これらを管理するのはバージョン管理ツールが最適と言えるでしょう。
ここで「成果物」にどんな情報があると嬉しいのかを考えてみましょう。
成果物を5W1Hで整理する
5W1Hで考えてみるとわかりやすそうです。5W1Hとは、why、what、when、who、whomの5Wと、Howの1Hです。
「成果物」さんの立場を例に上げて考えてみましょう：
- Why: なぜ僕は生まれたのだろう
- What: 僕は何なのだろう
- When: 僕はいつ生まれたのだろう
- Who: 僕が誰に作られたのだろう
- Whom: 僕は誰のためにあるのだろう
- How: 僕はどうやって作られたのだろう
厳密に言えば、以上で挙げているのは、成果物が少しでも変更されれば変わる可能性が高い情報群です。同じ成果物でも複数の目的で作られることもあります。
例えば、ソースコードはその典型例です。
ソースコードは、顧客情報の一部に使われるし、検索機能のためにも使われます。ソースコードは、1行でも変更されれば価値が大きく変わる可能性があります。さらに、ソースコードはひとつのファイルに完結していることはそんなに多くはないです。
なので、変更をパッケージ化して、「変更セット」として扱えるGitやSubversionが必要となってくるわけですが、今回はそのあたりは深く解説しません。
バージョン管理ツールで、成果物に対して持てる情報は何かというと代表格は以下です。
| 5W1H | バージョン管理ツール | 備考 |
| why | コミットメッセージに書く | |
| what | ○ | コミットした変更そのもの コミットメッセージに仕様書など出どころを書く （テストコードを作成して一緒にコミットする） |
| when | ○ | |
| who | ○ | |
| whom | コミットメッセージに書く 使う側に委ねる |
|
| how | コミットメッセージに書く（ポエム） |
「○」がつく箇所は人によっても異なる場合があるだろうという前提でスルーするとして、バージョン管理ツールでは、コミットするたびに、どのファイルをいつ、誰が編集してコミットしたかを自動記録します。つまり、この部分については間違いなく管理できている情報です。
ここで大事なことは、5W1Hのすべてを管理できているわけではないという事実です。
「だからバージョン管理システムのコミットメッセージに記述するんでしょう？」という意見もあるでしょう。大正解です！その通りなのです。
しかし、フリーテキストなコミットメッセージに、同じ書式で同じ粒度の情報を記載し続けるのは至難の技です。検索性もよろしくありません（頑張れば検索できる、という考え方は×）。
「人 → 行動 → 成果(物)」を思い出す
さて、ここで過去の記事を思い出してみてください。業務は「人 → 行動 → 成果(物)」で表せると書きました。
すると、バージョン管理ツールが得意とするのは、やはり「成果(物)」 であることがわかります。
逆にいうと、Why、Whom、Howといったところは記録するのが苦手なようです。理由としては、Why、Whom、Howはバージョン管理の対象とする前に決定していることが多く、管理対象とすることが難しいためです。
では、Why、Whom、Howは成果物のフェーズではなく「行動」のフェーズで管理するべきでしょうか？
一部正解があるような気もしますが、私の答えは基本的に「否」です。それは課題管理ツールが担います（ｷﾘｯ
課題管理ツールで成果物を管理する
課題管理ツールは、人によっては『万能』と言われますが、決してそうではありません。ただ、マネジメントにとっても、チームメンバーにとっても助かる仕組みが搭載されていて、『理解して使えばこれほど心強いものはない』と言えます。
先のバージョン管理ツールと同様に、課題管理ツールが「成果物」のどの情報を管理できるか整理してみます。
| 5W1H | 課題管理ツール | 備考 |
| why | ○ | 要望、要求、バグ修正など |
| what | △ | どのファイルのどの箇所を変更したのか記述する バージョン管理のコミットIDを転記する |
| when | ステータスの変更日時などで代替 | |
| who | 担当者で代替 | |
| whom | ○ | 要望、要求、バグ修正の登録者 要望、要求、バグ修正の理由の中に存在 |
| how | ○ | コメント欄に逐次記載して記録に残しておくなど |
「○」や「△」がつく箇所は人によっても異なる場合があるだろうという前提でスルーするとして、課題管理ツールでは、課題のタイプごとに、記入できる項目や、ステータスを持たせることができるのが一般的です。
それらを使うことで、5W1Hのいくつかの項目を取り扱うことができます。こちらも言えることは、5W1Hのすべてを完全な形で取り扱うことができるわけではないということですね。
課題管理ツールとバージョン管理ツールを統合する
以上で紹介した2つの表を統合してみましょう。
| 5W1H | バージョン管理ツール | 課題管理ツール |
| why | ○ | |
| what | ○ | △ |
| when | ○ | |
| who | ○ | |
| whom | ○ | |
| how | ○ |
どうでしょうか？「成果(物)」に関する情報が網羅できそうです。
「成果(物)」でプロジェクトをコントロールするには、バージョン管理ツールと課題管理ツールの両方が必要となることがわかってきました。
課題管理ツールとバージョン管理ツールの合わせ技
バージョン管理ツールは成果を文字通り成果物として管理することに長けています。言い換えると、プロジェクトの計画時や進行時にコントロールするには足りていないところがあると言えるかもしれません。
そうした不利点を補い、計画や進行時にも「成果」で駆動する、コントロールするには、課題管理ツールが重要です。
つまり、課題管理ツールで、成果となる要素を獲得・収集し、計画を立て、その計画と実際を照らし合わせて進捗を見るという形が理想です。そして、バージョン管理ツールで成果物を完成させるまでの経緯を的確に記録、管理できるようにします。
「行動」はどう管理するべきか
業務は、すべて「人 → 行動 → 成果(物) 」からなるとお話しをしてきて、ここまで「成果(物)」を中心に解説をしてきました。
「行動はどう管理したら良いの？」と思う方もいるでしょう。
行動内容は、5W1HでいうところのHowだということは前回でもお伝えしました。表をみると、Howは課題管理ツールの範疇のようです。
理由として、課題はできるだけ「成果」をベースに設定すると良いが、その行動たる作業内容についてはやり方にバリエーションがあるということが挙げられます。
つまり、課題に取り掛かると決めた時点で、担当者やチームで作業が発生して行動するため、極端な話「行動」は記録に残しにくい面があります。
例えば「成果」をベースにして、課題のコメント欄にやったことを記載することで、次から似たような課題を対応する際の“ナレッジ”として活用できます。過去の作業内容と共に成果物を閲覧できると、よりリアルなナレッジとして参照できますね（なので、課題管理ツールとバージョン管理ツールは統合しましょう）。
またこうした情報は、汎用的に活用できるナレッジになることが多いので、Wikiにまとめて奥と良いでしょう。
Backlogで課題とバージョンを統合管理する
Backlogは、プロジェクト管理・課題管理ツールとして知られています。持っている機能も豊富ですが、本記事での文脈を踏まえると、Backlogは以下の機能を包含しています。
- 課題管理
- バージョン管理 (Git / Subversion)
- Wiki
Backlogの課題とGitのコミットは連動される
Gitによるバージョン管理でコミットした時に、コミットメッセージにBacklogの課題キー（課題を一意に識別できる自動採番されているID）を入力さえすれば、該当課題のコメントに自動でコミットIDやそのコミットがなされたブランチの情報が記録されます。
これは、先の解説での5W1Hの情報が統合されたことを意味します。
Backlogのバージョン管理 (Git) で成果物の履歴から課題を識別できる
Gitのバージョン履歴からその履歴がどの課題に関連していたのかを識別できます。これは、成果物からその理由（Why）を知ることができるということを意味しています。
先のようにコミットメッセージに課題キーを記載するだけなので、コミットメッセージに長々とWhyを書き記す必要はありません。双方向に辿れるようになるということは、成果(物)をコントロールするための情報が、計画時→進行時→完了時と蓄積できているということです。
そして、この経過自体もHowではありますが、その行動について課題のコメントやWikiに記録していき、整理していければナレッジとしても活用できます。
BacklogにはWiki機能も搭載されている
まとめ
プロジェクトや業務をコントロールするために「成果」に着目することからはじめて、成果をコントロールするための「ツール」の重要性を課題管理とバージョン管理を例に解説しました。
本記事で紹介したBacklogでの実装を参考に、ぜひあなたの業務の成果物を管理してみましょう。
こちらもオススメ：
プロジェクト管理とは？目的や項目、管理手法について徹底解説！ | Backlogブログ
プロジェクト管理の基本や主な項目を紹介。CCPMやWBSなどのプロジェクト管理の代表的な手法やプロジェクト管理全体の流れを解説。これからプロ…
backlog.com