リーン・ソフトウェア開発と、アジャイルチームの先の話。組織のアジリティへ

4月にリーン・ソフトウェア開発の提唱者、メアリー・ポッペンディークさんと、パートナーでありソフトウェア技術者でもありプロ級の写真家でもあるトム・ポッペンディークさんの夫妻をお迎えして、(たぶん)日本初の有償研修をオーガナイズします(会社として)。

リーン・ソフトウェア開発の「リーン」は、トヨタ自動車の生産方式を研究した北米の科学者がつけた名称です。リーンは贅肉(ムダ)が取れた状態をさすそうです。日本では工場における「ムダとり」の活動が有名です。メアリー・ポッペンディークさんは、トヨタ生産方式やその成立に大きな影響を及ぼしたデミング博士の手法を研究し、ソフトウェア開発の分野でそれを活かせるよう、3冊の本にまとめています。

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

リーンソフトウエア開発?アジャイル開発を実践する22の方法?

リーン開発の本質

リーン開発の本質

リーンソフトウェア開発と組織改革

リーンソフトウェア開発と組織改革

工程間のムダを見える化する、バリューストリームマッピング

リーン・ソフトウェア開発で最も有名なエクササイズが、「バリューストリームマッピング」です。複数の人/部署/チームからなる製品開発において、各工程(チームや人)がどのように作業に関わり、その期間はどれくらいかをマップにするものです。一つの製品バージョンがリリースされるまでに、どういう時間がかかったか、スピードを早めるためにどのボトルネックを解消すべきかを、相談できるようにします。

私はこのバリューストリームマップの話を聞いたときに、すごくいい手法だと思ったのですが、しかし、自分で書こうとすると、多くの部署の人の話を聞かなければならず、大変すぎて実際にはつかいづらい、もしくは、会社として導入しないと難しいものなんじゃないか考えました。しかし数年後、とあるプロジェクトで「関係者が集まってバリューストリームマップ(っぽいもの)をみんなで書く」という機会を得て、実行したところ、非常にうまく機能しました。

付箋を使って、各部門、各担当がやっている仕事を一つ一つ、書き出していきました。ある人は申請書を貰ってから作業をしていました。ある人は、納期までに仕事を終わらせるために、いろいろな人に申請やお願いをして、スケジュールに間に合わせるべく努力していました。ある人は申請を待っていたらリソース計画が間に合わないので、事前に歩き回って情報を得て予算を立てていました。管理者が知り得ない多くの努力が見えるようになり、実質的に現在かかるはずの時間が分かるようになりました。小一時間程度のワークショップで、集まった担当者が関わる工程を付箋にまとめることができました。私はその結果を元に、Astahを使って、ユースケース図にまとめました。

その後、工程のもつ課題についてはこの図を用いて議論を行うようにしました。その結果かどうかわかりませんが、徐々に工程の問題点は改善されていきました。部署変更の際にも、どの工程に誰が関わっているのかがわかるため、仕事の引き継ぎが容易になるというメリットもありました。

大事なポイントは、自分たちで、リアルなプロセスをリアルタイムに洗い出す、ということです。メアリーが言っていました。トヨタでは、6ヶ月更新されない標準作業は、標準ではなくなるそうです。形骸したチェックリスト、誰かが作って、ちょっとずれていても誰もメンテナンスしないもの...。そうではなく、自分たちで自分たちのやり方を落とすことが重要なのだと思います。

アジャイルチームから、組織のアジリティへ

バリューストリームマッピングは、単なる会議法やファシリテーション法ではなく、現実の「業務のワークフロー」を扱っている点がポイントだと考えています。一つ一つの業務を、操作可能(タンジブル)なオブジェクトに落とし込むことで、あーだこーだいいながら、組織改善を個々人の目線で達成可能な対策に落としていきます。参加者同士の利害調整をすることが目的ではないのです。意見をまとめることも目的ではありません。組織を俯瞰する視点を持ち、そのときどきに最も弱点/ボトルネックとなる部分を把握し、各担当やチームでできそうな、現実的な、改善の努力を引き出すのです。

すでにご自身のチームにアジャイルを適用されている方は、1チームのアジャイル適用にはそれなりに自信を持たれているのではないかと思います。しかし、おそらくその一方で組織レベルの課題には直面しているのではないでしょうか。部門マネジメントやエグゼクティブとの意識合わせ、頻繁な人事異動への対応、部署間のすれ違いや文化の違い、予算の獲得など。リーン・ソフトウェア開発はそういった課題に直面するリーダーやマネージャーの方に、新たな問題のフレーミング(捉え方)を与えてくれるはずです。

Beyond Budgeting (脱予算経営) という概念について

昨年ヘンリックのTweetで知った Beyond Budgeting という概念について、昨日ちょっと触れたところ、(うちの代表でない方の)谷口さんにヒットしたみたいなので、自分なりに理解しているレベルで書いてみる。きちんと本を読んだわけでもないし、きっと間違っているところがあると思うので、いろいろご指摘いただけるとありがたいです。

予算で計画をする組織と、イノベーションのための社内ベンチャー

年次ないし四半期の予算およびその執行を監視するという従来のマネジメントのやり方というのは、中央集権的に組織を管理するためのやり方で、そうすると、現代のように顧客やステークホルダに寄り添ったところでイノベーションを生むことが重要視される企業運営にはちょっと向いてないんじゃなかろうか、という話だ。

企業全体をマネージするためには、全ての情報を中央に集め、一体的にスピード感をもって判断をしなければならない、というのは正しいように思えるのだけれど、判断が一カ所に集中するということは、伝達(形式知化)と時間調整のムダを最大化してしまう。それよりは現場をよく分かっている現場に近いチームが判断する方が効用が最大化するじゃないの、というのが、例えば現地現物とか、スクラムのようなマネジメントスタイルが主張している文化ではないかと思う。

そこで、企業のサイズを小さく保とう、というのは、最近のスタートアップ方面でよく聞かれる話ではないだろうか。37シグナルズの本「Rework ( 小さなチーム、大きな仕事)」でも、人を増やさないことがうたわれている。小さな組織が集まり、投資や育成を含めたエコシステムを作る、というのが Y Combinator のようなモデルなのかな、とも想像する。

一方で、既に大きな組織ではどうしようか、というのも議論されてきた(自分が議論してきたわけではないから、本を読んでそう思っただけだけど)。「イノベーションのジレンマ」「イノベーションへの解」でクリステンセン教授は「社内ベンチャー」という独立組織を提案しているし、「イノベーションの知恵」でも野中先生がそういった独立組織の成功例をあげている。これらのポイントは、従来型のサービスや製品で利用している、厳格/精密/最適化された予算と執行、人事評価の仕組みから切り離した、新しい挑戦と失敗を許容できるチームを作る、ということだ。そういう文化を好むイノベーティブな社員は会社を辞めてベンチャーに移ったり立ち上げたりしてしまうので、彼らを活かす方法、という意味合いもあるのではないだろうか。

Beyond Budgeting (予算レス経営 脱予算経営)

Beyond Budgeting は、同じく大きな組織での処方箋ではあるが、中央集権的な方法ではなく、各チームの自律性に任せ、メトリクスによって全体を調整するという考え方である。

従来型の組織は、継続的に利益を生み出している屋台骨であるがため、予算が予測可能、ということになっている。ある程度正確な予測をたてなければ、給与やオフィス賃料から福利厚生にいたるまで、会社のいろいろな計画が進まないのだから、やはり予測の正確性には気を使うようになっていきがちだ。予測性の根幹は売上予測なので、例えばリーマンショックのようなことがあると、企業運営に大きな誤算を生むようになる。資金というのは余るより足りなくなる方が圧倒的に困るので、緊縮型の予算を組む方に振れやすく、現在収益に直結していない部門から順、切りやすい順に予算を切り詰めていくことになる。そのため、期初は予算に余裕があり、期の途中で未執行の予算が絞られ、期末には税金対策のために経費の前倒し執行が奨励されたりするのは、わりとよく聞く話ではないかと思う。

予算というのは、税務や決算期に依拠すると、年次またはそれを1/4に細分化したものになる。年次の場合、最初にたてた計画を1年がかりで実施することになり、半年以上先のことが予測しがたい状況だと、後半に向かってロスが出やすいだろう。これはソフトウェア開発で、ウォーターフォールモデルが批判されるのと似ている。1年単位の納期の案件の相対的なボリュームが減ってきている、ということもアジャイルが注目される一因ではないかとみている。

Beyond Budgeting は「予算以外のKPIで経営判断をしよう」「資金がショートするかどうかは、執行情報を常に集め、リアルタイムでキャッシュフローを確認していく」「最も情報を持っている現場が最良の判断と執行を目指すことを信頼し、判断をなるべく現場に任せる」ということになる。

Beyond Budgeting は2000年代前半から出てきた考え方で、BBRT (Beyond Budgeting 円卓会議) という人たちが研究をしているようだ。洋書では2冊の本が有名で、メアリー・ポッペンディークの本でも、後者(Imprementing〜)が参照されている。

とりあえず今分かっている、考えていることはこれくらいです。

追記: 日本語訳が出てた

谷口さんに教えてもらいました。

追記

12の原則というのがあったので訳しました。
kawaguti.hateblo.jp