アジャイル,Trac,オープンソースなどの話。認定スクラムマスター。Twitterは@ryuzee
生産性や品質に問題のある現場の話を聞くと、だいたいの場合、会議のやり方が上手くない。成果を出すことが目的なのではなく、アリバイ作りだったり、会議をすること自体が目的化してしまっているケースが多々ある。
今回はそんな会議をなくし、より会議で成果を出しやすくするための方法を紹介する。なお全部出来てたらかなりすごい。
よくあるのが、会議の開始時間になると、席をたって移動し始めるパターンや、会議室には集まっているんだけど、プロジェクタのセッティングや資料の配布をそこから始めるパターン。
そうではなくて、定刻になったら本題を開始できるようにする。
たとえ、偉い人が参加する会議でも徹底して時間通りに始める。事前に不可避な事情について連絡がなくて会議に参加しない、または遅刻してきた場合は会議での決定事項はその場にいる人に委任したものと見なして良い。
ただ出席依頼が来ただけでは、会議に参加する前に、何を準備したら良いか、自分が発表するのか、どういう立場なのか全く分からない。
出席を依頼する側が期待するパフォーマンスを発揮できない可能性があり、お互いにとっての損失だ。
ゴールが満たせれば、例え会議室を1時間確保してたって、10分で終わって良い。
ゴールが明確でない会議はそもそも存在の必要性について考え直す必要がある。
進行役がひとこと「今日のゴールは◯◯です」といえばOK。会議中はゴールに関係ない話は誰もが軌道修正をかけて良い。
いくらゴールを明確にして会議を設定して、その場で意思決定を行ったとしても、結論を誤解していたり、聞き漏らしていたりするケースはやはりある。そして次回に向けたアクションを決めないと、せっかく会議で意思決定しても実行に移せなければ絵に書いた餅だ。
無駄な会議はリファクタリングする。たとえ30分の会議でも、参加者が10人いたら5時間分の人件費が掛かっていることになる。
プリンターをカラー印刷するな!とかいうよりも圧倒的にコスト削減、無駄の削減になる。
モノを削るのではなく、不要な時間を削って、投資効果の高いものに時間を使うべし。
原則的に意思決定権を持っている人、専門性ゆえに会議に必要な人、同じ案件の仕事をしているチームメンバーが入れば良い。
単に情報共有が目的ならば、あとから議事録でも送ればよい。
大量の人が参加したあげくに、それぞれが好きなことを言って会議が踊るのはよくあること。無駄。また、いつも発言しない人は会議には不要。呼ぶ必要もなし。
偉い人がアホなことをいって、咎められないような会議じゃ意味なし。
ゴールを達成することが目的なので、そこでの発言内容をネガティブな人事評価に利用しないこと。こういうことをやりだすとイエスマンばかりになり、会議が顔色伺いの場になり、組織の競争力が落ちる。
人間の脳は長時間集中できるようには出来ていないので、2時間とか3時間の会議を設定しない。学校の授業が小学校45分、大学でも90分なのには理由がある。
延長を許すとずるずる脇道に逸れたりしやすい。
またブレストのような会議はゴールが不明確なので、なんとなく延長すると時間を浪費するだけ。
そもそも人間の脳は朝起床後3時間くらいが一番働きやすく、夜に向かうに連れて疲れがたまり効率が落ちてくる。夜は時間が延びても良いから、とか昼間は忙しいから、とかいう理由で会議を設定する人もいるが、必要な会議なら日中の業務時間中に実施すれば良い。
家庭を犠牲にして良いと思ってる、または家庭に居場所がないオジサンにつきあって会議する必要なし。
Q:あなたは以下のどの理由でアジャイルではないのでしょうか?
以下から1つ以上選んでください。
a デイリースタンドアップミーティングしていない
b ペアプログラミングをしていない
c TDDをしていない
d 象徴となるような人を雇用していない
e スクラムマスターがいない
f イテレーション計画ミーティングをしていない
g インデックスカードを使っていない
答えはHで、上のどれでも無いです。プラクティスは「アジャイルであることを助ける」ための道具であって、それ以上ではない。
アジリティの意味するところは、頻繁に継続的に顧客のニーズにあった高品質なソフトウェアを届けることができる、ということに他ならない。
以下いくつかよくある例や思ったことの補足を。
技術評論社さん主催のAgile Conference Tokyo 2010に行ってきました。
スーツ率は半分くらいで、年齢層は30代から40代くらいの人が多かった感じで、いつものアジャイル系のイベントとは若干客層が違う感じかな。
頑張ってまとめようかとも思ったのだけど、その場で相当Twitしたし、かなりの内容をカバーしているかと思うので時系列で引用。
なお赤字は大事だと思うところ。
なんだかんだいって、マイクロソフトさんとIBMさんは別格だなぁ、と改めて思った。これはグローバルの強さでもある。
アジャイルの導入は難しい。これは事実だと思う。顧客もそうだし自社も変えなきゃいけない。現状をただ嘆くだけじゃなくて、あきらめず行動を起こしてすこしづつ変えられるかどうか。
| 今日は結構年齢層高い感じがするね #agiletokyo(2010-07-21 10:14:01) | link | |
| 会場前方のディスプレイに表示されちゃうからあんまり変なツイートできないじゃんw #agiletokyo(2010-07-21 10:18:34) | link | |
| MacBook公称10時間駆動! RT @hirsato: ところで、Twitter流すのはいいのですけど、みなさん電源もつんですかねぇ。 ^HS #agiletokyo(2010-07-21 10:25:59) | link | |
| 去年のコクヨホールのほうが見やすくてよかったです #agiletokyo(2010-07-21 10:27:19) | link | |
| アジャイルに興味はあるけどまだやってない、という人たちが多いのだろうかね。 #agiletokyo(2010-07-21 10:28:51) | link | |
| アジャイルコーチをしてて、ここ1年くらい大分潮流が変わったように見える。客層も以前と違ってきているようだし。 #agiletokyo(2010-07-21 10:34:31) | link | |
| つうかむしろウォーターフォールがなんでうまくいくと思うのかが不思議なんですがね。。 #agiletokyo(2010-07-21 10:39:00) | link | |
| 生産性だけじゃなくて、顧客ROIも語って欲しいですよ #agiletokyo(2010-07-21 10:40:02) | link | |
| Scrum of Scrumとか。玉川さんの本が日本語文献としては秀逸 #agiletokyo(2010-07-21 10:40:55) | link | |
| 一括請負契約とはなじまないなぁ、とは思う(準委任がいい)のだけど、もし一括請負しても内容の変更を顧客と随時できる関係にあるかどうか、顧客と同じゴールを向いているか、というのも大事だと思います #agiletokyo(2010-07-21 10:45:03) | link | |
| 英語だけでいいよw #agiletokyo(2010-07-21 10:46:42) | link | |
| 開発環境と本番環境やCI環境は揃える方がいいねー。仮想化が解決策だと思うよ #agiletokyo(2010-07-21 10:50:13) | link | |
| 常にリリース可能に! #agiletokyo(2010-07-21 10:52:58) | link | |
| 僕も紺屋(コーチ屋)の白袴なんですがね。。。 RT @rajun1971: ここ数日耳が痛い。。。 RT @Ryuzee: 常にリリース可能に! #agiletokyo(2010-07-21 10:57:35) | link | |
| CI使おう、ユニットテストと結合テスト、受け入れテストの自動化。言うは易し、行うは難しというのが日本の受託開発の現場でしょう。製品開発なら容易だけどね #agiletokyo(2010-07-21 11:00:23) | link | |
| いまの話ってVisual Studioの開発プロセスに似てるね #agiletokyo(2010-07-21 11:03:48) | link | |
| まぁ、アジャイル自体がそもそもリスクマネジメント手法であるといえる。 #agiletokyo(2010-07-21 11:05:24) | link | |
| 過去のいかなる環境(断面)も復元できるのが理想型だよね。 #agiletokyo(2010-07-21 11:07:35) | link | |
| コード書いたりテストするのが仕事なんじゃなくて、顧客のビジネス上の成果をあげるのを助けるのが仕事でしょ、と思います #agiletokyo(2010-07-21 11:15:09) | link | |
| ミルズさんとか! RT @yusukef: 翻訳者がCSMだと もっとこのPrinciplesが効果的に伝わりそうですね #agiletokyo(2010-07-21 11:15:37) | link | |
| それだけじゃないですが。顧客も参加してもらうと良いです。 RT @UnderClock: チーム全員がみんな参加してみたいなところがアジャイルなんですね。 (^_^) #agiletokyo(2010-07-21 11:18:23) |
link | |
| コマンド・コントロールからの脱却が必要 RT @materia_x64: 自分はこれだけしかやりません。他は知りませんってのもダメですね RT @diizuka: あなたはこれだけやればいい、という意識では駄目だよね #agiletokyo(2010-07-21 11:22:02) | link | |
| リーンにおけるラインの停止 RT @kyon_twit: 何かトラブルが起きたら、チーム全員が立ち止まること。一人で立ち向かったりしない。トラブル対処者が決まって初めてチームはもとの動きに戻ること。 #agiletokyo(2010-07-21 11:28:15) | link | |
| Fitnessとか使ったりしますね RT @kaorun55: 自動化された受け入れテストはイメージがわかない。どうやるんだろう? #agiletokyo(2010-07-21 11:29:20) | link | |
| いまのセッションにおいて気をつけないといけないことは、対象のプロジェクトが自社の製品開発や永続的に面倒を見るシステムなのか、作りきりの受託開発なのか、という点だろう。自動化のコストとROIを天秤にかけないと、際限なく自動化すると辛くなる。 #agiletokyo(2010-07-21 11:34:13) | link | |
| そうそう。ビジネス上の価値の実現のためにリリースする。 #agiletokyo(2010-07-21 11:39:03) | link | |
| 仮想化とかクラウド使えば大したコストではないと思います。得られるものとの比較でしょうね RT @diizuka: 本番環境を二組用意するコストを経営者が許してくれるかね #agiletokyo(2010-07-21 11:40:13) | link | |
| 振り返りとか反省がなきゃ、アジャイルではないと思います #agiletokyo(2010-07-21 11:42:45) | link | |
| 本でるんだ!翻訳したいねー #agiletokyo(2010-07-21 11:43:15) | link | |
| おー、以前玉川さんがTwitterで質問求めたパターンがメソッド化されてる。IBMさんさすがですねー #agiletokyo(2010-07-21 11:52:40) | link | |
| 大澤さんCSM同期ですねー #agiletokyo(2010-07-21 11:53:00) | link | |
| どうせなら玉川さんがやったもんたメソッドも使ったらさらに驚いたのにw #agiletokyo(2010-07-21 11:55:27) | link | |
| RTC Expressは10ユーザーまで無料です!(とつぶやき隊の前にいっておくw) #agiletokyo(2010-07-21 11:56:05) | link | |
| IBMにおける製品開発はかなりアジャイルが適用されているはず。確かアジャイルを採用するかどうかの判定メソッドもあるよね。公開してほしいなぁ #agiletokyo(2010-07-21 11:58:43) | link | |
| 以前玉川さんとも話したのだが、大規模開発と大人数開発は違うと思う。 #agiletokyo(2010-07-21 12:02:45) | link | |
| というかメールってコミュニケーションの道具ではすでにない、と思います。伝わったかどうか判らないUDPプロトコルみたいなもんでしょ #agiletokyo(2010-07-21 12:07:12) | link | |
| 通常、誰々が何何する、それによって何何を得る、という書き方をする RT @Kyoko_Hattori: 「Story」=顧客がわかる言葉で書かれた要求。一般的に2週間以内に実行できる要求の単位。 #agiletokyo(2010-07-21 12:22:41) | link | |
| プロダクトバックログのサンプルとか http://bit.ly/9TmDIM #agiletokyo(2010-07-21 12:26:36) | link | |
| NRIの人が質問中。もうアジャイルあきらめた感じじゃなかったっけか。。 #agiletokyo(2010-07-21 12:30:43) | link | |
| TFSも無償版だして欲しいなぁ #agiletokyo(2010-07-21 12:32:08) | link | |
| じゃあ、また@masayangの出番ですね! RT @samuraiRed: お客様の要望から熱を取り戻しつつありますよ~ RT @ryuzee: NRIの人が質問中。もうアジャイルあきらめた感じじゃなかったっけか。。 #agiletokyo(2010-07-21 12:34:34) | link | |
| しかし大手SIerがゼネコンモデルを維持するのは、レバレッジを多くかけられる、最後は2次請け以降を泣かせてでも利益を確保する、という考えのもとでそうしていて、今構造改革すると売上が減るんじゃないか、という変な危機感をえらい人が持っているんだよね。。。 #agiletokyo(2010-07-21 13:40:39) | link | |
| Scrum的には2~4週が1イテレーションですね。 #agiletokyo(2010-07-21 13:45:36) | link | |
| アジャイルを安い、早い、うまい、みたいに思われると困る #agiletokyo(2010-07-21 13:48:05) | link | |
| 大規模アジャイルだとアーキテクチャは前払いするのが定石ですねー RT @yoshidaei: だよなー、アーキテクチャってあまりYAGNIれない。アーキテクチャはagileの課題の一つ #agiletokyo(2010-07-21 14:01:44) | link | |
| そうそう。アジャイルでやったからって100%成功するわけじゃない(銀の弾丸じゃない)。これもエライ人は誤解したりする #agiletokyo(2010-07-21 14:05:09) | link | |
| えらい人たちはあと数年逃げ切ればよいだけだから RT @wasaist: 一次受けは全然変わってないなぁ。事業部長クラスはセキュリティ面とかのリスク以外、昔のPJの進め方から変わってくれない。 #agiletokyo(2010-07-21 14:07:26) | link | |
| 紙ばっか書いて人が作ったものの良し悪しを判断できる能力があまりついてなく、数値的な指標偏重で見ざるを得ないようになってるから RT @wasaist: 最近、システムインテグレータが丸投げしてくるのも原因な気がします。PJ管理だけで開発したことがないから、#agiletokyo(2010-07-21 14:25:40) | link | |
| フェーズ型ウォーターフォールに見えたけど、アジャイル開発ではなく、アジリティ開発と言われれば多少納得かも。 #agiletokyo(2010-07-21 14:39:17) | link | |
| 次のアジャイルソフトウェアプロジェクトに使える10の契約 http://bit.ly/93lTtB これみるといいよ #agiletokyo(2010-07-21 14:40:16) | link | |
| アジャイルプロセスへの期待に、顧客満足度とか顧客ROIは出てこないの?そこはすごい違和感だなぁ #agiletokyo(2010-07-21 14:44:46) | link | |
| この絵だと顧客テストって最後しかないじゃん?ずっと毎イテレーションごととか数イテレーションごとにやれば良いのに・・・ #agiletokyo(2010-07-21 14:48:28) | link | |
| あ、イテレーション中に顧客テストあるのか。 #agiletokyo(2010-07-21 14:52:25) | link | |
| Macbookのバッテリーがなくなった。。。以降iPhoneへ移行(2010-07-21 14:58:02) | link | |
| いや、大規模アジャイルだと定番ですね RT @materia_x64: 各チームにスクラムマスターとかキツくない? #agiletokyo(2010-07-21 14:59:01) | link | |
| @m_seki あ、そうですね。動くモノを常に顧客が触れる必要はあります。顧客の受け入れテストというコンテキストだとスプリントレビューでのデモとそこからの顧客側の精査かなーともおもうんですが。(2010-07-21 16:20:17) | link | |
| 残念だが顧客もまだまだ予算主義。 RT @miholovesq: Jezさんの話は理想的。でも競合他社に「この金額で全部やります!」ってやられちゃうと負けるんだよなあ…。ユーザーメリットで説得したい。 #agiletokyo(2010-07-21 17:58:38) | link | |
| 個人的には明らかに他社とは違う生産性と品質を顧客に先に見せられるか。差別化ポイントをみせてこそ、交渉もできようと思ったり。 #agiletokyo(2010-07-21 18:01:55) | link | |
| そもそもSIってのが日本独特で、海外はかなりの割合で自社主導の開発してるからなぁ #agiletokyo(2010-07-21 18:09:13) | link | |
| パネルディスカッションみるかぎり、みんな同じ問題を抱えているような感じだねー。 #agiletokyo(2010-07-21 18:11:52) | link |
まぁまだまだこれからなんだけど、せっかくMacにしたしTracのiPhone用クライアントを作っている。
これを作れば、外出先で、いちいちSafariの小さい画面でなくてもチケットの状況が把握できるし、電車の中で、「ふむふむ、まだこのチケット残っているから今日着手しなきゃ」みたいなことができるかなと。
とりあえずTracのXMLRPCを使ってデータとったり編集したりするところは出来ているが、細かい使い勝手とかカスタマイズ機能とかをこれから追加していく予定。当分電車内コーディングが楽しみではある。
一番大きな問題は、自分がCを忘れているということだったりして・・・。
個人的な感想
・やっぱりVisual StudioとかDelphi使ってWindowsアプリ作る方が簡単
・Xcodeの画面操作にまだ慣れない
・Androidアプリの方が、言語の敷居が低いかも。これは会社の人がAndroidアプリ作っているのを見る限りだが。
Slideshareを見ていたら偶然見つけたのでご紹介。
心当たりがあったら注意しよう!
ということでslideshareにSalesforceのアジャイル適用状況に関するスライドがのっていたのでご紹介。
ちなみに資料自体は2008年にストックホルムで行われたScrum Gatheringで発表されたものである。
以下に特徴などを適当訳でご紹介。
前回のベロシティの話の続き。書ききれていなかった話をつらつらと。
ベロシティとは何かというと、チームが相対的に見積もったストーリーにおける1スプリント中に完了したストーリーポイントの合算値のことである。
チームや案件によって何を1ストーリーポイントにするかは異なる。
例えば基準値の決め方としては、一番小さいと思われるストーリーを抽出し、それを1とするやり方や、基準値を決めるときだけ、2日間と5日間で終わると思うストーリーを抽出し、それを2および5のストーリーポイントとして定義する(注:ただし以降の計算時には一切ストーリーポイントを日付や時刻に変換するようなことはしないこと)といったようなやり方がある。
スクラムにおける見積もりの特徴は、見積もりをコストや体制や時間と直接リンクさせないことにある。チームは規模の見積もりをプランニングポーカーを使って行うのが一般的だが、この際、参加者が意思表示できるのは、見積もり対象のストーリーが、基準ストーリーと比較して何倍くらいなのか?という点のみである。
そこには、「自分が作ると8時間だが、スペシャリストの上司が作ると4時間で、外部の業者さんに発注すると16時間になるので、どうしようか?」みたいなブレは存在しない。誰にとってもストーリーポイント2のストーリーはストーリーポイント1の2倍(くらい)の規模であり、ストーリーポイント5のストーリーは5倍(くらい)ということになる。
もう答えは書いてしまっているが、チームによってストーリーポイント1の基準が異なるからである。
そして異なる基準の数値を比較するための変換係数を用意することは、作っているモノが異なり問題領域も異なるのであるから、極めて困難だし、たとえ定めたとしても妥当性の評価をしようがない。
唯一比較しやすそうなケースとしては、1つのプロダクトバックログを複数のチームで実装していくようなScrum of Scrumのケースで、この場合は基準となるストーリーポイントは同一で、Doneの定義も同じであるから、異なるプロジェクト間よりは比較しやすい。
前回の記事のパターンと良く似たことが起こる。すなわちストーリーポイントのインフレが起こる。他のチームより数字が多ければ良いからだ。
インフレが続くと、「統一した単位で数値を計算するように」などということを言い出す人がいるかもしれない。その際に絶対さけるべきであるのに使われてしまう単位は「時間」である。こうなるとウォーターフォールの問題点に逆戻りだ。
比較という点でよく聞かれるのが、「ウォーターフォールとアジャイルでの生産性の比較はどうしたら良いんですか?」という質問だ。
これも上のパターンと同じ。変換係数がないのだから一意に比較できない。
僕のおすすめは、顧客に満足度を聞きにいく、チームのメンバーの満足度を調査する、といった関わっている人にフォーカスをあてるものだ。
7/7に新宿のMicrosoftさんで実施された第7回Shibuya.tracにて話をしてきましたので、資料をアップしておきます。
基本的にはネタなんですが、IIS7はオープンソースのアプリケーションとの親和性がかなりあがっていて、FastCGIでPHPアプリケーションなら大抵動作し、PythonやRubyも動作します、ということと、マイクロソフトさんがVisual Studio ExpressやWeb Platform Installerなど無償のツールを公開しているよ、というあたりはお伝えできたかなと思います。
勢いで、IIS上でネイティブで動作するTrac for IISを作るよ、と宣言してしまった気がするので今後頑張ります(たぶん)
現実から得られるベロシティの実績値をもとに、次のスプリントでそれよりも大きい目標ベロシティを設定することはおすすめではない。
それは以下の理由からだ。
- そもそもチームの実績としての指標データであるベロシティが目標値として設定されることによって、チームがその目標に到達しなかった場合にチームに何か問題が発生しているようにとらえてしまう。
- もちろん継続的な改善によってチームのベロシティは一般的には初期のスプリントから中盤にかけては向上する傾向にはあるけれど、それはあくまで結果としての指標データである。
- 目標ベロシティを決めて、かつ、それをコミットしてしまった場合、往々にして、数字を満たすために、テストの手抜きをしたりリファクタリングするのをやめて目先の数字を追ってしまうことが多い。
- いくつかのスプリントをこなせば、チームとしての生産力は見えてくるので、数字をコミットさせるのではなく、チームの人数やリリース計画についての再検討を行っていくべきである。
- 僕のおすすめは、スプリントにおけるベースとなるベロシティの値は、前のスプリントの結果と同じにするか、前の数スプリントの平均的な値を取ることだ。もちろんチームの成長曲線もあるので、スプリントの期間を残してすべてのストーリーが完了することもあるだろう。しかしそれはそれで十分であり、チームの精神衛生的にも非常に良い。人間は通常追われるとプレッシャーを抱え、作業効率や品質が低下しやすい(まったく期日が設定されないのも作業効率があがらないが・・・)
そして、あまった時間で次のスプリントで実施予定のストーリーのうち、残り期間で終わりそうなものに再度着手する(=おかわり)のが良い。
また往々にして、ベロシティはインフレを起こしやすい。これはどのチームでも起こりうる。
- インフレを起こす原因として、上記に書いたような、目標ベロシティが設定されているため、それを成し遂げようとすること
- チームは成功している、と周りに思わせたい欲求があるので、達成したベロシティが水増しされやすい
ウォーターフォールがなぜ駄目なのか、というと、一番最初にたてた適当な計画が絶対的に正しいものとして扱われてしまうことだ。
たとえそれがとてつもなく無理な計画であっても、目標値として設定される。目標として設定されてしまえば、後は数字を満たすためにはなんでもありの世界だ。
ウォーターフォールでの失敗をアジャイルな開発に持ち込んではいけない。
透明性を保ち、常に評価、調整を繰り返すためには、ベロシティを目標にしてはいけない。
目標にするのは顧客の価値を創出することである。
ということで、今回もMicrosoftさん主催のアジャイルイベントであるAgile Dayで話をしてきました。
第一回から本編発表も含め発表をコンプリートです。
一応アジャイルコーチの端くれとして、本や人から聞いた知識のほかにも現場で気づいたり気づかされたりする知識がいっぱいあるわけで、そういう項目をまとめたら100個近くあったのですが、今回は30個ほどご紹介です。
あんまり時間がなかったので表面的な字面以外の背景みたいなところは説明できていませんが、経験するうちに分かるようになるから大丈夫だということであまり補足はしません。
ちなみにプレゼンは、セミナーの中で話に出たプレゼンテーションZenを参考に作ってます。これ読むと作るプレゼンがすごい変わります!
著者/訳者:Garr Reynolds ガー・レイノルズ
出版社:ピアソンエデュケーション( 2009-09-07 )
定価:¥ 2,415
Amazon価格:¥ 2,415
ペーパーバック ( 255 ページ )
ISBN-10 : 4894713284
ISBN-13 : 9784894713284
日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有