スクラムマスター

本日はヒカリエで、s'crum Master's Nightに参加してきました。

どんなマスター達がいるのか、どんな経験を持っているのか、簡単なのか、儲かるのか、そんな事を期待しながら。

アジェンダみるとディスカッションテーマもその場で募集して、投票の多いものを選択して行うという形式。

これなら、こちらの持つ懸念、疑問とかがマスター達と話しやすそうだと思い、参加してみた。

感想としては、この会合が三回目ということもあって、参加者がルールを良く理解してるのか、参加するからには何かもやもやをスッキリさせて帰ろうと思ってるのか、変な沈黙が少なくて、とても居心地が良かった。

テーマ募集

テーマがたくさん出て来るのかと思ってたが、意外に初動は遅く、1人が出してから、少しずつ出てきた。

自分もテーマ出してみた。投票がないとさみしいとか無かったし、選ばれなければ他のテーマで面白そうなところに参加すれば良かったので。

でも、選ばれた！

テーマは、「スクラムって儲かるの？」でした。

ディスカッションは、1時間

関係ないけど、テーマ的にピンと来なかった場合は、ファシリテーターのキャラで選ぶって楽しみもありますね。

なかなか個性的な人も居ましたし、完全に中立主義みたいな雰囲気の人もいました。

アジャイル開発推進は、ファシリテーションスキルが必要なので、そういう目線での参加でも何か持って帰れると思います。

特に、この1時間の使い方は、ファシリテーターに任せてるのがいいですね。最後にファシリテーターに対してのフィードバックも忘れずに。

今更ながら、

テーマは決めたが、ゴール決めとけば良かった

と思いました。

なので、私へのヒアリングから入ったわけですが、これから始めて見る価値を自分なりに理解したいということから、「お金」に着目してみた。

もちろん、お金以外のメリットはたくさんあるとは思うが、

ステークホルダー達への説明がしやすいのが「お金」なので。

スクラム導入支援は儲かるよ！

いわゆるコンサルタント。

まあ、これは最近になって急にもりあがって来たので、引き合いがあるんだろう。

でも、これってせいぜい1人しか儲からないじゃん？

それに

私のイメージでは、スクラムでソフトウェア開発、つまりチームの生産能力を上げるものみたいな話がしたかった。

コンサルの話では、

1度軌道に乗せても、離れると問題チームになったりするらしい

というのが気になった。

やはりコンサルタントってそういう仕事っぷりなんだよなぁ。

ゴール設定が無かったので

話が発散してしまったが、

人数が少なかったため、短時間ながらみなさんがちゃんとディスカッションに参加してくれたことが本当に良かった。

SIerのようなな受託開発領域に導入するなら、

保守、維持管理という固定費用の世界が向いてるかも？

という意見がありました。

スプリントのイメージが全くわかなかったけど、チーム維持が保証されてる中なら、まあやろうとすることは出来そう。

スクラムの最大の効果は、

人が育ちやすい

人が育つから生産性も品質も上がってく

そして、利益が出る、ということ。

チームのメンバが全員XPやTDDを短期間で経験するし、ウォーターフォールのように途中でサボれないから、凄く一生懸命スプリントを回して行くからねっ！

ウォーターフォールはサボれる？

確かに可能性はあるが、最後で

それ、ちげーよ！

みたいなどんでん返しあるから、サボってられない。リカバリ覚悟してれば、サボれるけど。

まあ、でも一旦要件が決まって、仕様も承認されると、受け入れまでは、

気が緩むのは否めない

多少新規技術要素とかで盛り上がるし、見えるものを作ってるとそうでもないが、Webポータルでないサーバアプリは見えないから設計工程、製造工程共に盛り上がりにかける。

そんな心理で作り込むから、試験工程で大変盛り上がる。バグが収束しない時なんかオールでお祭りですからね。

そもそもSIerは、開発プロセスがしっかりしてるから、信用されてる

そんなことは誰も言ってなかったが、最後にはちゃんとしたものを納めるためのチェック機構で歯止めがかかってる。

でも今は

そんな事は望まれてなくて、

早く安く

その代わり、SLAは相応のものにしてもいいよ！

なのである。

で、Scrumというかリーン

というのが注目されてる気がする。

スクラムは経験してないので、下手なことは言えないが、誕生から10年くらい経過してて、ツールはそれなりに揃ってる。

ただ、スクラムでやるか、ウォーターフォールでやるかのジャッジに正解がない。

おそらく、私のようなにわか知識でスクラムやるってのは、何回か失敗することが許容されてないと、ダメなんだろうな。

じゃあ、ウォーターフォールなら失敗しないの？

そんな事も言えない

だから、スクラムでやっちゃえばなのかもしれない。

自分がやるなら、スプリントをどのように回すかという仕組みの部分を構築して、メンバーにレクチャーしてから始めるかな。

で、この仕組みの構築だけを、しれっと導入支援してくれる人がいれば十分だと思った。

じゃあ、儲かると思うか？

ディスカッションではケース出しに終始したんだが、チームにいた方から、こんな本を紹介された。

ここには、ウォーターフォールからアジャイルにする時のノウハウが書いてあるらしい。

次回までに読んでおこう。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

まとめ的な話

この会合での私の結露は、

PM経験がそれなりで、ファシリテーション力があれば、

先ほどの仕組みを使って、アジャイルで成功することができるんじゃないかな？

ってこと。

ちなみに、仕組みというかツールも見つけた。AlminiumというOSSパッケージ。これは、RedmineのBacklogプラグインやJenkinsを統合したもので、バックログアイテムの状況をカンバンのように表示できるようになってる。

これは、朝会と夕会で共有しやすい。

更にWebなので、AWSとかで作っちゃうという手もあり、開発拠点が離れてても共有しやすいわけです。

また、過去の会合の中で、似たような議論をされた方が居たようで、大変参考になりました。

「 Scrum Masters Night （スクラムマスターズナイト）」に参加してきました #smn - HOW TO GO

最後に

今回のチームの皆様、ファシリテーターしていただいた方、本当にありがとうございました。

そして、時間が本当に短く感じられて、楽しかったです。

また、お邪魔しようかな。

課題の処理方法を考えてみる

リーン開発の本を読んでいても、現在最強とも言えるWaterFall配下で仕事してる関係で、そっちがすごく気になる。

リーン開発の本を読みながら、思いついたことをブログにして、実践して見るという営みにしてみよう。

このブログは備忘録

なのでね。

今日は

課題表について

業界に限らないかもしれませんが、やたらと列がある課題表を使ってます。

まあ、いろんな情報がフィルタで絞り込めるメリットがあるんですが、

にしても、横に長すぎるよ

画面が横に伸びるか、マルチディスプレイでないと、、、

こんな表で管理するのは、利用者の立場によって見たり更新する場所が異なるというのが事情なのである。

1. 課題登録
2. 課題受付、対応者振り分け
3. 課題対応
4. 登録者と対応者間の認識合わせ
5. 課題のクロージング

この他にも、課題がどれくらい難航してるかというのも見ないといけないし、対応者がオーバーフローしてて着手すらできてないとか、課題がプロジェクト全体に関係する場合はちゃんと周知できてるかなど、マネジメントの問題を解決しなくてはならない。

これらは、発生確率の非常に高いリスクで、放置すると開発メンバー数の稼働に跳ねるので、インパクトが大きい。

なので、

リスク顕在化への予兆検知

ができるようにしておかないといけない。

こんなパラメータが課題表から自動的に集められれば、判断できそうだ。

• 課題登録日から、何営業日経過？
• 対応指示日から、何営業日経過？
• 対応完了日から、何営業日経過？
• 現在その課題(つまり、EXCELの行)は、誰のアクションか？

判断した後、適正な稼働指示になるかはわかりませんけど、無駄に止まって工数垂れ流しみたいなことにはならないと思いました。

もちろん、登録者、受付者、対応者の名前、それぞれの開始／終了日付が記録されてる必要がありますね。

本当にExcel課題表でいいの？

Excelには、ブックの共有というのがあり、複数人で同時に編集することができますが、編集に制限もありますし、結構デグレや破損の事故も発生します。

確かに、手軽に使えますけどねぇ。

いろんな情報を取り込んだ、一見完璧とも言える課題表は、

完璧に使える人が課題表作った人だけ

という問題もあり、

完全な形で運用されない

最悪

課題が放置される

何ヶ月も

でも何故か放置されてる課題は、メンバー内では解決してたりするわけですが、その決定経緯がわからず、大問題になったりもしますよね！

結論から言うと、

カンバン

のしくみ、チケット駆動の運営で、ステータスと稼働をメンバー全員で見えるようにしておくのが1番いいと思いました。

さあ、どうやって変えていこうかな。

リーン開発の解釈

これまた久しぶりの更新。

アジャイルが一時的に流行り出し、感覚的には言葉自体があまり使われなくなったかなあ、と思っていたんですが、最近になって近場で浮上。

というわけで、私自身が不勉強なので、読書して正しく理解はしておこうと思いました。

タイトルが「リーン」となってるのは、呼び方の問題。実際日本では、トヨタ生産方式「TPS」という方がメジャーなのかもしれません。

自動車生産方式をTPS、ソフトウエア開発方式をリーンと区別しますかね。

方式というより、精神・ポリシーというのが定まってますね。

概要

• 全体を最適化する
• ムダをなくす
• 品質を作り込む
• たゆまぬ学び
• 速く提供する
• 全員を巻き込む
• 改善を続ける

重要なのは、全員を巻き込むことでしょう。

次に開発フレームワークとして

スクラム

• 順番づけされたプロダクトバックログ
• 職能横断型チーム
• スプリント
• 継続的にリリース計画を調整する
• 継続的にプロセスを調整する

プロダクトオーナーとスクラムマスターという役割がポイントのようです。

後は、イテレーションという短いスパンで開発を進めて、こまめにリリースして、イテレーション後に都度振り返り、プロセスを調整する改善しながら進めるという感じです。

で、実際の開発は

XP(エクストリーム・プログラミング)

こいつは、いくつか方法があって、XPだけを使って、「アジャイル開発やってます」みたいなことを聞いたりもしましたが、今はさすがにないかな。

で、方法とは

• 継続的インテグレーション
• ペアプログラミング
• テスト駆動開発
• コードの共同所有
• インクリメンタルな設計の改善

で、製造工程を可視化するのが

カンバン

少し前だと、ホワイトボードにワークフローを列にした表を書いて、ポストイットにタスクを貼り付けて、そのポストイットに担当者の名前を書いて進めたことが思い出された。

違いは、下記のWIP、つまりワークフロー単位に作業制限を加えてないことだったのか。

制限無かったから、対流状況がいまいち共有されなかったんだと思われる。

ポイントを以下に示します。

• ワークフローを可視化する
• WIP(仕切り作業)を制限する
• サイクルタイムを測定し管理する

これらを見ると、OSSのRedmineというツールがマッチするように思いました。

実際カンバンを意識して構築することができれば、滞留状況やWIP制限なんかもRedmine側で検知・ガード・優先予約とかもできそう。

しかも、このかんばんという開発推進方式は、10年の歴史があるので、Redmineのプラグインにありそうですね。

概要としては、以上です。

実践的なところを、後日図で補強しますね。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

Analytics 2014 レポート その4

いよいよ、有名な統計家の登場です。

前にこの人の公演を聞く予定でしたが、体調が悪くきけなかったんです。

今回は、SASからのオーダーで、サッカーネタに分析手法を話してくれってことで、データ的には古いですが、2011年ベストイレブンを自分なりにセレクトして、実際どうかという検証してらっしゃいました。

サッカーで学ぶデータ分析の勘所

統計家
西内　啓 氏

本はだしたが、全く売れなかった。

サッカー分析

たぶんこちらかと思われます。

遠藤保仁がいればチームの勝ち点は117%になる データが見せるサッカーの新しい魅力 (ソフトバンク新書)

データ分析は、下記の必読書からは逸脱しない。

データ分析者の必読者

Research Design: Qualitative, Quantitative, and Mixed Methods Approaches

Analytics 2014 レポートその3

午後のセッション2つ目のセッションは、情報システム部門の方です。

前回の記事と違って、この方がどれほどのメンバーでどんなレベルで分析してるかわかりませんでした。

資料は、かなり非公開らしく、報道関係者含めて撮影禁止！

Analytics 2014 レポートその2 - 猫好きな老体気味SEの備忘録

というわけて、これはちゃんと聞かないといけないな、とはいえ寝落ちリスクも高い時間、、、頑張りましょう。

情報資産をビジネスに生かすための取り組み

株式会社ＮＴＴドコモ
白川　貴久子 氏

情報システム部の情報戦略担当

関西でマーケティングの戦略とか、営業やってた

IT知識がない、、、おそらく統計手法やマーケティング手法には長けてて、プログラムを書けないというお話なんだと思います。話っぷりからEXCELで統計解析程度はご自身で対応できそうな、、、

docomoには、モバイル空間統計という研究成果がある！

ビジネスサイドにいた白川さんがデータを活かす目的を明確にしやすいはず

データマイニングは少しかじった

→無理に使うほどでは無かった。

Excelで処理できる程度

今は処理速度が格段に進化

その価値を知りビジネスに生かそうとする企業全体の風土

ドコモの分析組織とは

情報戦略担当は2003年4月に発足

情報資産を活かすための組織

• 分析チーム
• データ抽出チーム
• セキュリティチーム、顧客データ

システム担当

• データ構造知識
• システム活用スキル

ビジネス部門

この2部門と連携

提供後に手戻り

本当に欲しいものだったのか？

ビジネス部門のバックボーンなしに作業

データ項目、データ定義など、何に活かすかを伝えないから。

解約でもいろいろ種類があるので、

分析したいことが伝わらないという問題

→縦組織でよくある話

ヒアリング手法

NGワードは「とりあえず」

更に実作業はプロパーから言われるSEなので、言われたことを予想しながら、疑問も出せないままやって失敗

5年経過後、今は手戻り少なくできている

分析請負ではなく、データ活用のパートナー

期待以上のアウトプットが鍵

社内活用のための組織

電話での対応から、Q&Aボードへ

電話は1人しか対応できない。

名前をデータ分析お助けコーナーに変更

2年前の問い合わせが未回答だったので、活用されなかった。とりあえず、すぐに回答するようにプロセス改善

初動を迅速に！

• 事例発信
• 1人の悩みは全員で共有

分析力を高める取り組み

• 分析事例発表会→4Q毎に地域持ち回り
• 分析設計演習・マーケティングレクチャー

4年継続して、大分意味をなしてきた。

支社発信の内容が全国展開された事例にまで発展

地域の営業を巻き込むことで、化学反応が起こってきた。

繋ぎ役として、継続した。

回を重ねると、発表会だけでは飽きる

マーケティングマインドをもって

分析設計ができる演習を開催

1. 戦略編
2. 戦術編
3. 実践編

ディスカッションさせる

自分がどういうことに偏りがちなのか？を気づかせる

演習させると、出来なくて、

フィードバックで、セオリーを語る

マーケティングセオリーなので、フィードバックの内容は理解できる。

変化を浮き彫りにする工夫

基準、区分、スパンの見方

先を見る

データが膨大だと見落とすので、何が見つけたいのかをちゃんと定義する

なんでそれが必要だったの？

とかの振り返りで迷いが出ないように。

データでわからないこと

• 現場のリアリティを知ること
• 声に耳を傾ける
• 素直に観察する
• 現場の感も大事にする
• 声にならない気持ちを洞察→なりきって考え抜く

"なりきって考え抜く"

これを継続していく

「解約予兆モデル」

99年にやっていてなかなか良かった。

ただ、5ヶ月待たないと予兆が示せなかった。

3ヶ月だと解約予兆がない人も含まれる、という問題があった。

目的は喜んでもらうための分析だということ

施策の響き具合は、すぐに変わっていく

なので、モデルの精度が良くても施策が良ければ、そっちが採用される

故にライトに施策を実行し、繰り返し改善していくのだ！

あとがき

過去の事例でしだか、docomoさんも凄いマーケッティングの勉強をされてて、縦組織の壁も徐々に崩して行ってるのかも？と思わせるような発表でした。

途中でお話があったように、利用者が喜ぶという目的で、組織間の潤滑油としての活動内容をこれからも公開していって欲しいです。

SIerは、この視点が不足してますからね。技術屋全般かもしれないです。