アジャイルにやるなら評価も考えてほしい

ちかごろアジャイルと人事評価がホットな感じになってきてるので、便乗してそのあたりの個人的な意見を。

私がアジャイルの導入支援するとき、比較的早い段階でクライアントのチームの人に仕事がどう評価されるのか尋ねてみます。仕事のやり方を変えようってときにそれが個人への評価に反映されるかどうかって、とても重要なことですよね。別にそれによって私がコーチとして何かを判断するわけではないですが、これから一緒に工夫していく仲間としてメンバーそれぞれの動機や個人ビジョンって気になりますから。

チームボードの左側に

Roman Pichler 氏から転載許可をもらえたので、pichler consultingの記事から『Product Vision Board』と『Product Canvas』という２つのツールを紹介します。シンプルなものですが、かなり強力な手助けになるんではないでしょうか。

"仮説と検証"って

先日開催したPOMeetupで、「仮説と検証」のキーワードがテーマとして登場したが、私としても近頃とても気になってるテーマなので整理してみようと思う。

 

私なりの「仮説って何だろう」とは

• このゴールを得るために、こうすれば近づけそう
• このアクションによって、こういう成果がでるだろう
• そして、仮説は間違ってるかもしれない

当たり前のことだ。
しかし、悩んだ末にひと回りしてここにたどり着いた。

 

かつて事業リーダーになったときの話。

とつぜんの組織変更＆辞令で、それまで一緒だったチームと新しい事業グループを任された。このとき、会社のいろいろな事情により、新規受注を大幅に獲得しなければならなかった。これまでにシステム提案や予算の交渉くらいはしたことあるが、新規顧客の営業なんてしたことない。

しかし、アジャイルな開発を実践してきた経験から、少しずつ結果を出しながら軌道修正していけばいいと考えた。いま思い返してもこれはたぶん間違いではない。しかし、なんども軌道修正しながら、いろんな手を尽くしてきたが、ほとんど成果はなかった。ふりかえれば、確かに細かく軌道修正してはいたが、どこに向かうやも知れず、まるで巨大な迷路で迷っているようなものだった。あるいは、目印のない砂漠をさまよっていたとも言える。

 

当時から徐々にリーン・スタートアップといった単語を目にするようになっていて、私なりにやり方を踏襲しようとしていた。しかし、そこで聞かれる事例はどこか自分と違う世界の出来事のようで、先の砂漠に例えると、どこか彼方のオアシス周りの街であちらこちらと新ビジネスが出たり消えたり浮き沈みをしているようだった。それなのに、私たちは体力だけを頼りに砂漠の中をさまよっている。私たちの手元には、ビジネスの種になる品物も客もいないような気分だった。

 

役目を終えてみてはじめて本格的に振り返ることができる。

簡単に言えば、目的意識やゴールに対する狙いが甘かったんだろう。「なんだ、そんなことか」と思われるかもしれない。たしかに、ごくありきたりなダメケースだ。

当時の私は「目的は"受注を増やす"ことだ」と明確なつもりだった。ただ、「どうすればいいかわからない」ので手探りで進めていた。

 

「受注を増やす」は大命題であっても戦略目標ではない。これでは「増やす」ためなら、どんな選択肢だって取りうることになる。自分の中では「こういう課題を持つ顧客を探してこういう有価値なものを提供したい」と考えていても、周囲から（特に経営陣から）「訪問件数を稼げ」といった目先のアクションにプレッシャーがかけられたら、そちらを優先してしまう。'これ'という選択がないので、あれもこれもと目先を変えながら右往左往することになる。さらに、小刻みに再計画しているので、あたかも'ちゃんとやってる'つもりになっていたようにも思う。

はた目には馬鹿げた迷走っぷりだけど、やってる本人は必死だった。目標がボケてることは気づいていたが、全力で走っている間は、ふりかえっているつもりで何も対策できなかった。

 

このように整理してみると、このように陥らないために必要なのは、戦略を絞って、目標を立てて行動計画を立てることだとハッキリわかる。

「その戦略が難しいんだ」と当時の私は反論するだろう。

だからこそ、"仮説"というアプローチが活きる。なんとなく思い描いている抽象的なビジョン(想い)から、具体的な目的に絞ってみる。自分が描ける範囲の（あるいは、何人かの助けを借りて）目標を定め、修正または取り替えていくつもりで実行すればいいのだろう。「難しい」と言っても、想像もできないようなビジネスモデルは構築しようがなく、本当に難しいのは事業を完成させることだろうから。

 

• このゴールを得るために、こうすれば近づけそう
• このアクションによって、こういう成果がでるだろう
• そして、仮説は間違ってるかもしれない

小さく繰り返す実行に加え、もう少し長いスパンで、達成から得られた成果から目的や施策も見直す。このような２重ループ構造で運用することで、右往左往する失敗から回避する手段になるのではないかと考えている。

 

いま同じように私の代替で後任者が全力で走っている(走らされている)。同じように迷走して疲れ果ててしまわないよう、なんとかこのあたりをうまく伝えることができないか、と思う。

[読書]Running Lean ―実践リーンスタートアップ

実践的で具体的。分かりやすかった。

以前に『アントレプレナーの教科書』を読んで、"顧客開発"というアプローチを気には入ったものの、実践に移るには敷居の高さを感じていた。この本は、分かりやすい言葉でステップそれぞれに具体的な手段を示してくれていて、手引き書として利用価値が高いと思う。リーンスタートアップの背景や目的は別の本や情報を併用したほうがいいかもしれない。

Running Lean ―実践リーンスタートアップ (THE LEAN SERIES)

”顧客開発"を知ったのは、私が自社の事業リーダーをやっていたころだった。事業成績としてお尻に火がついた状態で、何とかして新しい事業を立ち上げなければならなかったが、いざ時間とコストをかけて人を動かすとなると躊躇していた。 計画と実施は私に責任があったが、コストは権限を持ってなかったのが実の理由かもしれない。

 先日、リーンキャンバスを書いてみるワークショップ(翻訳である角氏による)を体験する機会があったが、実際に書いてみると新しい気づきがあった。どういうものかは知っていたつもりだが、やってみると想像以上に頭の中の雲が晴れる感じだった。

無作為に手を付ければいいってものではないんだけど、この本を読みながら、製品や事業に明確なビジョンを持つことと、間違いのない企画を立てることとは別なんだと考えを改め直した。事業という大きな相手だと、思案するばかりでついつい何もせずに過ごしがちだが、怖いからこそ試して適応させるアプローチであるべきだろう。そのために、できるだけ軽量に始める必要があるんだと。

関連：アントレプレナーの教科書

[読書]わかりやすいアジャイルの教科書

わかりやすいアジャイル開発の教科書

文字どおり"わかりやすい"教科書だった。

Amazonで予約してたのに、著者のひとり細谷泰夫氏からいただいてしまい、手元に2冊になってしまった。ひとつは同僚にあげよう。

それにしても、どうして今さら教科書なんだろう？ 

巷ではアジャイルに関するネタが爆発的に増えてる(と感じている)。「アジャイルとは」「どうやってやるのか？」は もはやコモディティだし、先駆者に質問すれば「あなたは、なぜアジャイルにやりたいのか？」と質問で返されるようになった。

実際のところ、どんな風にアジャイルにやるかは業界や企業風土によって違うはずで。どんな説明が当てはまるかも違う。どのように促すのが適切かもまるで違う。と考えてる。

たとえば、私の職場では、進め方について若い人が提言する場面はあまり見ない。プロセスを工夫するのは上級技術者/管理職者の権限で、コードを書くのに忙しい人が提案するのは"おこがましい"と考えているのかもしれない。実は上級者は意見を聞きたいと思っていても、お互いに遠慮をしてしまっている感じがある。アジャイルなスタイルに興味を持っていて、ツールやプラクティスを利用する人はチラホラ出はじめたが、組織的に"変化ヲ抱擁"するように動けていない。

私がこれまでにうまく活動できていないところだなぁ。

そんなところを見ると、意見を言う勇気・正しいと信じる信念を得るために教科書は必要だと思う。アジャイルなスタイルに興味を持ち始めた人や、いままさに試し始めた人にとって、手本にすべき姿を誰かに教えてもらいたいんじゃないだろうか。

マインドや大上段に構えた"目的"意識も大切だけど、「なぜそれが必要とされるのか」「どうやってやっていくのか」「どんな風になれるのか」という易しく噛みくだいた情報が必要。情熱あふれる目的を語ろうにも、その前の段階で良い手引きに出会わなきゃいけない。

そんな人たちに、この本は正にタイトルどおり、やさしく教えてくれる教科書だと感じた。

アジャイルな開発に興味を持ってる人、導入し始めた人には、勘違いを最小にとどめて正しい知識を得ることができると思う。

システム開発って苦行ですか？

アジャイルスクラムが個人的に気に入っているのは、早期に失敗することで改善を促すところ。この失敗を安全な領域で発生させるよう、自己組織化された環境で改善を進めるよう、うまく出来ていると思う。書籍の発行や記事も近頃は盛況で、いいものが沢山出てきた。私も復習だったり再発見だったりで、とても楽しんでる。

ただ気になってるのは、ウォーターフォールと対比して、「(自分たちが)最後に失敗しないために」、「現場を改善するために」というスタンスの解説をみかける。これって「開発現場は辛いところ」とか「プロジェクトは上手くいかない」って前提に立ってるんじゃないだろうか。実際のところ、大変なプロジェクトが大半だろうし、悲惨なもの多い。だから、こういうものに興味を持つ開発側の人にとっては、導入根拠として大切なところ。でも、中には"指示されたものを隷属的に作るつらい仕事"という前提を持ってしまってる人はいませんか？

システム開発というのは、本来は、ユーザーにとっての利便性とか、顧客にとってのビジネスを改善したり、何らかの形で顧客がより儲かるとかいった目的のためのはず。だから顧客は予算をかける．．．はず。

でも、身の回りで見かける開発は「欲張った分だけお金はかかります」とか「次世代のフィーチャー、パフォーマンスのために予算をかけましょう」という感じ。顧客にとっての価値が見えなくて、金をかけるための提案を優先してる感じがする。顧客もそういうものだと思ってしまってる。たぶん仕方なく納得してる。なかには「仕様の内訳と1対1の見積もりをくれ」と言う顧客もいる。仕様と納期に追われるプロジェクトが多いのは、業界全体が自分たちで首を絞めてきたんじゃないだろうか。

目指すべきは、"現場の改善"だけでなく、それ以上に"顧客の改善"のためでないといけないと思う。 アジャイルもそのためのはず。プロジェクトの最初に仕様を決めるというのは、顧客や製品企画にかなりの難題を押し付けてる。開発のほうがITは得意なんだからニーズに応える適切な答えを見つけていかないと。そして、顧客が知ってる業務や製品サービスの情報をすり合わせるために、顧客と共に過ごす時間がたっぷり必要で、開発初期の限られた時間で仕様を決めるよりも、開発期間をそのために費やしたい。そのひとつの答えとして、アジャイルな手法の必要性があるんだと思う。

開発側がもたついたりスペックに固執したりしていてはいけないので、スクラムなどのフレームワークを利用して現場を改善していく必要はあると思う。同時に、顧客にとっての価値を漸進的に高めるために、プロダクトオーナーシップも強化していかなければならないのではないか。

とりあえず始めてみよう

とりあえず、何か書くところから始めてみよう。 

私はかなり筆不精で、いつまで続くか分からない。

いろいろ情報を仕入れるようになって自分の中でも思うところがあったりするが、いざ人に説明するチャンスに出会っても上手く説明できない。たぶん、頭の中では整理しているつもりでいて、実は稚拙な次元でしか考えれてないのかもしれない。

”語る"というスキルの重要性を最近になって再認識している。人を説得するには理路整然とした説明が必要だが、納得してもらったり心を動かしたりするには"語る"スキルが必要なんだと知った。ブログを書くことで、そのスキルの訓練にもならないかと期待している。

プロフェッショナルは「ストーリー」で伝える

"書く"ということは人に見せるつもりがあるわけでだし、そういう点で作品のひとつだと思う。上手く書けないと恥ずかしいところもあるが、そう考えて今までロクに書いていないことも私にとってマイナス要因になっている気がする。これもやはり最近読んだ本で感じたこと。ブログを書くことは"やりたかったこと"ではないんだけど、自分の感覚を大切にするという意味でやってみよう。

ずっとやりたかったことを、やりなさい。

 ともかく、気軽に書いてみようかと。