改善」カテゴリーアーカイブ

DevLOVE関西でタスクマネジメントについて話してきた #DevKan

DevLOVE関西“個人のタスクマネジメント”のコツや悩みを話す場で「リズムを作ってやる自分なりのタスクマネジメントの話」を話してきました。

言いたかったこと

タスクが積み上がってくると、時間も気持ちも余裕がなくなっていき、「どうやったら効率良くこのタスクを片付けることができるか?」と”やること”を前提に考えがちです。

しかし、落ち着いて一歩引いて見てみると、積み上がったタスクの中には、しなくてもなんとかなるものもあります。
少なくとも”今すぐ”でなくてもそれほど困らないものはけっこうあります。

まずは”やらないとどうなるか?”を小さく実験して、何が起きるのか観察してみることで、いらないタスクを見つけることができるかもしれません。

発表を終えて思い出したこと

発表ではデジタルツールの話しかしませんでしたし、付箋やA4の紙にタスクを書き出して消し込んでいくというアナログな運用もしています。

自分のデスクで仕事をする時にはA4のメモ用紙にタスクを書き出してやることが多いです。
ポモドーロをやっている時に思い出したものは(Trelloではなく)、手元にある紙に書いてすぐにそれまでやっていたタスクに戻ります。
そしてそのポモドーロが終われば、(目安として)15分以内に終わりそうなものはそのままやりますし、そうでなければTrelloにcardとして記録しておきます。

このあたりはアジャイルな時間管理術 ポモドーロテクニック入門の内容を応用しています。

このA4に書いていく+ポモドーロテクニックの組み合わせは自分なりのリズムづくりになっています。
すぐにするタスク達なので、自分だけにわかれば良いという乱雑な感じで書いていますし、それをリズム良く、ペンでシャッと消す感覚が自分の仕事のエンジンがかかる一因にもなっています。

Trelloの話

松尾さんもTrelloのお話をけっこうされていましたが、自分なりのTrelloの使い方などです。

Chrome拡張

  • Scrum for Trello:cardに見積時間、実績時間を入力することができるようになります(デフォルトだとプランニングポーカーで使われるフィボナッチ数列)。
  • Card Color Titles for Trello:ラベルの名称を表示してくれます。
  • CardCounter for Trello:それぞれのlistのcardの枚数を表示してくれます。

PowerUPS

Card Aging はちょっと変わり種で、放置されているとcardが”ボロボロ”になっていくエフェクトがかかります。

ステージ(Trelloではlistと表現)

  • いつかやる
  • 来週やる
  • 今週やる
  • 今日やる
  • 今やっている
  • もう終わった

「来週やる」「今週やる」は見積もった時間が週の働く時間を越えていないかチェックしています。
「今日やる」は見積もった時間が週の働く時間を越えていないかチェックしています。

「アジャイルコーチの道具箱 – 見える化実例集」を読んだ

アジャイルコーチの道具箱 – 見える化実例集」を読みました。

ギルドワークスで現場コーチとして、様々な現場がアジャイルな開発をうまくやれるような支援、現場の改善や見える化をしている自分としてはとても興味をそそられるタイトルです。
また翻訳した方々も@haradakiro@ryuzeeなど期待せざるをえない人達ばかりで、すぐに読み始めました。

読んでいる途中「あの現場のあのチームはこれが良さそうかな」「あのチームが持っている課題はまずこれをやってみて、それからこっちをやってみてはどうだろう?」とアイデアが色々出てきてワクワクしてきました。

やるかどうかは現場のチームが決めればいいですが、「こういうアイデアがあるよ」「こういう感じで一度試してみてはどうかな?」とコーチとして色々なカードを見せたり、背中を押すことができそうです。

コーチだけでなく、チームが見える化を推進していくのも役立ちます。
「見える化する対象は分かったけど、どう見える化すればいいかわからない」という悩みはここにある様々な実例でほとんど解決できそうです。悩みにピッタリのそれがなくてもパラパラと見るだけで解決できそうなヒントは浮かんできます。
#もちろんどうやって運用するか?当たり前にするか?という次のステップはありますが、「やってみる」ことはできそうです。

以下は読みながら垂れ流したツイートです。

コツ

最初に行う3つのプラクティスと継続していくコツ

このエントリは?

このエントリは達人出版会から出版された電子書籍【開発現場に伝えたい10のこと】で私が書いた内容を許可を得て転記したものです。

2014/01/14(火)にはDevLOVE関西で書き手が集まる【「開発現場に伝えたい10のこと」それぞれの後日談】を行います。
よろしければご参加ください。

では少し長いですが、お付き合いください。

最初に行う3つのプラクティスと継続していくコツの目次

前半はチームビルディングにフォーカスを当てて、私がチームに参加した際にまず最初に行うことが多い3つのプラクティスについて書きます。後半はそれらのプラクティスを導入し、継続していく時に気をつけている点を書きます。

前半:私がチームに参加したら最初に行う3つのこと

  1. 朝会
  2. ふりかえり
  3. タスクボード

後半:変化を起こそうとした時の心構え的なこと

  1. 「やり始める」のは簡単
  2. 「やり続ける」ことの難しさ
  3. 「効果を出しながらやり続ける」には……

最後に

前半:私がチームに参加したら最初に行う3つのこと

私が新しく開発チームに入った際に最初に何をするか?と聞かれるとまずは、次の3つです。それは”朝会”、”ふりかえり”、”タスクボード”です。

いずれもチームの状況を「見える化」して透明化をします。こうすることで、チームが自分達で工夫して少しずつでもレベルアップしていく状態になることが目的の1つです。もちろんレベルアップすることでユーザー、顧客へ届けるモノ、価値を期待以上にします。

透明化が十分でないチームでは、「誰がどのタスクを持っていますか?」という小さな話から、「今回のリリースの日はいつですか?」という大きめの話のいずれでも「知らない」とか、全然違う答えをそれぞれ持ってしまいます。しかも答えが違うことを分からないまま進んでいることもあります。これではチームがうまく回りませんし、レベルアップして良い成果を出すことは難しくなります。

一方、”朝会”、”ふりかえり”、”タスクボード”がチームに馴染んでいれば、”ふりかえり”で、「これまでと比較して何がうまくできなかったのか?」「これまでより何がうまくいったのか?」を検査することができます。検査によって様々な情報を得ることで、どう適応すれば良いか分かり、アクションをしやすくなります。そして、そのアクションは”タスクボード”や”朝会”によって「見える化」されていきます。

以降はこの3つのプラクティスについて詳しく書いていきます。

朝会

参考:プロジェクトファシリテーション 実践編 朝会ガイド(リンク先はPDF)

“ちょうかい”ではなく“あさかい”と読み、アジャイルな開発手法では、デイリー・スクラムやスタンドアップ・ミーティングと呼ばれることもあります。

特徴として以下が挙げられます。

1:朝行う
2:15分以内
3:チーム全員が参加し、発言する
4:昨日やったことの確認、今日やること、困っていることを簡潔に話す(長くなりそうなら別途設ける)
5:立ったまま行う

目的の1つは、メンバーが「お互い何をやったか?やっているか?困っていることはないか?」を共有し、必要であればチームが何らかのアクションを取る状態になることです。それを毎日同じ時間に同じやり方で行うことで、チームに一定のリズムを刻むことも大事なことです。詳しいやり方は上記の参考文献に掲載されています。

以下は、私が見かけたアンチパターンと私なりの解決方法です。

1:長時間ダラダラする

Scrumではデイリースタンドアップとして「15分」と定められています。それ以外のプロセスでも「短く」というのは共通しています。長くなると集中力が途切れ、しんどくなります。それぞれの状況を短い時間の中で把握できないということ自体が課題でもあります。

また、個別の課題にこだわりすぎて時間が長くなるパターンもあります。このような場合、朝会の進行役が「その話は後で個別にやりましょうか?誰と誰とができますか?」と提案するとうまく収まることが多いです。

2:誰も聞いていない

メンバーが話している時、他の人(ひどい時にはリーダーさえも)が誰も「我関せず……」という感じで聞いていないことがあります。関心事が「自分のタスク」に向かっていて、「チームとしてこのプロジェクトをどうするか?」ということに向かっていないのが原因の1つです。

このような場合、ペアでタスクに取り組むことで、お互いの状況を把握し、チームを意識しやすくします。またインセプションデッキを使って、「プロジェクトの目標を明確にし、チームとして成功させる」大事さを伝えたりします。

時には、メンバーがリーダーに向かって「のみ」話して「報告」になっていることもあります。朝会はリーダーとメンバー間のみの進捗確認や詰問の場ではありません。これが悪い方向に進んでいくとリーダーは「指示」を出し、メンバーは「指示待ち」の姿勢になってしまいます。さらには報告しているメンバー以外は他人に感心を持たなくなり、チームでなくなっていきます。

3.:見えるものがない

それぞれのタスクの量や状況が見える化されていない中での朝会もありました。WBSがファイルサーバーの奥底に眠ったままだったり、リーダーしかメンテしないとこのようなことが発生しやすくなります。まずはその日と前日の分だけでも、見える化するところから始めます。

あるチームでは、タスクボードではなくRedmineを使っていたので、スプリントでやるチケットの一覧を印刷して貼り出し、それを見ながら朝会をしていました。余談ですが、このチームが成熟してスピードが上がっていく中で、Redmineにアクセスして、チケットを操作することがボトルネックになったこともあり、最後にはRedmineを使わなくなり、タスクボードのみ使うようになっていきました。

また別のチームでは、大きいモニタの前に集まって、Redmineのチケット一覧を表示しながら朝会をやっていました。この方法は効率は良いのですが、朝会までに最新情報に更新しておく文化がないと、朝会でRedmineの操作役が他のメンバーのタスクまでいじることになり、自分のタスクを自分でマネージメントする(自分でいじる)感覚が薄くなってしまいます。

これらのアンチパターンに陥らないように、また、良い朝会をするために私が工夫してきたことです。

1:観察する

(リーダーやスクラムマスターは)できるだけ口を挟まずに場の雰囲気やメンバーそれぞれの話し方や表情などを観察します。そうすると徐々に「AさんとBさんは息があってそうだな」、「気にかかっていることがあるのかな?」とか「体調が悪そうだな?」ということが分かることもあります。

「昨日やったこと」を意識して聞いてみるのも時々行います。もし昨日やったことが当初の予定と大きく違っていることばかりであれば、(割り込みタスクが多いなどの)何か問題を抱えているかもしれません。

2:質問の形を工夫する

「課長」や「プロジェクトリーダー」のような肩書きは、その人の発言が命令になり「自分達で考える」ことを阻害してしまう場合もあります。

よく言われていることですが「You(あなた)」でなく「(止まっている)このタスクを片付けるのに、私達がやれそうなことはあるかな?」のように「We(私達)」を使った形で話すようにすると「(話している本人も含めた)チーム全員で考える」意識を持ち続けやすくなります。

3:その場で貼る

「貼っていないですがXというタスクをします。付箋は後で貼っておきます」という話が出たら、その場でさっと書いて貼るようにします。「後でする」というのは忘れてしまいがちですし、目に見えないタスクが多くなってくるとチームの透明性を徐々に奪っていきます。そのために朝会で使うタスクボードには付箋紙とペンを用意しておくとさっと書けるのでオススメです。

ふりかえり

参考:プロジェクトファシリテーション 実践編 ふりかえりガイド – オブジェクト倶楽部(リンク先はPDF)

次にふりかえりです。特徴は以下のようなものです。

1:チーム全体が、行動可能な改善策を探し、試す勇気を得ること
2:チーム全体が、これまでの行動を思い返し、新たな気づきを得ること
3:チーム全体が、やってみてうまくいった行動を、チームに定着させること
4:チーム全体が、メンバーの多様性を受け入れ、信頼関係を築くこと

ふりかえりでは「KPT」(Keep/Problem/Try:けぷと)というフレームワークを多く使うので、主にその「KPT」のことを書きます。ふりかえりの目的は、「自分達がうまくできていること、もっとうまくできそうなことはないか?」を共有して、さらに「もっとうまくできるために何をすれば良いのか?」というアクションを共有することがその1つです。

以下はそんなふりかえりでの経験談です。

1:KeepはGoodなことから導き出してみる

慣れていないとなかなかKeepが出てこなかったりします。その場合、些細なことでも良いので「良かったこと(Good)」という観点で出してもらうようにします。その良かったことを起点にして「なぜGoodと感じたのか?」→「これからもGoodと感じることができるにはどうすれば良いだろうか?」→「それはKeep(継続できる習慣)だろうか?」という流れで出てくることもあります。

なぜそのKeepが出てきたのか分からないと、偶発的なものになってしまい次に活かせないこともあります。その場合、「それは続けることができそうか?チームの習慣になりそうか?」と話し合います。

2:Problemは「それで何が困ったのか?」を意識する

「○○ができなかった」というProblemがあった時に、「それでチームは何が困ったんだろう?」と話し合うことがあります。

できなかったことは事象ですが、それで何が困ったか?を共有していないと、それに対する効果的なアクションであるTryを出せないこともあります。話し合った結果、その○○ができなかったことではチームの誰も困っておらず、○○という行為自体が不要なことであることが分かるかもしれません。

3:Tryは「それでPはなくなるか?」を意識する

1度に全てのProblemに対処するのが難しい場合もあります。その場合、ドットシールなどで投票して、どのProblemに対処していくかを決めた上で、Tryを出していきます。

一通りTryが出た後に「これらのTryができれば、次回のふりかえりではこのProblemはなくなっているだろうか?」と話し合うことがあります。その答えがNoなら、まだ何かTryが足りないかもしれませんし、もしかしたらProblemの深掘りが足りないのかもしれません。

4:観察する

何度かふりかえりをやっていると、Aさんはテストに関するKPTが良く出るなどのように誰がどの領域に強い関心事を持っているか?など色々なことが分かってきます。意外と自身では何に強い関心事を持っているかハッキリ分かっていないことがあるので、それを認識することでチームのレベルアップに繋がることもあります。

これまでのKPTを写真に残しておき、定期的に時系列に見て、KPTの割合、それぞれの内容などを話し合うこともあります。その時に過去のTryが次のKeep、Problemのどこに行っているのかトレースしてみるのが良いです。

またタイムラインという表現方法を使って、この半年や1年などでチームやプロジェクトにどのようなイベントがあったか?またどんな感情の変化があったか?などをプロットして、そこからチームの変化や成長を実感するということもします。

タスクボード

最後はタスクボードです。
参考:川口 恭伸(@kawaguti)さんの「Kanban and Scrum

タスクボードの目的の1つは自分達がどのようなことをするのか、そして今それがどのような状態なのか?を分かるようにすることです。これには、見える化、透明性の維持、周囲へのコミットメントなどが関係しています。また付箋紙などを動かしていくので、Doneに溜まった付箋による達成感、開発のリズムというようなものを感じることもできます。

私はまずはシンプルにTodo、Doing、Doneの3レーンからスタートします。

Todoのレーンでは「Doneの定義」や「Readyであるか?(タスクを着手できるか?)」などをチームと一緒に話し合ったりします。このようなポイントを見逃してタスクをやり始めると、手戻りが発生し、貴重なリソースをムダに使ってしまいます。

DoingのレーンではWIP(work-in-progress=作業途中)の数に気をつけます。これを意識しないとすぐにマルチタスクの状態になってしまいます。マルチタスクはタスクのスイッチングコストが多くなって効率が悪くなります。これもリソースのムダになってしまいます。私はWIPは多くても3までとしていて、チームができたてだったり、メンバーのタスクマネジメントの経験が浅い場合は、1にすることもあります。

開発プロジェクト以外にも、保守プロジェクトや問合せなどがタスクとして存在しているチームの場合、このWIPの制限によって「どういう優先順を付けると顧客やチームにとって良いのか?」と真剣に考えることになります。このことで自分達の生産量が向上したり、周囲との仕事の受け渡しや頼み方などにも改善が見られることもあります。

Doneのレーンでは、Doneに付箋を移動する時に「Doneの定義」に注意します。タスクを開始するとDoneの定義が修正することも時々あります。それが共有されていないといざDoneになった時に、その際に「あれ?そうだったの?」というすれ違いが発覚し、リソースをムダに使ってしまいます。

アンチパターンとしては、タスクボードの更新が全然されないことがあります。これは、タスクボードがチームから物理的に遠かったり、普段見えていなかったりすると発生します。

また、更新がされない状態はタスクの粒度が大きすぎる時にも発生します。最初はタスクの粒度が大き過ぎ、進捗が分かりづらいという状況になります。しばらくすると(チームが工夫することによって)タスクの粒度が細かくなっていきます。すると今度は細かすぎたりして、タスクを書き出す手間がメリットを上回ってしまう感覚を持ちます。その結果として「チームにとってちょうど良い感じ」のタスクの粒度が共通認識として出来上がる……というパターンとして経験したことがあります。

タスクの粒度は、チームの成熟度などのコンテキスト次第ですが、私の感覚では見積もりの最大時間が4時間程度を1枚の付箋紙(タスク)とするのが良いと思います。だいたい1日で1枚はDoneに持っていける粒度でもあり、精神的にもリズム的にも良い状態だと考えています。

タスクボードは時間が進んでいけば、そのチーム独自のタスクボードになっていくことが多いです。Readyレーンを用意してそのタスクをTodoレーンに移動できるか検討したり、Doing以外にWillDo(やる予定)レーンを作ったりしたこともあります。またタスクの付箋紙自体も追加されたことを分かるよう印をしたり、バグを付箋の色で一目で分かるようにしたり、Small/Medium/Largeの見積もりを色で分けるようにしたこともあります。

後半:変化を起こそうとした時の心構え的なこと

後半は、前半で書いたプラクティスなど新しいこと、ちょっとした変化を持ち込もうとする際に私が心がけていることなどを書いていきます。

「やり始める」のは簡単

「最初の一歩が難しいんだよ」という声もありますが、今回前半に書いたことは、いずれも1人でもできることであり、その効果を周囲に伝えることもしやすく、比較的始めやすいことです。

タスクボードは「Myタスクボード」を作り、自分のタスクをそこでマネジメントしていくようにします。

リーダーや同僚などに「今の進捗はどんな感じ?」や「後はどんなタスクが残っているの?」などと聞かれた時に、そのMyタスクボードを見ながら、サクサクと答えていくと興味を持ってもらえることもあります。このようなことが何度かあると「チームでタスクボードをやってみよう」という流れも起きやすくなります。私もMyタスクボードを出発点として、最終的にはチーム全員のタスクボードまで成長していったこともあります。

ふりかえりも1人で始めることができます。

私は(チームのふりかえりとは別に)、自身のふりかえりとして週単位で行っています。1人だと、Tryなどに対するモチベーションを保つのが(チームでやるのに比べると)一工夫必要だったりします。私は、リーダーや同僚との雑談で「こういうことを今週は自分なりにTryしてみようと思う」と宣言したりして、アクションをするようにしています。

「やり続ける」ことの難しさ

ダイエットでも経験がある方もいるでしょうが、やり始めてすぐに効果が出るわけではない……と、頭では分かっていても、数日して何も変わらないと「これでは効果が出ないのかな?」「前の方が良いのではないか?」というような考えがムクムクと頭をもたげてきて、「続ける」モチベーションが弱くなってしまうことがあります。

それまでのやり方とあまりに違うような方法をとっている場合、「前の方が(慣れていたし)良かったんじゃないか?」という声も聞こえてくることもあります。忙しくなってくると優先順位を落としたくなるのも分かります。が、このようなプラクティスは即効性のあるものではなく、じわじわ効いてきて、気がつくとチームに変化が起きていた……ということも多くあります。

一方で、それなりに続けていると今度は「マンネリ化」という課題が出てくることもあります。「なぜそれをしているのか?」という理由が消えてしまい惰性になり、「もっとうまくやる方法があるのでは?」という考えやアクションへの意識が弱くなり、すでに実状と合わなくなっているにも関わらず、「前からやっているから」という理由だけで続けてしまっている……という状態です。

このように「効果を出しながら、やり続けていく」ことは、言い訳の天才でもある人間にとってなかなか難しいことです。

「効果を出しながらやり続ける」には……

自分達はもっとうまくできるようになるという「信念」(のようなもの)、「交渉力」そして「ちょっとした幸運」が必要だと感じています。

1:「信念」

「自分達はもっと成長していき、うまくでき、それで良い結果を出すことができる」という「信念」が必要です。

すぐに効果が出なかったり、社外の成功事例が耳に入ったりすると「やり方が間違っているのか?」と思ったりすることもあります。しかし成功事例はあくまでそのコンテキストでの話に過ぎませんし、自分達が同じ状況、同じ能力を持っていない限り同じ結果にはなりません(おそらく持っていても同じ結果にはならないでしょうが……)。

すぐに成功事例に飛びついたりせず、自分達にあったやり方、エッセンスを抽出して、また「どこがうまく行っていないのか?」を冷静に客観視していく必要があります。

自分達のコンテキストは自分達が一番分かっているはずですので、ある程度は「信じる」気持ちが必要になります。もちろん自分達のやり方に(無条件に)固執することは成長を阻害する大きな要因ですので、バランス感覚も必要です。

2:「交渉力」

従来の管理手法との違いや(形骸化した)社内ルールとの衝突など外圧が発生することもあります。その外圧に負けてしまうと、新しい取り組みが定着し、効果が出るまで続けることができなくなるかもしれません。また鶏(=チーム外)の大きな声などによって自分達のやり方が脅かされることもあります。

そのような戦いに負けないように、そもそもそういう戦いをしないで済むように”根回し”などと言われる交渉力も少しは必要になってきます。

様々なタイプの上司や組織風土があります。「やり方は問わないので、とにかく結果が出れば良い」から「やり方は問わないがプロセスも報告し、もちろん結果も」というタイプ、そして「やり方もプロセスも詳細な報告を……」という感じです。

マイクロ・マネジメントが良い結果を生むことが少ないことは知られていますが、「何か得体の知れないこと」をされるのは気持ち悪い、そして自分の管理責任を問われると感じる上司や組織風土もまだまだあります。それぞれのタイプごとの関心事などを考え、うまく伝えるたり、見せることで味方にする……少なくとも敵にならないことが大事です。

多くの場合、これら「確実な成果は約束できないけれど、今より少しうまくできるようになる可能性がある」アクションに対しNo!と頭から否定されるフィードバックはあまり返ってこないと思います。もしあるとすれば、うまく「なぜするのか?」という理由や「どこを目指そうとしているのか?」などのゴールが説明できていなかったりするかもしれません。このように話を聞く側の心理的不安を取り除くようなアクションをすることも必要かもしれません。

3:「ちょっとした幸運」

本当に入ったプロジェクトがデスマーチの場合、なかなかこれらをやり始めることすらできないかもしれません。しかし、本当のデスマーチになる前であれば、少なくともこれらをやり始めることはできます。

また(数少ない話だとは思いますが)このようなアクションを一切認めない上司や組織風土も存在するかもしれません。そういう本当に「ひどい状況」に当たらないというのも、これら続けていくために必要な「ちょっとした幸運」です。

最後に

3つのやること、そしてそれらを続けることの私なりの方法を書いてみました。もちろん3つのことは他にもあるでしょうし、続けるコツも他にもあるでしょう。ぜひ皆さんのそういうコツなどを教えて欲しいですし、話し合ってみたいです。

これらをやり始めて、続けていったとしても、世界を、組織を変えることはできないかもしれません。しかし、チームは、自分は確実に変わっていくことができます。

DevLOVE関西のような多くのコミュニティでは、このような課題をテーマとして扱うこともあります。実際にアクションして解決するのはそれぞれの現場でのことかもしれませんが、ぜひコミュニティと現場を循環していくことで、自分の課題が解決し、その解決したことが、別の現場で困っている別の誰かの課題へのヒントになるサイクルが回るようになることを願っています。

※アイキャッチ画像:http://www.flickr.com/photos/stevendepolo/3605321899/in/photostream/

何かを変えたい(チェンジ)時の5つのコツ

先日「AgileTourOsaka2012 in Minoh」に参加してきました。

箕面という珍しい土地も楽しめましたし、スピーカー3人ともあまり関西ではお話されない方なので、お話が聴けて良かったです。
最初に質問や興味があることを付箋に書いて、それも絡めながら進めていくスタイルはオーガナイザーのtetsu_mさんだからこそと思いました。
#お話していただいたスピーカー、スタッフ皆さん、楽しい時間をありがとうございました!

一番、印象に残ったのは藤原大(@daipresents)さんの話でした。
#@daipresentsさんのエントリはこちら→解説!地図を捨ててコンパスを頼りに未来へ進め! Agile Tour Osaka 2012資料公開

そんな「AgileTourOsaka2012 in Minoh」のテーマは【チェンジ】でした。
その【チェンジ】について思ったことです。

時々耳にする話

「いつか変わらないといけないと思うんですよ。でも~」
こういう会話を耳にする度に…


…と思います。

「何かを変える/変わる」ことを”チェンジ”とした場合、自分がチェンジしようとする際に気をつけているコツみたいなものを書いてみます。

1:始めやすいこと

意外と始める前の手順が煩雑だったり、用意する物が多かったりする方法を選んでいることも見聞きします。
だいたい、揃えるまでに力尽きるか、揃えた時点で満足してしまったりするので、まずはすぐに始めることができる方法を選びます。

どうしても準備に時間をかけないといけないのであれば、準備をすること自体を「最初のゴール(あくまでマイルストーン)」に置くことも1つの選択です。

2:簡単に止めることができること

チャレンジの内容によりますが、「これは(自分には)向いていないかも」「この方法では難しいかも」と思ったらサッと止めて、方向転換できることもコツの1つです。
ただ、サッと止めることができるとは言え、判断は急がないこともあります。

AgileTourOsaka2012の中で藤原さんも言っていた気がしますが、自分もある程度の期間は様子を見ることもあります。チェンジにはそれ相応の時間がかかり「最初は違和感があっても、ある時期を越えるとプラスに変わる」というパターンもあります。

もう1つ気をつけることは、自分だけでなく周囲も一緒にやっているチェンジの場合、理由と共に「止める宣言」をすることです。
この止める宣言がないと、気まぐれな印象に見えますし、再びなにか行う時に「前も勝手に止めて…」と不要な抵抗を受けることもあります。

3:簡単に止めにくいこと

「2:簡単に止めることができること」の真逆ですが、これが有効な場合もあります

それなりに準備に手間暇かかっていたりすると「ここで止めるとこれまでの分がムダになる」と心理的なブレーキがかかって(ベストな状態では無いにしても)続けたりできます。
そして続けているうちに目的のチェンジができることもあります。
#ただ、意固地になって止め時を見誤るというリスクもありますが・・・

似たような話で「チェンジしたいことを周りに宣言する」というのもあります。
私は、宣言だけでなく、自分や周囲の人が見える場所にチェンジしたい内容を貼り出していたりしました。

4:早めの成功体験を得られること

チェンジに向かって動き始めた時は不安がけっこうあります。
なので、大きくなくてもかまわないので本当にちょっとした、自分達が成し遂げた成果とその成功体験が大事です。

不思議なことにそういう成功体験を得ることで、その後、何度か失敗しても「成功体験」があるため「今回はうまくいかなかったけど次は…」となり、続けやすい状態になります。
もちろん同じ失敗をしないようにふりかえりなどの対策は必要です。

5:1人でないこと

周囲に同じようにチェンジをしたい人がいれば、その人と一緒にやってみるのも1つのコツです。
もし社内にいなくても、外を見渡せばそういう人々がゴロゴロいますし、出会う機会もゴロゴロあります。

「変わらない」という選択肢もありますが、せっかく「変わりたいなぁ」と思っているなら、【チェンジ】の一歩を踏み出してみてはいかがでしょう?

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

Photo credit: nattu via Visualhunt.com / CC BY

業務の引継ぎや情報の伝達で思ったこと

今のチームで仕事をやり始めて2ヶ月半が過ぎました。
その2ヶ月半で、業務の引継ぎや情報の伝達について、ふと思ったことがあったのでつらつらと書いてみます。

自分の立場

中途入社でしたので、チームが携わっていた業務、またその業務に関するプロダクトへの知識は低い状態でした。
チーム自体はあまりメンバーは出入りせず、しばらくの間、この業務、プロダクトに関わっている状態でした。

職位としては上長にあたる立場で、期待されている役割としては引っ張っていくことが存在していましいた。

この2つの自分の状況が良いように影響し、うまく情報の伝達ができました。さらに改善できそうなプロセスやよりうまくやるためのボトルネックまで見つけることができました。

伝える側の話

私に情報や状況を伝えてくれる当初からいるメンバーの視座で見てみます。

日常的に忙しいと、後から入ってきたメンバー(今回の場合だと私)に業務や決まり事などを説明する時間が十分確保できないことがあります。
十分確保できないと「ここにあるから後は見ておいて」と、伝達を端折ってしまい、相手の理解度が不十分なまま日常の業務を進めることになります。
不十分なまま業務を進めると、アウトプットの質が十分でなく手戻りが起きることも多くあります。

今回の状況では、伝える相手は職位が上ということもあり「この人、わかっていないなぁ」と思いながらも丁寧に伝えようとしてくれました。
#もちろん「上長だから」丁寧に伝えてもらえるというわけではなく、聞き手の態度や姿勢なども関係しているとは思います。

この時間をとって、より丁寧に伝えようとすると、伝える側もあまり意識していなかった暗黙知が表出化してくることもあります。
この表出化の過程で、これまでなんとなく続けてやっていたけど、面倒、複雑なやり方であることに気づくこともあります。面倒や複雑なプロセスはムダやムリがあることも多くあり、改善するポイントでもあります。
「伝える」という行為を通じてこのような改善するポイントが見えることもメリットの1つだと感じました。

本来であれば相手が誰であれ、そのような暗黙知やムダなプロセスが明確になれば嬉しいのですが、なかなかうまくいかない経験をした方も多いと思います。

聴く側の話

伝えてくれる相手が職位的に上の場合だと、説明されている内容に違和感を覚えてもなかなかしつこく質問して聞けないこともあります。
またその業務やプロダクトに対する聴く側の経験が浅かったりすると、そもそもそのような質問を思い至らないかもしれません。

今回の場合、私が業務、プロダクトそのものの経験は少なくても、エンジニアとしての経験はそれなりにあったので、その経験と照らし合わせた上で伝えられた内容に対して質問や疑問を持って話をすることができました。
結果として、聴く側の動きによっても、先に書いたように暗黙知やムダなプロセスが明確になりました。

聴く側としては「聞くのが恥ずかしい」「こんなこと聞いたらバカにされるのでは?」といった自分をよく見せようとする気持ちが強くあると、知ったかぶりな態度を取ったり、表面的なことのみでわかった気になったりして、うまく情報を伝達できないということもあります。

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

Photo credit: davis.steve32 via Visualhunt.com / CC BY

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に遠征した際のもの)。

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

フリカエリ

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。

今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。

やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。
以下は、今のチームでやっている工夫や気づいたことです。

W(分かったこと)を書き出す

KPTに似たようなフレームワークで「YWT」というものがあります。
Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も・・・。

Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
それを「W(分かったこと)」として書き出します。
分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。

日常的に書き出す仕組み

youRoomをコミュニケーションツールとして使っています。
そこにイテレーション開始時に”あらかじめ”フリカエリ用のスレッドを立てておきます。そして、日常の開発などで「あっ!これはPかも」「次はこんなこと(T)したいなぁ」と思えば、すぐに書き込むようにしています。

イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
早く対応した分だけ、チームのパフォーマンスが上がります。
なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。

Problemの深掘り

これは最近やり始めたことです。

Pに対してTを書き出しますが、中には「本当にそれでPは解決する?もう少し深く話した方がいいのでは?」というものもあります。
例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。

このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。
こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。
(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな?」と半信半疑な雰囲気になっているPを取捨選択する必要があります。

ProblemのTry以外にも、チャレンジしたいTryを書く

(Pとは関係なくても)「こんなことにチャレンジしたい!」という意味のTも書き出すようにしています。
そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。

(サインアップのように)「自分がやりたい!」と手を挙げることで、その質やコミット感が強くなるのが良い点です。
Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
ですので、前向きにやる…とのが難しいこともあります。

それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。

同じProblemが上がっていないかを見る

同じチームで何度かフリカエリをやっていると「あれ、これって前も同じようなPが上がっていなかったっけ?」というシーンが出てくることもあります。
同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。

そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか?を見るようにしています。
そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。

気づき:暗黙知となったKは減っていく

同じチームでフリカエリを行なっていると(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」に参加してきました。
#参加した皆さん、お話していただいた皆さん、スタッフの皆さん、ありがとうございました!

参加したセッション

マルチセッションだったので、迷いましたが、以下に参加しました。
パーティー2:「実録!プロジェクトファシリテーションのWEBサービス開発運用現場への適用記」
パーティー4:「ようこそ“プロジェクトマネジメント保健室”へ!」
パーティー5:「上司・同僚にファシリテーションの重要性を体験してもらうワーク」

特に「実録!プロジェクトファシリテーションのWEBサービス開発運用現場への適用記」のセッションは「いつかお会いしたいなぁ」と思っていた方々の一人である、こしば(@bash0C)さんということもあって強く印象に残っています。

ここでは「ふりかえり」「見える化」「朝会」について「話す」→「グループでディスカッション」という流れで、@fkinoさんと@daiksyさんと同じテーブルでした。

お二人とはコンテキストは(多少)違うものの、マインドの部分は近いように思えたので、話が盛り上がりました。
そしてこの日一番の気づきもこの会話の中で出てきました。

一番の気づき

「『可視化』と『見える化』は違う」という@fkinoさんの言葉でした。ディスカッションした末の私の解釈は以下のようなものでした。

「可視化」と「見える化」は共に情報や事象を「見えるようにする」という点では同じです。
ですが「可視化」は「見えている」までで止まっています。
一方「見える化」は「見えている」情報や事象に対して【フィードバックができる】状態にあります。

【フィードバックができる】状態とは?

「こうしたらもっと良くなるよ」などのアドバイス、「こういう風にして欲しい」というより良くするリクエストをチームや関係者の間でやり取りできることです。
それには、場作りを含めた雰囲気、コメントをサクッと付けることができるツールだったり、プロセス、そのアドバイスを受け入れる姿勢などが関係してきます。

時々、上手く行っていないチームやプロジェクトに対し、この違いを分かっていないちょっと偉い人がテコ入れにやって来て「まずは『見える化』しろ」というシーンがあります。

その時にこの「可視化」と「見える化」の違いを意識していないと「よし、これで『見える化』ができた。大丈夫だ」と自己満足で終わってしまいます。

今まで見えていなかったことが見えるようになったのは最初の一歩としては良いのですが、その「可視化」されたことへフィードバックする環境ができていないことが多くあります。
つまり「見える化」できていないわけです。

これではチームはやる仕事(=可視化するためのタスク)が増えたにも関わらず、自分達の状況は改善しないことになり、ますますモチベーションが下がり、バラバラになってしまいます。

というわけで、「見える化」を目指す場合、「見えるようにする」のと「フィードバックができるようにする」の2つを意識する必要があるということでした。

「可視化」だけではうまく行かない

今まで、こういう「見える化」を何度もやってきた中で、うまく行った時、改善が出来た時は、この「フィードバックできる」環境に意識して、もしくは自然になっていたように思います。
一方、「なんかうまく行かないなぁ」という時には「可視化」で止まっていたことが、はっきりと分かりました。

他のセッション、懇親会でも色々な人の考えを聴いたり、自分の考えを整理して話すことができたりして、良い時間でした。

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

※アイキャッチ画像:http://www.flickr.com/photos/caroslines/1371200717/

チームへのRedmineの効果

Redmine Advent Calendar jp 2011の25日目になります。

#余談。本場のAdvent Calendarは「24日まで」を窓を開けていくことでクリスマスを祝うそうです。一方、【技術系】Advent Calendarは「25日」まで書くことが多いようです。

というわけでトリなわけですが、相応しい壮大な話ではなく「チームへのRedmineの効果」について書いてみます。

普段よく言っている「Redmineの効果」

先日、社内で「Redmineを活用したタスク管理改善セミナー」というのをしました。

Redmineの簡単な紹介から始まり、事例紹介を交えてそこから得た自分なりのメリットやTips、考え方をお話しました。
後半は参加者の方と「こんなことで困っていませんか?」などのディスカッションをしました。

その中で「Redmineを使った効果はどういうものがありますか?」と質問がありました。
私はたいがい「Redmineは【見える化】【トレーサビリティ】【開発リズム】を強化してくれるツールです」と「ツールを入れることが大事ではなく、そのプロセスやマインドを変えていくことが大事」の2つを合わせて答えています。

最近はそこに「教育に伴うチーム力向上の効果もあるかも?」と思い始めました。

教育効果があると思ったシーン

あるチームは、割とエンジニアとしての経験年数が少ない人が多かったのですが以下のような変化が出てきていました。

  • 1:チケットの書き方が(良いレベルで)揃ってきた
  • 2:(チケットに書く)設計やそれまでの経緯を共有することができて、設計の技術が上がってきた
  • 3:コードレビューの結果を共有することができて、実装のレベルが上がってきた

1:チケットの書き方が揃ってきた

親チケットに要求をプロダクトオーナーが中心となって書いています。
その要求に対し「どう作るか?」と言った子チケットは担当するメンバーがそれぞれ自分で考えるような開発プロセスで回っています。

最初の頃はそのチケットの粒度が大きすぎたり、内容が抽象的過ぎることもありました。
また、粒度が大きすぎることも原因の1つとなって見積もり(予定工数)の精度が低いこともありました。

そんな状況からイテレーションを繰り返していくうちに、他のチケットの良い粒度を参考にしたり、自分が書いた粒度が大きいチケットを苦労しながら片付け、それをふりかえることで、分かりやすいチケットの書き方がチームの中で浸透していったように思います。
ここで言う「分かりやすい」とは自分以外にも「チームが見ても分かりやすい」ということです。
「チームが見ても分かりやすい」ということはチケットの引き渡しをやりやすいということにもなります。

2:設計の技術が上がってきた

1はチケットの書き方の粒度のお話ですが、こちらはチケットに書く内容の話です。

チケットに「この設計はどういう考えで、この結論、仕様に至ったか」を書くことがあります。
特に複雑な要求や仕様の場合「A案、B案、C案と考えたけど○○な理由でB案で行く」という風に議論の過程も書くこともあります。

ちなみに「設計書」と呼ばれるドキュメントには「どういう設計になっているか?」は書かれていますが、「なぜこれになったか?」はあまり書かれていないと思います。
それ故に次にその機能を修正する際に余計なリソースがかかっているように思います。

そういうチケットを担当することで、設計の仕方や思考の経緯を学ぶことで設計の技術を上がってきたように思います。

3:実装のレベルが上がってきた

コードレビューはRedmine Code Review プラグインを使っています。

それまでのやり方(コードをプリントアウトして行ったり、レビュー指摘内容はExcelに書く)に比べると、効率が良くなっていますし、指摘内容の共有をしやすくなっています。
もちろんレビュー指摘もそのままチケットに登録されるので「どのように対応したか?」まで共有しやすくなっています。
そのため若手や新しく入った方が、過去にどのようなレビュー指摘があったかを見ることでそのようなコードは書かないようになってきました。

またそうなることで、コードレビューアの負担も軽くなり、より有効に時間を使うことができます。

チーム構成やその入れ替わりの頻度などによっては、Redmine(ITS全般でも同じことが言えますが)のこういう側面に着目してみても、使うことによるメリットは大きいと思います。

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

Jenkinsさんと気軽に友達になってみませんか?

今のチームではこちらのエントリにも書いたように「Jenkinsさん」はチームの一員・・・と言うほど、色々なことをしてもらっています。

使い始めるのは簡単だけど…

一方、社内でJenkinsのセミナーなどの出た声を聞いてみると「現場で入れてその後、継続して使うのが難しい」という声がチラホラ聞こえてきます。
どうやら「導入すること」は(上司などが「そんな訳の分からないもの入れるな!」と言わない限り難しくないのですが)「mavenなどの設定、Jobのメンテナンスが大変そう」と思っているようです。

そういうチームではリソース(できる人がいないし、仮にいてもそういう余裕がない)も無く「継続して使うのは難しい」という判断が多いようです。

まずは軽く使い始める

そんな時に思うのが「フルスペックでなくても【段階的に】使い始めてもでも良いのでは?」ということです。
100点(フルスペック)であればBestですが、何もやっていない0点よりも少しでもやっている方が良いという精神です。

「構成管理からチェックアウトしてコンパイルエラーが出ないか?」だけでもチェックします。
これで(別の誰かが)チェックアウトしたら壊れている…ということを早めに見つけることができます。

次にcheckStyle、PMDなどの静的チェックをやってみます。ルールのファイルさえあればすぐに導入できます。デフォルトでも良い感じにチェックできます。

これらが安定して実行されるJobがあるだけで「よろしくない」コードが混入するのを防ぐことができます。
少なくともコードレビューで「インデントが・・・」なんて指摘はしなくて済みます。

静的チェックの次は…

JUnitやSeleniumのテストはテストコードをいるので、ちょっと置いておくとして、次はデプロイに取り組みます。
本当はこの時点でテストコードを書き始めてくれると嬉しいのですが…。

これで常にチーム全員(チーム外の人も)が、動くアプリケーションを常に見ることが自動化できます。
時々ある「オレの所では見えるんだけど・・・」という状況も少なくなります。

そして、並行して「見える化」を進めるため(checkStyleなどの)レポートを表示します。
コードの出来高などもレポートするようにすると「やる気」も出てきます。
またcheckStyleの結果などがブルーだったりすると「うまく行っている」感が出て、チームのモチベーションアップにもなります。

そして自動テストへ…

ここまで来ると「テストの結果も見えると良いよね?」となって、テストコードやSeleniumのシナリオを書きやすくなります。
この時も「カバレッジ100%じゃないと意味がない」わけでなく、まずは重要なクラスや変更が入りやすいクラスからコードを用意すれば良いと思います。
今のチームでも、Jenkinsさんに色々やってもらっていますが、最初からいくつものJobやレポートがあったわけではありません。

使いながら「こんなことが自動化できると嬉しいね」「この情報がレポートで見えると嬉しい」という話が出る度に運用を追加していきました。

簡単なJobでも最初は思いの外、なかなかブルーにならないと思います。
でもそれまで「成功/失敗が分からなかった」ことが「分かる」ようになったことが変化の一歩(改善)です。

ですので、「大変そうだから」と尻込みせずに、気軽にJenkinsさんと友だちになってみてはいかがでしょうか?

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

やりたいことをするために一歩進んでアクションしてみる

あるエンジニアと話した時に「雛鳥が親鳥からエサをもらうように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはどうか?」と思うことがあります。

やりたいことを周囲に伝えていますか?

「これからどんな仕事に携わったみたい?どういうことをやってみたい?」と質問を投げた時の反応は様々です。

「平穏にサラリーマンできればいいです」という声もあれば、「プロジェクトマネージャーになって大きなプロジェクトを回してみたい」「アーキテクトになって技術でリードしたい」「もっとお客様に提案したい」「今はJavaだけど、これからはRubyでプログラミングしたい」など、様々なやりたいこと、ありたい姿、キャリアプランなどその人の想いが出てきます。

このようなやりたいことは、何もせず待っているだけで実現することは稀なことであり、実現するためには「私はこれをしたい!」と周囲に知らせる、発信する必要があります。定期的にあるフォーマルな評価面談から、呑み会やちょっとした日常会話でのインフォーマルな場まで色々機会があります。
#自分の経験で、ポロッと社内SNSで呟いたことが、関係者の目に止まってやりたかったことができるようになった話もあります。

このような発信を受け取った上司は「自分からやろうとしていることをなんとか実現してあげたい」という心境になるのが大半かと思います。

やりたいことを実現するために何かしていますか?

そこで「それをやるために、今まで何をしてきた?」「Rubyがしたい?ならサンプルで書いてみてどうだった?」「プロジェクトマネージャーになりたい?今一緒にやっているプロジェクトマネージャーから何を学んだ?」と”やりたいことに近づくアクション”の話になると、本人は途端にトーンダウンしまうことがあります。
「そこまではやる時間がなくて(ゴニョゴニョ)」「実際に使うプロジェクトに入るのが決まってから勉強しようかと(ゴニョゴニョ)」といった様子です。

今の自分が「できること」と「実際にしたいこと」にはギャップがあります。そのギャップを埋めるのは自分です。誰かが埋めやすくなるように手伝ってくれることはありますが、最後は自分で行動して埋めるしかありません。

こういう発信を受け取った上司はこのようなアクションをしているか?そのアクションのアウトプットはチャレンジしてもらっても大丈夫そうか?という視点でも見ています。

雛鳥が親鳥からエサをもらう時のように口を開けて待っているだけでなく、一歩進んで、アクションを起こしてみてはいかがでしょうか?

Photo credit: coniferconifer via Visualhunt.com / CC BY

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

ニコニコカレンダー

先日、チームのフリカエリをして、その時の(自分の)ネタに半年前から付けている「ニコニコカレンダー」を見てました。
「ニコニコカレンダー」の説明はこちらで。

私の今の使い方はデスクの卓上カレンダーにちょっとした一言と一緒に書いています。
ただ、ここ1ヶ月程は(チームで使っている)Redmineにニコニコカレンダーのプラグインを入れて、そちらも使っています。

で、その卓上カレンダーのニコニコカレンダーをそのまま公開しようとしましたが、仕事のメモ書きもあったので、集計結果だけ。

nikonikoC.PNG

こうして並べてみると、毎月の様子がなんとなく分かります。
3ヶ月目、6ヶ月目が他の月に比べ、「良い」が少ない(特に3ヶ月目)のは、リリース前でバタバタしていたせいです。
6ヶ月目はその反省も踏まえ、多少改善されていますが。

半年付けていて思ったことの1つは、あまりロジカルな基準を設けない方が良いということです。

人間なので昨日と今日では同じ出来事があっても感じ方が違うこともあります。
ある日は「良い」でも、また1週間後に同じようなことがあってとしても「普通」を付けても良いと思います。
「なぜ今日、これを『良い』と感じたのか?」とその自分の感覚を深掘りできれば、何か見つかるかも?と思いました。

また「今日は開発が進んだ!良かった!」と思って「良い」と付けたとして、それが(例えば)1週間続いたとすると、その進捗のパフォーマンスや「良かった」という感覚が慣れて「当たり前」になって「普通」を付けていたこともありました。
これはある種、自分のレベル(基準)が上がっているを示しており、「では自分が『良い』と思えるのはどんな価値を出した時か?」という切り口で考えみると面白いかもしれません。
やり過ぎると疲弊したりするので、あくまで持続可能なペースでレベルを上げていくと良いと思います。

日々のタスクが忙しいとなかなか付ける余裕が無いと思いますが、帰り際の数分、もしくは朝の数分をニコニコカレンダー(を使ったフリカエリ)を続けると、数ヶ月には何か見えてくると思います。

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

会議でメンバーが意見を言いやすくなる方法

会議が「20人以上」かつ、担当者レベルからマネージャ、部長クラスが「一堂に会する」ような場合、活発な議論、質疑応答が飛び交うことは稀かと思います。
部長から一方的に報告や連絡事項が行われ、他のアジェンダも双方向とは言い難いものになっています。

そんな会議で見かけるシーンはこんな感じです。

部長:「(ひとしきり報告が終わった後)みんな、何か意見、質問はないか?」
…シーンとする会議室…
部長:「A君はどうだ?」
(半ば無茶振りをされた)A君:「ええと…(ちょっと的外れ、もしくは分かり切っている質問をする…」

そのような会議で、意見を求め、疑問点を抽出し、議論をするのであれば、運営、進め方を工夫する必要があると思います。
私が今までやってきた中で効果があったと思われるものです。

1:質問を考えておいてもらう

急に「質問ある?」とふられるから的確な質問ができない部分もあります。
それを事前に資料を読み、それなりに疑問点を整理しておくことで質問がしやすくなります。

「事前になんて時間がないよ!」という程、忙しいのであれば、その会議に出ずに本来のタスクをやった方が良いと思います。似たようなことはこちらのエントリに書いています。

2:質問の例を示す

促す時に「何か質問ない?」の後ろに「そう言えば、○○というこんな質問があったね。こんな感じで良いので…」と簡単な質問の例を示します。
質問者に「そういう簡単な質問で良いんだ…」と思ってもらうことができます。

3:質問をグループで考える

2、3人を1グループにして、そこで相談して、質問をしてもらう形にします。1人だと言えないことでも、「グループで検討した」形式なら質問も出やすくなります。

4:ファシリテータ役を作る

進行、推進を部長ではなく、ファシリテータ(の適性がある人)が行います。部長クラスが議長役も兼ねるとたいがい独演会的になってしまいがちです。

部門の会議は多くの人が集まる割りには、アウトプット(価値)との費用対効果が良くない会議の1つだと思います。
そこには多くの改善の余地が残されています。
それを実現できれば生産性の向上も見込めますし、メンバーが自発的に発言する雰囲気作りにも役立ちます。

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

Photo on Visualhunt.com

(研修主催者が)良いフィードバックを得るためには

社内のある研修に参加した時(とその後)に「良いフィードバックを得るためには…」を考えさせられたので書いてみます。

その研修は、(何度も行われているものですが)私が参加した回はそれまでのやり方を大きく変えたとのことでした。
#私は「それまで」をあまり知りませんが。

進行役の方が「ぜひ(やり方を変えたこともあって)フィードバックを得たいので、アンケートを後日送るので、忌憚の無い意見を聞かせてください」と言っていました。
本当に忌憚の無いフィードバックが得て、良くしていくつもりなら、その場で声をかけて(10分でも良いので)直接話したりするのが良いのにと思いました。
#午前中の研修だったので、なんならお昼を食べながらでも。

会話だと受ける側も「なるほど~、じゃあ、こういうのはどう?」と、キャッチボールをしながら進めることができます。
また文章だと当たり障りのない回答になりがちでも、会話を通じて(論理的ではないかもしれませんが)本音を聞けたりします。

話を戻すと、そのアンケート依頼が届いたのが研修から1週間後のことでした。
忙しい現場だと、1週間も経つとせっかく研修で得た気づきやフィードバックも薄れていることが多いです。
「あぁ1週間前の話かぁ、どうやったけなぁ…今、忙しいし、当たり障りのないこんな感じで…」という感じで。

そんな状況だと本来得られるフィードバックの価値が小さくなり、もったいないと思います。
#私はアンケートの回答に「アンケート依頼が遅いっす」と書きましたが(笑)。

「アンケートを取る/取って分析する」のが目的となっていて、その先にある「研修を良くする」「参加者にとってより価値があるものにする」意識が弱いのかなと思いました。

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

Photo credit: cogdogblog via VisualHunt / CC BY

もっと会議の時間を有効に使いませんか?

今回は、ある会議に出ていて「もう少し効率良く時間を使えるなぁ」と思ったことを書きます。

出席者は地理的に離れている複数チームです。
チームごとのタスクは異なりますが、活動領域には重複する部分もあり協力して動くのが良いという状況です。
日常の情報共有も社内SNSを使って頻繁に行われており、そこに進捗や状況、課題などを書き込んでいます。
会議は、その社内SNSをみんなで見ながら進めていきます。
割とアジェンダもあり、決め事もそれなりに決まっていくのですが、こうしたらもっと良いのになぁと思う改善点があります。

それは報告の仕方…より言うと【報告行為自体をしないで良いのでは?】ということです。
会議の中で、その社内SNSに書いていることを読み上げていくのです。
この時間がもったいないなぁと思うわけです。
#書き忘れていたことや些末なことは口頭で補足して良いとは思いますが。

タスクの特性上、「報告」をインプットに「どうしたら良いか?」「そもそもどういう方向でするべきか?」など施策や手段を議論する必要があるものが多いので、そちらにより時間を使えればなぁと思います。
#そういう議論が不要なら、それはそれで会議が早く終わるので、良いことです。

事前に報告を確認できる社内SNSを読んで、質問や意見をそれなりに考えた上で、議論するように時間を使ってみたら…と思うわけです。
「忙しくてそれを読む時間が無くて…」という方もいます。

ただ、報告を読んでそれなりに考えるのは、10分…長くても30分もあればできると思います。
その時間を取れない程、忙しいのであれば、そもそも会議に出るよりも、その忙しさを解消するようなアクションをした方が良いと思います。
#議事録はその社内SNSを見れば分かりますし。

あと思うのは、その場で初めてその報告を読んで、深い議論をしたりできるんだろうか?と思います。
#頭の回転が良く、即応性に優れていれば良いのですが、私はこの辺が苦手なので…。

この会議が始まった当初は交流がなく、そもそも「お互い何やってるか全く分からない」状況だったので、お互いを知る目的もあり多くの時間を使い、このやり方をしていたと思います。

最近はそれらの目的も達しつつあるので、もっと「リソースの選択と集中」など議論の時間を増やし、ステップアップを目指しても良いと思います。

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

Photo via VisualHunt

雛形やテンプレートは現場の役に立って「ナンボ」

ある程度の組織にはPMO(プロジェクト・マネジメント・オフィス)や「品質標準化グループ」のような部署があり「設計書のフォーマットはこういうのを使ってください~」「レビューではこのチェックリストに沿って使ってください~」とテンプレートファイルや雛形が色々と用意されたります。

そういうのをプロジェクトの規模や状況、メンバーのスキル等に合わせてうまくテーラリングして使えれば、そのプロジェクトのQCDに貢献できる要素のものです。
#妄信的に「標準なんだから使え!」なんて説明責任も果たさずに強制的に言うともちろん猛反発を食らいます。

前職では、こういうテンプレートやチェックリストなんかを「作って」→「(頼み込んで)使ってもらって」→「改善して」と、現場のプロジェクトメンバーに使って「もらう」側にいました。

そして、今では「使う」側にいて、両方の気持ちはそれなりに分かっているつもりです。
先日、私の所属する会社のそういう部署から配布されたあるテンプレートが「う~ん」というもので、ちょっと残念な気持ちになりました。

それは(よくあるExcelの)チェックリストで「チェックした日付」を入力していくものでした。
が、その入力欄はどう見ても(実際に入力して見ても)入りきらない…####となってしまう…横幅しかありませんでした。
#よりによってこのチェックリストはプロジェクトを進める上で必須なようでした。

配布する前に少しでも「自分が使う立場」で入力すれば「お!?これでは使いにくいわ」と気づくようなことです。
こういうことが何回か続くと、現場と軋轢が生まれていくんだろうなぁと思いました。
冷静に考えれば「そんな些細なこと…」ですが、多忙な現場にとっては(しかも必須なドキュメントで)「なんじゃこれ!あぁもうめんどくせ~」になって拒否反応が広がっていくような気がします。

こういう部署(やその雛形やチェックリスト)の価値は「現場の方に使ってもらって、そして役立ってナンボのもん」なので、ちょっと悲しくなりました。

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

Photo credit: BMeunier via VisualHunt.com / CC BY-SA

週次フリカエリ

最近、お客様への納品が終わったプロジェクトで採用した「プチフリカエリ」について書きます。

(私の所属企業、かつ、知っている範囲では)「フリカエリ」は(大規模プロジェクトでは)工程の終了時、(小規模プロジェクトだと)プロジェクト終了時に行うことが大半です。

それ自体は有用なのですが、時間が空くと「フリカエリ」の効果も薄くなるので、私は「プチフリカエリ」と(勝手に)名付け、毎週金曜日の朝会の一部で行っていました。

普段の朝会では「昨日やったこと」「今日やること」「(あれば)問題点」を簡潔に述べ、あまり所感などは言うことはあまりありませんが、「プチフリカエリ」では「今週のタスクから学んだこと(と、簡単な感想)」を簡単に発表します。

「プチフリカエリ」をした理由として…。

1:メンバーの構成

このプロジェクトは私を含めて4人で、(技術的に優秀ですが)もう少しアンテナを広げて欲しいと(個人的に思う)若手メンバー、新人、そして、パートナーさんという構成でした。
このパートナーさんは仕事や技術に対する姿勢から学ぶべきところが多く、そこから吸収して欲しいと期待したためです。

2:プロジェクトの特性

もう1つは(期間としては短かったですが)、要件定義を除く、外部設計からシステムテスト、そして納品までシステム開発のほぼ全工程のプロジェクトでしたので、各工程で気付くがあるだろうと(特に新人には)。

結果として、ほぼ毎週行い続けたこともあってか、各工程でそれぞれ何らかの気づきや学びがあったようです。
#私自身も今回のプロジェクトでは学ぶことが多くありました。それはまた別エントリに書くとして。

ストレッチ的な目標として「学んだこと」から、深掘りした考察や横展開をする等して、各自の基礎能力(仕事力みたいなもの?)の底上げができれば…と期待はしていました。
本音を言うと、そこまでは至らなかったのが少し残念です。

とは言うものの、この習慣が根付いて、次やまたその次のプロジェクトは各自が一段上のレベルで仕事をしてくれれば良いなぁと思っているわけです。

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

Photo credit: -will wilson- via Visualhunt.com / CC BY-NC-ND

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ[読書感想]

ワンランク上の問題解決の技術《実践編》 視点を変える「ファンクショナル・アプローチ」のすすめ
著者:横田 尚哉

問題解決がテーマの本は色々読みましたが、その中でも良書の部類に入ると思います。

ポイントは題名にある「ファンクショナル・アプローチ」という手法です。
ある程度、この分野(問題解決)の知識、経験があれば題名の通り「ワンランク上の」考え方として使うことができると思います。

◆目次
1章 ワンランク上の問題解決とは
2章 実践ファンクショナル・アプローチ―ステップ1・準備
3章 実践ファンクショナル・アプローチ―ステップ2・分解
4章 実践ファンクショナル・アプローチ―ステップ3・創造
5章 実践ファンクショナル・アプローチ―ステップ4・洗練
6章 日常をファンクショナル・アプローチで考える
終章 目標に向かって、とるべき針路を見つけよう
付録 ファンクショナル・アプローチ・シート

私が印象に残った箇所を羅列すると…。

問題解決のカギは「問題の認識」と「改善点の特定」

ワンランク上の問題解決をもたらす思考のルール

1:固定観念にしばられず、前回と違った方法を試してみる
2:手段にこだわるのではなく、改善点に焦点を当てる
3:「見落とされている改善点」を探す
4:過去を手放し、未来のあるべき姿から発想する

身体的/精神的に疲れていて、余裕が無い状態だと安易に↑の思考に陥ってしまい、せっかくの問題解決の機会を逃していないか自問します。

「それは何のため?」「それは誰のため?」

これらの答えに窮するのであれば無駄な努力(=そもそも目的がおかしい)というロジックです。
似たような思考で、私は「これが解決すると誰がハッピーになる?」と考え、そしてそのハッピーになる人物にとって「どうあって欲しいか?」と思いを巡らせ解決策を考えたりします。

「手段志向」よりも「目的志向」

(上の話と似ていますが)問題/課題に対して「どのように~」と考えるのが手段志向で、「何のために~」と考えるのが目的志向であると定義し、目的志向で考えていきましょう(これが本書でいう「ファンクショナルな視点を持つ」ということ)ということです。

より効果的な解決手段を見つける5つのヒント

1:使用者優先の原則
2:機能本意の原則
3:創造による変更の原則
4:チームデザインの原則
5:価値向上の原則

ファンクショナル・アプローチの4つのステップ

準備→分解→創造→洗練とありますが、特に「分解」の記述は興味深いものでした。
上位/下位を設定したファンクションに対し…
「もし上位ファンクションが必要なくなれば、下位ファンクションも必要なくなるか?」
「下位ファンクションは、上位ファンクションの達成に役立っているか?」
「もし下位ファンクションが機能しなければ、上位ファンクションはまだ機能しないか?」
…と問いかけし、それに違和感があれば、問題/課題に対する目的が間違っているというロジックです。
そしてそれらを繰り返す中で問題/課題の本質であるキー・ファンクションを見つけ出していくという内容です。

ひょっとすると他の問題解決の手法や考え方を知らない方が読むと比較検討ができなかったりして、理解が少し難しいかもしれませんが、何度か読み、実践をこなすことで「あ、そういうことか!」と分かると思います。

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

Photo credit: Create-Learning Team Building & Leadership via Visualhunt / CC BY

1回の会議・打ち合わせで必ず結論を出す技術[読書感想]

1回の会議・打ち合わせで必ず結論を出す技術
著者:斎藤 岳

題名の通り、会議/打合せでいかに(参加者全員が納得し、次のアクションへつながる)結論を出すかを書いています。

◆目次
第1章 「結論を出す能力」を身につけよう(なぜ、会議の技術を学ぶのか
世の中に溢れる「メタボ会議」 ほか)
第2章 会議・打ち合わせを科学する(「結論が出る」メカニズムとは?
会議の「負のループ」を断ち切るには? ほか)
第3章 会議・打ち合わせの技術を知る(ゴールはなに?
アイスブレイク・巻き込み ほか)
第4章 困った!問題にどう対処する?(問題のある参加者にどう対応するか
グループが問題に直面したときにどう対処するか)
第5章 プロジェクトにおける会議のコツを学ぶ(「メタボ会議」ではプロジェクトは失敗する
難易度が高い会議では、準備が重要 ほか)

よく見かけるNGな会議/打合せを「メタボ会議」と名付け、それをなくすために「7つの心得」「11の技術」を紹介していくという流れになっています。

私が印象に残った箇所を羅列すると…。

「発散」「収束」のギアチェンジ

私自身が心の中で気をつけているつもりですが、参加者全員で共有できているか?、また、場の雰囲気がそうなっているか?までは辿り着いていないなぁと。

GAPのP(Point of view)

ハッとさせられました。G…Goal、A…Agendaは意識していてもPまで意識できているかは弱いかも…。

良くない会議の特徴

これに陥っていないか?をセルフチェックに使えそうです。

キーワード「今日のゴールはなに?」

特に社外のお客様との打合せに一緒に行くメンバーと事前に意識合わせをして「打合せが終わった時にどんな状態になっていればOKなのか?」を共有しておきます。

ラップアップ

色々話した末の結論の確認は大事で、これを怠ると「で、結局どうなの?」とまた振り出しに戻ってしまいまうこともあります。

後半の「困った人/状況への対応」部分は、後付けな感じがして少し蛇足かな?と思いましたが、前半…特に事例はOK/NGケースをそれぞれ対比しており、分かりやすく「すぐに実践できる」内容が多いように感じました。

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

Photo credit: shoothead via Visualhunt.com / CC BY-ND