ボドゲを愛するテスト屋さん

ソフトウェアテストとか、ボドゲとかを自由気ままに。

Backlog World 2019 参加レポート②

どうも、BacklogWorld のお昼ご飯が大好き、オムそばです。
今年のお弁当はまい泉のお弁当でした!(ミニバーガー付)
f:id:teamomusoba:20190129231222j:image

 

前回に引き続き、JBUG主催の、Backlog World 2019 というイベントのレポートを書いていきたいと思います。
backlogworld2019.jbug.info

前回の記事はこちら。

teamomusoba.hatenablog.com

 

■「連絡版」が支える、Backlog嫌いなクライアントとのコミュニケーション たにぐち まこと(株式会社エイチツーオー・スペース)

f:id:teamomusoba:20190127160258j:image

本セッションでは、社員、クライアント、パートナーのすべてのメンバーが、Backlogを通じてコミュニケーションを行うまでに至る経緯と苦労について、講演されていました。
以下、講演時のメモ。

  • 大学や教育機関のWebサイトの制作をやっている会社。
  • 大学の担当者は、ITをアクティブに使いこなしたくない人が多い。その人たちに対し、Backlogを使ってもらうために工夫したことを話す。
  • オフィスのない完全リモートワークの会社。東京-千葉-大阪に社員がいて、かつパートナーは各地にちらばっている。
  • 選択できるコミュニケーション手段は全部で4つ(電話、メール、チャット、Backlog)あるが、その中で、電話、メールはリモートワークに適さない。
  • 電話の欠点:記録として残りにくいため、言った言わない論になりやすい、など。
  • メールの欠点:CcやMLなどで自分に関係のない話題が飛び交う、など。
  • チャットの欠点:記録には残るが整理しにくい、など。
  • Backlogの利点:状況を整理でき、かつ記録として残り、後で参照しやすい
  • いくつかのコミュニケーション手段を試して使ったところで、クライアントやパートナーにもBacklogを使ってほしいという思いが生まれた。
  • 使っていくうえで、残念なBacklogの使われ方をしていた。(管理表あるある)
    - 意味のわからない課題件名
    - 更新されない担当者
    - 使われない優先度
    - 取り残された期限
  • 残念な使われ方をしないよう、ディレクターが整理、統制するような運用に変更した(タスクの棚卸や、タスクの精査など)
  • クライアントとパートナーは直接つないではいけない。繋いでしまうと、クライアントの要求が直接見えてしまい、パートナーの負荷が増したり、ディレクションできなくなる。そのため、ディレクターが間に入り、クッションとなるべき。そのために、プロジェクトが立ち上がった際には、Backlogに必ず「開発用」と「クライアント用」の2プロジェクトたてる。管理は面倒臭いが、必要。
  • スケジュールも内部向けと外部向けで使い分ける。
  • クライアントがBacklogを使いづらいという要望があがったため、「連絡版」というタスクを立ち上げた。連絡版には、なんでも放り込んでよい。タスクでも、雑談でもよいという運用にし、ディレクターは連絡版から抽出し、必要であればタスク化する、という運用にした。そうすることで、クライアントのBacklogに書くハードルが下がった。
  • やっていくうちに、段々慣れていく。(連絡版に書くとタスク化してくれるとか、見てくれるとか)
  • 内部向けテクニックとして、曖昧な課題をコメント欄で補足していく。
  • 締め切りについては、親課題を活用する。細かいタスク(子課題)の締め切りは決めず、親課題に定める。
  • 電話やMTGを減らす工夫として、管理ツールやメールの返信をできるだけ迅速にし、こちらからクライアントに電話やチャットを極力しないようにして、すべてBacklogを介して対応するようにした。

慣れていない人に、新しいことを浸透させる際、相手がクライアントであろうと徹底した運用(電話で依頼された事項は絶対にタスク化しないなど)を行っているそうです。
忍耐強く、継続的に、徹底してやることが、新しいことを浸透させるうえで大切なことだと感じました。

 

■小さなチームの全員マネジメントな日常 守屋 慧(株式会社IDOM)

f:id:teamomusoba:20190127160507j:image

本セッションでは、自律的なチームを目指していく中での取り組みについて、講演されていました。
以下、講演時のメモ。

  • スクラム開発をしている現場で、現在開発はペアプロやモブプロの導入をしている。その状態に至るまでの経緯を紹介する。
  • チーム発足して最初の2か月。
    当時は自己流スクラムをしており、そこでいくつかの弊害が発生した。具体的には、隣にいる人がなにをしているかわからなかったり、リリース頻度が下がったり、カンバンが荒廃(情報が更新されず、蓄積されていく一方になった)していったりした。
  • カンバンは物理ボードでメンテが大変なので、Trelloを使った。また、振り返りが活かされないないため、スクラムボードを使った。しかし、Trelloもすぐに荒廃し、アクションも起きなかった。
  • 次の2か月で、ようやく自分の無力さを悟る。
  • 書籍や勉強会に参加することで、知見を得るようにした。
  • やったこととして、スプリント期間を短くし、情報共有のBacklogを"きちんと"使って、計画を見える化した。きちんとツールを使うと、色々とツールが教えてくれる。この時点では、まだ見える化が不十分で生産性の向上はまだ実感できなかった。
  • 次の2か月では、スクラムマスター研修に参加し、知見を深めていった。結果、定量化が進み、カイゼンの意欲が向上した。
  • モブ・ペアワークの威力で業務効率アップし、ベロシティは2倍以上に。
  • 場(仕組み)が属人化を防いでくれる。問題があるから共有されるのではなく、共有する「場」があるから問題は共有される。
  • Next Try。最近、段々とカイゼンスピードが鈍化してきた。表面的な作業カイゼンの限界がきており、大きなカイゼン(Value Stream全体のカイゼン)には大きなリソースが必要となる。
  • Try1:PO(プロダクトオーナー)チームとともにアジャイルに!開発チーム主導でPOチームのタスクを確認し、POチームのデイリーゴールの共有をした。そこで見える化によるムリ、ムラ、ムダ撲滅をしている。
  • Try2:事実の共有から思いの共有へ。目の前の仕事を超えた相互理解で本当のアジャイル開発チームへ。
  • 大事なこと:「マネジメントは全員で」「とにかく小さく試す」「結果や過程は大事だが、そこに向かうモチベーションが重要」
  • アジャイルソフトウェア開発宣言に書いてあることを目指しており、実現していた、ということに気づけた。

最後の部分は、アジャイル開発を始めた当初に読んでいたものの、色々と試して失敗して、最終的に成功を掴んだ後に見たことで、書いてある言葉が実感として理解できたとのこと。
知識と実績(ただ漫然と過ごして得たものではなく、考えて実行して積み重ねた確かなもの)の見事な融合だと感じました。

 

全3回を想定していましたが、2回目でようやく折り返し地点なので、もう少し記事数を増やそうと思います。ではまた。

次の記事はこちら。

teamomusoba.hatenablog.com

 

※記事中に不快な言い回しや、誤った表現などございましたら、遠慮なくご指摘ください。