Backlogで挑む、透明化と越境 具体編
現在、私の携わっている25ヵ月にわたる基幹システム刷新プロジェクトにおいて22ヵ月が経過しました。システムの範囲は、顧客の日々の売り上げ入力から、倉庫業務の在庫管理、運送業務の配車管理、輸入輸出業務での他システムへの連携と多岐にわたり（というか顧客のほぼ全業務だ）フルスクラッチで構築しています。当記事ではBacklogを用いることで改善した内容及びなぜプロジェクト管理ツールの導入が必要かについて書きます。
Backlogとはnulab社の提供するSaaS型プロジェクト管理ツールです（製品についてはこちらのリンクを参照）。経済産業省が採用し業務改善結果を出したことは大きな話題となりました。
当記事では具体編と称し、プロジェクトの中で実際に起きた変化に焦点をあてております。透明化と越境について詳しくは次の抽象編で書きます。
はじめに、現プロジェクトでのBacklogの使用環境について書きます。協業先を含めた3社間で使用、メンバーは30人程度です。設計→開発→テストのフェーズにおいて、タスク、スケジュール、成果物の管理のために使用してます。コミュニケーションはほぼ全てBacklog及びチャットツールのTypetalkにて行っております。
なぜこの記事を書いたのか？
自分の中でプロジェクトの進め方について一度整理しようかなと思いたったため、もう1つは従来の業務の進め方に疑問を持っている方が現状を打開するきっかけになればと、この記事を書いてます。
メールでの連絡や、Excelでの課題やスケジュール管理が全て悪いとは言いません。しかし、私が運営しているコミュニティのJBUG広島を通して色々な方と話していると、「今までこうやってきたから」という思考停止によって生産性のない（しかし大半の人は疑問に思っていない）業務が蔓延しているように感じることが多々あるのです。
この記事が小さな気づきにつながれば、と。
Backlogで何が改善したのか？
Backlogの導入によって変化した点は以下の通りです。
- 協業先とのメールが "0" に
- 発生した課題を全員の自分事ととらえ、自発的に対応する環境が育った
- メンバ全員の進捗をリアルタイムで共有できるようになった
- 成果物及びソースコードの先祖返りや紛失がなくなった
ひとつづつ解説します。
- 協業先とのメールが "0" に
今まで業務の中心はメールでした。バグの修正依頼、仕様の確認、成果物の受け渡し、全ての業務はメール（もしくは電話）を介して進行し、休み明けのメールボックスには大量の通知が待っているという始末です。メールの性質上、伝達範囲が不十分なせいで（どこまでCC入れるか問題）一部の人間にしか情報が共有されない事態や、大量に降り積もるメール群に回答すべき内容が埋もれてしまったりといった事故が散見されました。挙句の果てには「メール送ったので見ておいてください！」なんて電話をかける始末。。。
コミュニケーションをBacklogの課題を介して行えば、「誰が」「誰に対して」話しかけ、「いつまでに」回答して欲しいか、そして「今どういう状況なのか」といった内容が一目瞭然です。また、課題はプロジェクトメンバ全員に共有されるため、メールで生じていた情報の提供範囲の過不足は発生しません。
現在のプロジェクトではBacklog及びTypetalkにコミュニケーションを限定。また、原則DMも禁止して全てのやり取りをプロジェクトに参加しているメンバが閲覧可能な状態を作りました。異なるサブシステム、設計、実装のレイヤーの垣根を越えて情報をいつでも閲覧できるようになり、一部の人しか知らない問題（レイヤーによる分断）が発生しない土壌で仕事が進みます。
しかるべき人たちがBacklog上の1つのプロジェクトに集結しているので、そこでの発言は自身宛でなくとも必要な情報ですし、また誤送信による部外者への発散なんてのも起こりえないんですよね。Slackを代表するオープンチャットが人気なのも、限定された範囲において秘匿性を排除することが可能だからだと感じています。
気が付いたら一日の大半を支配していたメールを送るという行為はなくなりました。
- 発生した課題を全員の自分事ととらえ、自発的に対応する環境が育った
以前はExcelで課題管理表というものを作成してました。メール等で問い合わせがやってくると、運悪く⁇問い合わせを受けてしまったものが担当者となり課題管理表に起票します。そして、他のメンバが何に対応しているのかを課題管理表を見るまで分からないといった状況でした。
自分の課題と他人の課題の分断が生まれると極力自分は課題を抱えたくないと思うのは当然でしょう。だから問い合わせは受けたくなくなり、問題を見つけても気づかぬふりをする環境が出来上がります。
Backlogでの運用はこの点を大きく変えたと感じております。「とりあえず担当者なしで課題をあげて、どう対応するか決めよう。」このルールで進めたところ、問題が発生する度に誰が対応するかを都度話し合うようになりました。今までは課題はマネージャが割り振るものだったのが、対応できそうな人が自分から課題を引き受けることが当たり前の仕事の進み方に変化したのです。これは次のトピックと強い関連性があります。
- メンバ全員の進捗をリアルタイムで共有できるようになった
自発的な課題への対応を生み出したのは、各人のタスクの透明化です。運用ルールとして課題には推定対応時間と開始日終了日を設定することを定め、ガントチャート上に時間を伴った形で課題を並べています。「誰が」「いつ」「何をしているか」をリアルタイムで共有しながら仕事を進めることでメンバ主体での負荷分散が行われるようになったのです。
一日一度の進捗確認でなく、その瞬間の業務の可視化はチーム間での素早い連携を生みます。それを実現するためにはタスクの細分化と運用ルールの徹底が必要です。運用ルールについて記載すると。
1. タスクの粒度は最小限にする。これによる効果は、タスクの再配分の容易化と、メンバが日々小さな成功体験を積むことにあります。
2. 状態を細かく変更させる。着手したら処理中、終了したら処理済み、受け入れが終了したら完了とすることでガントチャート上でカンバンのように細やかな状況把握を実現します（Backlogにカンバンボードが実装されたので今後はそちらでの運用に移したいなと考えてます）。
3. 担当者はボールを持っている人に設定する。担当者を明示化することで、課題が宙に浮いてしまうことを防ぎます。
上記ルールを徹底することで、発生した課題に対して皆で向き合い、各々が責任を持ち対応する土壌が作られたと考えています。
- 成果物及びソースコードの先祖返りや紛失がなくなった
これまでは成果物の管理はファイルサーバで、協業先との受け渡しはメールにて行っておりました。この運用の下では保存場所が分散します。バージョン管理もタイムスタンプやファイル名に頼ることになり、しばしば、成果物の紛失や先祖返りが発生しておりました。
今回のプロジェクトでは、ソースコードも成果物のファイルもすべてBacklogのGitに集約しました。成果物のファイルをGitで管理することには賛否があると思いますが私は肯定派です。なぜなら、全てのデータを一か所に集めることこそ大切だと考えているからです。そしてファイルが課題と直結することで、編集履歴の管理やそのファイルが存在する経緯を、Backlog上で追うことが可能になります。（Git コメントに課題のIDを入れてPUSHすることで、自動で紐づけしてくれます。）
BacklogではGit LFSに対応しており、容量の大きなファイルを置いたり、編集の競合への心配なんかもある程度面倒を見てくれます。
成果物やソースコードの管理において最も大切なのは「なぜその変更が発生したのか？このファイルは何のために存在するのか？」だと考えております。これまでは変更管理表を作成し変更の度に記載していたのですが、記載漏れや変更管理表自体の先祖返りが発生していました。変更管理はGitのログに経緯は課題に集約されるので、正確かつ手間のかからない管理が実現されます。
なぜプロジェクト管理ツールが必要なのか？
以下の2点のためと言えます。
1. 情報を一か所に集約するため。
2. ステークホルダーが等しく状況を把握し、方向性を共有するため。
もし、プロジェクトの進行が、週に1度のミーティングだけで何も問題が発生せず、メンバ同士も一言二言の会話で阿吽の呼吸が如く噛み合うのであれば必要ないでしょう。しかし、現実はそうもいかないですよね。10人いれば10通りの仕事の方法が発生します。プロジェクトの状況についても10通りの解釈が存在するでしょう。
プロジェクト管理には多数の管理資料が発生します。これらは、現状の把握と進むべき方向性の決定のために（あるいはお偉い方への報告のため）必要なものですが、顧客が求めるものではありません。
本当の価値のあるものは顧客へ提供するプロダクトです。
私たちの時間はプロダクトをより良いものにするために費やすべきです。その管理のために多大な時間を消費するべきではないはずです。
（報告資料？Backlog見てください!! ( ｀ー´)ノ）
そのために情報を一か所に集めることで無駄な時間を削減し（あの情報はAの資料、この情報はBの資料なんてことはやめましょう）、ステークホルダーが現状を把握するための環境を作ることが可能なプロジェクト管理ツールの導入が望ましいのです。
ソフトウェア開発の現場は刻一刻と状況が変化します。その変化を皆でとらえ、向き合うために、従来の管理方法では追いつくことが困難になっています。アジャイル宣言にもあるように、変化への対応こそ今の開発現場には求められるのではないでしょうか。
なぜBacklogがよいのか？
使いやすいからです。あと可愛いから。これが非常に重要です。
プロジェクト管理ツールは多数提供されており、Backlogよりも様々な機能を備えたツールも存在します。しかし、「使いやすい」この点においてBacklogに大きな価値と魅力を感じています。
プロジェクトには多数の人間がかかわります。そして、原則的に人は変化を嫌います。
使いかたがわからないツールは敬遠され、従来のやり方に戻ってしまう。これでは意味がありません。新しく参画したメンバや顧客の事務員の方に対して、ツールへの抵抗感と教育コストは低くないといけません。
Backlogの何がいいのかっていうと普通に使っているうちに情報が集約されるところ。そして何より普通に使うのが簡単なところ。これに尽きます。
さいごに
当記事では、Backlogを導入して具体的に何が変わったのかと、Backlog（及びプロジェクト管理ツール）の有用性について書きました。
これは、以前JBUG広島#3で話した内容を改めて練り直したものです（その時のスライド ↓ ）。この記事が現在仕事の進め方について考えている方々に対して小さなヒントになればうれしい限りです。
タイトルの「透明化と越境」について踏み込んだ内容は次の抽象編で書きます。長文にお付き合いいただきありがとうございました。
Backlogやプロジェクト管理に興味がわいた方がいましたら、ぜひJBUGに遊びに来てください。全国各地でやってます！私は広島の主催者です、お会いできることを楽しみにしています。
続きかきました
