DevLOVE Advent Calendar 2012 “Professional”に投稿しました。
私が考えているProfessionalの定義は以下の3つをやっている、もしくは、やろうとしている人です。
それは「Whyを考え続ける」「厳しいことを言える」「ベストを尽くす」です。
続きはDevLOVE Advent Calendar 2012 “Professional”のエントリでお読みください。
私以外にも多くの方が「自分にとってのProfessional」というテーマで書いています(し、これからも書いてくれるでしょう)。
何が正解･･･というのはありませんが、それぞれの考え方にふれることで何か新しい発見があるかもしれません。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via Visual Hunt
先日「AgileTourOsaka2012 in Minoh」に参加してきました。
箕面という珍しい土地も楽しめましたし、スピーカー3人ともあまり関西ではお話されない方なので、お話が聴けて良かったです。
最初に質問や興味があることを付箋に書いて、それも絡めながら進めていくスタイルはオーガナイザーのtetsu_mさんだからこそと思いました。
＃お話していただいたスピーカー、スタッフ皆さん、楽しい時間をありがとうございました！
一番、印象に残ったのは藤原大(@daipresents)さんの話でした。
＃@daipresentsさんのエントリはこちら→解説！地図を捨ててコンパスを頼りに未来へ進め！ Agile Tour Osaka 2012資料公開
そんな「AgileTourOsaka2012 in Minoh」のテーマは【チェンジ】でした。
その【チェンジ】について思ったことです。
「いつか変わらないといけないと思うんですよ。でも～」
こういう会話を耳にする度に…
「いつかやる」っていう、その「いつか」はいつまでも来ないんだよ
— yoh nakamuraさん (@yohhatu) 2012年11月5日
…と思います。
「何かを変える/変わる」ことを”チェンジ”とした場合、自分がチェンジしようとする際に気をつけているコツみたいなものを書いてみます。
意外と始める前の手順が煩雑だったり、用意する物が多かったりする方法を選んでいることも見聞きします。
だいたい、揃えるまでに力尽きるか、揃えた時点で満足してしまったりするので、まずはすぐに始めることができる方法を選びます。
どうしても準備に時間をかけないといけないのであれば、準備をすること自体を「最初のゴール(あくまでマイルストーン)」に置くことも1つの選択です。
チャレンジの内容によりますが、「これは(自分には)向いていないかも」「この方法では難しいかも」と思ったらサッと止めて、方向転換できることもコツの1つです。
ただ、サッと止めることができるとは言え、判断は急がないこともあります。
AgileTourOsaka2012の中で藤原さんも言っていた気がしますが、自分もある程度の期間は様子を見ることもあります。チェンジにはそれ相応の時間がかかり「最初は違和感があっても、ある時期を越えるとプラスに変わる」というパターンもあります。
もう1つ気をつけることは、自分だけでなく周囲も一緒にやっているチェンジの場合、理由と共に「止める宣言」をすることです。
この止める宣言がないと、気まぐれな印象に見えますし、再びなにか行う時に「前も勝手に止めて…」と不要な抵抗を受けることもあります。
「2：簡単に止めることができること」の真逆ですが、これが有効な場合もあります
それなりに準備に手間暇かかっていたりすると「ここで止めるとこれまでの分がムダになる」と心理的なブレーキがかかって(ベストな状態では無いにしても)続けたりできます。
そして続けているうちに目的のチェンジができることもあります。
＃ただ、意固地になって止め時を見誤るというリスクもありますが･･･
似たような話で「チェンジしたいことを周りに宣言する」というのもあります。
私は、宣言だけでなく、自分や周囲の人が見える場所にチェンジしたい内容を貼り出していたりしました。
チェンジに向かって動き始めた時は不安がけっこうあります。
なので、大きくなくてもかまわないので本当にちょっとした、自分達が成し遂げた成果とその成功体験が大事です。
不思議なことにそういう成功体験を得ることで、その後、何度か失敗しても「成功体験」があるため「今回はうまくいかなかったけど次は…」となり、続けやすい状態になります。
もちろん同じ失敗をしないようにふりかえりなどの対策は必要です。
周囲に同じようにチェンジをしたい人がいれば、その人と一緒にやってみるのも1つのコツです。
もし社内にいなくても、外を見渡せばそういう人々がゴロゴロいますし、出会う機会もゴロゴロあります。
「変わらない」という選択肢もありますが、せっかく「変わりたいなぁ」と思っているなら、【チェンジ】の一歩を踏み出してみてはいかがでしょう？
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: nattu via Visualhunt.com / CC BY
今のところ、個人で一番使っているタスクマネジメントツール「Trello」です。
「Fog Creek Software」が提供しているWebベースのタスクマネジメントツールです。
Fog Creek SoftwareはWebサイト「Joel on Software」や「ジョエル・テスト」で知られているJoel Spolskyさんが設立した企業です。
Trelloを業務で使ってみた＠タチットにアカウント作成(Googleアカウントでログインできます)から基本的な使い方まで詳しく載っています。
Trelloは割と頻繁に機能追加がされているため、上記エントリ当時(2011年9月頃)と違うかもしれませんが、シンプルな作りなので、すぐに使えます。
Androindのクライアントもあり、Webの機能全てができるわけではありませんが、困らないレベルです。
1：リアルタイムに更新される
もちろんリロードする必要もありませんし、(複数人で)色々操作している時もそのタイムラグはありませんでした。
2：直感的な操作方法や機能
D&Dでサクッと移動できますし、ショートカットも色々用意されていて、思考と(アプリの)操作が直結する感じです。
3：Trello自身の開発もTrelloを使ってそのアイデアや状況を開示しているところ
Trelloというアプリの特性上当たり前なのかもしれませんが「ドッグフードを食べる」という点と「ユーザーへの透明性を確保している」という点がすごく好きです。
そのボードを見てもらえると分かりますが、(自分はこの機能が欲しいというように)投票できます。
レイアウトはタスクボード風にTodo/Doing/Doneという3レーンに分けて使っています。
具体的な使い方で工夫している点(「誰かに依頼したタスクはどうしているの？」「Doneをいつ消すか？」)はまた別のエントリで書きます。
タスクマネジメントツールは、ユーザーが「本来したいことに集中できる」ようにするのも目的の1つです。
その点でTrelloはそのサクサク感や直感的に分かる点から優れていると思います。
Trelloユーザーの方、「自分はこんな風に使っているよ～」というフィードバックをくれたりすると嬉しいです。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
これまで(セミナーや読書会などの)社内勉強会をやったり、他社さんで社内勉強会のお手伝いをした中で、難しいところや思うところがあったので書いてみます。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
クローズドで開催され、参加者は(原則)社員のみ。スピーカーや講師は外部の場合もある。
参加者のモチベーションは(社外勉強会とは)大きく異なっています。
社外勉強会ではほぼ「自分で選択して参加」しています。
中には上司や会社から命令されて参加するというパターンもありますが観測範囲では少数だと感じています。
一方、社内勉強会では「面倒だけど評価に響くかも」とか「仕事的だから」とモチベーションが高くなく、良い感情を持っていない状態で参加する人もいます。
不思議なことに「自主参加で評価などには一切関係ありません」とアナウンスしても一定数の割合で本当に嫌々参加している人がいます。
残念ながら、そういう人の一部は(無関心でなく)抵抗勢力になってしまうこともあります。
そのような抵抗勢力との対応にリソースを使うと、数少ない興味ある人へのリーチやリマインドが弱くなり、参加者が集まらなかったり、無断キャンセルやドタキャンばっかりだったということも起こります。
＃講師と参加者の割合が2対1というマンツーマンどころか講師の側がダブルチームという悲しいセミナーも経験しました
いつ行うか？も社内勉強会では悩ましい問題です。
「(日常の)業務タスクとの兼ね合いをどうするのか？」という声が上がってきます。
「○○という社内勉強会に参加していたため、進捗が遅れました」なんて報告されたりすると、そのプロジェクトからクレームが飛んでくることもあるかもしれません。
「それは業務命令ですか？残業時間として付けますが良いですか？」という声が上がってきます。
この場合、「業務命令でないから自主参加」or「業務命令」という2パターンがあります。
「業務命令」の場合、残業代や業務監督責任なども発生してくるので、それなりに上司や組織に根回しをしてバックアップを得ておく必要があります。
そこまでゴタゴタ言う人はモチベーションが低いことも多いので「そこまで言うなら来なくて良いよ」と思うこともありますが、組織に社内勉強会から得られる何かが根付いて欲しいと思うと割と対応することが多かったりします。
定時後の場合と同じ問題がより高いレベルで発生します(休日出勤手当や振り替え休日など)。
「業務命令」という形にしても、なかなか組織としては認めてくれないと思います。
「うまくいく方程式」があるわけではありませんが「参加者のメリットを提示する」と「仲間を見つける」はまず最低限必要なことだと感じています。
「メリット」というと生々しいですが、「今、困っていること」を少しでも解決できそうなら、時間を作って参加してくれることもあります。
またすぐ役立ちそうなことなら、参加者もいつか役立つかもしれないことよりモチベーションが高くなることが多いです。
このパターンで1、2回社内勉強会に参加すると、後でテーマが「いつか役立つかもしれないこと」になっても継続的に来てもらえたりします。
継続しようとすると、準備などを全部自分1人でするのは、時間的にも気持ち的にもしんどい時期が来ることもあります。
その時に頼れる仲間やバックアップしてくれる上司がいれば、継続することもできます。
※参考：[雑多]「XP祭り関西2012」でLTしてきました。
社内勉強会はモチベーションの問題など悩ましいことがあります。
＃もちろん全然問題なく社内勉強会をやれる組織もあります。
一方で、自分の多くの時間をその組織とそこにいる同僚(仲間)のために使っています。
なので、そのレベルアップのため、そして伝える側のレベルアップのためにも社内勉強会をやってみてはどうでしょうか？
※アイキャッチ画像：http://www.flickr.com/photos/mattimattila/6878384654/
ずいぶん前に書いたまま放置していたのを(ちょっと書き足して)アップします。
組織において「えらくなっていきたいか？」という話です。
一時期「昇格/昇級したいか？」という問いにNoと答えていました。
なぜなら「上の人が楽しそうに、やりがいを持って仕事をしているように思えなかった」からです。
自分がやりたい仕事でないのか、責任やプレッシャーの割に(評価された結果の)給料が低いのか分かりません。
が、目を輝かせて「今の自分の仕事が楽しい/やりがいがある！」と伝える(伝えなくても態度で示す)人が少なかったように思います。
恵まれたことに(一番お世話になった)直属のボスは上記に当てはまらない人でした。
(現場や若手から見て)管理職や上司が魅力的に見えない組織は、新しい力も出てこなく、新陳代謝も起きず、 新しい変化にも対応できず、結果として若く有望な方は出て行ってしまうし･･･で、良いことは何もありません。
最近(※2011年の冬頃)は少し変わってきていて「その組織で自分がしたいことをやりやすく、横槍を入れられずにやる(＝自分でハンドルを握る)には、えらくなって上に行くのが一番の近道」と思うようになっていました。
この話の前提には「その組織で頑張るなら」がありますが。
えらくなることを目的としてとらえると(魅力が無いように映っているので)イマイチ前向きになれませんが、「自分がやりたいことするため」の手段として見ると、そう悪い話では無いと感じたからです。
それからしばらくして、ハンドルを握るまでの時間の長さに待ちきれずに移る※ことになったのですが。
※[仕事]会社を移ることになりました
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on Visual Hunt
今のチームで仕事をやり始めて2ヶ月半が過ぎました。
その2ヶ月半で、業務の引継ぎや情報の伝達について、ふと思ったことがあったのでつらつらと書いてみます。
中途入社でしたので、チームが携わっていた業務、またその業務に関するプロダクトへの知識は低い状態でした。
チーム自体はあまりメンバーは出入りせず、しばらくの間、この業務、プロダクトに関わっている状態でした。
職位としては上長にあたる立場で、期待されている役割としては引っ張っていくことが存在していましいた。
この2つの自分の状況が良いように影響し、うまく情報の伝達ができました。さらに改善できそうなプロセスやよりうまくやるためのボトルネックまで見つけることができました。
私に情報や状況を伝えてくれる当初からいるメンバーの視座で見てみます。
日常的に忙しいと、後から入ってきたメンバー(今回の場合だと私)に業務や決まり事などを説明する時間が十分確保できないことがあります。
十分確保できないと「ここにあるから後は見ておいて」と、伝達を端折ってしまい、相手の理解度が不十分なまま日常の業務を進めることになります。
不十分なまま業務を進めると、アウトプットの質が十分でなく手戻りが起きることも多くあります。
今回の状況では、伝える相手は職位が上ということもあり「この人、わかっていないなぁ」と思いながらも丁寧に伝えようとしてくれました。
#もちろん「上長だから」丁寧に伝えてもらえるというわけではなく、聞き手の態度や姿勢なども関係しているとは思います。
この時間をとって、より丁寧に伝えようとすると、伝える側もあまり意識していなかった暗黙知が表出化してくることもあります。
この表出化の過程で、これまでなんとなく続けてやっていたけど、面倒、複雑なやり方であることに気づくこともあります。面倒や複雑なプロセスはムダやムリがあることも多くあり、改善するポイントでもあります。
「伝える」という行為を通じてこのような改善するポイントが見えることもメリットの1つだと感じました。
本来であれば相手が誰であれ、そのような暗黙知やムダなプロセスが明確になれば嬉しいのですが、なかなかうまくいかない経験をした方も多いと思います。
伝えてくれる相手が職位的に上の場合だと、説明されている内容に違和感を覚えてもなかなかしつこく質問して聞けないこともあります。
またその業務やプロダクトに対する聴く側の経験が浅かったりすると、そもそもそのような質問を思い至らないかもしれません。
今回の場合、私が業務、プロダクトそのものの経験は少なくても、エンジニアとしての経験はそれなりにあったので、その経験と照らし合わせた上で伝えられた内容に対して質問や疑問を持って話をすることができました。
結果として、聴く側の動きによっても、先に書いたように暗黙知やムダなプロセスが明確になりました。
聴く側としては「聞くのが恥ずかしい」「こんなこと聞いたらバカにされるのでは？」といった自分をよく見せようとする気持ちが強くあると、知ったかぶりな態度を取ったり、表面的なことのみでわかった気になったりして、うまく情報を伝達できないということもあります。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo credit: davis.steve32 via Visualhunt.com / CC BY
最近、UltimateAgileStories Iteration2(UAS2)のエントリ([雑多]UltimateAgileStories Iteration2が届きました)を書きましたが、その1冊目･･･「UltimateAgileStories Iteration1(UAS1)」で書いた内容を原文のまま公開します(少し長めです)。
これをきっかけにRxTstudyなどを始め、お話する機会を多く得ることができました。またコミュニティ活動にも積極的に関わっていったのもこれがきっかけの1つでした。
最後にベースにお話したスライドへのリンクがあります。
題名が中学生の作文みたいですが…良いのが思いつかなかったのでこのまま行きます。
初めまして(またはそうでない方、こんにちは)、@yohhatuという者です。
大阪在住でとあるSIer所属です。
「お客様も自分達もハッピーにして、かつ、より良い価値を届けるか？」を日々考えています。
チームビルディングやファシリテーションに重きを置いていて、「自分は”スクラムマスター”的なことをしたいんだ」と最近気づきました。
こんな者です。
しばらくお付き合いください。
今のプロジェクトでは「開発の三種の神器」と言われるITS/CI/SCMを使って開発しています。
ITSはRedmine、CIはJenkins、SCMはSVNです。
その中でもRedmineは(いくつかのPJで)4年近く使っており、その使い方、成果や課題を伝えたいと思ったためです。
構成は、主なプロジェクト(3つ)毎に「特徴」「使い方」「成果」「課題」として書いています。
【特徴】
メンバーは約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で大きく役立ちました。
【特徴】
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つのポイントを作り、バッファを持たせ、「待ち」が発生しても別のチケットをやるなどリソースを効率良く使うことを工夫しました。
【特徴】
社内向けにフレームワークやそれに関するツール群の開発、またそれらの導入支援などを行っています。
メンバー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はあくまで「ツール」です。
「ツールを入れて終わり」でなく、そのプロセスやマインド(振る舞い)を変えていくことが大事です(もちろん、最終的には「お客様により良い価値を提供すること」です)。
「今日から変えましょう！」と言って変わるわけでなく、日常の中で継続的に運用、改善を行っていくことが大事です。
そしてそれがどういう形になるか…はPJの特性やチームの成熟度、規模などによって毎回変わってきます。
アンチパターンはあるでしょうが、必ず正解するパターンはないと思っています。
その点から、(今回挙げたどのPJでも)運用方針の枠を最初に作りましたが、イテレーション終了時などのフィードバックから、より使いやすいように改善しました。
その際には、(管理者よりも)開発者にとって「自然に負荷なくできるプロセスはどういうものだろうか？」という視点を重点にしました。
次に、メンバーにRedmineの使い方やマインドを理解してもらう時の心構えです。
トップダウンで「やらせる」感じではなく、母性的や世話役的な感覚で接して、メンバーが「やれば楽になるんだ」と理解した上で浸透していくのを、じっくりと待つ辛抱強さが必要です。
トップダウンでやっても「Redmineを使うこと」自体が定着しても、そこから引き出すことができるチーム力の向上にはなかなか至らないと思います。
Zプロジェクトでのフリカエリでも、何度目かのイテレーションが終わった後くらいにやっと「こういうやり方も良いよね」という言葉、雰囲気が出るようになりました。
一方、リーダーの心構え的なものです。
このスタイルがチームに浸透し、理解してくると、【リーダーがタスクを作る/割り当てる/確認する】スタイルから、【自分達がタスクを洗い出し/割り当て(自分から手を挙げる)/進捗を管理する】スタイルに変わります。
(メンバーもそうですが)リーダーが自分の役割の変化…管理から違う価値の提供へ…を受け入れる必要があるとも思います。
繰り返しになりますが、「入れて終わり」でなく、プロセスやマインドが少しずつ変わって行って「当たり前」になる…のが、1つのゴールだと思います。
ですので、即効性のある/大きな効果を期待するよりも、まずは自分達のチームで使い始めて「お、ちょっとこれは良いかも」という点を1つでも見つけ出していくことから始めれば良いと思います。
最後までお付き合いいただき、ありがとうございました。
この記事をベースにお話したスライドが↓です(ShinagawaRedmineに遠征した際のもの)。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
開発プロジェクトの立ち上がりではなく、途中から参加することはどれくらいの頻度であるでしょうか？
また、それはどのあたりから参加することが多いでしょうか？
開発プロセスがウォーターフォールの場合、要件定義、基本設計の立ち上がりの時期に参加したプロジェクトと、より後の工程で参加したプロジェクトを比較した場合、自分なりに上手くいったのは前者が多かったように感じます。
後者のように、詳細設計や実装の途中工程から入った場合にいくつか困ったことがありました。
「あぁこの前工程で決めた内容だと問題があるかもしれないな。別の案も提案して一緒に考えた方が後々良いかもしれないな…」と思ったことがありました。
このような考えが浮かんで来た時に、前工程までの前提知識やそれまでの培ってきたお客様との関係をなかなか感じ取ることができず、提案した方が良いか悩んだことがありました。
特にお客様が遠方で同じ場所にいなかったり、自分自身がお客様との打合せに出ていないことで、お客様個人個人との関係性が築けていなかったり、性格などをわかっていなかったりするとなかなか効良いアクションができませんでした。
その結果、冒頭のような、もしかしたらプロジェクトの結果をより良くするアイデアや考えが浮かんでもそれを活かせないことがありました。
自分がそのプロジェクトに入るということは、何からの期待、果たしてほしいミッションがあります。
その期待を出すために、早くキャッチアップしようと過去の経緯や現状の作戦の背景などを知りたくても、プロジェクトのキーマンは多忙で聞けないこともありました。
キーマンはチームのリーダーやお客様です。
そうこうしているうちに時間が過ぎて、期待されたアウトプットは出ないし、追いつけない焦りも生まれてしまい、中途半端な情報の理解のまま仕事をして手戻りが出るという悪循環に入っていきました。
キーマンが多忙な程、プロジェクトのこれまでの経緯や情報がまとまっておらず、新しく入ったメンバーのパフォーマンスがあがらない、またキーマンに質問が集中することでキーマンがさらに多忙になっていくといった良くないパターンも見受けられます。
自分や後から入って来る誰かが、これまで書いたことのように感じるのはチームビルディングの観点からもったいないですし、不安のためなかなか自分から考えてアクションをしにくくなります。
こうなると指示待ちになり、プロジェクトに対しての自分事感も低くなってしまいます。
これはプロジェクトの目的を成し遂げ、目標をたどり着く上で、損失となります。
こうならないために、ベタな方法ですがこまめなコミュニケーションを増やすことが大事だと思います。
多忙なキーマンだと、まとまった時間をなかなか取ることが難しいので、毎日30分でも良いので、毎日の朝会、頻繁なふりかえり、チームで行くランチMTGなどまずは細切れでもコミュニケーションの量を増やすようにします。
そういう細切れの時間の中で得た情報から、少しずつ不安を取り除き、また「わかっていないことがどこか？」をわかることでよりうまく情報を集めることができるようになります。
早めに不安を取り除くことは「こういうことも聞いて/提案して良いんだ」という信頼関係を作ることにもなります。
いずれにせよ、チームを新しく作る、後から加わったメンバーが期待するパフォーマンスが出るまでには、相応の時間的なコストがかかることを意識したプロジェクト運営が必要になってきます。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via VisualHunt
「How to Change the World 〜チェンジ・マネジメント3.0〜」を読み終えました。
以下、自分用のメモ書きですが、感想などを。
クイック・ウィンは、フィードバックを増幅し、その結果、生み出されたものを集約し、さらに多くのポジティブな変化を生み出すのに役立つ。
頻繁なフィードバックは大事で、そのスピードに対応できるだけのチームや組織の実力なんかも必要だと思いました。
ADKAR モデル
5番目に「補強（Reinforcement）」ってのを定義しているのが興味深かったです。
実際に変化を起こす際には重要な要因だと思います。
彼らはそれが自分自身の心地よさにつながると考える時にも行動を変える！
この辺のイメージをうまく伝えて、自分も含めたチームが自分達の中にその「心地よさ」を持つことができるか？というのが大事だと思いました。
変化の結果を恐れるため、変化は望ましくないと考えている。
変化した後もその人が重要と考えることを(それまでと同じ形でないにせよ)提供できる･･･ことを保証できれば、強力な味方になることもあると思います。
それを提供できるか？というのは簡単なことではないかもしれませんが。
「ありがとう」の言葉だけで、人々のよい行動を認知をし、やり続けさせるに十分なこともよくある。
こればっかりでも困るけど、これがあるだけで、頑張れる、アクションを起こす動機にはなりうると思います、少なくとも自分は。
組織で変化を促そうとするなら、いくつかの異なるメッセージとやり方を使い分けて、異なる人々に対処していくことになるだろう。
まさにそうだと実感しています。これを十把一からげにしてやろうとするから、結局何にも変化しないものになってしまいます(で、リソースだけが消費される･･･というパターンで)
よい仕事をするための正しい下地を作ること
良い表現。
自分の想いだけが先走り過ぎて、結局アウトプットや変化に至っていないのも多いので注意しないと。
物事がうまくいっているように見えるときは、自己満足に陥っているだけだったり、終わったと 勘違いしているのかもしれない
これは自戒を込めておかないと落ち込んでしまうと思いました。
チームのふりかえりと一緒で「自分自身のふりかえり」を客観的、定量的にできるようにする･･･などの工夫がいるかなぁと。
人の振る舞いを変えるためには、彼ら自身を変えるかわりに、環境を変えることを考えて欲しい。
自らの意志がないと変わらないよってことで。
変えることはできなくても、変わることのお手伝いはできるかもしれませんが。
で、それがここで言っている「環境を変える」ことと理解しました。
よい結果に対する褒賞はよい振る舞いに対する褒賞とは異なることを覚えておこう。
これは結果だけを見るのではなく、そのプロセスを見るってのも大事ということと理解しました。
最初は入り込むのがちょっとしんどい印象があったけど、すぐにグイグイ引き込まれていきました。
おそらく翻訳者がよく知っている方々なので、安心感があったというのも関係していると思います。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
2012年6月末で会社を移ることになりました。
(何度か転職をしているのですが)今のところ、社会人経験の中で一番長く所属していた会社になっていました。
入社後しばらくして、(弊社では)お客様向けとして開発実績の無かったRuby(とRuby on Rails)を使いシステムを構築し、(お客様に)良い評価をもらったことです。
1システムだけでなく、確か計4つほど作ったと思います。
チームはRuby未経験者ばかりだったので、当時(Rubyで)社内SNSを作っていた@kuranukiさんや@nsgcさんが助っ人で来てくれ、合宿形式でペアプロをしたのも良い思い出です。
直近で長く携わった社内向けのプロジェクトも印象に残っています。
この時のチームは(ボスを筆頭に)本当に仕事に対する姿勢が素晴らしいもので(もちろん技術力もですが)、私も本当に多くのものを得ることができました。
チームを抜ける時には「卒業証書」をもらったりもしました(笑)。
このチームでは「ここぞとばかりに」色々チャレンジしました。Redmine、Jenkins、テストコード、そしてファシリテーションやスクラムなどなど…。
RxTstudyに携われたりスクラム道な方々と出会えたりする機会にもつながりました。
またそれらをきっかけにして社内外で人前で発表するという貴重な経験もできました。
アジャイル(スクラム)については「教科書的にはこうだけど、自分達のコンテキストでは…」という点が多く、大きい壁となり、その度チームで話し合って、自分達なりの開発のやり方とユーザへ価値を届けるベストな方法を模索し続けました。
これも良い経験でした。
アジャイルサムライの道場(社内読書会)やランチ勉強会を通じて、(サラリーマンSE色の薄い)前向きなエンジニアと出会えたことです。
「勉強会」が全てではありませんが、こういうのが積極的に開催されていて、参加者も多い組織はエンジニアにとって魅力的だと思います。
(夢物語な感じですが)「毎日どこかのセミナールームで(社内外を問わず)勉強会をやっていて、色々な人がやってきて交流ができる環境にしたい」と思っていたりもしました。
この考えに影響を与えた方として、入社した当時に(社内SNSを通じて)出会った@papandaさんがいます。
今ではDevLOVE関西でつながっていたりします。
相変わらず大阪でエンジニアをしています。
新しい職場のことはまた折を見て書こうと思います。
これまでの勉強会にも参加したいですし、新しい技術要素に出会うと思うので、その界隈の勉強会などにも参加すると思います。
よろしくお願いします。
余談ですが、コミュニティの知人には「どこに行くの？」よりも「(弊社を使っている)勉強会やセミナーの会場確保は(これからも)大丈夫？」と聞かれることが多かったです。
幸いなことにそれぞれのコミュニティに弊社社員が(スタッフ的に)いるので会場を使うことは(社内規則が変わらない限り)大丈夫なのでご安心ください。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on VisualHunt
主に月末/月初に「退職します(した)」エントリ、「入社します(した)」エントリやつぶやきがちょくちょく見受けられます。
弊社からも新天地へ行った方もたくさんいて、中には「おぉ、あの人もいなくなるのか…寂しいなぁ」という方もいます。
ただ、たいがいそういう人とはTwitterやFacebookなどでつながっていたり、ブログを読んでいるので「元気にやっているなぁ」と分かります。
そしてそれを励みに「自分も…」と思ったりします。
ふと「同じ会社に所属していても、部署が変われば、日常的に言葉を交わすことは少なくなることがある。それって会社を移るのとそれほど変わらないのでは？」と思ったりしました。
部署の異動以外でも、「自社での開発」から「お客様常駐(そのまま数ヶ月帰ってこない)」のパターンだと(同じ部署でも)言葉を交わすことは少なくなります。
ただ、食堂で見かけたり、エレベータで乗り合わせたりしたら「久しぶり。最近どうよ？」てな感じで言葉を交わします。
で、それは冒頭に書いたように(会社を移った人が)TwitterやFacebookで興味深い事をつぶやいていたり、書いているのを見かけたら「久しぶり。最近どうよ？」と声をかけるのと感覚的には一緒だったりします。
部署異動したり、プロジェクトを移ると、(会社的に共通な)お作法以外に、ローカルルールや独自のやり方があり、けっこう覚えることもそれなりにあります。
時にはそれまでのお作法が「間違い」と言われることもあったり(苦笑)
また「知った顔」という意味でも、(プロジェクトによっては)ほとんど初対面ということもあり、結局(あまり価値の高くない)「まずはお互い知る」というチームビルディングにパワーが必要な状況も多くあります。
組織としての成熟が足りないとも言えますが、そこそこ普通な光景だと思ったりします。
「会社を移るとそれまでの人脈が…」という方もいますが、お互いが必要と思っていれば会社を移っても情報交換やディスカッションは続けます。
むしろ、違うフィールドで新しい情報や視点を持ってディスカッションできるようになるので、刺激になります。
「会社」という共通項以外でやり取りできないのであれば、あまり太い関係でもないと思いますし。
こういう感覚は、どの程度「会社」「部署」などの組織を拠り所としているか…によりますが、自分の場合はこんな感じだなぁと思ったわけです。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on Visualhunt.com
以前、「社内読書会をやってみて」というエントリを書きましたが、今度は社内でやってる「ランチ勉強会」のお話です。
週に1回、(社内の会議室などで)お昼を食べながら、プレゼン＋ディスカッションをしています。
テーマはプレゼンする人が決めるか、参加者からリクエストがあったらそれについて話すという感じです。
6,7年目頃の同期数人で情報交換のために集まったのが最初だったようです。
私も途中から参加するようになりました。
同期ばかりだと発展性のない雑談だったり、(年次が近いこともあり)同じ視点になりがちなので、「色々な人にも声をかけよう」と動いていきました。
今では、部門もバラバラ…現場/本部系、開発部門/パッケージ導入などなど…ですし、年次も2年目～10数年まで広がっています。人数も多い時には10人を越えるようになって、最初の頃にやっていた会議室では手狭になり、場所を変えたりもしました。
これまで20回以上やっていますが、テーマも様々です。
・Meteorの紹介とデモ
・CCPMってなに？
・RxTstudyの再演
・社内で作ったリッチクライアントフレームワークの話
・バーンダウンチャートの説明
・世代交代するためには
・お客さんとの付き合い方
・英語勉強会の進め方の相談
・インセプションデッキをつくろう
・社外勉強会ってどんなの？
後、新しい参加者がいれば、その人の自己紹介もあります。
同じ部門、同期でも「何をやってきたか？これから何をやっていきたいか？」は知らないことも多く、自己紹介をきっかけに話が盛り上がることも多くあります。
出欠や資料、終わってからのやり取りはyouRoomを使っています。
ランチ勉強会本編以外の話題…主に最近ネットで話題になったエントリとか…を起点に「youRoomでディスカッション」→「ランチ勉強会本編へ」という流れもあります。
冒頭に書いた社内読書会との違いは「組織有りきで考えるかどうか」というところです。
「社内読書会」のメンバーは社外勉強会にも多く出ていたり、若い方が多いこともあってか「自分はどうなりたいか？そのために～」「(自分のやり方、キャリアの)こんなことで悩んでいる。〇〇はどう思う？」という感じがします(組織云々よりも)。
一方、「ランチ勉強会」は、中心メンバーがそれぞれお客様と向きあって、また、プロジェクトリーダーなりでやっているからか「自分達のお客様とのビジネスをどうしたら良いか？」「この組織のどこをどういう風にしていけば良いのか？」というような「組織があって、その中でどうすれば良いか？」という話が多くあるように思います。
良い/悪いではなく、それぞれの立場や考え方があるのですが、両方参加している自分としてはその対比がなかなか興味深いです。
「ランチの時間ぐらい好きにさせてよ」と言う意見もあります(また、毎日やっていると疲れると思います)が、普段あまり話さない別チーム、別部門の人と話すことで新しい意見や情報を手に入れる良い機会だと思っています。
これをきっかけにして新しい何か…「〇〇さん、ランチ勉強会で△△に興味あるって言っていたから、このプロジェクトに引きこんでみよう」とか…が始まるかもしれませんし。
「いつもの」同僚と「同じような」話をするランチも良いですが、たまにはこういう風に「違う」人と「違う」話をするのも良いと思います。
ランチ勉強会を継続して続けている当初メンバーの皆さんに感謝です。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via Visualhunt
先日社内勉強会で「バーンダウンチャート」について説明する機会がありました。
その際の資料として@ryuzeeさんの「[Agile]バーンダウンチャート虎の巻(資料公開)」を使わせてもらいました。
＃@ryuzeeさん、ありがとうございました！
その資料で自分なりに疑問に思ったことを@ryuzeeさんとやり取りした内容を「誰かの役に立てば」と思いまとめておきます。
※スライド11枚目：「バーンダウンから分かること」
「チームが自己組織化されていて～」とは具体的にどのようなことでしょうか？バーンダウンの進み方と「自己組織化」の紐付けがイメージできませんでした。
チームがスプリントを主体的に行なっているかどうかが分かります。
他人からの指示を欲してしまうチームは、一般的には問題が発生してもすぐ対応しないので、スコープ調整が行われず完了しないスプリントになったりスコープ調整が後半になったり、そもそも経験から学ばずに、毎回似たようなバーンダウンを描いたりします。
スプリントの見積総時間とスプリント終了日を結んだ場合、チームの1日辺りの理想時間と乖離すること(※1)もあると思います。
この場合は「詰め込みすぎ」なので「スコープを見直す」アクションにつながると思っていますが、この理解にコメントあればお願いします。
(※1)3人チームで、1人の開発時間は6時間/日の場合、18時間/日のパワーです。一方、理想線の傾き(1日の時間)は24時間とした場合、毎日6時間のオーバータスクになってしまいます。
その理解であってます。
ただし、チームにはキャパシティというのがあります。これはチームメンバーの稼働可能時間の合計値ですが、それは一般的には就業時間の6割程度です。
したがってスプリント計画第二部が終わって計画ができた時点で、まずチームの総キャパシティの中に合計タスク時間数が収まっているかは確認すべきポイントです。
既にこれを超えているようであればプロダクトオーナーと議論して順位の一番低いストーリーから順に外します。
またチームがタスク出しになれていない場合は、2割くらいの追加タスクが出るのが普通なので、これも見込んだほうがよいです。
結果として、理想線のスタート地点はキャパシティの下側になければいけません。
※スライド21枚目：早期学習パターン
残時間が44→26のように(スコープの調整等がなく)ガクッと下がった場合、以下のことが考えられます。
A：チームがレベルアップして当初見積より早くそのタスクが終わった
B：チームが残業した
前者であれば良いのですが、後者であればそれは持続可能でないと思います。
そういう場合に「最終コミット時間」を別にプロットすることで「原因を明らかにする」のが良いと思っています。
この理解にコメントあればお願いします。
本当は最終コミット時間プロットしなくたって振り返りで分かりますけどね。
本質的な原因を明らかにしなければいけないのはその通りです。
往々にして成果達成に対する強いプレッシャーがかかってたりします。
※スライド35枚目：複数スプリント間で分析する
スプリントで作る機能の難易度の違いを考慮する良いアイデアはあるでしょうか？
「ふりかえり」でチームでディスカッションして明らかにするのが1つの方法と思っています。
難易度の違いはストーリーポイントと、ばらしたタスクに明確に現れるはずだと思います。
そのためにチームで見積るので。
それが着手してみて初めて難易度がわかるようであれば、そのバックログ項目はまだReadyではないです。
バーンダウンチャートを始めることは割と簡単にできます(おそらくガントチャートと並行してもできるはずです)。
実際にやってみるとガントチャートだけでは見えなかったチームやプロジェクトの色々なことが見えて来ます。
もし何も見えなかったらそれはそれで無茶苦茶素晴らしいチームか、何か隠しているかです。
それらの分かった情報をもとに改善のきっかけにしていくこともできると思うのでまずはやってみてはいかがでしょうか？
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
ここ1年ほどいくつかの勉強会に参加して、時にはスタッフだったり、スピーカーをさせてもらったりした中で「仕事と勉強会の源泉の関係」について感じたことです。
「今日の勉強会でエネルギーをもらったので、明日からまた現場で頑張れます！」という声を時々聞きます。
(スタッフだったりすると)そういう声は嬉しいのですが、一方で【うまく行っていないのに変化しようとしない現場やデスマの現場でエネルギーが切れる(心が折れる)】→【勉強会でエネルギーを補給】→【また日々のしんどい現場で…】→【エネルギー切れたら勉強会へ】という(改善ではない)ループにハマっている感じがする時もあります。
「(しんどい)仕事をやり切るために勉強会へ参加する」みたいな。
もちろんこういう方は少ないよ！ってのであれば嬉しいことですが…。
一方、自分はどうだろうか？と考えてみました。「勉強会で話したいために仕事で(改善も含めて)楽しんでガンバル」が自分のスタイルかなぁと。
自分にとって(会社での)仕事で改善を意識し続けてやっている源泉の1つに「(自分が経験して学んだ)アウトプットを話したい」というのがあります。
もっと言うと、それを伝えた人からの(良い悪い関係なく)フィードバックを得て、もっと良いモノにしていきたいです(そして、それを共有したい)。
さらにさらに言うと、自分と同じようなことに(不必要に)悩まず、はまらず、本来やりたいことにリソースを集中して、より良い仕事ができるようになれば…と思っています。
そのためには、(当たり前ですが)上っ面をなぞるようなことでなく、自分が腹落ちしていることを言いたいわけです。
腹落ちしていなくて、自分が悩んでいてもっと意見を聞きたい場合は、正直に伝えるようにしています。
(自分で腹落ちするために)漠然とするのでなく、工夫や改善を意識して、「何か伝えるエッセンスがないか？」ということも意識しながらやっているわけです(いつもってわけではないですが)。
勉強会やセミナーなどでよく話されるスピーカーの皆さんの(話す)源泉ってどんなんだろうって気になります。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo on Visual Hunt
[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。
今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。
やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。
以下は、今のチームでやっている工夫や気づいたことです。
KPTに似たようなフレームワークで「YWT」というものがあります。
Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も･･･。
Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
それを「W(分かったこと)」として書き出します。
分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。
youRoomをコミュニケーションツールとして使っています。
そこにイテレーション開始時に”あらかじめ”フリカエリ用のスレッドを立てておきます。そして、日常の開発などで「あっ！これはPかも」「次はこんなこと(T)したいなぁ」と思えば、すぐに書き込むようにしています。
イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
早く対応した分だけ、チームのパフォーマンスが上がります。
なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。
これは最近やり始めたことです。
Pに対してTを書き出しますが、中には「本当にそれでPは解決する？もう少し深く話した方がいいのでは？」というものもあります。
例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。
このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。
こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。
(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな？」と半信半疑な雰囲気になっているPを取捨選択する必要があります。
(Pとは関係なくても)「こんなことにチャレンジしたい！」という意味のTも書き出すようにしています。
そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。
(サインアップのように)「自分がやりたい！」と手を挙げることで、その質やコミット感が強くなるのが良い点です。
Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
ですので、前向きにやる…とのが難しいこともあります。
それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。
同じチームで何度かフリカエリをやっていると「あれ、これって前も同じようなPが上がっていなかったっけ？」というシーンが出てくることもあります。
同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。
そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか？を見るようにしています。
そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。
同じチームでフリカエリを行なっていると(PやTはそれなりに出ているのですが)Kは少なくなっていきました。
チームの状態が悪くなったわけではなく、そのKがチームにとって当たり前になり「暗黙知」になったのです。
そして「あえて書き出すまでもない当たり前のこと」になり、Kとして出ることがなくなったわけです。
新しいメンバーが入って、そういう暗黙知を「K」として書き出すことで改めて、チームがその良さに気づくということがありました。
このように、いくつか工夫はしていますが、最初に上げた「プロジェクトファシリテーション実践編 ふりかえりガイド」に書かれているほぼその通りです。
大事なのは(リーダーなどを含めた)チーム全員が、そこに書かれている心持ちや姿勢を取ることができるか？ということです。
その点では、(日常の)朝会に比べると少し難しいかもしれませんが、フリカエリをきっかけにチームが大きく変わることもあるのでチャンレジする価値はあります。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo by Acarlos1000 on Visualhunt.com / CC BY
[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」について考えることがあって、その後もチームで話すことがあったのでちょっと書いてみます。
今のチームでも、もちろん朝会をやっています。
そのやり方はほぼプロジェクトファシリテーション実践編 朝会ガイド(※リンク先はPDF)の通りです。
以下は、(別のチームも含む)過去の朝会でやった工夫です。
最初はリズムを作るためにリーダーがやっていたのですが、リズムができてからは司会者をメンバー持ち回りでするようにしました。
背景として、若手メンバーにチームの朝会ではありますが、場を作って進めることを学んで欲しかったというのがありました。
自分が実際にその役割(ここでは朝会の司会)を実際にやってみないと、考察や気づきには至らないこともあります。
また実際にやってみることで新しい適性に気づいたりして、レベルアップにもなりますので「いまいち、若手が積極的でない…」という場合にはやってみても良いかもしれません。
当時はなかなか頻繁な「ふりかえり」がなかなかできませんでした。
社風的なこともあるのかもしれませんが「プロジェクトが終わった後に一気にやる」というアンチパターンな形が多かったように思います
＃それでも「無し」よりはマシですが。
当時のチームは新人もいたので「頻繁なふりかえりとそこからのフィードバック」はきっと効果があると考えていました。
そこで、「朝会の延長戦」的な感じで、毎週金曜日の朝会の後に「プチふりかえり」と称して少し話し合うようにしました。
朝会と同じ場所ですので、チームの目の前には「今週にやったタスク」「次週にやるタスク」がタスクボード上に付箋としてあります。
＃その会社の標準的なタスクボードでは(カンバンとは違い)時系列で作られていることが多いのです。
そのタスクボードをインプットにして、KPTをサッと話しあうようにしました。対象期間は1週間ですので、15分程度ですぐに終わります。
「ふりかえり」単独の場合「今回はちょっと忙しいからスキップしようか」となることもありますが、朝会はスキップされることが少ないので、このプチふりかえりを安定して行うことができました。
改善する点としてはKPTを書き出していなかった(話すだけ)ので、ここは書いておいた方が見えるようになるので、その点はこれからの改善点です。
「今日は19時に帰ります！」と宣言します。
こうすることで「今日やること」とのバランスが分かります。
「今日やること」が残業そうな量なのに「定時で帰ります」と宣言していると、タスクが漏れていたり、勘違いしているのでは？と気づいたりします。
また表明することでその表明した人にも良い意味のプレッシャーがかかり(いつも以上に)集中できます。
＃「あれ？○○さん、19時過ぎたよ、帰らないの？」なんて声がかかって来ることもありました
さらに他のメンバーとのスケジュール調整ができるようになります。
「19時に帰る」と表明したメンバーに仕様の相談、レビューなどをお願いする場合、18時半ではなく、15時とかにお願いする必要があることに気づき、そうであれば、タスクの順序を変えるなどというようなことができます。
定時の予定を(プロジェクト状況次第ではありますが)ちょっと気をつければ防げた的な予期せぬ割り込みタスクで影響を受けるのが好きでないので、このルールは助かりました。
同僚が(朝会と)夕会をやっていたチームにいたこともあって、それについても考えてみました。
予定通り行っていないことやハマっていることなどの心配事を夕会で言う(はき出す)ことができるので、退社後から朝会までの間ではありますが、あれこれ気にかけることが少なくなります。特に週末などは効果が高そうです。
ちょっとやればクリアできそうであれば、夕会後、ペアプロなどで対応すれば、スッキリしてその日のタスクを終えることができます。
また「本当に今日それが必要なのか？」「(残業が必要でも)他の人とペアでやったりすることで早くできないか？」などを考える場にもなり結果的に不要な残業も少なくできます。
ここで大事なのは、2交代制(でも人が変わらない)のプロジェクトのように「後半戦(長時間残業)開始の合図」にしてはダメということです。
朝会はお金がかからないですし、特別な準備もそれほどは不要です。
もちろんより効果を出そうとすれば、見える化された情報は必要になります。
が、まずは集まって「リズムを作って」「隣の人が何やっているか知る」ようにしてみてはどうでしょうか？
そうすると「もっとこういう情報が見えた方が朝会が効果的になるよね？」と改善していくと思います。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像：http://www.flickr.com/photos/practicalparticipation/4055214381/
先日「プロジェクトファシリテーションパーティ2012」に参加してきました。
＃参加した皆さん、お話していただいた皆さん、スタッフの皆さん、ありがとうございました！
マルチセッションだったので、迷いましたが、以下に参加しました。
パーティー２：「実録！プロジェクトファシリテーションのWEBサービス開発運用現場への適用記」
パーティー４：「ようこそ“プロジェクトマネジメント保健室”へ！」
パーティー５：「上司・同僚にファシリテーションの重要性を体験してもらうワーク」
特に「実録！プロジェクトファシリテーションのWEBサービス開発運用現場への適用記」のセッションは「いつかお会いしたいなぁ」と思っていた方々の一人である、こしば(@bash0C)さんということもあって強く印象に残っています。
ここでは「ふりかえり」「見える化」「朝会」について「話す」→「グループでディスカッション」という流れで、@fkinoさんと@daiksyさんと同じテーブルでした。
お二人とはコンテキストは(多少)違うものの、マインドの部分は近いように思えたので、話が盛り上がりました。
そしてこの日一番の気づきもこの会話の中で出てきました。
「『可視化』と『見える化』は違う」という@fkinoさんの言葉でした。ディスカッションした末の私の解釈は以下のようなものでした。
「可視化」と「見える化」は共に情報や事象を「見えるようにする」という点では同じです。
ですが「可視化」は「見えている」までで止まっています。
一方「見える化」は「見えている」情報や事象に対して【フィードバックができる】状態にあります。
「こうしたらもっと良くなるよ」などのアドバイス、「こういう風にして欲しい」というより良くするリクエストをチームや関係者の間でやり取りできることです。
それには、場作りを含めた雰囲気、コメントをサクッと付けることができるツールだったり、プロセス、そのアドバイスを受け入れる姿勢などが関係してきます。
時々、上手く行っていないチームやプロジェクトに対し、この違いを分かっていないちょっと偉い人がテコ入れにやって来て「まずは『見える化』しろ」というシーンがあります。
その時にこの「可視化」と「見える化」の違いを意識していないと「よし、これで『見える化』ができた。大丈夫だ」と自己満足で終わってしまいます。
今まで見えていなかったことが見えるようになったのは最初の一歩としては良いのですが、その「可視化」されたことへフィードバックする環境ができていないことが多くあります。
つまり「見える化」できていないわけです。
これではチームはやる仕事(＝可視化するためのタスク)が増えたにも関わらず、自分達の状況は改善しないことになり、ますますモチベーションが下がり、バラバラになってしまいます。
というわけで、「見える化」を目指す場合、「見えるようにする」のと「フィードバックができるようにする」の2つを意識する必要があるということでした。
今まで、こういう「見える化」を何度もやってきた中で、うまく行った時、改善が出来た時は、この「フィードバックできる」環境に意識して、もしくは自然になっていたように思います。
一方、「なんかうまく行かないなぁ」という時には「可視化」で止まっていたことが、はっきりと分かりました。
他のセッション、懇親会でも色々な人の考えを聴いたり、自分の考えを整理して話すことができたりして、良い時間でした。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像：http://www.flickr.com/photos/caroslines/1371200717/
年末年始の小休止中＆次の書籍を検討中ですが、社内で行っている「アジャイルサムライ読書会」のことです。
やりはじめた経緯は(当時、同じ会社だった)@mah-labさんが何気なくつぶやいたのがキッカケです。
そこから「やってみよう！」と数人が集まって始まりました。
そのキッカケの詳細は@mah-labさんがこのイベントで話していました。
その時のスライドはこちら。
東京と大阪をテレビ会議でつないでやっています。
大阪2名(最初の頃は私1人)と東京6～8人という感じで最大10人程度の小さな所帯(でもみんな同じ会社に所属)です。
時々、話を聞きつけたり、(テーマによっては)声をかけたりしてゲスト的に参加する方もいます。
7：30～8：30と朝早い時間です。
定時後などの場合、残業や打合せなどで来れなくなることが多いと思ったためです。
毎回、対象の章…1章とは限りません…と発表者を決めてネタ振り(軽いプレゼン)を10～20分行います。
残りの時間をみんなでディスカッションしていきます。
次回のテーマや事前の議論、連絡などはyouRoomを使っていました。
(部門の違いはありますが)同じ会社だからこそ「社内やお客様の状況を共通のコンテキストとして話ができる」のは大きな特徴です。
もちろん部門やPJが違う部分もありますが、少し説明すると「あぁ、あのことね」となります。
そのため、「自分達の今の仕事とマッピングして、どう取り入れていくか？」という話が深くできるように思います。
反面、コンテキストに縛られすぎて「うちの状況では、それはムリよね」とネガティブな話になる時もありました。
また1時間という短めの時間、話が深くなってヒートアップして・・・という感じで、(終了時間を)オーバーしがちでした。
＃朝早いということも寒くなるにつれて「起きることができなくて」遅刻する方もいたりして。
この社内読書会をきっかけに参加者(とその周辺の方々)と新たなつながりができました。
もちろんディスカッションをすることで自分の中でも深く考えることにつながりました。
自分でインセプションデッキを書くことからスタートして、社内でインセプションデッキのワークショップをやったりもしました。
そのワークショップの参加者がそれをキッカケにして、そのチームや部門にインセプションデッキが広まっています。
遅くとも2月頭には社内読書会を再開予定です。
「アジャイルサムライ」はほぼ全ての章を行いましたが、そこからの疑問やディスカッションのネタはストックされています。
＃対象の本が変わったとしても、アジャイル関連の本だと思います。
こんな本に出逢わせてもらった@nawotoさん、@kakutaniさん、そしてJonathan Rasmussonさんに感謝です。
＃Jonathan Rasmussonさんのお話は3月にあるAgileJapan2012で聴くことができそうなので、楽しみにしています。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
Photo via Visualhunt.com