はじめてのイベント参加でJBUG 札幌#4に行ってきた
TL;DR
- 勉強会とかそういうのに行ったことなかった男がこちらに参加してきたレポ↓
- Backlogというツール自体は優れている
- 運用ルールの作成と、徹底がなされないことが問題
- Backlog APIは可能性の塊
- 怖くないし、意外と初参加の人も多い
- 自社外の人と話すのはいいぞ
参加の経緯
いきなり個人的な話ですけど、今まで勉強会とか参加したことなかったんですよね。
前々から自社以外の人と会うことで刺激を受けたいなと思ってたりしたんですが、人見知りだから知らない人怖い、初めての勉強会怖い……と思って時は流れ……
業務でBacklog見てたら札幌でイベントをやるらしい → スピーカーの人知ってるー！
知ってる人がいればなんとかなるのでは……？ と思って思い切って参加してみました。
会場
フュージョン株式会社さんのオフィスで行われました。
入って最初に思ったのはおしゃれなオフィスだなーってことですね。
木目調の部屋で、カフェに来たかと思いました。
写真はこういう時に撮っていいかもわからなかったのでありません。
個人的に意外だなと思った点としては、
受付みたいなところで名前を聞かれたりするのかなと思ったのに特にそういうのがなかったところです。
みんな来たらどんどん部屋に入っていく。
性善説だ……と思ったけど、顔見知りが多いから割となんとかなるんでしょうかね。
あと他にも知り合いがいました。
意外と世間って狭いんだなあ。
セッション
小林さん
プロジェクトの成功率の話から始まり、
失敗の原因あるあるを挙げていき、結局はいろんなことを曖昧にしているからイカンよね、という話。
- ゴールが共有されていない
- 客の言われるままのスケジュール
- アジャイルが、仕様をいつでも変更できるという誤解がある
- 決定が先延ばしになりがち
最近読んでるエンジニアリング組織論への招待の中でも、不確実性を減らしていくのがエンジニアリングという話があって、まさしく上記のようなことが不確実性そのものなんだろうなあと思いました。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
あとここ2年近くほどで強く実感したのは、
- wikiがカオス(情報が古い、似て非なる情報が点在している)
- レビューの文化がない
の辺りで、割と今の会社の課題かなと感じているところです。
個人でコード見てくれる人はいるけど、ルールがないのが問題。
個人的に一番刺さったのは、
- 進捗率90%から進まない
ですね。
作業中に発覚した要素によって残り10%を埋められないやつ。
本質的ではないかもしれませんが、こういう時って進捗率を下げる方が管理サイドとしては工数が見えて嬉しいんでしょうね。でも作業者は90%にした手前、また戻すという選択は取りにくいよなあ……。
曖昧なことへの対策としては、明確にするということを挙げていました。
- すべてチケット化する
- しない人には教育する
- とりあえず、一旦、で決めることは禁止
- すぐに決められない場合は、いつ決めるかを決める
- Backlogには開始日、期限日を必ず入れる
- 進捗率付きガントチャートを作成
割とBacklogの課題の日付やカテゴリとか入れなくても使えるんですが、しっかり埋めていく(=明確にする)ことで曖昧さによる失敗を解消できるんじゃない？という話でした。
進捗率ガントチャートの実装方法が個人的にはハック感あって好きでした。
川筋さん
Backlogアンチパターンの紹介と、それに対してやっていること/やりたいことの紹介。
SQLアンチパターンをはじめとしたアンチパターン大好きマンなので興味深く聞きました。
- 作者: Bill Karwin,和田卓人,和田省二,児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2013/01/26
- メディア: 大型本
- 購入: 9人 クリック: 698回
- この商品を含むブログ (46件) を見る
- お知らせ機能
- お知らされない
- 担当者未設定
- どこにもお知らせされていない
- お知らせテロ
- 関係あるなし問わずあらゆる人にお知らせする
- お知らされない
お知らせしてないのも多数にしすぎているのも問題で、前者はもちろん気づいてもらえない。
後者はいわゆるお知らせ疲れみたいな感じで、見なくなるし本当に重要なものは埋もれてしまうという指摘でした。
それに対してやっていることは、お知らせ機能はメールのCCのような感覚で使うとあって、さじ加減の説明としては結構腑に落ちた感覚がありました。
メールのCCって感覚、今の新卒とかそれより下の人に伝わるのかなあ……。
あと、お知らせテロのスライドが、100人くらいお知らせしていた画面のスクショで度肝抜かれました。お相手氏ギャグのつもりかな？
- 課題の作り方
内容の本当の優先度が伝わらないし、Excelだと後から情報が追いづらいよね、という話。
これらに対しては、5W1Hを明確にする(タイトルならWhat, Howを書く)、脱Excel課題管理とありました。
前者は割と個人的には気をつけていて、タイトルだけ読めばだいたい何すべきかわかる状態が一覧化できる方が後から助かるんですよね。
Excel課題管理に関しては、自社で事前に運用のグランドルールを決めて、それをお客さんにも守ってもらうように働きかけるのがよいよね、って話も出てきました。
Backlogにも簡易的なものですが優先度設定できる機能があるので、せめてそれを使ってもらいたいですね。
- 課題の運用
- 課題の途中下車
- コメント上は
クローズ、完了って言ってるのに、実際のステータスは処理済み
- コメント上は
- 棚卸さない
- 課題を起票したけど、誰も着手せず何年も塩漬け
- 起票者がプロジェクトアウトしてもう誰もわからないなんてことも
- 課題の途中下車
途中下車は、課題一覧でステータスの検索をした時にノイズとなる課題が出てくるし、逆に引っかからないケースも出てきて困るという話。
棚卸さないは、いつ誰がやるのかがわからない、けどただただ溜まっていくという問題。
これらに対しては、課題のステータスの運用ルールを決めること、定期的な課題の棚卸し、似た課題はマージ、期間を決めて過ぎたら機械的にクローズしていく、というようなことをやっていきたいとありました。
ここまでを総括すると、ツールそのものの不足というより、使う人間が自分ルールでやることが大半の問題を引き起こしているという感じですね。
小出さん
Backlog APIとGoogleスプレッドシートを駆使して業務に必要なツールをゴリゴリ作った話。
お知らせ機能のユーザに入れてもらえなくて本当は見たい課題を見れなくて困ったから自作したという経緯。
Backlog APIで差分比較機能を実装したのは素直にすごい。
会社のツールになるので公開できないというのが残念。
こういうところでExcelではなくGoogleスプレッドシートを選ぶところにエンジニアっぽさを感じます。
LT
新井さん
結局今のスタートアップでは課題管理ツールをGitlabにしたのでBacklogは使ってないよ、でもコスト以外の面ではBacklogはいいよ、という話でした。
社内でGitlabを使っているので、プロジェクトをまたいだ情報をどこで管理していくか、という話題が出たときに、どうしたらいいんだろうなあ、と同じように考えました。
今回はGitlabだけど、Backlogにした時でも同じような課題が起こるんじゃないだろうか。
プロジェクトをまたいだものは別のツールを使う？
他の会社ってその辺どう解決しているのだろうか気になる。
懇親会
人見知りなので行くかどうか迷いましたが、結果としては行ってよかったです。
他の会社の方の業務についてとか抱えている課題について話を聞くのってめちゃくちゃ面白い。
意外とJBUG初参加の人も多かったりして、みんな顔見知りでアウェー感があるのでは……？ という心配は吹き飛びました。
あと、飲み会の中で次回の勉強会の予定も決まったので良かったです。
こういう場の出会いを繋げられたというのは単純に嬉しい。
まとめ
勉強会とかイベントとか行ったことなくても、行ってみたらなんとかなったし得られたものは多かったです。
行ってよかった。
Backlogはあくまでも1つのツールなので、どれだけ便利なものになるかは運用ルールや使い方1つだなと再確認できました。
エンジニア以外のユーザにもとっつきやすいツールですが、それゆえに運用方法なんかがファジーになってしまいがちになるので、そこはロジカルに詰めて運用していく必要があるなと思いました。
