Ryuzee.com

生産性や品質に問題のある現場の話を聞くと、だいたいの場合、会議のやり方が上手くない。成果を出すことが目的なのではなく、アリバイ作りだったり、会議をすること自体が目的化してしまっているケースが多々ある。
今回はそんな会議をなくし、より会議で成果を出しやすくするための方法を紹介する。なお全部出来てたらかなりすごい。

1. 時間通りに開始する

よくあるのが、会議の開始時間になると、席をたって移動し始めるパターンや、会議室には集まっているんだけど、プロジェクタのセッティングや資料の配布をそこから始めるパターン。
そうではなくて、定刻になったら本題を開始できるようにする。
たとえ、偉い人が参加する会議でも徹底して時間通りに始める。事前に不可避な事情について連絡がなくて会議に参加しない、または遅刻してきた場合は会議での決定事項はその場にいる人に委任したものと見なして良い。

2. 会議を開催する際には、会議の趣旨、ゴール、出席希望者を明示する

ただ出席依頼が来ただけでは、会議に参加する前に、何を準備したら良いか、自分が発表するのか、どういう立場なのか全く分からない。
出席を依頼する側が期待するパフォーマンスを発揮できない可能性があり、お互いにとっての損失だ。

3. 会議の冒頭では、その会議におけるゴールを確認する

ゴールが満たせれば、例え会議室を１時間確保してたって、１０分で終わって良い。
ゴールが明確でない会議はそもそも存在の必要性について考え直す必要がある。
進行役がひとこと「今日のゴールは◯◯です」といえばOK。会議中はゴールに関係ない話は誰もが軌道修正をかけて良い。

4. 会議の終わりには、その会議における決定事項と、宿題事項を再確認する

いくらゴールを明確にして会議を設定して、その場で意思決定を行ったとしても、結論を誤解していたり、聞き漏らしていたりするケースはやはりある。そして次回に向けたアクションを決めないと、せっかく会議で意思決定しても実行に移せなければ絵に書いた餅だ。

5. 会議は定期的に不要かどうかの判断をする

無駄な会議はリファクタリングする。たとえ３０分の会議でも、参加者が１０人いたら５時間分の人件費が掛かっていることになる。
プリンターをカラー印刷するな！とかいうよりも圧倒的にコスト削減、無駄の削減になる。
モノを削るのではなく、不要な時間を削って、投資効果の高いものに時間を使うべし。

6. 会議に関係ありそうだから、という理由で大量の人を呼ばない

原則的に意思決定権を持っている人、専門性ゆえに会議に必要な人、同じ案件の仕事をしているチームメンバーが入れば良い。
単に情報共有が目的ならば、あとから議事録でも送ればよい。
大量の人が参加したあげくに、それぞれが好きなことを言って会議が踊るのはよくあること。無駄。また、いつも発言しない人は会議には不要。呼ぶ必要もなし。

7. ゴールの達成のため、職場の職位を会議に持ち込まない

偉い人がアホなことをいって、咎められないような会議じゃ意味なし。
ゴールを達成することが目的なので、そこでの発言内容をネガティブな人事評価に利用しないこと。こういうことをやりだすとイエスマンばかりになり、会議が顔色伺いの場になり、組織の競争力が落ちる。

8. 長時間の会議を設定しない

人間の脳は長時間集中できるようには出来ていないので、２時間とか３時間の会議を設定しない。学校の授業が小学校４５分、大学でも９０分なのには理由がある。

9. 会議の時間は延長しない

延長を許すとずるずる脇道に逸れたりしやすい。
またブレストのような会議はゴールが不明確なので、なんとなく延長すると時間を浪費するだけ。

10. 就業時間後に会議を設定しない

そもそも人間の脳は朝起床後３時間くらいが一番働きやすく、夜に向かうに連れて疲れがたまり効率が落ちてくる。夜は時間が延びても良いから、とか昼間は忙しいから、とかいう理由で会議を設定する人もいるが、必要な会議なら日中の業務時間中に実施すれば良い。
家庭を犠牲にして良いと思ってる、または家庭に居場所がないオジサンにつきあって会議する必要なし。

Q:あなたは以下のどの理由でアジャイルではないのでしょうか？
　以下から１つ以上選んでください。
　a デイリースタンドアップミーティングしていない
　b ペアプログラミングをしていない
　c TDDをしていない
　d 象徴となるような人を雇用していない
　e スクラムマスターがいない
　f イテレーション計画ミーティングをしていない
　g インデックスカードを使っていない

答えはHで、上のどれでも無いです。プラクティスは「アジャイルであることを助ける」ための道具であって、それ以上ではない。
アジリティの意味するところは、頻繁に継続的に顧客のニーズにあった高品質なソフトウェアを届けることができる、ということに他ならない。

以下いくつかよくある例や思ったことの補足を。

• RedmineとかTracとかJIRAとかRTCとかTFSみたいなWeb系のアジャイル支援ツール使っている＝アジャイルである、というわけではない。ツールは道具であり、価値の実現に寄与して初めて価値があるといえる。
• 従って、自分たちにとって価値の実現に寄与できる！と思う機能は現場ごとにも違うだろうし、ツールの全ての機能を使う必要性はない
• ツールの機能は一般的に「最高にうまくいっているチームはこうしてるよ！」というモデルをベースにして開発されるので、チームの成熟度が低いうちにツール化に走ると、かえって混乱に陥る可能性もある。もちろんツールをうまく使いこなせると生産性はあがる。
• TDDやCIやペアプロはウォーターフォールにだって適用できるし、やっている現場は多々ある。アジャイルにおけるプラクティスがウォーターフォールにおいて排他なわけではない
• 一気に完璧なチームが出来上がるわけではなく、チームのアジリティの向上はプロジェクトを通じて改善のループを回して、反映していけるかどうかである。
• 現状がうまくいっていても、もっとうまくいくかもしれない。改善をやめた時点で、思考停止→組織の力が衰退していく
• そういう意味でも、アジャイルな開発プロセスを、書面で標準化して守らせよう、というアプローチを全面的に採用しない方が良いだろう。マイクロソフトにおけるVisual Studioの開発は多数のチームから構成される大規模分散開発だが、最低限のルールと品質チェック項目（クオリティーゲート）以外については、各スクラムチームの裁量が多い

技術評論社さん主催のAgile Conference Tokyo 2010に行ってきました。
スーツ率は半分くらいで、年齢層は30代から40代くらいの人が多かった感じで、いつものアジャイル系のイベントとは若干客層が違う感じかな。
頑張ってまとめようかとも思ったのだけど、その場で相当Twitしたし、かなりの内容をカバーしているかと思うので時系列で引用。
なお赤字は大事だと思うところ。
なんだかんだいって、マイクロソフトさんとIBMさんは別格だなぁ、と改めて思った。これはグローバルの強さでもある。

アジャイルの導入は難しい。これは事実だと思う。顧客もそうだし自社も変えなきゃいけない。現状をただ嘆くだけじゃなくて、あきらめず行動を起こしてすこしづつ変えられるかどうか。

まぁまだまだこれからなんだけど、せっかくMacにしたしTracのiPhone用クライアントを作っている。
これを作れば、外出先で、いちいちSafariの小さい画面でなくてもチケットの状況が把握できるし、電車の中で、「ふむふむ、まだこのチケット残っているから今日着手しなきゃ」みたいなことができるかなと。

とりあえずTracのXMLRPCを使ってデータとったり編集したりするところは出来ているが、細かい使い勝手とかカスタマイズ機能とかをこれから追加していく予定。当分電車内コーディングが楽しみではある。
一番大きな問題は、自分がCを忘れているということだったりして・・・。

個人的な感想
・やっぱりVisual StudioとかDelphi使ってWindowsアプリ作る方が簡単
・Xcodeの画面操作にまだ慣れない
・Androidアプリの方が、言語の敷居が低いかも。これは会社の人がAndroidアプリ作っているのを見る限りだが。

Slideshareを見ていたら偶然見つけたのでご紹介。

1. スプリントバックログの項目ではないタスクをやり続けること
2. 妨害事項を隠してしまうこと
3. スプリント中はプロダクトオーナーと決して会話しないこと
4. Doneの定義を無視すること
5. スプリントバックログの前で、「俺やることないや」ということ
6. スプリントレビューのわずか５分前から準備を始めること
7. スプリント期間中全部を使ってしまうほどのタスクを小さいタスクに分割しないこと
8. いつも遅刻すること
9. 次にどのタスクをするべきかいつもスクラムマスターに聞くこと
10. スクラムミーティングで関係ない話をしたり、誰かと電話していること

心当たりがあったら注意しよう！

ということでslideshareにSalesforceのアジャイル適用状況に関するスライドがのっていたのでご紹介。
ちなみに資料自体は2008年にストックホルムで行われたScrum Gatheringで発表されたものである。

以下に特徴などを適当訳でご紹介。

• Adaptive Development Methodologyと名付けたScrumとXPを利用したSalesforce用のメソッドを策定
• 自己組織化、継続的統合、Seleniumでのテスト、タイムボックス、リファクタリング、ユーザーストーリー、ジャスト・イン・タイム、コードレビュー、いつでもリリース可能、技術的負債なし
• 30名のスクラムマスターを認定スクラムマスター研修に参加させ、35名のプロダクトマネージャを認定プロダクトオーナー研修に参加させた
• スクラムマスターとプロダクトオーナーが週に一度集まって交流できる場を作った
• このメソッドに関する社内用のWebサイトをwikiで作成した
• 常に改善を続けている
• 経営層から変化させることに対してコミットを貰うことは重要
• 自動化を進める（2008年の時点でかばれーじは72.8%）

前回のベロシティの話の続き。書ききれていなかった話をつらつらと。

ベロシティとは

ベロシティとは何かというと、チームが相対的に見積もったストーリーにおける１スプリント中に完了したストーリーポイントの合算値のことである。

ストーリーポイントとは

チームや案件によって何を１ストーリーポイントにするかは異なる。
例えば基準値の決め方としては、一番小さいと思われるストーリーを抽出し、それを１とするやり方や、基準値を決めるときだけ、２日間と５日間で終わると思うストーリーを抽出し、それを２および５のストーリーポイントとして定義する（注：ただし以降の計算時には一切ストーリーポイントを日付や時刻に変換するようなことはしないこと）といったようなやり方がある。
スクラムにおける見積もりの特徴は、見積もりをコストや体制や時間と直接リンクさせないことにある。チームは規模の見積もりをプランニングポーカーを使って行うのが一般的だが、この際、参加者が意思表示できるのは、見積もり対象のストーリーが、基準ストーリーと比較して何倍くらいなのか？という点のみである。
そこには、「自分が作ると８時間だが、スペシャリストの上司が作ると４時間で、外部の業者さんに発注すると１６時間になるので、どうしようか？」みたいなブレは存在しない。誰にとってもストーリーポイント２のストーリーはストーリーポイント１の２倍（くらい）の規模であり、ストーリーポイント５のストーリーは５倍（くらい）ということになる。

で、なんでベロシティを他のチームと比較してはいけないのか？

もう答えは書いてしまっているが、チームによってストーリーポイント１の基準が異なるからである。
そして異なる基準の数値を比較するための変換係数を用意することは、作っているモノが異なり問題領域も異なるのであるから、極めて困難だし、たとえ定めたとしても妥当性の評価をしようがない。
唯一比較しやすそうなケースとしては、１つのプロダクトバックログを複数のチームで実装していくようなScrum of Scrumのケースで、この場合は基準となるストーリーポイントは同一で、Doneの定義も同じであるから、異なるプロジェクト間よりは比較しやすい。

それでもチーム間で比較するとどうなるのか？

前回の記事のパターンと良く似たことが起こる。すなわちストーリーポイントのインフレが起こる。他のチームより数字が多ければ良いからだ。
インフレが続くと、「統一した単位で数値を計算するように」などということを言い出す人がいるかもしれない。その際に絶対さけるべきであるのに使われてしまう単位は「時間」である。こうなるとウォーターフォールの問題点に逆戻りだ。

派生パターン

比較という点でよく聞かれるのが、「ウォーターフォールとアジャイルでの生産性の比較はどうしたら良いんですか？」という質問だ。
これも上のパターンと同じ。変換係数がないのだから一意に比較できない。
僕のおすすめは、顧客に満足度を聞きにいく、チームのメンバーの満足度を調査する、といった関わっている人にフォーカスをあてるものだ。

7/7に新宿のMicrosoftさんで実施された第７回Shibuya.tracにて話をしてきましたので、資料をアップしておきます。

基本的にはネタなんですが、IIS7はオープンソースのアプリケーションとの親和性がかなりあがっていて、FastCGIでPHPアプリケーションなら大抵動作し、PythonやRubyも動作します、ということと、マイクロソフトさんがVisual Studio ExpressやWeb Platform Installerなど無償のツールを公開しているよ、というあたりはお伝えできたかなと思います。

勢いで、IIS上でネイティブで動作するTrac for IISを作るよ、と宣言してしまった気がするので今後頑張ります（たぶん）

現実から得られるベロシティの実績値をもとに、次のスプリントでそれよりも大きい目標ベロシティを設定することはおすすめではない。

それは以下の理由からだ。

• そもそもチームの実績としての指標データであるベロシティが目標値として設定されることによって、チームがその目標に到達しなかった場合にチームに何か問題が発生しているようにとらえてしまう。
• もちろん継続的な改善によってチームのベロシティは一般的には初期のスプリントから中盤にかけては向上する傾向にはあるけれど、それはあくまで結果としての指標データである。
• 目標ベロシティを決めて、かつ、それをコミットしてしまった場合、往々にして、数字を満たすために、テストの手抜きをしたりリファクタリングするのをやめて目先の数字を追ってしまうことが多い。
• いくつかのスプリントをこなせば、チームとしての生産力は見えてくるので、数字をコミットさせるのではなく、チームの人数やリリース計画についての再検討を行っていくべきである。
• 僕のおすすめは、スプリントにおけるベースとなるベロシティの値は、前のスプリントの結果と同じにするか、前の数スプリントの平均的な値を取ることだ。もちろんチームの成長曲線もあるので、スプリントの期間を残してすべてのストーリーが完了することもあるだろう。しかしそれはそれで十分であり、チームの精神衛生的にも非常に良い。人間は通常追われるとプレッシャーを抱え、作業効率や品質が低下しやすい（まったく期日が設定されないのも作業効率があがらないが・・・）
  そして、あまった時間で次のスプリントで実施予定のストーリーのうち、残り期間で終わりそうなものに再度着手する（＝おかわり）のが良い。

また往々にして、ベロシティはインフレを起こしやすい。これはどのチームでも起こりうる。

• インフレを起こす原因として、上記に書いたような、目標ベロシティが設定されているため、それを成し遂げようとすること
• チームは成功している、と周りに思わせたい欲求があるので、達成したベロシティが水増しされやすい

ウォーターフォールがなぜ駄目なのか、というと、一番最初にたてた適当な計画が絶対的に正しいものとして扱われてしまうことだ。
たとえそれがとてつもなく無理な計画であっても、目標値として設定される。目標として設定されてしまえば、後は数字を満たすためにはなんでもありの世界だ。
ウォーターフォールでの失敗をアジャイルな開発に持ち込んではいけない。

透明性を保ち、常に評価、調整を繰り返すためには、ベロシティを目標にしてはいけない。
目標にするのは顧客の価値を創出することである。

ということで、今回もMicrosoftさん主催のアジャイルイベントであるAgile Dayで話をしてきました。
第一回から本編発表も含め発表をコンプリートです。

一応アジャイルコーチの端くれとして、本や人から聞いた知識のほかにも現場で気づいたり気づかされたりする知識がいっぱいあるわけで、そういう項目をまとめたら100個近くあったのですが、今回は30個ほどご紹介です。
あんまり時間がなかったので表面的な字面以外の背景みたいなところは説明できていませんが、経験するうちに分かるようになるから大丈夫だということであまり補足はしません。

ちなみにプレゼンは、セミナーの中で話に出たプレゼンテーションZenを参考に作ってます。これ読むと作るプレゼンがすごい変わります！

« 前の記事 

日記 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 情報共有