メソッド屋のブログ

米マイクロソフト Software Development Engineer 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

「無理を承知で」のお願いが「無駄」を生む - 不確実性を受入れる 第3の習慣

仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「8つの習慣」のうち「不確実性を受入れる」に関して考察した。具体的な実践プラクティスを踏まえ言及してみたい。

f:id:simplearchitect:20170125235652j:plain

ご興味があれば、是非以前にご紹介した第一、第二の習慣に関してもご一読されるとよいかもしれない。

不確実性を受入れる

f:id:simplearchitect:20170125235828j:plain

  • マネージメントは詳細まで細かく練られた計画を期待しない。
  • 予算と報告のプロセスは精密な結果の予測を要求しない。
  • 内部プロセスは計画や優先順位の変更に柔軟である
  • 事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ
  • システムとプロセスは柔軟で、複数の頻繁な変更を受入れられる
  • 学びに基づいて、変化を精力的に行う。

この習慣は日本人の最も苦手とするところのうちの一つかもしれない。しかし、変化に柔軟に対応する必要のある分野特にソフトウェア開発の分野では最も理解し、実戦して練習しておいたほうがよいと思われる習慣だ。  この考えなしに新しいモダンな開発スタイルのマネジメントは不可能といっても過言ではない。逆にいうと、あなたがこの習慣をマスターすれば、日本人の良さも生かしながら相当かっこいいマネージャになれるかもしれない。

「納期は絶対」の神話

 日本人には、「不確実性の忌避」という文化的性質があるらしい。つまり、不確実な状態を嫌うので、先に予見したり、計画するということをがっつりやってしまいがちになる。比較的先が見通しやすい産業においてはとても有利な性質かもしれないが、ソフトウェアのように非常に先の見通しが立てにくく変更が多い分野にはこの性質がマイナスになりがちだ。我々の傾向として、よくわからないものがあった場合、先に試してみるよりも、やる前に、いろいろ「検討」したりしてしまい、なかなか着手できなかったり、どんなに計画しても分からないものに対して、一生懸命予見し、完璧な計画を立てることに時間を使ったうえ、一度立てた計画が実態にそぐわなくても、その「計画通り」に遂行しようとして、プロジェクトが炎上してしまうという場面もしょっちゅうある。

 我々は「計画通り」でないと「失敗」と思うかもしれないが、そもそも未来を予見できる人なの世の中に存在しないのではないだろうか?なぜ「計画通り」でなければならないのだろうか?計画はあくまで、当初の見込みで、作業を円滑に進めるためのものじゃないだろうか?よくわからないものに対して、事前に検討しても予見できない。その予見に時間をかける暇があったら、検証するほうがよいというのは前回のテーマにもつながることだ。

simplearchitect.hatenablog.com

 私が、クロスカルチャーの専門家のロッシェルカップさんから聞いた話で衝撃的だったのは、「納期(Deadline)」の意味が日米で異なるということだった。日本の場合は、納期に、予定された機能の納品物を、予定された品質で提供するのが必須であるという感じだ。しかし、米国では、「納期は柔軟」であるらしいと聞いて目が飛び出るぐらいびっくりしたのと同時に、そういえば同僚のことを思い出しても、日本ほど「納期」に厳しくない。大抵は、納期にリリースするけど、予定よりも少ない量に変更するいうことはしょっちゅうだ。少なくとも納期を守るために、徹夜とかいう場面は見たことがない。我々はたぶん納期に厳密すぎて無理をしすぎる傾向にあると思う。それはどの程度バリューがあるだろうか?  

ソフトウェアエンジニアリングでの考え方

 そもそも、Q(品質)C(コスト)D(納期)+S(スコープ)は、トレードオフの関係にある。納期を短縮したければ、お金をたくさん払うか、品質を落とすか、提供する物量(スコープ)を減らすかという塩梅だ。予定通りQCDSをすべて達成するというのは非常に困難だ。だから、多くのマネージャは、大きなバッファを持って、それを達成しようとする。私も昔は常に30%ぐらいのバッファを残しておいた。そもそも、ソフトウェアの場合は変更が入るので、当初の計画通りにはまずいかない。

 つまり、エンジニアリング的には当初に想定された、QCDSをトレードオフせずに納期通り納品するのはほぼ不可能に近い。しかも、その計画はソフトウェアの場合、統計的にも相当予見しにくいものである。段階にもよるが、最初の段階で計画したコストの3倍になる確率も十二分にあるといった精度でしかない。これを信じるほうがよっぽどリスクが高い。

実績のみで判断する

その代りどうすればいいか?というと、単純化していうと「実績」だけで判断し、「納期」を固定して「スコープ」つまり、予定の機能を出し入れするほうがいい。

 納期はまもって、その日にデリバリしつつも、間に合わないものはそのリリースに入れずに次に回す。もしくはやめてしまえばいい。ある機能が1週間遅れたからといってそれがどの程度インパクトがあるだろうか?それが「達成される」という前提で計画を立ててしまうから、「必達」とかになってしまうけど、そもそもそれは計画なので「いまのところは、こういう予定」ぐらいの感覚で見たほうが確実じゃないだろうか?

 例えば、マイクロソフトや、他のサービスプロバイダを見回してみても、必ず納期通りすべての予定の機能をリリースしているソフトウェアジャイアントは存在するだろうか?ロードマップを持つことは見通しがよくなってよいことだが、実際リリース予定の日が近づくと、しれっとその機能が削除されていることはざらではないだろうか?  それはどの程度のインパクトを起こすのだろうか?そして、その納期とリリース機能を守ることは、プログラマの生活や健康や楽しみを犠牲にして守るほどのものだろうか?そもそもマネジメント的にも、中長期的には生産性は疲弊するためどんどん低下してしまうので効率が悪い。

f:id:simplearchitect:20170126001407j:plain

 予定日にはリリースする。そして、例えば開発が1週間単位でおこなわれているならば、前の週、その前の週とかがどの程度の量をこなすことができたかを測定して、次の週、その次の週も、たぶんそれぐらいの量はこなすことができるだというという想定を立てるとより現実的な計画を立てやすくなる。

 ただし、この計画も状況は刻一刻と変わるので、ずっと現実的であるとは限らない。チームの誰かが病気になるかもしれないし、チームの生産性が上がるかもしれない。楽観的でも、悲観的でもなく、現在のチームの生産性を測定して次の直近の予測に使うという方法だ。そうしておけばシンプルだし、気合や根性の正解や、楽観的もしくは悲観的な感覚が入り込む余地が無くて楽ではないだろうか?

 さらにこれがいいことに、無理してリリースするとすると、問題を覆い隠す。つまり、チームの生産量を超えた量を一定期間で達成した結果、今回出来たら、次回もこれぐらいできるよね。ってなりがちだ。そうするとどんどん無理が積み重なっていく。そして、無理をしていることが上層部や周りにも伝わらないことになる。だから、問題も改善されない。

 無理を積み重ねるのではなく現実を見て、「工夫」をしていこう。たぶんポイントは、第一回でご紹介した「物量を減らして、より大きな価値を生み出す工夫」だ。つまり「やらないこと」を見つけることだ。

詳細な計画を求められないために

もしかすると、あなた自身ではなく、上の人から詳細な事前の計画を求められるケースがあるかもしれない。詳細な計画はコストも時間もかかるうえに、着手を遅らせるという最悪な結果を招く(少なくともソフトウェア開発の場合は)。そのようなケースだと、プロジェクトが始まる前に、その上の方に「こういう形式でレポートします。今回 Agile / DevOps なので」ということを事前に合意しておくとよい。そもそもそれが通らないって?その場合は、私のお勧めは例えば、Agile / DevOps をやる場合にはお勧めの方法がある。Value Stream Mapping という現在の開発プロセス見える化して、改善ポイントを見つけ、リードタイムを短縮することができるツールを使うとよい。

f:id:simplearchitect:20170115002010j:plain

このツールを使うと、素晴らしいことに4時間ぐらいで、無理なくリードタイムを短縮できる「見込み」を知ることができる。例えば、ある会社さんでは、リードタイム8.5か月だったのが、Value Stream Mapping を実施して自動化したら、1週間になる見込みだとわかって、数か月後、実際に1週間…どころか、1週間に数回ソフトウェアをデプロイできるまでになった。上層部にとって、細かい開発プロセスはどうでもいいことなので、こう言ってみるといい「DevOps という開発のやり方をやってみたいのです。我々のプロジェクトのリードタイムが今8.5か月なんですが、それを入れると、1週間に短縮できるみたいです。やってもいいですかね?」とかいうと大抵は「そらやるしかないだろう!」という話になる。そして、「DevOpsをやるためには、レポートの実施方法も変える必要があるので、今度、どんなレポートになるのかを事前にお見せしますね」と事前に合意しておくといい。

 そうすれば、上の人は大抵シンプルなレポートに喜んでくれる。そもそも、細かいどうせ把握できないものより、リードタイムが短くなるほうがよっぽどうれしいはずなので、先に「どうせいっても無理」とあきらめるのは非常にもったいないのだ。

例えば私はチームから出すレポートは次のようなものをおすすめしている。上の方に行けば行くほど、シンプルなレポートが好まれる。

いまならさらに、BIを活用して、自動でダッシュボードをつくっちゃってもいいだろう。

確実に納期を守る方法

中には納期が絶対的なものが存在する。それは米国も日本も変わらない。オリンピックが開催されてそのアプリの納期を伸ばすのは意味があるだろうか?じゃあどうすればいいかというと単純だ。本当に納期を割りたくなかったら早く始めたらいい。

f:id:simplearchitect:20170126003857j:plain

さらに、ソフトウェアの場合とかだと、既に動いているものを「リリースする」と約束すればいいだろう。例えば今だと、フィーチャーフラグというテクニックがあり、実際の機能がすでに盛り込まれているが、公開するスイッチをもっておき、そのスイッチをオンにしたら特定のユーザにのみ公開されたり、全体に公開されるようにしておく。そのスイッチを使って、先に実装しておいて、一部のユーザにつかってもらって、実際に動くし、価値もあると判断してから、本当の「公開」をするようにしたらどうだろうか? これは、Azureや、Windows10をはじめマイクロソフト以外でも多く使われている方法だ。

皆さんの開発だと、納期を固定して、スコープを変動させる考えがある。つまり、納期に何らかのリリースをするけど、すべての予定されていた機能のうち、実装できたものをリリースするという考えだ。つまり、出来なかった分は入れないようにする。 この考えの場合、含まれる機能が増減しても、ユーザにとって価値のあるものがなんらかリリースられるようにしておくとよい。機能A、機能B、機能Cがリリースされないと意味がない、、、という場面では、機能A、機能B、機能Cを順につくるのではなく、機能A、機能B、機能Cを同時につくるけど、想定よりずっと簡単で、シンプルなものにする。だけど、連携してなんから動作して、価値を提供する単位でつくると、常にリリース可能な状態ができあがる。そうすれば、機能の増減に関係なく「いつでもリリース可能」になる。ただ、予定された機能がすべて納期通りにそろうとは限らないというだけだ。  

「不確実性を受入れる」プラクティス

 さて、なかなかこれは受け入れ型考えかもしれないが、モダンなソフトウェア開発メソッドではこの考えが基本となってくるので、すくなくとも「思考回路」だけは手に入れておきたいところだ。そうすれば、すくなくとも「選択可能」になれる。   まずは、この「不確実性を受入れる」ために自分で練習できるプラクティスを考えてみたい。

対象者

  • 上位マネジメント
  • プロダクトオーナ
  • チーム

おそらく、対象者のうち、最もこのプラクティスに影響をうけるのは、上位マネジメントだろう。次にプロダクトオーナ。だが、実際には上位マネジメントの方は詳細を知りたがる人はあまり多くない。中間層のマネジメントの方に詳細を知りたがる人が多いイメージだ。

1. 楽に達成できる計画で仕事をしてみる

 日々の仕事を実施して、仕事を他の人にお願いするケース(そういうのが無い人は自分の計画を立てるとき)に、その人の能力でいうと、これぐらいの日数で出来るという日を納期にするのではなく、もっともっと余裕で出来る程度の日程を設定しよう。日本にいると「なるはやで」とか、家に帰宅後「明日までに」というオーダーで仕事を依頼されることもしょっちゅうあるが、向こうにいくと、こういう依頼は「マネージメント能力の欠如」としてみなされるらしい。それは、納期を割る確率が非常に高い賭けをしているようなものだし、依頼先にも相当な負担をかける。そして、日々仕事をしていると、割り込みが入らないことのほうが少ないだろう。だから、かなりの余裕を持った日程で、しかも、早めにチェックポイントを設けて、仕事をやってもらうようにしよう。わたしだと、どうしても、自分が「理想的にできる時間」とかで見積もってしまいがちで、「あーわし全然仕事が遅いなー」とがっかりすることもなくなる。人間そんなものなのだ。

f:id:simplearchitect:20170126002314j:plain

 それがうまく出来なかったら、どうしたらよかったか、改善をしてみよう。ただ、「計画通り」が良いという思考は忘れてしまうほうがいいと思う。計画通りはよい事とは限らない。ものすごーーーく余裕があるかもしれない。そしたら効率悪いではないか。そして、それは、「新しいことに対応しなかった」ということも意味する。計画は単に「見通しをたてて、仕事を進めやすくするため」のものでしかない。未来は予見できない。計画や、物量ではなく、自分が創出した「価値」をどの程度定常的に提供できているか?を判断基準にして考える練習をしてみよう。そもそもその納期にどれぐらいバリューがあるかも考えてみるといい。この背景には、沢山物量をこなすのが生産性がいい事であるというマインドセットが背景にあるかもしれない。

また、初回に学んだ「時間を固定して、中身を変動させる」というプランニングの方法を練習しておくとこちらにも効果が上がる。

simplearchitect.hatenablog.com

 

2. 「無理・断る」と言う練習をする

 先のロッシェルさんと一緒にやったワークショップで、あるとき、ブラジル人と日本人の混成チームがあった。ロッシェルさんは、日本人の人に対して次のように言った「もし、みなさんが仕事で忙しいときに、上司からこの仕事をやって欲しいと言われたらどうしますか?」というと、日本人の人は、「わかりました」といって残業とかでカバーするという回答だったのだが、同じ質問をブラジル人にすると「私は今仕事で手一杯だからごめんななさい」と断ると言っていた。

f:id:simplearchitect:20170126001838j:plain

 心理学では鏡の法則というのがあり、自分に適用しているルールを知らず知らずのうちに、他人に適用してしまうというのがある。例えば、自分に納期厳守を課している人は、他人にもそれを求めてしまう傾向があることだ。我々のDNAには骨の髄まで納期厳守のDNAが刷り込まれている。  つまり、自分が寛容になるためには、自分もそれでOKにしてしまうといい。そのブラジル人の人みたいに、そういうケースがあったら、「無理」だとか「断る」ということをしてみよう。そのうえで、どうしたらいいか相談にのってあげよう。自分が我慢して受けてしまうと、改善につながらないし、自分以外の人にも我慢を強要してしまう傾向になる。

 「無理」というのを認識したうえで、楽に達成できる計画に2人で落とし込む計画に変更するのはどうだろうか?無理であることがわかったら工夫したらいいし計画に無理があったサインかもしれない。「ここまでだったら、協力できるよ」というラインについて話をするのもいいかもしれない。こういうマインドセットをチームでシェアすると、「無理!」が言いやすくなるので、8つの習慣をチームでシェアしておくのはおすすめだ。「無理を承知で」のお願いの連鎖が、みんなの疲弊を生んでないだろうか?「無理」と言えるようになったら、「無理じゃない」計画に対してみんな対応できるようになる。

3. 他の文化の視点を学んでみる

 先ほどのブラジル人と日本人のチームの例ではないが、日本人ではない、他の国だとどうなっているだろうか?というのを学んでみる練習も楽しい。私は英国留学を3か月していた時があるが、その時マーケットリーダーというビジネス英語のテキストを使っていた。その内容は結構面白くて、いろんな国の商習慣や文化習慣についても学べる構成になっていた。我々は日本だけで生きて育っているので、例えばの納期を守るのは人として当然ぐらいの感覚がある。

f:id:simplearchitect:20170126001908j:plain

 しかし、他の国だと、時間通り待ち合わせに来るのが失礼という国すらある。先ほどのブラジルの例だと、日本人よりダイレクトに思っていることを話す。しかし、デンマークだともっとダイレクトだし、日本よりももっと、ダイレクトに思ったことを表現しない国もある。  そういったことを学んでいくと、もはや「常識ってなんだっけ?」という感覚になってくる。そうすると、「自分の常識」というものも、他の人には当てはまらないなぁ。という感覚になってくる。下記のロッシェルさんのクローバるマインドセットの記事はとても興味深い。もしご興味がある人はぜひご一読いただきたい。

ビジネスで成功するための グローバルマインド養成講座|ビジネス英語|アルク

 我々は計画の変更に不寛容だ。前回も書いたが、誰もが失敗と思っているプロジェクトで価値がなくなっても計画通り継続してしまう。しかし、「リスクや間違いを快く受け入れる」マインドセットがあれば、計画通りいかなかったことを受入れて、計画を変更するマインドセットにつながるだろう。計画自体が仮説でしかないので、変更されるものなのだ。「Be Lazy」のマインドセットがあれば、無理に全ての物量を納期通りリリースすることに本当に価値があるかを考え直すことが できるかもしれない。

 他の例でいうと、マイクロソフトで私に降りてきている方針も1年の間にずいぶん変わってしまった。数か月で変わっていく。それは健全なことだと思う。だって、状況が変化していくのだから、変化に対応することのほうがよっぽど大切だ。そういう環境にいると、時間をかけて計画を立てることはばかばかしくなる。どうせ変わるのだから。  つまり、「計画の変更」は悪ではない。現実をみて、フィードバックを受けての変更で、むしろ善だろう。そういうマインドセットをチーム内や関係者でシェアしているだけで、その人がさぼっているわけではなく、「不確実性を受入れる」マインドセットで行動しているということが周りも認識できる。そしたら周りももっとやりやすくなるだろう。

 じゃあ、さぼる人はどうするんだ?という意見もでそうだ。それはまた違う習慣でお話ししたいが、性善説性悪説があるときに「性悪説」でかんがえると、「性善説」で考える時より「ずっとコストがかかる」ということだけはシェアしておこう。是非「サーバントリーダシップ」の回をお楽しみに。