3章 より効果的なアジャイル : 複雑さと不確実さという課題に対処する
煩雑系であるという絶対的な確信がある場合以外は、プロジェクトを複雑系として扱い、アジャイルプラクティスに投資するほうが安全である(なお、プロジェクトを煩雑系として扱う場合は、シーケンシャルアプローチがうまくいくだろう)
ここの前までの説明を読んで、たしかにそれはそうだなーっていう思いになったし、自分がとりあえずアジャイルでやっておくって思っているのとだいたい一緒の理由だった。
シーケンシャル開発でやってるからっていうのもあるかもしれませんが、複雑系でも煩雑系として扱えると思ってしまっている感じがする…
検査
現在 の プロジェクト を 見直す。 プロジェクト の どの 要素 を 複雑系 に 分類 し、 どの 要素 を 煩雑 系 に 分類 すれ ば よい だろ う か。
煩雑系:データ連携の遅延の原因を特定し、リプレース時に取り除く、複雑系:アプリ間の疎結合化を図るため、メッセージングを取り入れる。、
煩雑系 : 特定のプラクティスを体験するワークショップ、複雑系 : ユーザーインタビュー、アイディア創出
最近 取り組ん だ プロジェクト を 見直す。 チーム は プロジェクト の 重要 な 要素 を 煩雑 系 または 複雑系 として 扱っ た だろ う か。 そうした プロジェクト の 課題 の 中 に、 複雑系 の プロジェクト を 誤っ て 煩雑 系 に 分類 し た( または その 逆) こと に 起因 する よう に 思える もの は ある だろ う か。
煩雑系のものをて離れよくするようにマテリアル化がなかなか進んでいないっていうのはあるかもしれない。プログラミングでいうドキュメントが揃っていない状態っていうか。
「ビジネス要求に対して現行のデータ構造を大きく変更する」は煩雑系として考えていたが、試行段階で問題が結構な数発覚したのは実は複雑系としてとらえる必要があった可能性があるかも。
プロジェクト では 検査 と 適用 を どれ くらい 活用 し て いる だろ う か。 他 に 検査 と 適応 を い つ どこ で 活用 できる だろ う か。
2週間に1回は少なくとも活用しているかなー。小さい粒度では2時間ごととかにも。
ほぼ活用できていない(この内容を認識できていないので)。プロジェクト終わりでの反省/ふりかえりで近いことを少しだけ検討しているかも。
OODA の 観点 から、「 敵」 が 誰 で ある かを 観察 する( 特定 の ライバル 会社、 市場 シェア、 利益 目標、 官僚主義 など)。
最近の仕事だと明確に競合製品があることがおおいかなー。
自分たちの領域では直接競合や市場シェアを意識してということは少ないので観察できていない
敵 を 出し抜く ため に 利用 できる かも しれ ない 不確実 性 の 領域 を 3〜 5 個 ほど 観察 する。
チームでの学習とか、既存自社製品とのコラボレーション能力とか、SNSでの各種マーケティング(有名人とのコラボ)とか
適応
あなた の 組織 において 煩雑 系 では なく 複雑系 として 扱う べき プロジェクト を リストアップ する。 それら の プロジェクト を 複雑系 の プロジェクト として 扱う よう に プロジェクト チーム に 働きかける。
ケイパビリティがないことによって複雑系とするほうがいいプロジェクトはたくさんあるなー。専門家がいれば煩雑系だよねっていうプロジェクトが多いというか。
システムリプレースのプロジェクトは開発サイドとしては複雑系として扱いたいが、マネージメント側に煩雑系として(全部問題を洗い出してつぶして計画をって感じ)の人がいるので
不確実 性 の 領域 を 使っ て 敵 よりも 優位 に 立てる よう に 方向付ける。
自分達に不断の努力があってこそできる選択だとおもっていて、それをできるように常によい習慣を実践しないとなー。
不確実 性 について わかっ た こと を どの よう に 利用 すれ ば よい かを 意思 決定 し、 行動 に 移す。
うまく計画に落とし込むっていうのがいまいち自信がないかもしれない?言い換えると「スケールしないことをしろ」の一例なんだとはおもうけど。