はたらきかた

Regional Scrum Gathering Tokyo 2017 報告会 にいってきた

2017-02-05 はたらきかた, 仕事術, 勉強会

201702_06 Devlove関西&スクラム道関西の合同イベントのRegional Scrum Gathering Tokyo 2017 報告会 にいってきたので、メモや感想をざっくり。

動機

イベント構成

  • 1部 RSGT2017の関西や名古屋の登壇者の再演
  • 2部 ビアバッシュで報告会

再演を聞いたあとに、会場を変えて、ピザとビール片手にビアバッシュな感じで行ってきた人の感想や、報告会の参加者同士で交流を深める2部って感じでした。
これで参加費500円だったのは安すぎるので、お金大丈夫なのかしらという心配をしてしまった。

再演の感想

つらい問題に出会ったら 開原 隆弘さん

こちらの再演。

かってな要約

  • 時間をオーバーするところまできっちり再演するという徹底した再演。
  • テーマ・キワードとしては対話
  • 福原 美砂さんに「自分を立て直す対話」という本を進められ、そこに書いてある智慧の車座を開催通じて得た気づきやポイントの共有
  • 初っ端からスクラムほとんど出てこないw

メモ

  • ロジカルに解決できない問題もある
    • ひとりだとぐるぐると悩みに陥る
  • 自分がとらわれている問題からの対話
    • 人の力を借りて「問題をほぐす」
  • 智慧の車座を開催
    − 一人の相談者、4,5人の賢者
    − 無責任に発言するという掟が難しいが大切

  • 問題をほぐしてテーマを再設定する
    − 例: お客さんにいいようにつかわれていざとなったら裏切られる
    → 信頼できないお客さんに、どう接したらよいか?
  • やってみて
    • 短時間で深い本気はなしになりやすい。
    • 居酒屋だとガス抜きににだけなるのがもうちょいすすむ
    • 相談者が自分自身を改めて知り「賢者」も得るものがおおい
    • フォーマットにそってやってれば簡単にできた
  • やってみて気づいたポイント
    • 同じような役割・立場の人をあつめたほうがいい。
      • 上司部下だといつも通りになってしまうのでファシリ力が求められる。
      • 問題解決ではなく、相談。
    • 仕事上の繋がりが薄い方がいい
    • 計画的に定期的にやる。なんかの場とからめてやったほうがいい

感想

  • ある程度、多様性を埋める人数規模の組織ででないと車座は上手く回しづらいかも。
  • 始めの第1回を始める蹴り出し方がポイントになりそう。
    • マネージャーから始めるかメンバーかはじめてみるかどうやるか気になった
  • とりあえず、本買った。

アジャイルカルチャーが 組織に根付くまでの挑戦 中村 洋さん

こちらの再演
スライドが違いすぎたので本当か?と思いつつ聞いてたら、どうやらスライドはこっちが正解っぽい

かってな要約

  • 中村さんが現場コーチとしてまわってきたなかで感じてきた変化に対する組織の反発とどう向き合っていくかのポイントと実際に活用しているコーチの道具箱の紹介。

メモ

  • 導入への3つの壁
    − 変化することへの壁
    − やりかたの壁
    − 役割の壁

  • 壁を崩すための姿勢

    • 視座をたかくもつ
      − あせればあせるほど自分の視座が下がっていく
    • ありたい姿がないと改善の余地がない
      − ゴールデンサークル:Why → How → What
    • 実験をくりかえす
    • 最近はプロダクトだけでなく、組織も実験を繰り返しやすくなってきてる
  • 道具箱
    組織のコンテキストによって同じ道具でも使いかたをかえている。

  • デリゲーションポーカーで役割と権限の認識をそろえる

    • 権限の7階層:命令する 説得する 相談する 同意する 助言する 尋ねる 委任する
  • 組織の変化 タックマンモデル:新しい人をいれたら安定してた組織も一度混乱期にもどるんだから人足せばいきなり上手くいくものではない。
  • お披露目会:できたものを説明したりフィードバックを得る機会
  • 星取表:今必要なスキルや今後必要なスキルを各自どんな状態かならべてみる。プロダクトで今後必要とされるものを誰ができるのか?などチームの状態を可視化。人事評価に使うと正直に答えなくなるからだめ。
  • メトリクス重要。

感想

  • スクラムやりはじめるのは簡単だが習得は困難
    • スクラムやアジャイルをやり始めることはできるが、当然そんなにすぐにうまくいくわけもない
    • 銀の弾丸的に即効性を求めて、効果が出て定着させる前にアジャイルはうちのチームやプロダクトにはあってないと評価されている現場もありそう・・・
    • そこらへんタックマンモデルを使って上に説明できるとよさそう。
  • とりあえず、紹介された道具から、お披露目会星取表は、近しいものがすでにあるので、取り入れてみたい。
  • デリゲーションポーカーもやってみたいんだけど、そもそもそういう事に対する妙な抵抗を示す人もいるので、タイミングを探ろう

結果的にスクラムになってる!なのがいいと思う! 椎葉光行( @bufferings )さん

こちらの再演

かってな要約

  • 椎葉さんが楽天大阪支社でやってきた経験のお話。
    • スクラムやるよ〜っていうと、スクラムおばけが出てきて上手くいかないんだけど、
    • それより問題解決しようよ〜っていって解決のためにスクラムのメソッドを一部使っていく
    • 結果スクラムになってるくらいがちょうどいい

メモ

  • スクラムを始めない
    • 先に問題を解決しよう
    • KPTのProblemがおもすぎるので、Good & Moyyatoの問題からその問題を解決するためのものにスクラムの道具を適用していった
    • スクラムをしようから始めるとスクラムお化けがでてくる
    • 正しいスクラムにとらわれてしまう
    • やってるだけで安心しちゃう
  • スクラムうまくいってないところでも結局は問題から解決をの形へ
    • 例)差し込みが多いとスクラムが上手くいかない、リリースが遅れる
    • ループする問題はどこかを解決すればループがとまる
  • 組織として価値を生み出す流れを意識
    • 開発はスクラムでもビジネス側がちがう・・・とか言ってたら上手くいくわけない
    • 全体最適で問題解決から始める、結果として組織の形にあったスクラムへ

感想

  • 問題解決から始めるアプローチは、報告会の中で、一番どこの現場でも適用できそうな内容だなぁと感じた。
  • 開発だけでなく、組織として価値を生み出す流れの中の問題を解決していく。というのは、僕も意識してるところなのでぐっときた。
  • 2部のテーブルで椎葉さんがファシリっぽく話す場面がありテーブルの全員にしっかり話ふっていたりとか質問の投げ方とか、声のトーンとか、椎葉さんの姿勢に学びを貰った。
    • もうちょい椎葉さんと話てみたかったけど、いまいち上手く話しかけれなかったのは反省。
    • 椎葉さんが登壇する理由は、「自分から話かけるのが苦手だけど、登壇してたら、懇親会で話かけてもらいやすいから」。共感。

Scrumありがとう、そしてさようなら-Scrum 破- kyon_mm

こちらの再演

かってな要約

  • 守破離の
  • 守のスクラムなんて20年たってる枯れた手法。だれでも上手くいける。
  • いい加減スクラムを超えていいんじゃね?だって、20年前の言語で開発するとかだれもしたくないでしょ?
    • kyon_mmのチームは、破。そして世界最高のチーム、1スプリント1日。6分単位でのみつもり。さらには秒単位で見積もってソフトウェア開発から生産を目指すんだ。って話。

メモ

  • スクラム自体がうまくいってるかどうかもメトリクスとらないと、スクラムしてるんなんて言えないよね
  • プロダクトを最高にする以上にチームを最高にする必要がある
    • チームとしてのビジョン:
      • kyon_mmの例)世界最高のソフトウェア開発チーム、スクラムを超える、ソフトウェア工学に新たなページを作る
    • チームビジョンのマイルストーンを作る
  • スクラムは20年たってるからもう超えていいだろう
  • スキルマップ
    • できるかどうかじゃなくやったかどうかで星取表
    • 例)基本知識を活用して仕事をしたかどうか
  • レビューのメトリクスを常にとっておく
    • レビュー時間 x 何の品質にかかわるものか
    • 狩野モデル https://sites.google.com/site/techdmba/kanomodel
    • レビュー時間ながいけど指摘が無関心品質ばかりの人が出てきたりする
  • ソフトウェア生産へ
    − 徹底的に無駄を省く。できない人の無駄ではなくできる人の無駄を省く。もはや20%ルールどころか50%ルールで、仕事の半分は学習・研究に時間をさけるようになっている

    • 同じものを3,4回作る。最終的には1回目の4分の1くらいの時間で作れるようにする。この再現性があがれば生産にもっていけるのではないか。

感想

  • 発表の怒涛の勢いにかなり飲み込まれていく感じの発表
  • 6分単位での見積もり、1スプリント1日など、なかなかすぐには真似できそうにないので、未来とか、タイムトラベラーみたいなワードが飛んでた
  • 話を聞いていて、ぶっ飛んでいるようで理にかなっているし、日々改善していくというだけなので、実は当たり前のことかも。
    • 星取表を「できる」ではなく「やった」という事でマップするのもシンプルで運用しやすそうだし、発表のコアはとてもシンプルで案外他でも再現できるかも
  • 会社やプロダクトとしてのビジョンだけでなく、チームとしてのビジョンをシンプル持っているのも大切だよなぁ〜と共感。

  • 50%は新しいことに時間が使えるようになったというのがすごい
    • 開発の創造性・クリエイティビティ、ムダも必要みたいな話はあるが、徹底的に無駄をなくし生産を目指すアプローチで、結果として50%で仕事が終わる。
    • 単純に考えると、空いた50%に仕事を詰め込むこともおきそうだが、なぜなってないんだろう?というのを聞きそびれた。

2部のビアバッシュの感想

  • ビルの10階にカフェ的なスペースがあってそちらに移動。会場だったMOTEXの本社のファシリティーに感動w

  • トークセッション

    • 2部始まってすぐ、トークセッションとなり、実際に参加された方が会場やセッションの雰囲気を共有。
    • 雰囲気を聞いておくと初めて行くとしてもあまり身構えずにいけるので、そういう共有もあるのはいいですね。
  • テーブルトーク
    • トークセッション後にテーブル毎に登壇者をかこんで話ができた
    • 参加者の意識高いなぁ感もうける
    • 2部全体で1時間しかなかったので、15分くらいしか話はできず。すこし残念。

全体通して感想

仕事で多少はスクラムっぽいことも取り入れているけど、やっぱりやってる人たちの事例をどんどんInputしていきたいなとおもっていたので、大阪でRSGT2017の再演が聞けて、交流もできるイベントはまさにラッキーでした。
いつもなら二次会にいくのですが、予定いれてしまってたのが失敗。あと30分2部の時間が欲しかった・・・

しかし、ひさしぶりに自分の感想まとめてみようという動機にもなったステキな時間でした。運営の皆さんありがとうございました。

いくつか自分の現場で試してみたいネタも拾えたので月曜日からがんばります! Monday!

カンバン仕事術が活かせそうな点満載だった

2016-04-17 はたらきかた ,

会社でホワイトボードに書き出してはいるものの上手くいってなかったので、いっときAmazonでも在庫切れになったりとい人気っぽいカンバン仕事術を読んでみた。

総論

ってきり、はじめはスクラムとかXPとかアジャイルの手法ゴリゴリかな?と思っていたのだが、むしろ逆で、かなりピュアなカンバンの本だった。
スクラムとかXPとかのアジャイルを現場に持ち込むのはそれなりにパワーいるが、この本のようなカンバンだけなら簡単に導入できる部分がありそう。
カンバンでの見える化からはじめて、いきなりやるには、作法がわからないとか、その作法の裏にあることを理解できてなくて諦めがちなアジャイルの手法にも段々ともっていくというようなこともできるのではないだろうか。

カンバン仕事術だけでは具体的案イメージがつかなかった点も多いのだが、アジャイルコーチの道具箱 – 見える化実例集を合わせて読んだらよりイメージがわいたのでセットでオススメです。

感じている課題の解決にむけて試してみたいなって思う事などあったのでメモ。

うちの現状

  • チーム構成 
    • 開発: 社員+協力会社
    • 運用・サポート: 開発のできる社員・できない社員+シフトで開発支援のアルバイト数名
    • マーケ: 運用・サポート兼任メンバー+営業やデザイン系の部署
  • PJの状態
    • いくつかのチームにまたがるものや、跨がらないものなのど、サイズはかなりバラバラ
    • 開発は比較的PJ単位で動けていて少しスクラムっぽいことも始めている
  • タスクの状態
    • PJ単位で発生しているもの、部署全体で月次や週次で定められたタスク(ルーチン)、運用・サポート中心に顧客からの問い合わせなどに合わえて受動的・突発で動くものなど

こんな現場でチーム横断で情報を共有するためにホワイトボードをおいていたのだが、結構うまくいってなかった。
ちなみに最近、開発は開発だけで別にカンバン的なことを始めている

  • 感じている課題
    • 部署全体のルーチンタスクが特定の人に依存・集中しがち?
    • 出ているタスクの粒度に差が激しい?
    • いつまでも消化されないタスクが積み上がってる?
      • 特に開発がわからないメンバーが出したタスクはおかれたまま消化されない物が多そう
    • 全チームを取りまとめてる部長や開発のリーダーがしょっちゅうボトルネックになる
    • そもそもホワイトボードに張り出しているが普段見てない部分がほとんどな気がする
    • 朝会の時間が守られない、ボードにない内容で時間がすぎていったりするし、同じような報告を別なMTGでもしている
    • ルーチンや他のタスクに追われて本来のしごとができていないという発言が全メンバーから出てくる
    • アルバイトに渡す仕事が当日の朝まできまってないことがある
    • アルバイトが定形作業ばかりでもうすこし開発系の仕事も任せたいがどれくらいできるかわからない

なかなかの課題はたくさんあるのだが、ここらへんについて幾つかヒントがもらえた。

試してみたいなと思った事

追記:以下は、本に書かれている各エッセンスを自分の現場ならこういうことをやってみたいなと思ったもので、本に書かれている内容とは異なりますので、ご了承を。

  • WIP制限
    • これは基本っぽいし人によってのタスクの粒度の差や特定の人への依存、ボトルネックの可視化に一番有効そう。ただいきなり小さな数でやるのは怖いので少し大きめの数字で始めてみようと思う。(人数x2.5くらい)
  • マグネットに名前入れて付箋にはる
    • だれがやってるタスクかということの可視化。カンバン仕事術ではアバターとしてえらく可愛いのがでてたが、アジャイル
  • アルバイト用カンバン+定形タスクと開発タスクで付箋の色わける
    • アルバイトに何を任せているのかやアルバイトに任せたい仕事を可視化しやすくなれば、アルバイトが定形以外の開発タスクにももっと関われるし、何をやるか明確になっていくのではないか?
  • どれだけできたかメトリクスを測る
    • アルバイトもそうだし社員の仕事にしても貼りだすだけになっていて、どれだけできたかを測ることができていなかったので、よけいどれくらいできるのかわからなくなっているのかも。
    • まずはサイズが安定しているルーチンから開始日と終了日を記載していくことにして、アルバイトが中心のルーチンはアルバイトだけでも改善を検討できるようにもっていけるのではないか?
  • 開発ができない社員のタスクを分けてみる
    • 開発できない人が作ったタスクが残りがちなのは、その人だけで終わらないものがあるのに持ち続けているので、他から助けにいけばいいのか可視化されていないのかも。自分でできないものとできるものに分解するようにしていけば、他のメンバーのサポートを受けやすくなるか?
    • 分解はしなくても、そのタスクが終わるまでのフローを書き出したカンバンにすれば自分でできるところできないところがわかりやすくなるかも。
  • 粒度を成果の単位にする作業単位にしすぎない
    • 付箋の粒度がまちまちなので、何かしらアウトプットとして成立する単位という粒度のルールを共通でもったらどうだろうか。
  • 誰になにをしてもらわないとおわれないのか?それは本当か?見直す
    • 部長や開発リーダーがボトルネックになりがちなのはなぜなのか?例えば絶対部長のレビューが必要な仕事のレベルを決めて、それを付箋に書けば実は必要のない仕事まで部長や開発リーダーに念のため〜で回っていないだろうか。
  • PJ以外のタスクの可視化をして優先順位と制限をつける
    • PJで決められているタスク以外のものの優先順位をはっきりさせて週にやっていい量を制限する
    • 優先順位を決めるルールも共有する
  • 朝会の内容を絞る
    • 部署全体の朝会は運用作業と全体で共有しておきたい(他のチームにしらせておかないといけない)事に留める(デイリーシンク・リリースシンク)他にすべてのチームが知っておくべきことはないか?
  • 改善のタスクの仕方
    • ワークフロー上に自分ができる仕事がなければ普段できていない、他がはいってきたらすぐやめれるそういう仕事に着手する

一番大切にしたいと思ったこと

  • ゆとりの無いところに改善はない
  • みんなで決める

試してみたいことはいっぱいでたけど、一人でやるとか、いきなりトップダウンで下ろすのではなくもっとほかのアプローチもないかみんなで決める
そして、まずはそのゆとりを作れるようにするところは、一番上から働きかけていく。

とりあえず、明日からの仕事に向けて自分なりに思ったことをまとめた。
また機会があれば、この結果どうなったかをどこかでまとめてみる。