月別アーカイブ: 2012年8月

UltimateAgileStories1で書いた内容

最近、UltimateAgileStories Iteration2(UAS2)のエントリ([雑多]UltimateAgileStories Iteration2が届きました)を書きましたが、その1冊目・・・「UltimateAgileStories Iteration1(UAS1)」で書いた内容を原文のまま公開します(少し長めです)。
これをきっかけにRxTstudyなどを始め、お話する機会を多く得ることができました。またコミュニティ活動にも積極的に関わっていったのもこれがきっかけの1つでした。

最後にベースにお話したスライドへのリンクがあります。

題名:Redmineと私

自己紹介

題名が中学生の作文みたいですが…良いのが思いつかなかったのでこのまま行きます。
初めまして(またはそうでない方、こんにちは)、@yohhatuという者です。
大阪在住でとあるSIer所属です。

「お客様も自分達もハッピーにして、かつ、より良い価値を届けるか?」を日々考えています。
チームビルディングやファシリテーションに重きを置いていて、「自分は”スクラムマスター”的なことをしたいんだ」と最近気づきました。

こんな者です。
しばらくお付き合いください。

なぜこのお題にしたか?

今のプロジェクトでは「開発の三種の神器」と言われるITS/CI/SCMを使って開発しています。
ITSはRedmine、CIはJenkins、SCMはSVNです。

その中でもRedmineは(いくつかのPJで)4年近く使っており、その使い方、成果や課題を伝えたいと思ったためです。
構成は、主なプロジェクト(3つ)毎に「特徴」「使い方」「成果」「課題」として書いています。

最初のプロジェクト:X

【特徴】
メンバーは約6人。
お客様内のWebシステム新規構築というものでした。
このPJで初めてRedmineを使いました。

開発プロセスは(弊社のほとんどのPJで採用されているウォーターフォールでなく)、いくつかの機能群でグルーピングし、それらの完成を1つのイテレーションとする反復形式のプロセスでした。

このPJでは割と弊社標準を使わないでやってみよう…という雰囲気があったのか、課題管理、不具合管理も(弊社標準のExcelではなく)、Redmineを利用することにしました。
これがきっかけです。
ただ当時のRedmineは諸事情があり、カスタマイズやプラグインを自由に入れることができませんでした。

【使い方】
1:WBSの1つを1チケットとし、進捗管理をチケットレベルで行いました。
ただし、お客様やマネージャーとの共有のため、大/中日程レベルの進捗管理はExcelのガントチャートとして存在していました。

2:(WBSレベルの)タスク、不具合、仕様検討項目、課題等は全て同じレベルのチケットで管理し「トラッカー」で区別しました。

3:カスタムクエリで『前営業日に作成されたチケット』『未対応バグ』『課題一覧』などを使い「(こういう時には)このクエリを見ればOK」という工夫をしました。

4:「バージョン」をイテレーションの単位としました。

【成果】
1:(Excelと比較して)タスクや課題が『チームで管理する』ものになったため、リーダーに(不要な)負荷がかからず、本来のタスクに集中することができました。

2:進捗管理にガントチャートを使った際に、陥りがちなマイクロマネジメントにならず、イテレーション単位での大枠の進捗管理ができ、大きな問題になりませんでした。結果、これもリーダー(管理者)の負担軽減に役立ちました。

3:そのイテレーションで得た知見などを次のイテレーションにすぐに反映することができ、見積精度や品質が上がりました。

【課題】
1:チケット1つがWBS1つだったため、粒度が大きすぎたチケットがありました。
結果、そのチケットのアクティブな期間が長くなり「いつ終わる」「どうなっている?」ということが、チケット上で見えにくいことが何度かありました。
改善として、「チケットの予定工数は長くても1日、通常2.5時間程度に区切ってみる」と変えてみることにしました。

2:チケットと(弊社でよく使う)『付箋にタスクを書き出して見える化する』方法を共存したため、その棲み分けが難しかったことがありました。
改善として、(自分が関係して、Redmineをガッツリ使ったPJでは)開発タスクに関しては付箋に書き出さないことにしました。

【全般】
BTSとしては十分機能していましたが、チケット駆動開発としてはまだまだ使いこなせておらず、工夫が必要な感じでした。
ただ、メンバーがRedmine(とそれを中心にしたPJの進め方)に慣れて経験したことは、次のPJで大きく役立ちました。

改善を試みたプロジェクト:Y

【特徴】
Xプロジェクトと同じお客様、技術要素、ほぼ同じメンバー(4人)で、これまたお客様内のWebシステム新規構築というものでした。
開発プロセスは(ほぼ)Agile開発で、RedmineをITSとして全面的に利用することにしました。

【使い方】
Xプロジェクトでの運用をベースにし、課題などを改善して、使っていきました。
1:チケットは(WBSレベルより)細かく、最大でも2.5時間程度に分割して作成しました。
ガントチャートはマイルストーンのみを表記したレベルで簡略化しお客様と共有しました。

2:イテレーション毎にお客様に動く機能を見てもらい、フィードバックを得て、次のイテレーションのチケットとして登録するようにしました。

3:お客様には(Scrumにおける)プロダクトオーナー(PO)の役割を説明し、優先順位の検討、チケットの取捨選択、お客様内の調整などを積極的に動いてもらうようにしました。
Redmineそのものは共有していませんでしたが、エクスポートすることでほぼリアルにチケット一覧を見ている状態にしていました。

【成果】
1:「着手する前に、とにかくチケットを登録しましょう。結果、しなくなってもかまわないので」という考えが浸透したため、タスク漏れ等がほとんどなかった
※前回のXプロジェクトとメンバーがほぼ同じだったため、浸透しやすかったです。

2:チケットの登録はメンバー全員ができ、また、やりたいチケットを(自分で)アサインする方式にしたので、(ある程度は)「自律的なチーム」になりました。
ここでは言い出しっぺが損をしない工夫をしました。

3:イテレーション毎にお客様に見てもらっていたので、WFの開発プロセスにありがちなシステムテスト、ユーザテストなどで(仕様齟齬などによる)「仕様追加/変更」がほぼありませんでした。
この点は「こんなにスムーズに行ったのは初めて」と評価されました。

4:お客様が(弊社へ)丸投げでなく、その役割を果たしてくれました。そのため、PJを通じて「問題vs私達(弊社+お客様」という動きができました。
そこには「押し付け合い」や「お客様対自分達」「誰かが言うだろう」という雰囲気はありませんでした。

この土台には、チームメンバー間、弊社とお客様間の信頼関係があってこそで、Xプロジェクトでの経験が大きく役立ちました。

【課題】
1:(細かなガントチャートを作っていなかったため)細かな進捗を好むマネージャから「何が進んでいて、遅れているか分かりづらい」との声がありました。
これに対しては「イテレーション単位で確認している」「細かな進捗はチームで管理するので、それよりも別のことにリソースを使って欲しい」などを話し合い、役割分担することで解決しました。
※当時は標準のガントチャート以外にそのような進捗を表現する機能がなかったためです。

2:お客様POが(別の職務で)多忙時に、進捗のボトルネックになったこともありました。
対策として、マイルストーンに「Best」と「Better」の2つのポイントを作り、バッファを持たせ、「待ち」が発生しても別のチケットをやるなどリソースを効率良く使うことを工夫しました。

現在のプロジェクト:Z

【特徴】
社内向けにフレームワークやそれに関するツール群の開発、またそれらの導入支援などを行っています。
メンバー10人ほど…東京、大阪に分かれて…で、何度かのリリースを行っており、現在も進行中です。

開発プロセスはAgile開発のScrumの要素を多く取り入れています。
RedmineをITSとして、さらにチケット駆動開発を意識して、全面的に利用しています。

【使い方】
1:(これまでの2つのPJと異なり)Redmine自体の管理者権限を持っているため、Redmine本体のカスタマイズやプラグインの導入を積極的に行っています。
その運用方針も、柔軟に改善していくサイクルになっています。

2:主に使っているプラグインですが、その1つは「見える化を強化する」類のものです。 ロードマップの強化やバーンダウンチャート、ベロシティ、ニコニコカレンダーなどです。
もう1つは生産性の向上で、「開発の三種の神器」を相互連携させるプラグイン…ソースコードレビューやJenkinsとの連携…を入れています。

3:(基本的に)1ヶ月をイテレーションとし、終了時にフリカエリと次のイテレーションのタスクばらしを行っています。
この時点で大まかにしか分からない機能は親チケットとして登録し、詳細が分かる、調査する時期に来たら、その段階で子チケットとして登録する形式にしています。

4:チケットには「Doneの定義」を記述し、またその作業ログが残すように運用しています。
まだ全てのチケットで、できているわけではありません。

5:「ステータス」遷移は「未着手→着手→レビュー待ち→完了」というようなシンプルな形にしています。
「進捗率」はチームとしては利用していません。

6:朝会では「活動」「バーンダウンチャート」「ニコニコカレンダー」を使いながら行っています。

【成果】
1:Redmineを中心にした「開発の三種の神器」とその土台となるプロセス、マインドがチーム全体に行き渡っているため、生産性と品質が高い状態を維持できています。
また、チームの雰囲気も(最初から良かったのですが)良い状態を保っています。

2:チケットにDoneの定義、仕様検討の結果などがまとめられて、情報の集約が進みました。

3:(まだ改善の余地はありますが)このPJ以外で使っている時間が明確になり、ベロシティが安定してくるようになりました。

【課題】
1:RedmineやAgile開発プロセスに慣れていないメンバーの増減が何度かあり、またそういうプロセスの導入を(一気にすると負荷になると思ったため)徐々に行ったため、その定着と効果の発揮まで数イテレーションくらいはかかりました。

【参考】
このPJでは開発系以外のツールとして「Googleカレンダー」でのスケジュール共有、「youRoom」でのアイデア出しやディスカッション、「社内SNS(」での週次進捗ミーティングなどを行い、極力、無駄な会議の時間を減らしているという特徴もあります。

最後:私がRedmineを4年間ほど使っていて思ったこと

始めに…Redmineはあくまで「ツール」です。

「ツールを入れて終わり」でなく、そのプロセスやマインド(振る舞い)を変えていくことが大事です(もちろん、最終的には「お客様により良い価値を提供すること」です)。
「今日から変えましょう!」と言って変わるわけでなく、日常の中で継続的に運用、改善を行っていくことが大事です。

そしてそれがどういう形になるか…はPJの特性やチームの成熟度、規模などによって毎回変わってきます。
アンチパターンはあるでしょうが、必ず正解するパターンはないと思っています。

その点から、(今回挙げたどのPJでも)運用方針の枠を最初に作りましたが、イテレーション終了時などのフィードバックから、より使いやすいように改善しました。
その際には、(管理者よりも)開発者にとって「自然に負荷なくできるプロセスはどういうものだろうか?」という視点を重点にしました。

次に、メンバーにRedmineの使い方やマインドを理解してもらう時の心構えです。

トップダウンで「やらせる」感じではなく、母性的や世話役的な感覚で接して、メンバーが「やれば楽になるんだ」と理解した上で浸透していくのを、じっくりと待つ辛抱強さが必要です。
トップダウンでやっても「Redmineを使うこと」自体が定着しても、そこから引き出すことができるチーム力の向上にはなかなか至らないと思います。

Zプロジェクトでのフリカエリでも、何度目かのイテレーションが終わった後くらいにやっと「こういうやり方も良いよね」という言葉、雰囲気が出るようになりました。

一方、リーダーの心構え的なものです。

このスタイルがチームに浸透し、理解してくると、【リーダーがタスクを作る/割り当てる/確認する】スタイルから、【自分達がタスクを洗い出し/割り当て(自分から手を挙げる)/進捗を管理する】スタイルに変わります。
(メンバーもそうですが)リーダーが自分の役割の変化…管理から違う価値の提供へ…を受け入れる必要があるとも思います。

繰り返しになりますが、「入れて終わり」でなく、プロセスやマインドが少しずつ変わって行って「当たり前」になる…のが、1つのゴールだと思います。
ですので、即効性のある/大きな効果を期待するよりも、まずは自分達のチームで使い始めて「お、ちょっとこれは良いかも」という点を1つでも見つけ出していくことから始めれば良いと思います。

最後までお付き合いいただき、ありがとうございました。

この記事をベースにお話したスライドが↓です(ShinagawaRedmineに遠征した際のもの)。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

プロジェクトに途中から入る難しさ

開発プロジェクトの立ち上がりではなく、途中から参加することはどれくらいの頻度であるでしょうか?
また、それはどのあたりから参加することが多いでしょうか?

開発プロセスがウォーターフォールの場合、要件定義、基本設計の立ち上がりの時期に参加したプロジェクトと、より後の工程で参加したプロジェクトを比較した場合、自分なりに上手くいったのは前者が多かったように感じます。
後者のように、詳細設計や実装の途中工程から入った場合にいくつか困ったことがありました。

前工程での決まり事にどこまで首を突っ込んで良いか分からない

「あぁこの前工程で決めた内容だと問題があるかもしれないな。別の案も提案して一緒に考えた方が後々良いかもしれないな…」と思ったことがありました。
このような考えが浮かんで来た時に、前工程までの前提知識やそれまでの培ってきたお客様との関係をなかなか感じ取ることができず、提案した方が良いか悩んだことがありました。

特にお客様が遠方で同じ場所にいなかったり、自分自身がお客様との打合せに出ていないことで、お客様個人個人との関係性が築けていなかったり、性格などをわかっていなかったりするとなかなか効良いアクションができませんでした。
その結果、冒頭のような、もしかしたらプロジェクトの結果をより良くするアイデアや考えが浮かんでもそれを活かせないことがありました。

心理的に焦る

自分がそのプロジェクトに入るということは、何からの期待、果たしてほしいミッションがあります。

その期待を出すために、早くキャッチアップしようと過去の経緯や現状の作戦の背景などを知りたくても、プロジェクトのキーマンは多忙で聞けないこともありました。
キーマンはチームのリーダーやお客様です。

そうこうしているうちに時間が過ぎて、期待されたアウトプットは出ないし、追いつけない焦りも生まれてしまい、中途半端な情報の理解のまま仕事をして手戻りが出るという悪循環に入っていきました。

キーマンが多忙な程、プロジェクトのこれまでの経緯や情報がまとまっておらず、新しく入ったメンバーのパフォーマンスがあがらない、またキーマンに質問が集中することでキーマンがさらに多忙になっていくといった良くないパターンも見受けられます。

ではどうすればよいか?

自分や後から入って来る誰かが、これまで書いたことのように感じるのはチームビルディングの観点からもったいないですし、不安のためなかなか自分から考えてアクションをしにくくなります。
こうなると指示待ちになり、プロジェクトに対しての自分事感も低くなってしまいます。

これはプロジェクトの目的を成し遂げ、目標をたどり着く上で、損失となります。

こうならないために、ベタな方法ですがこまめなコミュニケーションを増やすことが大事だと思います。
多忙なキーマンだと、まとまった時間をなかなか取ることが難しいので、毎日30分でも良いので、毎日の朝会、頻繁なふりかえり、チームで行くランチMTGなどまずは細切れでもコミュニケーションの量を増やすようにします。
そういう細切れの時間の中で得た情報から、少しずつ不安を取り除き、また「わかっていないことがどこか?」をわかることでよりうまく情報を集めることができるようになります。
早めに不安を取り除くことは「こういうことも聞いて/提案して良いんだ」という信頼関係を作ることにもなります。

いずれにせよ、チームを新しく作る、後から加わったメンバーが期待するパフォーマンスが出るまでには、相応の時間的なコストがかかることを意識したプロジェクト運営が必要になってきます。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo via VisualHunt

How to Change the World 〜チェンジ・マネジメント3.0〜

 「How to Change the World 〜チェンジ・マネジメント3.0〜」を読み終えました。

 以下、自分用のメモ書きですが、感想などを。

クイック・ウィンは、フィードバックを増幅し、その結果、生み出されたものを集約し、さらに多くのポジティブな変化を生み出すのに役立つ。
頻繁なフィードバックは大事で、そのスピードに対応できるだけのチームや組織の実力なんかも必要だと思いました。

ADKAR モデル
5番目に「補強(Reinforcement)」ってのを定義しているのが興味深かったです。
実際に変化を起こす際には重要な要因だと思います。

彼らはそれが自分自身の心地よさにつながると考える時にも行動を変える!
この辺のイメージをうまく伝えて、自分も含めたチームが自分達の中にその「心地よさ」を持つことができるか?というのが大事だと思いました。

変化の結果を恐れるため、変化は望ましくないと考えている。
変化した後もその人が重要と考えることを(それまでと同じ形でないにせよ)提供できる・・・ことを保証できれば、強力な味方になることもあると思います。
それを提供できるか?というのは簡単なことではないかもしれませんが。

「ありがとう」の言葉だけで、人々のよい行動を認知をし、やり続けさせるに十分なこともよくある。
こればっかりでも困るけど、これがあるだけで、頑張れる、アクションを起こす動機にはなりうると思います、少なくとも自分は。

組織で変化を促そうとするなら、いくつかの異なるメッセージとやり方を使い分けて、異なる人々に対処していくことになるだろう。
まさにそうだと実感しています。これを十把一からげにしてやろうとするから、結局何にも変化しないものになってしまいます(で、リソースだけが消費される・・・というパターンで)

よい仕事をするための正しい下地を作ること
良い表現。
自分の想いだけが先走り過ぎて、結局アウトプットや変化に至っていないのも多いので注意しないと。

物事がうまくいっているように見えるときは、自己満足に陥っているだけだったり、終わったと 勘違いしているのかもしれない
これは自戒を込めておかないと落ち込んでしまうと思いました。
チームのふりかえりと一緒で「自分自身のふりかえり」を客観的、定量的にできるようにする・・・などの工夫がいるかなぁと。

人の振る舞いを変えるためには、彼ら自身を変えるかわりに、環境を変えることを考えて欲しい。
自らの意志がないと変わらないよってことで。
変えることはできなくても、変わることのお手伝いはできるかもしれませんが。
で、それがここで言っている「環境を変える」ことと理解しました。

よい結果に対する褒賞はよい振る舞いに対する褒賞とは異なることを覚えておこう。
これは結果だけを見るのではなく、そのプロセスを見るってのも大事ということと理解しました。

最初は入り込むのがちょっとしんどい印象があったけど、すぐにグイグイ引き込まれていきました。
おそらく翻訳者がよく知っている方々なので、安心感があったというのも関係していると思います。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。