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に遊びに来てください。全国各地でやってます！私は広島の主催者です、お会いできることを楽しみにしています。
続きかきました
Backlogで挑む、透明化と越境 抽象編
私の携わっている25ヵ月にわたる基幹システム刷新プロジェクトにおいて22ヵ月が経過しました。当記事はその中で得た知見とプロジェクトの進め方についてまとめています。
下記「具体編」の続きです。抽象編と題し、プロジェクト管理にBacklogを導入することで起きた変化を踏まえ、プロジェクト及びチームの目指すべき姿について抽象度を上げた内容としております。
Backlogとはnulab社の提供するSaaS型プロジェクト管理ツールです（製品についてはこちらのリンクを参照）。経済産業省が採用し業務改善結果を出したことは大きな話題となりました。
なぜこの記事を書いたのか？
長い時間をかけプロダクト開発（私の場合プログラムです）に取り組む中で、プロジェクトが一歩前進するために不可欠な三つの要素に自分なりに気が付きました。新たな製品を生み出すという「不確実性との闘い」に明け暮れている方々にとって、日々の業務を見直すきっかけになればと、三つの要素についてここに書きます。
具体編は実際に起きた変化について事例ベースの記事にしました。具体を伴わないマネジメントの手引きを書いたところで理想論止まりだと私自身感じるからです。実際の事例を背景として、抽象度の高い（普遍的な）領域に踏み込んでみましょう。
Backlogで透明化に挑む
こんな経験ないでしょうか？
- いつの間にか、なぜ発生したか不明な修正がプログラムに施されている。
- 仕様書と実装に乖離があり、どちらを信じればよいのかわからない。
- 隣の席のやつは今何をやってるんだっけ？（忙しそうには見える）
透明化とはこれらの問題を解消することを目指した、プロジェクトのあるべき姿と私が考えるものです。ここでは二種類の透明化について書きます。
プロダクトの透明化
プロダクトの現在までの過程を起点となった発言や思想まで遡ることが可能な状態
チームの透明化
プロジェクトの現状についてメンバが共通認識を持ち、それぞれのタスクと着手状況が明らかになっている状態
先頭に挙げた三つの例は透明化がなされていないから発生します。
プロダクトの存在意義は問題解決。そして、問題が存在するのは、誰かが「今よりも良くしたい」と思ったからですよね。完成したプログラムやドキュメントから経緯や想いを汲み取ったとしても、想像の域を出ません。先人達は変更管理表や議事録という方法でそれを残してきましたが、それでは足りないと痛感してます。なぜなら、変更管理表に記載されるのは「AをBに変更」といった表面的な部分だけであることが非常に多いからです。
ゴールデンサークルという考え方があります。
サイモン・シネックにより提唱された「ものごとの核であるWhy(なぜ) から外側のHow(どうやって), What(なにを) と伝えることで人の本能に訴え共感を生む」というものです。シネックはWhyこそが本質に迫ると繰り返し伝えています。
なぜこのプロダクトが必要なのか？なぜこの仕様変更は発生したのか？なぜ私たちはこのプロジェクトに取り組んでいるのか？
プロダクトの透明化は変遷に「なぜ？」を付与することを目的とします。
私は顧客はプロダクトそのものに価値を見出すが、開発元にとっては完成に至る過程にこそ価値があると考えています。プロダクト自身も利用者も環境は日々変化します。現在への変遷が整理されていないとプロダクトの状態を保ち続けることはできません。新規メンバが参画した際にも過去から現在までの道筋が透き通って見渡せないとブラックボックスが出来上がる確率が高まります（某銀行のような悲劇が待っていることに…）。だからこそ、完成形の品質と同じくらい、なぜ今の姿になったかが重要なのです。
問題の起点は会話から生まれることが大半ではないでしょうか。顧客との電話しかり、メンバとの雑談しかり。決定した仕様だけをドキュメントに残すだけでは透明化は果たせません。
Backlogは透明化を推し進める強力なツールです。私たちはnulab社の提供するチャットツールであるTypeTalkで会話し、一連の流れをBacklogに紐づける形で課題登録することで課題発生の起点を追えるようにしています。また、Gitの commit も課題に紐づけ、コードの修正=該当する課題への対応と明示的に示す運用をとっています。会話⇒課題⇒成果物への一連の流れをBacklogで一元管理することで、成果物に「なぜ？」を付与することを実現可能となるのです。
複雑なことはしていません。整った土壌で、決められたルールで日々業務を行うだけです。
チームの透明化はガントチャートやカンバンを使用して「メンバが今何をしていて今後何をするのか」をリアルタイムで共有することで成立します。
それぞれのタスクを明確にすることは自走するチームへの成長につながります。詳しくは具体編に記載していますが、メンバの状況を明らかにすることでマネージャが指示せずとも勝手に助け合うように変化しました。ヒトデ型組織や生物的組織への第一歩とも言えます。
私が参画しているプロジェクトでは原則オープンチャットです。全てのやり取りをメンバが閲覧可能な環境づくりを心掛けています。
必然と隠し事をすることも難しくなります。私自身も「あいつだけが知っている」といった小さな隠し事が、重大な局面で脅威となって襲い掛かってくる経験を何度もしました。隠し事を生まない（意図せずとも）土壌が透明化を実現します。
そのためには、ネガティブなことを素直に言える、心理的安全性が担保されていることは必須です。
プロダクトの変遷を明らかにする。メンバの状況を共有する。そして情報をひとところに集約する。私が重要視する透明化のポイントです。
透明化の土壌が整ってきたら次は越境です！
皆で越境する
2019年のベストセラーFACT FULNESSにこんな一文があります。
人は誰しも、さまざまな物事や人々を２つのグループに分けないと気がすまないものだ。そして、その２つのグループのあいだには、決して埋まることのない溝があるはずだと思い込む。これが分断本能だ。
営業職と技術職、設計者と実装者、企業と顧客、周りを見ても多くの分断が存在します。まあ、お互いを分断することで生まれる一体感は実際ありますよね。。。しかし、良いプロダクトを生み出すために意味があるとはとても思えません。
設計者は綿密な設計書を書くことが仕事でしょうか？
プログラマはバグのないコードを書くことがゴールでしょうか？
顧客は要件の提示と金額の支払いをすれば責任を果たすのでしょうか？
全く違う。皆でよいプロダクトを生み出し活用することで、昨日より良い今日を迎えること。そのために尽力しているはずです。
そのためには分断を越える必要がある。越境です。
設計者は思想を共有し、実装者は技術的観点から議論し、可能であれば顧客にもアクセス可能な場所で公開すればいいと思っています。お偉い方への進捗報告に最年少のメンバが参加し「なぜこんなに遅れているかって？そもそもの要件がおかしいんだよ！！」くらい言ってもいいでしょう。分断によって本当に必要な人とものを作る人の距離が離れてしまい、「なぜこのプロダクトが必要か？」という本質が薄まってるように思えて仕方ないのです。
では、どうやって越境するのか？透明化がなされていれば越境は可能です。
経緯、思想、現状をステークホルダに等しく明らかにし、我々はなぜこのプロジェクトに取り組むのか？に対して共通の認識を持つことさえできれば境界なんて意味を持たないはずです。
Backlogを使う上で心掛けていることがあります。プロジェクトに対して個別に人を追加するのではなく、チーム単位で参加させるようにしています。必要な人間には皆同じ土俵に立ってもらい、同じ情報にアクセス可能な環境をつくる。越境のためには限られたメンバの自己保身なんて知ったこっちゃない。
俺たちが今まで何をしてきたか、何を考えているか、全部見せるから一緒に戦おう！という想いです。皆で越境しなければ、本当にいいものは生まれないと強く感じています。
心理的安全性が全ての土台となる
心理的安全性とは、Googleが提唱する効果的なチームを可能とする条件の中で最も重要とされる概念です。
心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。
透明化と越境について書いてきました。しかしこれらは心理的安全性が担保された環境でないと実現しないと断言できます。それほどまでに一人一人は弱く、伸び伸びとした環境でないと力を発揮できないと言えます。
コンウェイの法則に代表されるようにびっくりするくらいプロダクトは人間たちの影響を受けます。それもA君とB君は仲が悪いから、A君のシステムはB君のシステムとうまく連携しないという稚拙なレベルで。
結局どんなに素晴らしい思想や環境を用いても、今のところはうまくいかないというのが残念ですね（とんでもない技術革新が起きればあるいは）。
透明化も越境も同様です。
Backlogで挑むのは結局のところ心理的安全性の担保に帰結します。というのも、Backlogというツールはものすごく人の温かさやちょっとしたユーモアに重きを置いているんじゃないかなと思うのです。
具体編でも述べましたが全体的にかわいくて使うのが簡単です。例えばアイコン。一人一人アイコンを設定することにより画面の向こうには人がいるってことを思い出させてくれます。実際、想像以上の絶大な効果がありました。
ちなみに私が所属するチームはビオレママメーカーでアイコンを作ることが必須条件です。プロジェクトに参画した際に最初に行うことがアイコンを作ることです（協業先にもお願いしています）、このルールを発案した私たちのマネージャは本当に素晴らしいです。プロジェクトではこの顔がバグ報告をしたりします、なんかちょっと楽しいですよね。
↓ちなみにうちのシステムの偉い人です。これで怒られても怖さ半減です。
スター（Facebookでのいいね！に近い）ボタンも気軽に感謝を伝え、モチベーションの向上に非常に良い機能です。Backlogのスターボタンは何度でも押すことが可能です。いいね！ボタンを連打するなんて発想ありませんでした（nulab推奨）。
心理的安全性の担保は非常に難易度が高いミッションだと思います。仕事である以上、結果を出さなければ話になりません。メンバを律しつつ安心感も与える、マネージャの腕前の見せどころです。正解なんてないでしょう。
選択肢の一つとして、プロジェクト管理ツールに頼るのもありじゃないでしょうか。
さいごに
プロダクトを作るというのはなかなかにしんどい仕事です。でも、私は非常に魅力のある、己をかけてもいいものだと思っています。
一人で挑むにはつらい仕事です。透明化で健全な土壌を整えメンバと越境することができれば、今日よりよい明日へ繋がってるはずです。
この記事が日々の業務の進め方に迷う方にとって、小さなヒントになれば幸いです。
おまけ
当記事は私がJBUG岡山#3のLTのアドラーの心理学×Backlogをさらに拡張したものです（↓下記スライド）。Backlogやプロジェクト管理に興味がわいた方がいましたら、ぜひJBUGに遊びに来てください。全国各地でやってます！私は広島の主催者です、お会いできることを楽しみにしています。
おまけとして当記事を書くにあたって影響を受けたものを列挙して終わりとさせていただきます。長文にお付き合い下さり、ありがとうございます。
お付き合いいただきありがとうございました。
JBUG (広島#2 mini開催) Backlogを使うと何がいいの？初級編に参加してきました
時代に逆行する愛煙家のイチミチです。一週間前に行われた、JBUG(岡山#2)に引き続き、ホームグラウンドである広島で開催された、JBUG (広島#2 mini開催) に参加してきたので、その様子をレポートします。 ちなみに、JBUG(岡山#2)のレポートはこちらです。
イベントの詳細は↓
当日のタイムテーブルはこちらです。
はじめに
なぜ参加しようと思ったか
- 前回のJBUG岡山でBackLogの奥深さに感銘を受けました。そして、ユーザ同士で意見交換することの面白さを体験してしまったからです。
参加してどうだったか
- やはり今回も面白かった！！ 主催者の石橋さんの話から多くのヒントをいただきました。 あと、ビール！！ *1
では当日の様子を書いてゆきます。 ※今回は写真が1枚しかありません。撮り損ねました"(-""-)"*2
プロジェクトマネジメントツール、バックログの使い方
石橋さんが業務でどのようにBackLogを使用してきたか、BackLogで何ができるのかを実体験をもとにレクチャーいただきました。
ところで、開始早々満席。
mini開催にもかかわらず、20人を超える参加者で椅子がすべて埋まるという事態です。
素晴らしい… #JBUG 広島#2 🍁 https://t.co/GY7uHJSAvB
— Meggy🍫ヌーラボ (@Megumi_Isogawa) April 17, 2019
話の流れとしては、
1. BackLogの基本的な概念。操作説明。
2. BackLogを導入することで何が変わったか。
3. Git連携のデモ
でした。
BackLogの基本的な概念。操作説明。
第一印象は「派手な色じゃあ！」だったそうです。
#JBUG 石橋さんのバックログの最初の印象は派手な色！だそう。
— イチ ミチ (@ici_mici) April 17, 2019
(石橋さんがもっと呟けと囁いている)
しかし、使いやすさは正義！ってことで、基本的な課題の登録をササっと実演。
また、初めての方向けにスペース、ユーザ、プロジェクトの関係を図解で説明。
会場の中には初めてBackLogを知った方も多い中、シンプルなUI故に、何ができるツールなのか伝わったのではないでしょうか。
シンプルさもいいところ #JBUG
— カッキー (@k2works) April 17, 2019
BackLogを導入することで何が変わったか。
プロジェクトのステークホルダー間のやり取りにおいて、Excelでの課題管理からBackLogに切り替えていった過程を聞かせていただきました。
これが、非常に共感できる内容で。今風に言うなればわかりみというのでしょうか。
便利そうだとわかりつつも、なんか面倒だからなかなか使ってくれない年配のお客様や、課題管理の重要性に気づいてくれないのか更新してくれないユーザに対して、
まずはExcelとの併用で運用してみて、良さに気づいてもらえればBackLogでの運用に切り替える。
定期的にメンバでの課題の棚卸を実施する。
といったアプローチで浸透させた話等々、共感と関心が溢れ出て止まらない状態( ;∀;)でした。
中でも感心したのは、
リアルタイムな課題の状態更新が、仕様の決定にスピード感を与えた
という内容でした。
皆で共通の画面を見ながら課題を更新することで、共通認識を持つだけでなく、意思の集束と促進を起こすなんて素敵だと思いませんか？
Git連携のデモ
ここからはマネージャではなく、エンジニア目線でのお話です。
BackLogで仕様変更依頼を課題として起票
⇒ それに対するプログラムの修正
⇒ BackLogのGit及びGitHubへのプッシュ
⇒ BackLogでの反映の確認（課題のステータスも変化）
といった流れでデモが進行しました。
ライブでもはだいたいなんかトラブルが起きるのはお約束 #JBUG
— カッキー (@k2works) April 17, 2019
途中、投影範囲の見切れによって大事なところが見えない。。。等の可愛いハプニングが起きつつも、課題⇒修正⇒反映という流れがBackLogを介して一つの情報源に集約されている様子に驚きました。
プログラムの修正において、後々最も困ることが、誰が？何時？何のために修正したか？の管理だと思っております。
それがBackLogというツール上で一元管理できるのは、便利である以上に製品の品質という観点で大きな意味があるのではないかと感じました。
とまあ堅い話はさておいて、
始まりました！ #jbug pic.twitter.com/2EQ7ZEiqOJ
— イチ ミチ (@ici_mici) April 17, 2019
第二部の意見交換会です！！
酒があると話が弾む！！
ビール呑んでる。 #jbug
— Tatsuo SATO (@tatso310) April 17, 2019
第二部に残られた、ITコーディネーターから大学教授まで多種多様な方々で、プロジェクトマネージメントの話から落語の話まで非常に盛り上がり、気が付いたら予定時間を1時間もオーバーしての終了となりました。
最後まで残られたメンバで恒例の写真撮影です。
・・・いや、これｄやん！！
一人以外酔いすぎたのか間違っとるやん。
私もいささか飲みすぎましたが、非常に楽しい会でした。ご愛敬ってことで。
これからの広島でのBackLogのさらなる活躍に期待です。
JBUG (岡山#2) 遅れてきたBacklog World2019 岡山サテライトに参加してきました
時代に逆行する愛煙家のイチミチです。この度、広島在住ではありますが隣県大都会の岡山で開催されたJBUG (岡山#2) に参加したので、*1その様子をレポートしてみようと思います。
イベントの詳細は↓
当日のスケジュールはこんな感じです。
- 阿部 信介さん オープニング
- 長沢 智治さん プロジェクト管理とツール
- 前川 昌幸さん カスタマー・リレーションとエンジニアを繋ぐBacklog
- 河内 一弘さん 大都会岡山の、両方備えたシステム会社で始まったストレスフリーなプロセス快善
- 永野 英二さん 思い返せば失敗だらけのプロジェクトマネジメント
- みんなで ボードゲーム体験！！？
- 懇親会へ！
はじめに
なぜ参加しようと思ったか
-
私の参画するプロジェクトで最近BackLogを採用し、課題とスケジュール管理を始めたので【脱 Excel !!】、BackLogの活用方法と他のユーザはどのような運用をしているか学びたかったため。
参加してどうだったか？
- 最高でした。同じような問題に悩み乗り越えた事例や、プロジェクトを進めるために重要な考えに触れることができ、運用のヒントを山ほどもらいました。あとすげー楽しかったです。
では内容に触れてゆきます。
阿部 信介さん オープニング
阿部さん挨拶のもとJBUG岡山開始です！
ぶどうジュース⁉を飲んでいる方もいらっしゃって*3、初参加の私は衝撃を受ける中、衝撃な発表が！
ジェイビーだそうです。お腹の「19」は2019だからだそう。インクリメントされるのかっ⁉
長沢 智治さん プロジェクト管理とツール
ライダーベルトを巻いての登場です。
何故!!??
疑問は晴れないままだが、内容は無茶苦茶面白い。以下当日の私のメモです。
プロジェクト管理の基本要素であるQCDは相反する。それぞれはスタックする。
しかしそこにS(Scope)を加えることで楽になる。
リリースのスピードも品質の一つである。(他社との競争)
固定要素と変動要素の見極めこそ重要。
すべて固定は無理。スコープを可変にできるのか？？そもそも固定できるのか？
現場の中で、プロジェクトが今どのような状態なのか把握しておく必要がある。そして共通認識を持ち改善する必要がある。
仮面ライダークウガの世界！！各フォームに変身！！
そう！プロジェクトは絶え間なく状況が変化する。大切なのは、現状を把握しメンバで共通認識を持つこと。
そして、状況に応じた適切な打開策を打ち出すこと。
姿を変え戦うクウガのように。↓※ベルトの色も変化しています。
特に心に残ったのはこの言葉です。
「プロジェクト管理ツールを、マネージャーだけのツールにしてはいけない。情報をメンバで共有し、共通認識を持つことが大切。そのためには情報を一か所にまとめなければならない。」
時代とともにプロジェクトマネジメントもツールの使い方の変化する。痺れました。。。
当日のスライドはこちらでご覧になれます。ぜひご覧ください。
前川 昌幸さん カスタマー・リレーションとエンジニアを繋ぐBacklog
「婚活といばオミカレ！！」からスタート。
業務では、BackLogをはじめ、Slack、GitHub、ESA等の数々のツールを使用し婚活サイト オミカレ の運用についてのお話しでした。
業務上コミュニケーションは重要な問題である。
会社のコミュニケーションはほぼSlackに集約、社外とのやり取りは別の方法と切り分けている。
BackLogはタスク管理として使用。
社内外のタスクはすべてBackLogに集約し、担当者でだれがボールを持っているかを把握。Backlogグルーミングを週に一度行う。ここで課題の整理、再確認を行う。そこで課題の進行を確認。
婚活といえばオミカレ！！
業務効率化の為にツールを使うには、使う業務、運用ルール、使用者を明確に定義づける必要がある。
身に沁みました。
河内 一弘さん 大都会岡山の、両方備えたシステム会社で始まったストレスフリーなプロセス快善
岡山の両方備えたシステム会社の社内運用をBackLogに置き換えるために奮闘するお話でした。
自身の置かれた状況とかなり酷似した部分があり、歴史があり規模が大きい会社だからこその悩み、そこに果敢に立ち向かう姿に感動しました。
皆の顔が見えない中、なかなか効果のある管理ツールがない。
Backlogの説明会をしたが、反応はいまいち。。。自信はあるのに伝わらない。何が変わるのかを伝える必要がある！！ツールの導入はゴールではない、未来を見せる。
現状Excelとメールが業務の40％を占める。Excelとメールに支配されている！！部門単位、少人数でまわって意見交換を行ったところ、そこで初めてやりたいことが伝わった。
少しづつ、運用は広まり、当初の想定を超えた使い方をする人も。
BackLogにない機能をどう補うか…。作るしかないっ!!BackLog＋を!!*4
自発的な利用を促進、あえてトップダウンの指示は出さない。
新しいツールを導入するだけでなく、それによるメリットを実感させ、さらに自発的に使用する環境を作ることの重要さを改めて実感しました。
永野 英二さん 思い返せば失敗だらけのプロジェクトマネジメント
これはジョージさん自身が失敗した(他のメンバのことではない【重要】)って話です。
BackLogWorld2019の裏話。
自身が失敗したんだからね！！ミスした点、ツールの役割、使い方を決めなかった。情報の分散。
登壇者とのコミュニケーションにメールを使用した。小規模なら、BackLogですべて管理できる。
会社によって、BackLogの使用方法が異なった。意図のすれ違いが発生。
最初のルール付けが非常に重要。
会社によって、担当者の示す内容が異なった。起票した人、現在ボールを持っている人。ツールは使い方が非常に重要。
痛いほどにわかります。状況把握のためにも、担当者の扱いは無茶苦茶大切ですよね。
セッションを通しての感想
セッションの中で皆さんが非常に重要視されていると感じたことが2つあります。
- 情報の集約。これは私自身も非常に難しいと現在感じていることです。
ただツールを導入するだけでは、手間も増え情報もさらに拡散してしまう恐れがあります。BackLogとExcelでの2重管理なんてもっての外。大切なのは、どの情報をどこに集約させるか。そして現状の業務をきちんと導入するツールに置き換えること。 - ツールの使い方を決める。そしてその運用を徹底する。
導入したツールをどの業務で、どういう用途で、どのように使用するか。これが徹底できないと情報の集約はできず、業務品質は低下するということ。
BackLogは非常に便利な課題管理ツールであると感じています。しかし日々の細かな進捗管理等、やはり苦手な部分もあり、全てをBackLogで管理しようとするのではなく、BackLogでの管理範囲と方法を今一度メンバで話し合おうと、痛感しました。
ボードゲーム体験
お待ちかねのボードゲームの時間です。
Nulab社が開発したという、プロジェクトマネジメントゲームです。
ルールは簡単。納期までに遊園地を完成させること!!
今回は5人1チームで挑戦しました。
プレイヤーは配られたキャラクターでプロジェクトに挑みます。そこには個性豊かなキャラクターたちが!!
・やる気だけは十分な「新人」 しかし能力は低い
・サイコロで奇数を出すと他人のやる気を削ぐ「トラブルメーカー」
・何徹での戦い続けられる「鉄人」
などなど、プレイしていて皆、身近な誰かしらを想像したのではないでしょうか？
このゲーム、非常によくできており、現実同様プロジェクトは計画通りに進むほど甘くないということを、ゲームの世界でも叩きつけてきます。
しかし、当日集まったのは強者ぞろい。皆の知恵と運気を集結して、何とかかんとか完成にこぎつけました。
プロジェクトが完遂してにっこりの図。
最後にこのようなお楽しみもあり、非常に充実した会でした。
この会を開催いただいた方々、同席した皆様、この場を借りてお礼申し上げます。
ちなみに4/17には広島でこちらに参加しようと思います。
