Slide 1

Slide 1 text

元発電所設計者からみたBacklogについて ~ツールで変わる会議のあり方~ 2023/ 10 / 5 北海道ガス株式会社 峠(とうげ) JBUG札幌#9 仕事の“うまい”進め方 〜経験をシェアしよう〜

Slide 2

Slide 2 text

峠 幸寛(Tohge Yukihiro) 出典:https://www.asahi.com/articles/ASM633H8BM63IIPE00B.html <経歴> ▶【現場】 1年半   ガス工事現場監督 ▶【ハードウェア開発】 4年 電力自由化への発電所開発 ▶【ソフトウェア開発】 2年  IoT・AWSの社内勉強      コミュニティ立上げ ▶【プロジェクトマネジメント】 1年   発注:① 調定システム      ② 督促回収システム  ※ 私のBacklog使用歴 10か月

Slide 3

Slide 3 text

発電所開発とシステム開発を比べてみた 発電所開発  ~まるでプラモデル作り~ ・配管、壁厚、床下寸法、  コンクリート打設等 「形あるものをどう配置するか」 → 配置する部品・配置方法に  技術が詰め込まれている。 システム開発 ~部品から自作でプラモを作る感覚~ ・要望、要件定義・・・・開発、テスト → 形がない部品を決めるために、 「いつどこで誰が何を決めたか、  要望に答えるための”この部品”」  に対して、責任と技術を詰め込む。

Slide 4

Slide 4 text

発電所開発とシステム開発を比べてみた 発電所開発  ~まるでプラモデル作り~ ・配管、壁厚、床下寸法、  コンクリート打設等 「形あるものをどう配置するか」 → 配置する部品・配置方法に  技術が詰め込まれている。 システム開発 ~部品から自作でプラモを作る感覚~ ・要望、要件定義・・・・開発、テスト → 形がない部品を決めるために、 「いつどこで誰が何を決めたか、  要望に答えるための”この部品”」  に対して、責任と技術を詰め込む。

Slide 5

Slide 5 text

峠の感想 機能美な部分が素敵

Slide 6

Slide 6 text

サバイバルナイフは、   機能的にはシンプル。 でも、人間側が工夫すると   いろんな使い道がある。 Backlogって、サバイバルナイフに似てる

Slide 7

Slide 7 text

「切る」「削ぐ」「割る」「刺す」「掘る」 「ほぐす」「フェザースティックを作る」 「ファイヤースターターで火花を放つ」 「枝でペグを作る」▶ 1つ機能でも、色々出来ちゃう。   Backlogのシンプルな機能で、色々できる部分が似ている。 特に、”情報の集約力”が魅力。 Backlogって、サバイバルナイフに似てる

Slide 8

Slide 8 text

● 親課題一覧 ・会議: アジェンダと議事録 ・ToDo: 何をすればいいか明確なもの ・成果物: 各工程におけるレビュー対象物 ・タスク: 成果物を修正する内容 ・変更管理: 仕様変更に伴う 「前提条件、原因、対応方法、工数、 対応結果、運用上の注意点」を整理 ・課題: 複数のToDoが発生し得るもの Backlog利用ルールについて#1

Slide 9

Slide 9 text

会議カードのサンプル ■アジェンダ --- 議事録 【会議名】 【日時】2023年月日() 【場所】北海道ガスグループ本社 ○○室 【出席者(敬称略)】  KG:峠 【資料】 【議題】 【決定事項】 【ToDo】 【主な議事内容(決定事項、TODO事項を中心に記載)(敬称略)】

Slide 10

Slide 10 text

会議カードを育てる ■アジェンダ <オフライン JBUGについて>  ・ 自己紹介    資料: ファイルURL <焚火について_峠追記>  ・ 資料写真: ファイルURL   ★下記写真はどこで撮影しました?             ← ”スクショ貼り付け” <その他共有事項>  ・ 懇親会では、色んなと交流したい。 --- 議事録 【会議名】 JBUG_Sapporo_オフラインミーティング#9 【日時】2023年10月5日(木) 【場所】EZOHUB 【出席者(敬称略)】  KG:峠

Slide 11

Slide 11 text

● 全ての課題ステータスを完了は、プロマネのみ実施 ● 会議中の”ToDo”を子課題としてぶら下げる。  成果物(設計書)へのToDoは、”タスク”として子課題 Backlog利用ルールについて#2 会議: <議事録本文> 【ToDo】  課題キー:ToDo①  課題キー:ToDo②  課題キー:ToDo③  課題キー:タスク①  課題キー:タスク②  課題キー:タスク③ ToDo① ToDo② ToDo③ 成果物:A タスク① タスク② タスク③ 成果物:B

Slide 12

Slide 12 text

私のBacklogのお気に入り 1.資料保存 ~SVNとファイルの使い分け~
 2.会議カードの運用
 3.孫課題が作成できないこと


Slide 13

Slide 13 text

■SVN  ・承認が必要なもの、   互いに更新する可能性があるものを保存   →資料の履歴管理のため。   「最新版どれ?」と「後戻り」を無くす。 ■ファイル  ・”打合せ時点”の資料を格納。   ファイルURLをアジェンダへ追記。   例:20231005_JBUG#9プレゼン_峠   →資料へのアクセス性を高めるため。    「今日の打合せ資料どこ?」を無くす。 1.資料保存 ~SVNとファイルの使い分け~


Slide 14

Slide 14 text

<ポイント> ①アジェンダの追記+事前連絡 ②確認事項は資料名がわかるようにスクショ張付け ③アジェンダを上からなぞれば、会議完了 2.会議カードの運用


Slide 15

Slide 15 text

<ポイント> ①アジェンダの追記+事前連絡  ▶追加の依頼事項は全て事前に記載 ②確認事項は資料名がわかるようにスクショ張付け  ▶Excelの吹出しによる修正依頼よりスクショが楽  ▶更新結果もスクショ。ファイルを開かずチェック ③アジェンダを上からなぞれば、会議完了  ▶すり合わせ内容の集約  ▶ファイル保存で資料を探す手間をゼロに 2.会議カードの運用


Slide 16

Slide 16 text

会議カードを育てる ■アジェンダ <オフライン JBUGについて>  ・ 自己紹介    資料: ファイルURL <焚火について_峠追記>  ・ 資料写真: ファイルURL   ★下記写真はどこで撮影しました?              <その他共有事項>  ・ 懇親会では、色んなと交流したい。 --- 議事録 【会議名】 JBUG_Sapporo_オフラインミーティング#9 【日時】2023年10月5日(木) 【場所】EZOHUB 【出席者(敬称略)】  KG:峠 2.会議カードの運用
 ③ 上 か ら 確 認 す れ ば 会 議 が 終 わ る ①追記 ①追記 ①追記 ①確認 ②スクショ張り付け

Slide 17

Slide 17 text

会議カードへのアジェンダ集約イメージ ToDo① 依頼① 依頼② 依頼③ 返答① 指摘① 指摘② 会議: ■アジェンダ <依頼事項>  ①AAA  ②BBB  ③CCC <確認事項>  返答内容①について  資料: fileURL <資料への指摘>  ① 資料のスクショ#1  ② 資料のスクショ#2 ToDo③ ToDo② ToDo④ 事前にアジェンダで全やり取りを拾い上げ、 定例会議後に子課題を生めば、抜け漏れが無い 2.会議カードの運用
 情報集約!

Slide 18

Slide 18 text

BackLogを活用した会議の変化 【会議】  進捗報告  作業依頼  資料提示  資料への指摘  資料説明  意思決定  ディスカッション 2.会議カードの運用
 Before

Slide 19

Slide 19 text

BackLogを活用した会議の変化 Before After 【会議】  進捗報告  作業依頼  資料提示  資料への指摘  資料説明  意思決定  ディスカッション 【Backlog】  進捗報告(+子課題にて催促)  作業依頼  資料提示  資料への指摘(+指摘への回答) 【会議】  資料説明  意思決定 (予め上層部へ確認)  ディスカッション   +具体的なテーマ ▶ 1時間くらい余裕で会議時間が削れる   + 協議内容の濃度が高まる 2.会議カードの運用


Slide 20

Slide 20 text

3.孫課題が作成できないこと
 <Backlog 利用_1か月目>  あれ、孫課題できない!            なんでだろう。。。 <現在>  うん、孫課題は作れない方がいいなぁ。  作れるとBacklogの機能美が失われてしまう(´;ω;`)

Slide 21

Slide 21 text

”孫課題”を好きなツールから整理してみた ツール 利用用途 利用者・利用方法 データ・情報の流れ マインドマップ ・思想を深める ・カテゴリ整理 個人が頭の整理に利用 個人の中での対流 ~池のようなもの~ コミュニケーション ツール ・掲示板形式の    公開対話 チームが  テーマ毎にコメント 常に流れる ~川のようなもの~ プロジェクト管理 ツール ・プロジェクト      管理 複数チームが  各自の検討を進め、   作業を管理 全てを受めて管理 ~ダムのようなもの~ 3.孫課題が作成できないこと


Slide 22

Slide 22 text

ツール 利用用途 利用者・利用方法 データ・情報の流れ プロジェクト管理 ツール ・プロジェクト      管理 複数チームが  各自の検討を進め、   作業管理する 全てを受めて管理 ~ダムのようなもの~ ・複数チームの複数人数をコントロールする上では、  シンプルな管理方法で運用したい。 ▶”孫”課題形成は独自ルールが生まれ過ぎる可能性大 ▶”複雑なルールを覚える”作業は排除すべき。   「管理のための管理が生まれてしまう」 3.孫課題が作成できないこと
 ”孫課題”を好きなツールから整理してみた

Slide 23

Slide 23 text

UNIXのターミナル ”ls”コマンドで”空”なら「何も表示されない」美しさ  ➡ 表示しない・表示させないという機能をあえて持たせている。  人間側が工夫した管理は、複数チームの複数名が関わっても、   綺麗に管理できる状態になりやすいのでは?と思う。※個人的な感想 3.孫課題が作成できないこと
 「沢山の機能がある便利そうな10徳ナイフ」よりも、  機能美を追求した「1本のナイフ」をどう扱えるか?  人間が試されているように見えた。

Slide 24

Slide 24 text

・Backlogの最大の魅力は”情報集約力” ・集約情報の利用しやすさの担保ために、    ”孫課題を生成させない”機能を実装。 ・使い方と工夫次第で、   効果的で高密度な会議を形成できる ※Backlogは人間側の工夫力を試している まとめ