正しいものを正しくつくる

デジタルプロダクト中心型組織になるのか、価値探索・開発型組織になるのか

　「アジャイル型価値開発」の話に触れた。　「価値を探索し、開発する」という文脈と、その組織的拡張、スケール化は別の話になる。実際のところ、アジャイル型価値開発（仮説検証型アジャイル開発）では、複数チームの構造化については言及していない。むしろ、「チームを分けない」ところに立っている。　「より新規性の高い価値の探索と開発」という文脈に立って考えるならば、大勢のメンバーがいてぞろぞろとチームと編成するところから始まる、というのは考えにくい。考えにくいというか、既に何かがお

「アジャイル型価値開発」とは何か

　プロダクトや事業開発向けに「仮説検証型アジャイル開発」という論を掲げて、長らく適用している。内容は書籍「正しいものを正しくつくる」にまとめており、いまだ私の主なライフワーク先となっている。　ただし、適用先が広がるに連れて、ソフトウェア・プロダクト開発に端を発した方法では微妙な「調整」が必要となることも出てきた（例えば、ソフトウェアに限らない事業開発や業務への適用）。　実践に際してその調整を加えながら適用しているが、そろそろその調整分についても整理をしようかと思っている

自分たちの居る場所を、自分たちの好きな場所に変えていこう。

　数年前、「デジタルトランスフォーメーション」を入り口にして始めたこの活動は、確実にその所在地を「アジャイル」に移してきている。開発に留まらず、組織そのものにアジャイルを宿していく。いわゆる組織変革。　組織変革といえば、組織内の言葉を変えることだ。それはいわゆる「文化、風土を変える」ということに繋がっていく。そのことは、前提であり、目指す先であり、最初にして、最後の最大のハードルと言える。　この手の文脈には学習する組織、組織開発、近年で言えばパーパス経営といったキーワ

「まあ何とかやれた」からも学びを引き出すふりかえり

　「ふりかえり」を繰り返していると、段々と「意見があがらない」「表出が少ない」という状態が続くようになることがある。Keepも、Problemも、概ねこれまでの派生のものだったり、それほど新鮮味のあるものではなかったり。中身は頑張ってひねり出した、という具合で、取り立てて扱うほどでもないように感じる。こうなっていくと、ふりかえりの意義が段々と感じられなくなってくる。　実際のところ、表出が少なくなっていくのには様々な要因が考えられる。ここでは、その一例として「ふりかえりの題

探索プロジェクトの「立ち上がり」を作る

　探索活動・探索プロジェクトをはじめるにあたって、最初に必要になる一式とは何か。最小限とすると以下を置く。なお、ここでいう「探索活動」とは、仮説検証型アジャイル開発における「左円」のサイクルのことである。探索立ち上げの一式 (1) 事前知識を揃える (言葉の理解をあわせる) (2) 探索のインセプションデッキを作る (3) チームビルディングワークを行う (ドラッカー風エクササイズなど) (4) スクラムイベントを決める (いつ何やるか決める) (5) バックログ

「作りたいものを作り続けられるようにする」が最強

　自分たちが作りたいものを作っていくことと、作ったものを使ってくれる人のために作っていくことと、どちらに重きを置くか？　という二項対立的な問いに向き合う意味はそれほど無いかもしれない。どちらか一方ではなく、どちらにも足を置きながらいく。現実的かつ、無難な回答だ。「いい塩梅で進めていこう」は回答としては正しいが、現実どうしていけば良いかには何も示すことができない。　あえて、白黒をつけるには？　私は「作りたいものを作り続けられるようにする」を選ぶ。　作りたいものを作る

「熱量マネジメント」を自分たちで行う

　組織としてこれまでの取り組みが弱いところ、あるいは組織初の取り組みを手掛けていく場合。「私がやらねば誰がやるんだ感」が自分自身を励まし、後押ししていくことになるだろう。この手の「越境活動」（組織内に前例がない取り組み）の最初の原動力は他ならぬ自分自身の中にある熱分に他ならない。　最初はそれで良い。一方で、初期段階は極めて燃費が悪く（投入する熱分に対して、進みは牛歩だ）、「次の段階」に向かう頃には底をつきはじめる。一人の思いだけでは持続させていくのが難しい。「次の段階」で

アジャイルの「氷山モデル」（プラクティス、原則、価値観）

　アジャイルを取り入れていく、という話。まず、取り掛かりになるのは「プラクティス（方法や手順）をはじめてみる」ということが多いだろう。そこで、多くの人が語っているように「単にプラクティスをコピペするだけでは上手くいきませんよ」という観点が取り沙汰されることになる。　とはいえ、プラクティスへの最適化が無条件に行われてしまう、ということは未だよく見かける状況だろう。なぜだろうか。それは、 (1) プラクティスは具体的な活動なので目に見えやすく、理解しやすい (2) プラクティ

チームで向き合おう「イシュー、仮説、タスク、問題リスク」

　チームでやるべきこと（タスク）の整理がついていない….なあんて状況はいまだありえることだが、その要因は「タスクマネジメントの方法が分かっていない」ということではないように思う。方法が分からないのではなく、タスクマネジメントを始める「タイミング」を見失っているのではなかろうか。　チームで仕事をはじめたばかりの最初は、やることも少なくて、あるいは物事がシンプルで肩肘張ったようなタスクマネジメントなんて要らなかった。なくても回るし、かえって決め事を増やす方がオーバーヘッドにな

プロダクトレビューでユーザーの動きを再現する

　以前、「プロダクトレビュー」なるものについて書いた。　インクリメントとプロダクトという粒度関係とは別に、「検査・検証」の観点からも整理してみよう。3つの活動それぞれで、特徴が出てくる。　ある意味で、内部で行う検証、外部で行う検証という分けが見えてくる。内部であれば速い動きが期待できる。外部（想定ユーザー）を巻き込むとなると、その分のオーバーヘッドは伴う。さっと確認、早く検証する分には内部で、異なる視点・より本質的なフィードバックを得るには外部で、と使い分けるイメージ

アジャイルとは「過程」をともにするためのもの

　仕事の速さ、上手さはどこで違いとなって現れるのだろう。先日、アジャイルを取り入れて何が変わったのか、チームとふりかえっていて、ある感想をもらった。　アジャイルな仕事の取り組み方を行う前に、ロジカルシンカーに仕事の定義、設計、計画などを一手に引き受けてもらい、そのアウトプットをもとにその後の仕事を続ける、というやり方を取っていたらしい。ロジカルシンカーが一人で考えるものだから、アウトプットが出てくるまでの速度はチームで考えるよりも圧倒的に速い。　ところが、そのアウトプ

スプリントで変化に向き合う5つの観点

　スプリントによってチーム仕事を進めるスタイルを取っていたとする。当然、スプリントプランニングを行っているだろうから、当該スプリントで何ができるといいか、何をやるか、どこまでやれるかといった計画作りはそこで担保しながら進めているはずだ。　そうして変化を受け入れられる仕組みを作るのがスクラムの狙いとなる。…というはずなのだけど、プランニングで収まり利かないレベルの「変化」「変更」というものもありえる。なにそれ？　スプリントはそれぞれ独立しているが、スプリントを通じて形作

複雑な論点をチームで仮説としてまとめるには？

　アジャイルを組織に取り入れていこうという話は、いわば「仕事の取り組み方」「仕事の進め方」に等しい。それだけに、具体的にどう進めていくのか、というところで議論百出、収拾をつけていくことが難しい。　何が「論点」になりうるか、整理してみよう。ざっと4つあげられる。　もちろん、ほかにも論点はありえる。適宜考慮が増えるが、4つでも多いくらいなのでこれ以上は同時に寄せていくよりも、論ずるタイミングを分けた方が良い。まず4つの論点を通して、ベースとなる仮説を作る。　にしても、

結果に向き合う際の「3つのスタンス」がチームの未来を左右する

　日々の営みから得られる「結果」にどう向き合うか。この向き合うスタンスにとって、その後の展開があまりに変わるため留意しておきたい。　まず、最初に取り上げるスタンスは、「起きている結果は正しい」。この考え自体は、間違いではない。持てるものを最大限投じて得た結果、あるいは「やってみる」で得た結果、それを否定し始めると「とことん準備しなければ始められない」メンタリティを高めていくことになる。このメンタリティをどうにかしていくのが昨今の組織に共通する「根強い問題」であることを思え

フォローしませんか？

2023年11月の記事一覧