読者です 読者をやめる 読者になる 読者になる

「ピープルウエア」を読みました

書評

事務所にあったやつをひっぱってきたので、最新でないちょっと古いやつ。名著と言われてたけど読んだことなかったし、今の立ち位置的に読んでおいて損はないと思って。

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

ピープルウエア 第2版 ? ヤル気こそプロジェクト成功の鍵

第 II 部:オフィス環境と生産性

騒音、特に電話の話。電話という点では、うちにはそこまで影響がないとは思ってます。が、(別チームの)ミーティングがうるさい問題は以前ちょっと感じてたので、その辺を頭に思い浮かべながら読んでました。

なお、つい先日事務所引っ越しして、ミーティングルームが増えたので、今はかなり改善されてるのかなと思ってます。

第 III 部:人材を揃える

採用における「能力テスト」についての説明が気になりました。

その人物は、能力テストで測られた作業を2年間で終え、他の作業を20年間やることになるかもしれない。

採用の際には、今できることという短期的な視点だけではなく、長期的にどうなりそうかを重視するのがよさそうだというのを、改めて考える機会となりました(もちろん、今までも無意識的にそういう風に考えていたとは思いますが、改めてということで)。

第 IV 部:生産性の高いチームを育てる

組織のビジネス的な目標、例えば「今期の利益を2倍にする」といったものが、ダイレクトに個人やチームの目標と結びつくかは分からないという話。この点も、うちではある程度解消されているのかなと感じています。というのは、自分たちが作ってるサービスを自分たち自身でも使ってるので、「サービスをよりよくすること=自分たちも楽になる」というのが分かりやすく実感できる目標なためです。

とは言っても、「自分たちのサービスをよりよくする」だけじゃ足りないところももちろんあるので、やっぱりその他やれることはやっておく必要があります。という点では、この辺かな。

チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。

このチームの目的は満たされたとき、チームのメンバーはずっと効率よく働く。一体になったことでベクトルが合ったからだ。

これを達成するためにも、チームの目標が何なのかと、それを各チームメンバーにも意識付ける取り組みに注力しようとしてるところです。


全般的に、名著と言われるほどには自分が読み解けない点が多かった気がしました。もっと経験を積んだ後に読み直すと、また違ったものが見えてくるのかなあ。

「リーン開発の現場」を読みました

書評

前回のカンバン仕事術でカンバンが気になってきたので、もう一冊カンバン系の本を読んでみました。少し昔の本ですが、カンバン仕事術が最近の本だったので、敢えて古めの本を手にとってみることに。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

第3章:デイリーカクテルパーティーに参加しよう

30人から60人の大規模チームにおける、デイリースタンドアップミーティングの効率的なやり方について。

こんな感じで、3段階に分かれてそれぞれデイリーミーティングを行ってるようです。

  • 第1段階:機能開発チームのスタンドアップミーティング
  • 第2段階:スペシャリティ同期ミーティング(テスター同士のミーティングや、開発リーダーミーティングなど)
  • 第3段階:プロジェクト同期ミーティング(プロジェクト全体に関連するミーティング)

今の自分のチームの状況と照らし合わせると。規模がここまではないので3段階はやり過ぎ感があるけど、2段階で各チーム + 開発リーダーミーティング的なのはありかなと思いました。というのも、今は自分がハブになる感じで各チームとのミーティングを個別にやってるけど、それだとどうしても自分がボトルネックになりがちなんですよね。持続可能じゃない気がするので何とかしたいところ。

第16章:僕たちが学んだこと

「実験しよう」「失敗を抱擁しよう」とか、色々いい言葉が書いてます。時々、この辺の言葉を思い出したいです。

いくつか気に入った言葉をピックアップしておこう。

完璧な解決策を探そうとしてはダメだ。そんなものを期待して待ってもたぶん仕方がないだろう。
...
その代わりに、小さく少しずつできる改善点を探して、改善を実験だと考えてみよう。

失敗への恐怖が、改善の最大の敵だ。「なぜ俺達は失敗したんだ?誰がやらかしたんだ?」と問いただす代わりに、「僕たちは何を学んだんだろう?そして、次に何を試そう?」と聞いてみよう。

本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。

たいていの人は変化を好む。でも、他の誰かに変えられるのは好まない。だから変化を起こすときは、影響を受ける人々をまず主体に巻き込まなければならない。

第20章:因果関係図

カンバン仕事術でも紹介されてたし、「なぜ5回」とかも呼ばれてるよくあるやり方だと思うけど、この本は説明が多く例が分かりやすかったです。これやらないと、何か気持ちモヤモヤしたままになったり、ひとまず一番最初に思いついた問題に対して(結果として表層的な)解決策を実施しようとかなったりするので、大事なことかなと思ってます。結構時間使うのでいつでもできることじゃないとは思いますが、ふりかえりと合わせて、自分も取り入れ始めてみました。

翻訳者の一人の@papandaさんのスライドも合わせて。

www.slideshare.net

おまけ:5分で理解するリーンな「かんばん」

本書でもとりあげられてますが、このサイトのマンガ、カンバンやWIPの制限の紹介に便利なのでよく引用させてもらってます。

lean-trenches.com

「カンバン仕事術」を読みました

書評

ちょっと読むのに時間かかってしまった、カンバン仕事術。最初読んでるときは、カンバンもよさげな開発手法だなとは思いつつ、実業務の中で活かしどころがイメージできてなかったのですが、読んでるうちにちょっと霧が晴れてきた気がしたので、2周読んだ感じ。

カンバン仕事術

カンバン仕事術

カンバン3原則

カンバンって何となく、最初の「見える化」したものって思ってたのですが、それだけでなく「WIPの制限」とそれによる「流れの管理」も必須なんだなと理解できました。見える化だけでもある程度は解決するものもあるでしょうが、カンバンから継続的な改善を引き出すには後ろ二つが重要になってくると。

「流れ」対「リソースの稼働率

WIPとリードタイムについて疑似体験するゲーム、コイン渡しゲームの結果を受けての一言。

逆に、最後のイテレーションでは、リードタイムは短くなりましたが、それぞれの作業者の作業時間は長くなりました。効率が落ちたのです。ですが、チーム全体としては一番でした。

「WIPを小さくして流れを早くすると、個々のリソース(開発者)の効率は落ちる」ってのは、目からうろこでした。ついリソースの稼働率を気にしちゃうけど、稼働率が max なのがそのままユーザにとっての価値につながるわけじゃないですもんね。ならば、稼働率にとらわれ過ぎるのではなく、リードタイムを短くして流れを早くし、より早くユーザに届けることを意識するのは理にかなってると思いました。

そのままキャプチャで抜粋させてもらいますが、同様のことを言ってるやりとりがこちら。これはがつーんときましたね。意識改革が必要なんじゃないかと思ったところ。個人個人がそれぞれで動くのではなく、チームとして動くべき一つの理由になると思いました。


デイリースタンドアップ

他の手法でのスタンドアップミーティングとは違って、「個人の作業ではなくてチーム全体の作業・流れについて着目する」ってのはなるほどなと思いました。

多分、この辺のことを意識せずに普通にスタンドアップを開くと、「昨日やったこと」「今日やること」「困ってること」をそれぞれ個人に聞く形式をしそうだなと思ってました。だけど、カンバンでは「ボードを右から左に歩く」つまり完了に近い方から見ていって話し合うというやり方がいいようです。

f:id:ikikko:20160605021748p:plain


ほかにも色々実運用を考える際に参考になるところはあったのですが、大きく揺さぶられたのはこの辺ということで。カンバン使えそうな気がするので、もうちょい追ってみようかと思ってます。

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

書評

カンバン仕事術を先に買ってたのですが、京都遠征したときに@yohhatu, @posauneと話した際、まずはこっちを読んだほうがいいとアドバイスもらったので。

leanpub.com

いつでもさくっと確認できるように、iPhoneにPDFを入れておいた上で、気になるやつをブックマーク付けしておきました。ブックマークしたやつはいくつかに分類分けできそうなので、記憶の定着がてら、簡単に紹介します。

モチベーション上げる系

ちょっと反省点なのですが、ふりかえりなどでどうしても悪い点ばかり目について指摘しがちになってしまってます。言うべきところでは言わないといけないと思いますが、そればかりだとモチベーション的にもあーあーってなっちゃうので、悪い点を指摘するのではなくいい点を取り上げてうまくモチベーションを向上できるような仕掛けもやっていかないとなと、改めて思いました。

f:id:ikikko:20160508173203p:plain

  • 成果ポスター
  • 時間通りのスタンドアップ + ハイスコア
  • 遅刻はケーキ
  • ごほうびビン
  • 失敗ボード
  • レース場

なお、偉そうなこと言ってる割に自宅でのモチベーション管理がまったくできていないので、家でも導入しようかしら・・・


チームのコンディション確認系

↑のモチベーション上げる系にも関連しますが、チームのコンディションを手軽に見える化できると面白そうかなと思いました。口で「ツライわー」とはなかなか言いにくい人もいるけど、こんな感じでアイコンちょっこっと動かすぐらいなら朝会の前にでもぱっとできそうなので。

f:id:ikikko:20160508173253p:plain

  • 自信のニコニコマーク
  • ストレスレベルのメーター
  • チームのムードメーター

情報共有系

うちは拠点が分散してるのもあるので、通常以上に情報共有を意識しておかないといけないんですよね。その辺を見える化するためのやつもいくつか気にかかりました。

f:id:ikikko:20160508173307p:plain

  • サーバンドマネージャーのドア
  • 私の学びたいこと

アジャイルレトロスペクティブズを読みました

書評

スクラム現場ガイドに引き続き、今回はアジャイルレトロスペクティブズです。日本語では「ふりかえり」ですね。

スクラムでもいくつかスクラムイベントが定義されてますが、その中でもこのふりかえりが一番大事なんじゃないかなと思ってきました。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

レトロスペクティブの基本は、以下の構成に従ってるようです。

  1. 場を設定する
  2. データを収集する
  3. イデアを出す
  4. 何をすべきかを決定する
  5. レトロスペクティブを終了する

以下、それぞれ気になったことを簡単にピックアップ。

1.1 場を設定する

チームの約束(ワーキングアグリーメント)を最初に定めておいた方がいいと書かれてました。同時に、なぜワーキングアグリーメントが必要なのかの説明も。

基本的にはワーキングアグリーメントはチームそれぞれに特有のものになるから、他のチームがこうだからうちも真似しよう、というのはあまり意味がありません。とはいっても、どんなものを設定していいか、最初はよくイメージできないと思います。なので、うちのチームでは、下記のサイトを参考にさせてもらい、その上で自分たち特有のルールを話し合って決めました*1

blog.guildworks.jp

3.2 集団ダイナミクスの管理

「集団ダイナミクス」と言われるとちょっと分かりづらいですが、「集団力学」もしくは「グループダイナミクス」と言われることが多いみたい。詳しくは、グループ・ダイナミックス(グループ・ダイナミックス)とは - コトバンクとかを。

集団ダイナミクスを管理する際の一つのアドバイスとして、「あなたが言葉」ではなく「私が言葉」を使っていこうとあります*2。例として、

OK:あるチームメンバーがビルドを壊したメンバーを非難した。「お前がちゃんとやってれば目標を達成できたんだよ!」
NG:「私が怒っているのは、目標を達成できなかったことだ。あのビルドを修正するのはとても厄介なんだよ」

な感じ。相手を一方的に決めつけるのではなく、自分がどう感じたかをもとに話を進める。ファシリテーションの文脈でも結構大事な要素だと思います。

その他にも、参加者の感情の変化について、注意が必要な状況とその対処方法についても述べられてます。具体的には、下記のような行動を参加者が取った場合。

  • 怒鳴る
  • 部屋を出て行く
  • 不適切な笑い・おどけ

自分も心の準備なくこういう状況に遭遇するとすぐにテンパるので、予めシミュレーションしておくことは効果的だと思いました。

5.1 タイムライン

ここからは、レトロスペクティブを構成する各アクティビティの紹介。

タイムラインは、チーム内のイベントを思い出して、年表形式に洗い出していくもの。割りとイメージしやすいしGWで少し区切りができるので、さっそく使ってみました。

毎スプリントレトロスペクティブでやるというよりは、ちょっと長めの区切りでやった方がいいかなと思います。実際、うちのチームでやったときも1月から4月末までを思い出す目的で行いました。

6.6 ドットによる優先付け

出てきたアイデアのうち、どれを選択するかを決めるときに使う手法。参加者が、決められた数の投票権をドットとして持ち、アイデアにドット投票していくやり方です。

これもさっそく採用しました。うちは基本的に拠点が分散してるので、あまり複雑な手法は取りづらいのですが、これはドットを書いていくだけでいいので、シンプルに導入できました。

7.2 SMARTな目標

  • Specific (明確な)
  • Measurable (計測可能な)
  • Attainable (達成可能な)
  • Relevant (適切な)
  • Timely (タイムリーな)

の頭文字をとって、SMARTらしいです。

まあ個々はさておき、「計測可能な」というのが一番重要だと思ってます。計測できないと、達成できたかどうか分からなくて、結局流されてしまいますしね。

というわけで、何か目標を立てる際は「計測可能かどうか」を常に意識するようになりました。常に「計測可能なこと」が一番ですが、たとえ「計測可能かどうかちょっと曖昧」な状態でも、それを踏まえて次のふりかえりで問題があったかどうかを考えるようにしています。その結果、やっぱり計測可能にした方がいいと判断したら、改めて考えなおすことに。

7.4 短い話題

ここで、ふりかえりの手法として有名なKPTも挙げられています。

ただ、ここで触れられていたのは、こればかりやってると飽きがくるよとも言われてます。

イテレーションごとにレトロスペクティブを開いていると、1~2週間のインクリメントなどの短いイテレーションのときは特に、毎度おなじみのアクティビティにチームは飽きてしまう。

あまり色々やって、チームが新しいものに疲弊してもあれなので、飽きがこない程度にちょっとずつ新しいものを取り入れるなり、区切りでは別のアクティビティをやるなりを考えようと思います。

付録B 感想を聞くアクティビティ

ふりかえり中に問題を深堀りしていくことや、(ポジティブ・ネガティブ問わず)何かしらの意見を聞きたいことがあります。けど、「何で?」ばかり連発してても、聞いてる方は萎縮するときがあります。

このときのうまい質問方法について、少しだけ紹介されてました。何も意見が出てこないときに「何か一つだけ感想を述べるとしたら?」とか、まったく別の考え方をしてもらうために「もしも〜だったら」とか。

と、この辺のを読んでたときに、グッドタイミングで目に入ってきたので、また紹介しておきます。

blog.guildworks.jp


最後に、ファシリテーションについての参考資料として、- プロジェクトファシリテーションTOPが紹介されていました。今更ながらちゃんと読んでみて、そういやKPTの正しいやり方も知らずに亜流でやってたのがかなり凹む・・・。ちゃんと読んでおきます。

*1:厳密にはグランドルールとワーキングアグリーメントで適用されるスコープがちょっと違うみたいですが、まあ目的は大体一緒だから参考にするのはありかと思ってます。

*2:英語では"You language / You message"と"I language / I message"と呼ばれてるみたい。日本語より英語の方がカッコいいですねw

スクラム現場ガイドを読みました

書評

最近全然できてなかったので、本を読む時間を増やそうとしています。合わせて、メモ的にでもアウトプットしておくことによって、読みっぱなしではなく、より自分の中に定着させようかと。

というわけで、最初はスクラム現場ガイドです。この本がどんなものかは、前書きから引用しますが、今の自分のフェーズに丁度合ってると思って、色々参考になりました。

スクラムアジャイルを始めようと思っていたり、まさに始めたところだったり、1年くらいやってきて道に迷ったように感じているなら、本書はあなたのためにある。僕は公式には、新たにプロジェクトを始めて6ヶ月から18ヶ月の12ヶ月の間にいる企業が対象だとしている。

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-

まえがき

少なくとも3回はそのままで試してみて、結果を見て欲しい。

ってのは、忘れがちだけど大事だなと思いました。新しい取り組みをしてるわけだから、今までと違ってうまくいかないことも結構あるのですが、そこで安易にモデルを変えちゃうと、よく分からなくなるんですよね。

一方、うまくいかないことは改善するために変えていかないといけないですね。そこで、モデルを変えるのではなく、自分たちのやり方を変えていく、という自分たちが今どっちを変えようとしているのかは意識していかないとダメだなと思いました。

というわけで、モデルを変えないためにもモデルがどのようなものかは、上辺だけでなくちゃんと把握しておかないとだめだなというところが、今ここ。

第1章 スクラム:シンプルだが簡単ではない

「新しいやり方になったせいで、仕事は悲惨になったの?それとも前から悲惨だったのが目に見えるようになっただけ?」
「元々ひどかったんじゃないかな」「そうだよ、ここまでひどいとは今まで気づかなかったけど」

というやりとり。

うまくいかないときはプロセスに責任を押し付けたくなるけど、実はだめな部分が見えるようになっただけなんじゃないか?というのはいつも意識しておかないとですね。

第3章 チームコンサルタントでチームの生産性を最適化する

この本の中でも、一番革新的な内容だと思うこの章。

"チームコンサルタント"は、特定のチームに所属するのではなく、その人の専門性を活かして複数のチームをサポートする役割とされてます。社内にいる、特定分野の専門家ですね。デザイナーやUIに携わる人などが、イメージしやすいかなと思いました。

うちだと、まさにデザイナーやマークアップエンジニアが、特定プロジェクト専属というよりスポットでプロジェクトに入ることが多いので、図らずもそういう感じで動いてるところはありました。ただ、アプリエンジニアはそういう働き方はしてなかったので、今以上に組織をスケールさせるときに、こういうアプローチももしかしたら取れるのかなという、一つの引き出しにしておこうと思います(正直、効果があるのか?とか、効果があったとしてもうまくそういうアプローチにもっていけるのか?はまだ半信半疑ですが)

第5章 スクラムの役割

スクラムマスターの役割を、チームメンバーが交代で受け持つようにして成功したというチームの話もある。僕自身は試したことがないし、うまくいっているのを見たこともない。スクラムマスターが長期にわたる観点を持てないと、ただの管理者に成り下がってしまう。スクラムマスターに必要なスキルは特殊だし、とても重要な役割でもある。キャンプファイヤーで回し飲みするボトルのように考えてはならない。

ちょっと長いけど、ここはなるほどと思ったので。

スクラムマスターの仕事は、以下の三つとされてます。

  1. 高効率のチームを作り、維持する
  2. プロダクトオーナーに協力しつつ、プロダクトオーナーの意図をチェックしバランスを取る
  3. 組織を変える

割りとイメージしやすいのが1番目かなと思ってて、具体的にはデイリースクラムやチームのミーティング・タスク調整とか。で、この辺の見えている作業をこなすだけならば、持ち回りでやるとか開発チームが肩代わりしてやるでもいいかと思ってます。

が、具体的な作業は見えていないけどチームや組織・会社の大枠を改善するような施策は、交代制だと難しいんじゃないかなとは思ってました。ある程度チームが完成されてくれば、もう具体的な作業に落とし込めるものばかりになって、そしたらスクラムマスターもいらなくなるのかなとは思いますけどね。

なので、完成されたチームになって物事を具体的な作業に落とし込めるところを目指しつつ、そこに向かってどういう手を打つのが効果的かを大枠で考えることが、今の自分の仕事じゃないかなと勝手に考えています。

第8章 専任スクラムマスターの利点

スクラムを初めて取り入れるときによく言われるのが、「スクラムマスターを専任でおく余裕がない」ってことだと思ってます。それに対する一つの回答が、この章に書いてありました。

この章いわく、スクラムマスターが開発チームと兼任した場合と専任した場合の、それぞれおチーム全体の生産性向上率は、大体こんな感じになるようです。

  • 兼任時の生産性向上率:110~125%
  • 専任時の生産性向上率:180~200%

こうやって数値として出るのであれば、専任した方がすごく価値があることかなと思いました。もちろん、専任したら誰でも200%の生産性向上につながるわけではないので、そこに向かって努力はしないとですが。

生存戦略、考えてます (2016) - 目標

去年の振り返りは、生存戦略、考えてます (2016) - 振り返り - @ikikko のはてなブログです。こっちは今年の目標。



自分を取り巻く状況

ヌーラボの2015年は、ニューヨークのオフィスも本格的に稼働し、おおよそ15名の新しいヌーラバー(ヌーラボの社員)が新たに加わり、これまでの成長を更に上回る成長を感じることが出来た1年間でした。


...


Backlogチームは社内でも一番大きなチームに育ってきており、2015年からBacklogのプロジェクトマネージャーになった中村知成は「大きなプレッシャーを感じるが、非常にやりがいがある」と語っています。

2015年のヌーラボを振り返る: ヌーラバーが選んだヌーラボのトップ5ニュース - ヌーラボ [Nulab Inc.]

にも取り上げられていますが、最近人が加速度的に増えてきています。数年前の、人の出入りがほとんどなく、毎年一歳ずつ平均年齢が上がっていくときと比べると、ほんとに目まぐるしいぐらいです。そんな中、自分にとってもチームにとっても、違う何かが求められるようになってきたかなとは感じています。

そういうわけで、以前も書いていましたが、この辺はより一層意識するようになりました。新しく入ってくる人たちは基本的に優秀な人ばかりなので、同じ分野でがちで勝負してもなかなかついていけないんですよね。

で、凡人の自分が生きていくためには、(会社の)現状を考慮してニッチだけど必要なところをうまく補っていく方向性がいいのかなと考えています。それが、自分が強い分野 or 興味ある分野だったらよりいいですね。

生存戦略、考えてます (2014) - @ikikko のはてなブログ

チームを推進するためのスキル

一番考えているところは、チームとしてうまくプロジェクトを推進するためのスキルかな。

数年前までは、人もそれほど多くなく、かつ入れ替わりもあまりなかったので、割りとあうんの呼吸でやれてました。けれど、最近は人が増えてきたということもあり、あうんの呼吸が通用しなくなってきたので、もうちょっとシステマチックにできないかという取り組みを色々やってます。

その中の一つに、開発プロセスの整備も入っています。で、もろもろ交通整理して、人が増えてもチーム全体として最大限のパフォーマンスを発揮できるようにしていきたいなと考えています。いわゆる、スクラムマスター的なところですかね。

今の社内にはそういう役割の人がいないのですが、逆にチャンスとも言えるので、そういうスキルも含めた総合力で何とか勝負していきたいです。

テクニカルスキル

とは言っても、エンジニアである以上、一定水準のテクニカルスキルは必要になるし、何もしなければ錆びていく一方だと思ってます。ただ、交通整理係になったら、今までのようにテクニカルなところに身を置く時間は絶対に減るので、その現実は受け止めた上でどう対応していくかかな。

具体的には、以下の点はなるべく実践していきたいと思ってます。

  • (開発するところはメンバーにお任せするけど)空き時間にソースコードをはじめ、やってる内容を確認すること
  • インフラ・裏方面はまだまだ関わってる人が少ないので、その辺は手を動かせる範囲で動かしていくこと

英語学習

英語学習は、ちょっと目標を見失い中。

前回はWritingを鍛えようと思ってたのですが、これは現実問題難しそうと思いました。で、多分現実的な目標としては、日常会話を英語でできるようになるというところなんですしょうが、今の僕のチームだと幸か不幸か英語でのコミュニケーションが必須ではないんですよね。時々英語しか通じない場面でのコミュニケーションはあるけど、そんなに頻度が多くない。

ここはちょっと目標立てづらいですが、いい言い方すれば習慣化、悪い言い方すると惰性で続けておいて、いざというときに少しでも早くキャッチアップできるようにという感じかな。現状維持でリスニング・スピーキングを中心に、毎日30分でも英語学習を続けて、週一で英会話の先生とマンツーマンレッスンぐらい。もっと必要度が増したら、量を増やすというぐらいで。


というわけで、2015年途中のポジションチェンジから半年ぐらいで少し馴染んできて、ようやくのぼりはじめたばかりですが、今後も乞うご期待ください。

http://www1.odn.ne.jp/cjt24200/yamada/text/otokozaka/8.gif