Backlogって？
ヌーラボさんが提供しているクラウド型(ASP型)とパッケージ型のタスク管理ツールです。2005年にサービス提供されていて、使っている方も多いんじゃないかなと思います。
ちなみに私は大学生時代にインターンで行った会社で初めてBacklogを触っており、現職(お昼の方)でも使っています。
今回は札幌のコワーキングスペース「スペースカンテ」にて開催され、飲み物・食べ物・会場についてはヌーラボさんご提供となっています。いつもありがとうございます！
JBUG札幌のキャラクターが出来ました！
JBUG札幌のキャラクターが出来ました！(HAMWORKS様ありがとうございます)
セッション1. プロジェクト管理目線で見たbacklogでの進捗管理ってどう？
村井 茂樹さんによる登壇でした。
村井さんは営業のお仕事をされている方で、かつプロジェクト管理にも関わる場面も経験されているそうです。
今回のセッションでは、ガントチャートを利用したウォーターフォール型のPJでどのようにBacklogを利用すると管理(監視)しやすいのかを考察するという内容で、村井さんの過去の経験を踏まえてお話が進んでいきました。
村井さんは今までウォーターフォール型の案件に関わることが多かったため、Backlogを初めて触ったとき、「そもそも思想が違う！」と感じたそうです。
最初はフリープランでBacklogを使用していたのでガントチャートを表示出来ず、進捗を確認しようにもなかなか把握しづらい状況でした。
(執筆者補足：Backlogのフリープランではガントチャート機能が無効になっています)
周りからのアドバイスを元にBacklogを触っていくにつれて、「Backlogはウォーターフォール型開発よりもアジャイル型開発に特化しているのでは？」と感じたそうです。
ざっくり言うと、細かいイテレーションで開発からテストまでを行い、徐々に完成に近づけていくタイプの開発手法。
細かく書くと違うブログ記事が何枚も書けてしまうので、詳細は割愛します。。。
既にプロジェクト管理体系として確立されているPMBOKに基づき、PMBOKの「監視・管理」プロセスをBacklogのガントチャート機能に適用させる事を考えます。アジャイルでも、PMBOKと根幹は変わらないという考えの基に、今回は「監視・管理」というプロセスに着目しています。
カテゴリーや種別に「要件定義」「試験」と設定した上で課題一覧画面を表示すると、確かにチケットを取る側(作業者)は楽ですが、全体管理を行うPM側から見るとわかりづらい。
そこで有料プランに切り替えた上でガントチャートで表示させると、親子課題も可視化されるので少し見やすくなってきました。しかし、実績線がわからないため、実際に進捗が進んでいるのかどうかが分かりません。(予実管理が難しい)
課題には「予定工数」と「実績工数」を入力させることが出来るのですが、ガントチャートでうまく可視化されず、今後のアップデートで期待しているとのことです。また、土日もガントチャートに可視化してほしいという意見も。
ちなみに村井さんは最終的にはExcel出力機能でExcelに出力して管理もしているそうです。
また、ガントチャート上での「変更管理」を追うことが出来ず、プロジェクトの予実管理も出来るようになると良いという意見もありました。
(Backlogのガントチャートは割と簡単な操作で期間を変更出来ちゃうので、ガントチャート上で変更履歴を確認出来るようにして欲しいとのこと)
LT. ソース管理どうしてますか？
伊藤 蓮さんによる登壇でした。
伊藤さんはビットスターに入社されてから、Webエンジニアとして働いていて、Backlogは2年半ぐらい使っているとのことです。
ビットスターではgitによるソース管理をしているのですが、お客様から指定が無ければBacklogのgitリポジトリ機能で管理されているそうです。ブランチも課題キー(執筆者補足：課題1つずつに付与される、ユニークなID)を指定するようにしており、コミットメッセージにも課題キーを指定する運用を取っています。
コミットメッセージ中に入っている課題キーは自動的にリンクになって、後からBacklog上で追いかけることが出来るようになっています。
伊藤さんはある日稼働中の開発案件を任されることになったのですが、引き継ぎを始めて1～2週間ぐらいで前任者がいなくなるという事態が発生してしまうという、業界あるあるな状態になってしまったそうです。
今まではトラブルが起きてもその前任者の方に連絡が行っており対応もされていたそうなのですが、いきなりいなくなってしまったという事もあり、今後は伊藤さんが対応することに。
伊藤さんがお客様からの問合せを受けていて困ったことは、「昔こんな改修をしたんですけど、他のページにもやってほしい」と言われたことと、「ソースコードを読んでも意味が分からない」という2つの事だったそうです。
このため、まず課題をわかりやすく整理し、課題の詳細を統一化することから始めることに。
まず伊藤さんはBacklog上の課題を改めて整理し、過去の改修内容を調べたそうですが、課題自体は見つかったものの「何を実際にしたのか」があまり書かれておらず、結局全容を把握することは難しかったとのこと。
git上のコードが読みにくい問題については、git blameを使ってコミットメッセージから課題を探したものの、課題の詳細内容が薄い場合も多く、結局理解に苦しむという事態に。
修正内容をわかりやすくするべく、「1人プルリク」を始めることに。プルリクにすることで、課題と紐付けてBacklog上に表示させることが可能になるので、1人での作業でも、プルリクをしていくことから始めたそうです。
Backlogには、新規課題に対してテンプレートを付ける機能「課題テンプレート」があります。
バグ発生時の課題テンプレートなどを用意することで、記録を整理出来るようにしたそうです。
誰かにコードレビューをもらう事が本当は大事ではあるものの、なかなか皆忙しかったりとレビューをもらうのは難しい事があります。しかし1人プルリクは1人でも行えるのと、誤addにも気付けるという効果もあるのでおすすめとのこと。
セッション2. 新人研修をBacklogで管理してみたら (仮)
木原 卓也さんによる登壇でした。
木原さんはお仕事では技術検証や様々なプロジェクトの見守りをされているそうです。今回は、Backlogを新人研修で使用したときのお話でした。
木原さんの会社では、新人研修は主に「開発研修」「書籍研修」「座学研修」「プレゼン研修」を行っており、木原さんはこの研修をマネージドされています。
どのように管理していくか？という問題で、いくつか観点を捉え、時間軸観点での分類が挙げられていました。
時間軸という観点で研修を分解してみると、「タスク管理」「進捗管理」「スケジュール管理」の3つに分解することが出来ます。
「タスク管理」は基本的に「未着手」か「完了」かを管理します。
「進捗管理」は作業に期間があり、「未着手」や「着手」「完了」といった、状態が変化するステータスを管理します。
「スケジュール管理」は進捗管理と被っているのですが、タスクの実行順序や終了日時を管理します。
次の新人研修までは期間があるため、ここからは「仮に来年の新人研修をBacklogで管理したらどうなる？」という事をシミュレーションしたお話になりました。
改めて整理すると、Backlogで新人研修を管理するためには、下記の機能が必要で、これらはBacklogに実装済みです。
- ドキュメント管理 (読書会のサマリ作成)
- ファイル管理 (座学スライド・開発研修の設計書など)
- コード管理 (開発研修のソースコード / Git)
- タスク管理 (特定日時での実行のみを管理)
- 進捗管理 (期間内のステータス変化を含む管理)
- スケジュール管理 (課題の対応順と開始・期限の管理)
木原さんの会社では、GSuiteやTrello、Gitbucketを使用していますが、「ファイル管理」や「タスク管理」、「コード管理」についてはこの部分についてBacklogに置き換えをすることが出来そうです。
具体的な機能の当て込み方ですが、こちらは木原さんのスライドにあるスクリーンショットが非常に分かりやすいので、スライドの50ページ目から見てみてください。
まずBacklogには必要な機能が全て揃っており、UIも非常に分かりやすい構造になっています。全社的には元々Redmineを使用しているので、Backlogへの移行はスムーズになりそうとのこと。サービスを統一できる事で指導も行いやすい環境に持って行くことが出来、これは新人研修では非常にありがたい話です。
繰り返し型のタスク(新人研修あるあるなやつ)を登録する機能はBacklogに無く、事前に数ヶ月分のタスクを登録しておくのは地味に大変とのこと。
テンプレートや課題複製である程度はカバーしているものの、繰り返し発生するタスクを自動生成出来ると嬉しいかも？
可能であれば、WebhookのPOSTの内容を調整したいとのこと。
「次回の新人研修ではBacklogを使っていきます！」とのことでした！
JBUG東京リモートセッション BacklogWorldとプロジェクトマネジメントと私
西 武史さんによる登壇でした。
西さんの会社では、元々デジタル要素が全く無かった田舎の木材工場でデジタルトランスフォーメーションを実現するプロジェクトを手がけています。工場で使用する設計図や資料は元々全て紙で管理されており、紛失などの問題は多かったそうです。
プロジェクトメンバーが現地に何回か赴いてヒアリングを重ねつつ、「何をやるか？」という課題を発見していきます。その結果、タブレットを職人さんに配布して慣れてもらうことから始まりました。
西さんの会社では、設計図のペーパーレスシステムを開発し、タブレットで図面を共有出来るようにしました。その結果、最初は慣れないものの次第にタブレットの使い方に慣れてきて、設計図面の作業状況も共有出来るようになりました。
この結果、業務効率の向上を図ることに成功し、またこのデジタルトランスフォーメーションが「きっかけ」になりベテラン職人さんへの質問が増えてコミュニケーションが活発になったそうです。
お客様曰く、「システム化はきっかけに過ぎない」とのこと。システム開発が目的ではなく、システムを１つのツールとしてお客様の業務を効率化し、課題を解決することが目的とのことです。
おわりに
私自身、年末年始でバタバタしていた上に正月早々風邪をひいてしまい、なかなかブログ記事を執筆できずにいました・・・。(初詣に行ったその日の夜にいきなり38℃近くまで熱が上がってビビった・・・)
自宅の近所に夜間診療所があったのでその日の夜に行ってきたんですが、年始と言うこともあって3時間ぐらい待たされました・・・
皆様も風邪にはご注意を。。。。
