ThoughtWorksが提唱するビジネス・イノベーションのための「カンバン」

  • このエントリーをはてなブックマークに追加
  • このエントリーをはてなブックマークに追加

戦略としてのカンバン
Agile Conference Tokyo 2013に行ってきました。会場は満席に近く大盛況。コンテンツも目白押し。そんな中、ThoughtworksのKraig T.Parkinson氏によるキーノート「戦略としてのカンバン:ビジネスイノベーションのために」の感想を書いてみます。すげー意訳しています。

イントロダクション

Thoughtworksは言わずと知れた開発企業です。15年前に60名だったスタッフも、グローバル化によって2000人へと増加したそうです。グローバルとはいえ、組織は似たような問題を持っています。例えば、「従来型のやり方にしばられてしまう」というのは典型的な課題でしょう。しかし、アジャイル開発のような手法は、すべてを投げ出すぐらいの意気込みがなければ実践は難しいものです。

すでに従来型産業と技術産業を区別する時代は終わりました。IT部門という考え方も古臭いものです。現在では、ビジネスとテクノロジーの融合が必要で、一体感を持って取り組まなければなりません。このあたりは、最近じわじわ人気を集めているDevOpsより広い視点ですね。そのうちBizDevOpsになっていくのでしょうか。

そして、プロダクトの寿命も短くなっています。何年もかけて開発をするのも古い。スピードによる優位性が強まる現在社会では、開発に時間をかけることすらビジネスに致命的なダメージを与えるのでしょう。

アジャイルな3本柱の登場

そこで、リーンスタートアップ、ビジネスモデル・イノベーション、継続的デリバリーといった考え方が重要になります。これは今の時代の3本柱とも言えます。特に継続的デリバリーは、Thoughtworksのビジョンでもある重要な考え方です。常に「プロダクションレディー(いつでもリリースできる)」の状態を維持し、文字通り継続的にデリバリーを進め続けます。

技術制約もゆるやかになくなっていますが、依然として技術は複雑です。それいがいにもたくさんの難問に直面しているため、上にあげたような3本柱を実現するのも難しい。ではどうすればいいか?恐らくThoughtworksはイノベーションのルーティン化を解決策の1つとして考えているようです。

戦略としてのカンバン

ここで「Kanban」という方法論が登場します。しかし、氏の説明を聞く限り、単純にKanbanの原則や価値を用いるのではなく、Kanbanのアイデアの中から必要な要素を取り入れ、ビジネスモデル・イノベーションのための枠組みを作ろうとしているように見えました。つまり、このセッションのカンバンはKanbanという意味ではなく、彼らが考えた新しいカンバンなのだと思います。(恐らく、Kanbanを期待した僕のような方は混乱たかも)

その新しいカンバンの原則は3つです。

  1. ストーリーを知っていると思いこまない
  2. 適切な人員をアサインする
  3. 実行と確認を継続的に行う

「ストーリーを知っていると思いこまない」については、Thoughtworksではアイデアを大切にしているため、どんなアイデアも受け入れる文化があるのかもしれません。だから、「それはこうだ」という思い込みをやめ、全部出しきってから判断をします。

個人的に興味深かったのは、どこかの顧客のために作ったユーザーストーリーの話でした。はじめは以下の様なストーリができました(うるおぼえ)。

リサーチャーとしてリサーチ結果に素早くアクセスしたい。なぜなら〜

ストーリーとしてはイメージしやすい内容ですが、彼らはこう考えました。

リサーチ結果をどう管理すればイノベーションにつながるだろうか?

作るべきストーリーの中からのストーリー発見。これが、ユーザーストーリーの重要なポイントかもしれません。何度も繰り返し伝えられているように作るだけではダメな時代なのですから。

スクラムのバックログが有名になり、バックログの管理や定義などがよく話題になります。しかし、ストーリーはその時、その場所で生まれたものであり、時間がすぎれば過去の価値になる可能性があります。Thoughtworks流の要求分析手法はとても興味深いものでした。

継続的イノベーションフレームワーク

彼らの考える継続的イノベーションフレームワークは以下の要素から成り立ちます。

  1. 機会を増やす
  2. アイデアを出す
  3. 物事の本質への道を確立する
  4. テストと検証
  5. 解決策を収穫する

いろいろな視点で考え、デイリースタンドやスプリントプランニングのような場で議論を重ねます。実行は厳密に行い、失敗しても安全になるように考えます。

ユーザテストやゲリラテスト(カフェなどで知らない人に使ってもらうなど)を活用し、フィードバックに耳を傾けます。3人30分のフィードバックで十分な量のフィードバックが集まるはずです。そしてそこから学び、前進するのです。

きっと、ここまで考えると組織の視点が必要になってきそうですね。多種多様な人が集まるカンファレンスなので、いきなりの組織してんは難しいかもしれませんが、避けては通れない道なのでしょう。

そして、氏はエドワーズ・デミング氏の言葉で、セッションを締めました。

変化が必要なのではない。生き残ることが必要なのだ。

おわりに

最後に、全体を通して、かなりハイレベルな視点のものが多かった気がします。どちらかというと現場の話ではなく、フレームワークや標準化といったプロセスを確立する人たちの視点です。

ただ、彼らは顧客に応じて適応しながら作り上げているのを忘れてはなりません。

こういった氏のような人材がいて、その声に耳を傾ける顧客がいることで成り立つのでしょう。こういった開発コンサルティングは、日本ではまだあまりメジャーではない気がしますが、やがて増えてくるようにも思えます。

仮に、これまでのアジャイルが部分最適だとすると、これからは全体を最適化するアジャイルが台頭してくる。そんな予感を感じさせるセッションでした。

タグ: ,
カテゴリー: 記事
アーカイブ