2016/06/25 AgileJapan2016 高松サテライト

1. チャレンジの見える化
と
改善の日々
2016/06/25
AgileJapan2016 高松サテライト
上田和亨
1

2. 発表の目的
• 普段、開発の仕事をしている上で、問題になったこ
とをチームで話し合い、解決策や改善方法を出して
います
• そんな解決策や改善の方法をお伝えして、
”自分もこの方法はできそうだ”、”やってみよう！”
など、思っていただけたら幸いです
2

3. レジュメ
• 自己紹介／会社紹介
• 見える化の活動／改善の活動の紹介
• 活動を行う上で大切だと気づいてきたこと
3

4. 私
• 去年（2015年）：
・愛媛県在住
・社内システム開発職
• 今年（2016年）：
・東京都在住
・Webサービス開発エンジニア（2015/10〜）
・（スクラムマスタ）
• コミュニティ：
・Agile459
・（元）日本ファシリテーション協会四国サロン
4

5. • 『REST APIで世界中のアプリケーションとつながるクラウド
ERP』 ツバイソ を開発している会社
• 会計機能に強み
• 中小企業におすすめ
• Webサービス（AWS, Ruby on Rails… 等）
• 「ツバイソ」は「ブリ」の富山県での幼名
四国で言うところの「ハマチ」…より小さいかも（？）
• エンジニア募集中！
ツバイソ株式会社
5

6. メンバ
• 要求を管理したり新機能のアイディアを出す人
（＝ビジネス側）
・２人（かなり忙しい。オフィスにいないことが多い）
• 開発する人
（＝開発側）
・フルタイム：６人（うちインターン１人）
・不定期：４人
• 国内（オフィス近郊）、海外（インドネシア・中国）から
リモートワークで開発している人もいる
• 日本語・英語・中国語が飛び交う職場
6

8. ”チャレンジ”とは
• 仕事をしていると、何かしら問題が出てきます
（うまく仕事が進まなかったり、感情的にモヤッ・
イラッとすることだったり）
• そんな問題たちを、前向きに改善していきたいとの
思いから、”チャレンジ”と（勝手に）呼んでいる
8

9. ふりかえり
チャレンジを出す場

10. • 出てきたチャレンジを、
どう見える化したり、
改善しようとしてきたか、ご紹介します
10

11. 誰がどんな仕事をしているか
見えない
• 誰が、どんな仕事をしているか分からない
”あれ…２，３日会話してないけど、仕事は
大丈夫かな？”
• スムーズに仕事をしているのか、何かあって仕事が
止まっているのか分からない
11

12. タスク管理ソフト
JIRA
12

13. どうなったか
• 誰が何をしているか、分かるようになった
• 進んでいなさそうな仕事を
フォローできるようになった
• 仕事を持ちすぎる人も分かるようになり、
フォローできるようになった
13

14. 時間通りに会議が終わらない
• 私たちは、毎日13:30 - 14:00の30分間を使って、も
うちょっと先にとりかかる仕事の簡単な設計や見積
もりを行っています
• 時間通りに終わらないことが多くあり、イライラが
溜まる
14

15. 時間で強制終了
• 30分経ったら強制終了できる
よう、砂時計を使用
• 「砂が落ちきったら終わり」
ルールを共有
• ”砂時計”はあまり見ないので新
鮮な感じ
15

16. どうなったか
• 時間通り終了するようになった
• 集中して議論できるようになった
• ムダに長引かなくなって、ストレスが減った
16

17. ペアプロがあまり
できない
• ペアプログラミングを行う回数が少なくなってきた
ような気がする
• ”良い”コードを書いている人の知識が、
チームメンバに伝播していないのでは、という不安
17

18. ペアプロマトリクス
18

19. どうなったか
• ペアプロの回数が分かるようになった
• メンバーの誰かしか持っていない知識を、ペアプロ
を促すことで、共通して持てるようになってきた
19

20. 問い合わせに回答が
いつくるのか分からない
• 要求に対し、内容を確認するような問い合わせを投
げかけても、返答が来ないまま何日も仕事が手付か
ずに。。。
• いつ返答が来るか分からない。。。
• ビジネス側の人は、忙しい
20

21. 問い合わせ表
21

22. どうなったか
• 運用されていません！
• 返答が１週間単位で来ない場合が多い
• 回答を急いでもらわなくても（実は）良かった？
• 返事待ちの間に、他の仕事をやっている
22

23. 仕事がどこまで進んだか
認識が一致しない
• 開発側：「この仕事終わったよねー」
ビジネス側：「え、まだ終わってないんだけど？」
• 仕事を依頼した（と思っている）ビジネス側と、
仕事が完了した（と思っている）開発側の
認識が違う
• ミスマッチがイライラの原因に！
23

24. プロジェクトボード
24

25. どうなったか
• ボードを作る過程で、”何がゴールなのか”、認識の違
いが明らかになった
→ 話し合いを進めるうちに、”開発のゴール”が一致
した
• 開発の進み具合が、ビジネス側・開発側で一致する
ようになってきた
• どのくらい開発に時間がかかっているのか、分かる
ようになってきた
25

26. 具体的な要求が
来ないときがある
• 開発する新機能の内容がイメージできない。。。
（例）「予約管理機能が欲しい。あとよろしく」
「・・・え？ なんですかそれ」
※あくまで例です
• 開発メンバがイメージしづらい内容は、
開発に着手できない
26

27. ペーパープロトタイプ
27

28. ユーザーの利用イメージを
共有
ユーザーストーリーマッピング
28

29. どうなったか
• 開発にとりかかりやすくなった
• ユーザの利用イメージと、開発内容を具体的に結び
付けられるようになった
• 開発途中でビジネス側に質問をすることが減って、
スムーズに開発できるようになった
• まだこれから
29

30. 見える化や改善活動を
大切だと気づいてきたこと
• 見える化・改善の活動を行っていく上で、大切だと
気づいてきたことをご紹介します
30

31. 何が問題なのか
全員で共有する
• 問題が特定できないと、解決策も出ない
• まずは、解決策とか対案とか出さなくても、問題を
指摘できるだけで良い
• 『ふりかえり』の場があることが大事
31

32. 改善は全員で取り組む
• 改善策は、”誰か”がやってくれると思うのではなく
、全員で実施するのが大事
• 解決策を決めるとき、運用方法も（できれば）全員
で決める
32

33. 時間がかかる
• 『一夜にして世界が変わるようなツールや方法』は
なさそう
• ”問題が共有できるタイミング”を待ってみる、とい
うことも大事
33

34. チャレンジを”楽しむ”
• 「問題だ！問題だ！」と思っていると辛い
• 「改善の種があった。ラッキー♪」と思うと、
前向きになれる
• １人で悩まない。まず誰か（全員）に相談
34

35. そしてチャレンジは
続く…
ツバイソ株式会社は、エンジニアを募集しています！
35