プロジェクトマネジメント

2021/02/13

トランザクティブ・メモリーを使え~「プロジェクトをリードする技術 / Project Leading is Skill」の資料はプロジェクトリーダー初心者にお勧め

プロジェクトをリードする技術 / Project Leading is Skill - Speaker Deckを読んで、特に「トランザクティブ・メモリー」が良かった。
良い資料と思ったのでメモ。

【参考】
akipiiさんはTwitterを使っています 「良いスライド資料だなあ。進捗管理で、ボトルネックを常に移動させることは僕も感じていた。プロジェクトをリードする技術 - kakakakakku blog https://t.co/vB5toW5fSy」 / Twitter

プロジェクトをリードする技術 - kakakakakku blog



【1】プログラマ上がりのプロジェクトリーダーは、プレイングマネージャーだと思う。
すると、一人でプログラムを書いたり、自分でバグ修正した方が速いわけだが、それではチームは回らない。
いかにチームを回すか?

上記の資料で良いと思ったのは、アジャイル開発でやればいいんだ、みたいな一本調子ではなく、バランスが取れている所。
たとえば、「計画が得意=クリティカルパスの見極め」は、ガントチャートでも、バックログ管理でも、スプリント管理でも重要だ。

以前、どこかの本で、MSProjectでいちばん重要な機能はガントチャートではなく、PERT図だ、と喝破した記載があって、同意する。
優れたリーダーは、タスクにばらした時に、ネットワーク図をイメージして、どのパスが最短ルートなのか、を頭の中でイメージしている。

ソフトウェア開発が難しいのは、日々の状況によって、クリティカルパスがどんどん変化することだろう。
たとえPJ計画当初にガントチャートを作っても、初めての技術、コロコロ変わる要件、仕様への落とし込みで、クリティカルパスはコロコロ変わる。
つまり、ボトルネックは常に推移していく。
駄目なリーダーはガントチャート保守でボトルネックを見出そうとするが、その作業に追いつかずに破綻する。

【2】チームビルディングも重要な技術の一つ。
タックマンモデルとか色々あるけど、「トランザクティブ・メモリーを大切にしよう」という言葉は僕も同意する。
メンバーの役割分担をリーダーだけでなく、メンバー全員が知って、リレーのバトンを渡すように上手く回す。
そのためには、誰がどんな専門スキルを持ち、誰が暗黙知を持っているのか、を知っておけばいい。

「トランザクティブ・メモリー」は僕は以前は知らなかったので、もっと早く知っておけばよかったと思う。

「トランザクティブ・メモリー」という言葉は、「ビジネススクールでは学べない 世界最先端の経営学」ではなく「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」を読んで僕は初めて知った。

【3】「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」では、トランザクティブ・メモリーの社会実験でこんな話がある。

交際期間が3ヶ月以上の大学生のカップル60組を集めた。
そのカップルの半数はそのまま、残りはランダムな組み合わせのカップルにする。
そして、それぞれのカップルに、記憶力ゲームを試してもらう。

具体的には、科学、歴史、食べ物、テレビ番組などのカテゴリの文章を、カップルは自分の判断で選択して記憶し、どれだけ正確に記憶できていたかを試す。
カップルごとの合計点で評価する。
つまり、記憶作業は1人で行うが、パフォーマンスの優劣はカップルの合計で決まる。

この実験のポイントは、カテゴリ選択時にカップルが相談できないこと。
つまり、カップルはお互いに相手がどんなジャンルを覚えているのか、知らない。

さらに、交際していたカップルと赤の他人同士のカップルをさらに半分に分けて、もう一方には、男性は歴史、食べ物、テレビ番組、女性は残りのカテゴリと指定しておく。

つまり、
①交際しているカップルでジャンル指定のないカップル、
②他人同士でジャンル指定のなかったカップル、
③交際していて男女それぞれが覚えるべきジャンルを指定されたカップル、
④他人同士で男女それぞれが覚えるべジャンルを指定されたカップル、
の4つでランダム化比較試験を行うわけだ。

その結果はどうなるか?

①のカップルの方が②のカップルよりも結果が良くなった。
交際していたカップルの方が記憶力がいい、というのは常識の範疇。
なぜなら、交際していたカップルは、彼と彼女の強みの部分をお互いに知っているので、強みを発揮できるジャンルをお互いに選べばいいから。

しかし興味深いのは、③のカップルよりも④のカップルの方が結果が良かった。
つまり、あらかじめ記憶するジャンルを指定されてしまうと、交際していたカップルよりも、赤の他人同士のカップルの方が記憶力が良かったのだ。

この実験が意味していることは、「ある程度の交際期間を経たカップルは、お互いにどんな強みや弱みを持っているのか、というトランザクティブ・メモリーを自然に持つようになる」ということだ。
たとえば、彼が映画に強いけど彼女は弱い場合、彼女は彼に聞けばいい。
一方、彼女は美味しいレストランはよく知っているが、彼は知らない場合、彼女に聞けばいい。

つまり、Who knows What、誰が何を知っているのか、誰が組織内で特定分野の専門知識や経験を持っているのかを知っていること、というトランザクティブ・メモリーの重要性を示す。

他方、カップルとして自然に形成されたトランザクティブ・メモリーを新しい枠組みで無理に歪めると、非効率を生み出し、カップルの記憶力は著しく落ちてしまう。
むしろ、赤の他人同士のカップルの方が、ジャンル指定だけに基づいて記憶するので、トランザクティブ・メモリーを歪められてしまった交際カップルよりも、はるかに効率的に記憶できたわけだ。

この実験の話を読んで連想したのは、暗黙知を重視する、トランザクティブ・メモリー型の組織文化を故意に歪めた事例は割と多いのではないか、と思った。

たとえば、自社でソフトウェア開発しないユーザ企業やSIでは、大量の派遣プログラマを案件ごとに短期間に総動員してはリリース後に切り捨ている。
すると、案件のプロマネは、トランザクティブ・メモリーに依存しない、属人性のないPJ管理、属人性のない技術で管理したくなる。
そのやり方は、メーカーの単一製品の大量生産方式のように、単純労働者が多い場合には、トランザクティブ・メモリーを重視しなくても、効率的なオペレーション管理を重視すれば成功しただろう。

しかし、ソフトウェア開発のように、暗黙知があまりにも多いビジネスでは成り立たない。
むしろ、苦労して開発してリリースにこぎつけた時、数多くの暗黙知は派遣プログラマに残っているが、彼らが解き放たれたら、そのチームに得られた暗黙知は雲散霧消してしまう。

たとえば、M&Aで買収した企業の社員を、買収元の経営者が勝手に異動させてバラバラにさせてしまうと、せっかく買収先の企業の社員の中であったトランザクティブ・メモリーが破壊されて、M&Aの相乗効果が得られなかった、とか。

うまい例が思いつかないが、トランザクティブ・メモリーを有効活用していない組織や企業は、日本に割と多い気もする。

なお、「世界の経営学者はいま何を考えているのか――知られざるビジネスの知のフロンティア」も「ビジネススクールでは学べない 世界最先端の経営学」の本もお勧め。

| | コメント (0)

2021/02/12

信頼度成長曲線の落とし穴

@MadoWindaheadさんの信頼度成長曲線の記事を読み直して、色々感じたことがあったのでメモ。

【参考】
信頼度成長曲線を語る夕べに参加 | マドびっ! Madosan's View

信頼度成長曲線については、過去に、SRATSのようなツールを試していた時もあって、色々考えていた。
個人的には、信頼度成長曲線は品質管理の中で華のような技術の印象を持っていた。
なぜなら、その他の品質管理の技法よりも、見た目は美しいが実際の中身は統計処理が含まれて割と複雑なので、研究するのにお手頃だから。

また、テストの収束傾向やテストの終了条件の判定に最終的に使うので、リリース判定というタイミングで使われるから、品質管理の中ではかなり重要な位置を占める。

いつテストを終わらせるか?: プログラマの思索

SRATSの使い方: プログラマの思索

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い: プログラマの思索

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

アジャイル開発はメトリクスが取りやすい: プログラマの思索

忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索

しかし、上記の記事の書いてある通り、信頼度成長曲線は前提条件がある。
前提条件とは「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」こと。

信頼度成長曲線は別名、バグ収束曲線でもあるから、バグの発生傾向やバグの発生頻度が重要な観点になる。

僕の理解では、信頼度成長曲線の前提では、テスト作業プロセスそのものにバラツキはないと想定する。
つまり、「単位テスト時間あたりの検出される不具合の数はテスト期間中を通じて一定している」。

一方、システムの機能に依存したバグ数にばらつきがあっても良い。
実際、システムの機能に関係なくバグが機能毎に全て一定の割合で埋め込まれていたら、S字型曲線にはならず、直線になるはずだから。

具体的には、システムテストでバグ出ししていくと、最初はテストは順調に進んでバグもあまり出ないが、途中からバグが出る機能にぶち当たって、大量のバグを検出するフェーズになる。
そして、何とかバグを全て解決して、最後は、全ての機能をテストし終える頃には、潜在バグも残存バグも抽出しきって、バグも収束傾向になって落ち着く、というイメージ。
すなわち、バグ収束曲線はS字型曲線、イメージとしてはロジスティック曲線みたいな感じになる。

そういう経験則が成り立つ状況であれば、開発規模や過去のバグ密度の経験値、システム特性などを元に、信頼度成長曲線の予定曲線をゴンペルツ曲線とか、S字型曲線に似た曲線で予定しておく。
そして、システムテストでのバグ管理の実績を取ることで、信頼度成長曲線の予実管理を行って、バグの収束傾向を見て、残存バグが出し尽くしたか否か、を判定するわけだ。

しかし、実際のシステム開発の経験では、そもそもバグ累積件数はS字型にならない。
むしろ、一直線に発散する感じの場合が多い。
特に新規加入した開発者が多いチーム、過去のシステム保守の経験がないチーム、新しい技術を使った案件などでは、試行錯誤して、ハンドルが荒れた車の運転みたいな感じになるから。

また、横軸にテスト実施日を取ると、テストしない日とか、テストケースの実績が少なければ、信頼度成長曲線は自然に横向きになるが、それはバグが収束した傾向を示すとは限らない。
横軸には、テスト工数を引くとか、テスト作業そのもののバラツキをなくすように、正規化する必要がある。

こういう処理をExcelでやるのはとても面倒。
信頼度成長曲線はBTSがあればデータをExcelにプロットするだけで実現できるのがメリットの一つだが、実際に正確なグラフを描き出すのは面倒。

結局、信頼度成長曲線にせよ、ソフトウェアメトリクスは、安定したプロセスで初めて有意義な意味を持つ。
そういう意味では、一発限りの請負型案件ではとても使いづらい。

Redmineのようなチケット管理ツールは、最終的にはソフトウェアメトリクスを集計・出力するプロセス基盤であると僕は思っている。
しかし、安定したチームで長期間活動するのは、日本のSIではとても実現が難しいので、ソフトウェアメトリクスを効果的に使えた経験は正直少ない。
パッケージ製品の自社開発、長期間の自社の基幹システム保守のように、長期間のPJでは当てはめやすいかもしれない。

| | コメント (0)

2021/01/26

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説

SAFe 4.5のエッセンス」「大規模スクラム Large-Scale Scrum(LeSS)」を読み比べていると、色々気づきがある。
2冊共に完読していないけど、アイデアをラフなメモ。

【1】SAFeの本質はアジャイルリリーストレインにあるのではないか?

複数のスクラムチームのアウトプットを同期させるために、アジャイルリリーストレインで統制をかける。
さらに、アジャイルリリーストレインを複数チームだけでなく、複数PJの集まりであるプログラム、複数の組織、果ては予算まで同期させようとする。

つまり、アジャイルリリーストレインによって、ソフトウェアという成果物、リリース計画、予算まで同期させようとする目論見を企てている。
ただし、SAFeは既存組織の組織構造は変えずに、アジャイルPMOという立場も認めている所は現実的かもしれない。

たぶん、日本のように組織構造も組織文化も変化させにくい所では、SAFeが導入しやすいのかもしれない。

【2】LeSSは忠実に、スクラムをスケールアップしようとしている。

だから、いくらPJが大規模になってもPOは1人だし、スクラムマスターがPJや組織の中心にいる。
SAFeではスクラムマスターの役割は大規模PJの中に埋もれてしまっているが、LeSSでは、大規模PJであっても、スクラムマスターは積極的に活動し、スクラムプロセスを推進する原動力になっている。

LeSSは最終的には、PJのスクラム運用だけでなく、既存の組織そのものをスクラム化しようと企んでいる。
スクラムマスターは、チェンジマネジメントの変革者として、既存組織の文化を変えてしまう役割も担っているように思える。
実際、LeSSでは、従来のプロジェクトマネージャや中間管理職には否定的で、彼らの存在はなくなってもいい、と思っているから。

| | コメント (0)

2021/01/25

キャズム理論をプロセス導入の問題解決に使うアイデア

「BABOK入門」を読んでいたら、ERP導入の難易度と組織文化をマトリクスで整理していたのが非常に分かりやすかった。
そのマトリクスの考え方の背後には、キャズム理論がある。
なるほど、そういう考えなのか。
適当なラフなメモ。
間違っていたら後で直す。

「BABOK入門」を読むと、キャズム理論は、ERP導入だけでなく、PMOが新しい標準プロセスを導入する時に、どういう対処をすれば運用を拡大して推進できるか、という示唆が得られると思う。

まず、キャズム理論は、ERP導入や開発プロセス導入対象の組織文化のレベル分けに使える。

ビジョナリーは、イノベータなので、最新のERP、最新の開発プロセスに興味を持ち、導入してくれる。
アーリーアダプターは、実利重視なので、自分たちの目的に叶うならば、リスクを背負って導入してくれる。
アーリーマジョリティは、保守的なので、他社が多数導入して、デファクトスタンダードになってから導入し始める。
ラガードは、自分たちの組織文化に誇りを持ち、他の価値観を受け入れないので、そもそも導入しないか、導入しようとしても自分たちの組織文化に合うように、ERPをカスタマイズしまくったり、プロセスをカスタマイズしまくる。

他に、キャズム理論は、ERP導入やプロセス導入の問題解決に使える。
キャズム理論では、アーリーアダプターとアーリーマジョリティの間にあるキャズムを乗り越えるのが重要、と知られている。
だから、ERPであれ、新しいプロセスであれ、キャズムを乗り越える対策が必要。

キャズム理論が教える所では、ホールプロダクト理論が知られている。
ボウリング・ピンのように、主要ターゲットを狙って成功させて、その後は次々にターゲットを定めて落としていく。
同様に、ERP導入でも、プロセス導入でも、主要ターゲットを定めて確実に成功させて、周囲のボウリングピンを一つずつ落として、シェアを高めて、デファクトスタンダードに近づけていく。

アジャイル開発の導入でも、Redmineの導入促進でも、同じような苦労があったことを思い出した。

今、PMOが導入しようとしているフェーズは今どこなのか、自分の足元を確認しながら、進めていくべきなんだな、と改めて気づいた。


| | コメント (0)

2021/01/19

文化は組織構造に従う

大規模スクラム Large-Scale Scrum」を読んでいたら、「文化は(組織)構造に従う」という文章があった。
なるほど、と思ったのでメモ。
以下、結論のないラフなメモ。

【1】「大規模スクラム Large-Scale Scrum」P.63では、「文化は(組織)構造に従う」をラーマンの組織行動の法則として紹介している。

組織は、中間管理職やマネージャの権力構造を維持するために、暗黙的に最適化されている。
その結果、組織を変えようとする試みは、職種の名称を変更するくらいで現状維持になる。
その結果、組織を変えようとする試みは、マネージャや現状維持しようとする人々から、理想主義者として非難される。
その結果、文化は構造に従う。

つまり、組織の文化を変えようとするのは愚かな試みで常に失敗する、と。
人々の行動(文化)はシステムの産物なので、システム(組織構造・組織階層)を変更すると、人々の行動が変化する、と。

【2】チームの文化、メンバーの行動、組織の文化は、所属する組織の構造の影響下にある。
逆ではない。
構造は文化に従うよりも、文化は組織構造に従う力の方が大きい。

人々の行動はシステムの産物。
システムを変更すると、人々の行動は変化する。

組織の構成要素を変更すると、人々の行動は変化する。
たとえば、ポリシー、役割、組織階層など。

【3】「文化は(組織)構造に従う」考え方は、システム思考と同じ考えだ。
システム思考では、発生する問題、人々の行動を即座に変更できないのは、悪循環を生むシステムが存在していて、その因果関係によって発生しているとみなす。
つまり、原因となる悪循環のシステムを変更するか、壊さない限り、問題は変化しないし、人々の行動は変わらない。

また、「文化は(組織)構造に従う」考え方は、行動経済学と同じ考えだ。
行動経済学では、人はインセンティブの奴隷、とみなす。
人々にインセンティブを付与することで、人々の行動を特定の方向に誘導しようとする。
たとえば、政府の財政政策や給付金、競争を取り締まる政策によって、企業や消費者、市場を特定の方向に誘導し、政策の効果を引き出そうとする。

【4】「大規模スクラム Large-Scale Scrum」はまだ読みかけなのだが、組織論の話が多い点に気づいた。

いかにマネージャを排し、フラットなチームを残してスケールさせるか?
現場で生き生きと活動しているスクラムから、いかに大規模な組織のスクラムにスケールアップするか?

そのためには、既存の組織構造に手を入れて、スクラムというチームの活動(文化)に悪影響を与えないようにする。
つまり、組織構造にスクラムの原理を反映させて、組織そのものをフラットにしてしまう。

この考えや意見は理想主義的なように思えるが、「大規模スクラム Large-Scale Scrum」を読んでいくと、あながちそうでもない気もする。

コロナ時代では、企業も人もいきなり変化する環境に放り出されて、物理的な接触を禁じられて、リモートワークを余儀なくされた。
すると、物理的にもマイクロマネジメントなプロジェクト管理は実施できなくなり、事実上、組織人ではなく、自由な一個人として労働するようになっているし、そうならざるを得ない。
コロナがなくなっても、労働環境も組織も変化してしまったのだから、もう昔のやり方に戻ることはできない。

そういう時代だからこそ、スクラムをチームベースではなく、大規模な組織ベースにスケールさせることには意義がある。
そのために、組織構造に手を加えて、人々の行動を変容させることも必要になってくるのだろう、と思う。

| | コメント (0)

2021/01/14

管理職に求められる能力はPM理論そのものではなかったのか

管理職に求められる能力の記事を読んでいたら、三隅二不二のPM理論そのものではないか、と感じた。
ラフなメモ書き。
浅い考えなので後で直す。

【参考】
管理職に求められるものとは─新世代リーダーへの条件─(前編)【ONE JAPAN CONFERENCE 2020レポート:PEOPLE④】|ONE JAPAN|note

(3) akipiiさんはTwitterを使っています 「これって、昔のPM理論そのままじゃないか!管理職の職能は不変なんだなと思った。“管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。” 管理職に求められるものとは─新世代リーダーへの条件─(前編)【ONE JAPAN CONFERENCE 2020レポート:】https://t.co/XFNjuiTutr」 / Twitter

【1】(引用開始)
基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンスです。パフォーマンスとは、部門の業績を管理することで、メンテナンスはそのために多様なメンバーをマネジメントすることです。

しかし、管理職は組織の中間点にいるので、この2つに加えてダイバーシティや働き方改革、DX(デジタル・トランスフォーメーション)などあらゆる組織の問題が、すべて管理職にしわ寄せが来てしまっています。

さらに経営層からは、新規事業や新しい価値を作ってくれとオーダーされたり、現有の戦力の中で、多様な部下の強みを引き出して、なるべく早く革新的な成果を、しかもリモートで出してくれと命じられています。
(引用終了)

「基本的に管理職に求められることは今も昔も変わらず、パフォーマンスとメンテナンス」ということは、まさにPM理論そのままだなと思う。
成果を求めるパフォーマンス(P)と、チームビルディングなどのメンテナンス(M)の2つ。

PM理論 ? リーダーシップインサイト

PM理論by三隅二不二 | EARTHSHIP CONSULTING

PM理論とは ~理論から理解するリーダーシップとその変遷~|人材育成・社員研修|ラーニングエージェンシー

【2】そう言えば、PM理論は別名、パパママ理論とも呼ばれるらしい。
「業績:目標達成機能」(Performance)はパパ、「維持:集団維持機能」(Maintenance)はママに相当するように覚えると理解しやすかった。

(引用開始)
当時はまだまだ男が稼いで奥さんが家を守るという雰囲気の世の中だったので、このPM理論はパパ・ママ理論とも呼ばれ、厳しく子どもを育てるお父さんと、子どもの気持ちに寄り添うお母さんのイメージをあてて、このPM理論を説明していた。
(引用終了)

【研究ノート1】リーダーシップ理論(その1)「PM理論」|鈴木康宏|note

【3】「管理職に求められる能力はPM理論そのもの」という意見から気づいたことは3つある。

1つ目は、リーダーシップには成果(P)を求められること。
採用基準」本に「リーダーシップとは成果を求めること」というフレーズがあったが、たぶんそのことを指しているのだろう。
問題解決のためには、リーダーシップを発揮して、周囲を巻き込みながら、あるべきゴールへ到達するルートをとにかく進んでたどり着く。
まずはそういうスキルがなければ、話にならない。

2つ目は、ファシリテーション能力が10年以上前から重視されている理由は、メンテナンス機能の特徴の一つであること、そして、リーダーシップを補完する機能であるためだろう。
管理職に成り立てのマネージャは、部下に仕事を回すよりも自分でやった方が速いので、どうしてもマイクロマネジメントになりがち。
そういう時に、プロジェクトファシリテーションのようなスキルがあると、結果を出すチームを形成できるようになる。
スクラムマスターという役割も、メンテナンス機能を重視しているのではないか、と思う。

3つ目は、上記の記事では、管理職には新規事業を提案することまで求められてはいない、と記載されていたが、優秀な中間管理職ほど、新しい事業アイデアを実現したくてウズウズしている。
誰だって、上から言われた仕事をそのままやるのがモチベーションではない。
自分で実現したいアイデアや夢があって、それが会社の方向性と一致していれば、やる気も上がるし、そうなるように仕向けたいと思うからこそ、職務や権限を利用して動く。

特に、日本の組織では、名君と言われる経営トップは必ず、優秀な中間管理職をブレーンとして持ち、自由に采配が振れるように配慮してくれるものだろう。
たとえば、幕末から明治維新の頃は、薩長の下級武士がそういうトップに引き立てられて、彼らが原動力となって時代を変えていったように。
たぶん、日本は、経営トップが独裁的に振る舞うような欧米・中国のやり方ではなく、中間層のリーダーがリーダーシップを発揮するような、そういう組織文化なのだろう、と思う。

| | コメント (0)

2021/01/02

カンバンはステータス名が大事

カンバン仕事術」を読んで、気づいたことをメモ。

【1】カンバンの運用では、ステータスはどんな観点で作るべきなのか?

カンバンはチケット管理と相性が良い。
なぜなら、カンバンのステータスはチケットのステータスと同じだから。
チケット一覧をタスクボードでビジュアライズすれば、障害修正プロセスのどの工程でボトルネックが発生しているのか、一目で分かる。

では、カンバンのステータスはどんな観点で作るべきなのだろうか?
一般に、Redmineのワークフローでは、新規→進行中→解決→完了 がデフォルトだが、現場で運用する場合は必ず変更した方がいい。
チケットのステータスと同じ、と言っても、それぞれの現場でワークフローはかなり違う、という経験をしてきた。

たとえば、デフォルトステータスのまま運用すると、実は、ステータスに対応する担当者がいない時もあれば、複数人もいる時がある。
たいていの場合、SIの開発プロセスはインフラ基盤・デザイナー・アプリ開発・DB基盤・設計レビュー担当のように部門ごと、役割ごとに縦割り組織になっているので、割と複雑だ。
よって、ステータスが組織と対応付けられていないと混乱しやすい。

では、カンバンのステータスはどんな観点で作るべきなのか?

【2】カンバンのステータスは、役割やチームごとに割り当てる

カンバン仕事術」のイントロでは、Jiraを例として、カンバンのステータスを決める場面がある。
最終的には、ToDo→分析→開発→テスト→受入→運用待ち→本番 に決まる。
決め方は、各ステータスに役割ごとの担当者がアサインされる。

最後に「完了」ステータスがない理由は、チケットのタスクを実装して運用待ちになっても、リリース作業は別のベンダーが担当するので、自分たちで本番リリースしてバグがなかったことを見届けられないからだ。
本番リリースしたとしても、バグが出れば、また戻ってくるので、完了という呼び名が合わない、とチームで決めたからだ。

この場面を読んでいると、カンバンのステータスは、作業の役割ごとに決められる点だ。
開発プロセス、組織構造の部門ごとに、作業の役割は細分化されるので、その単位ごとにステータスが対応付けられる。
Redmineのデフォルトステータス「新規→進行中→解決→完了」ではステータスが少なすぎる場面が現実では多い。

経験上、メーカーのように生産工程が、生産計画部・製造部・品質保証部などのように縦割りになっている場合、ステータスの個数が増える傾向が多い。
メーカーの生産工程を模倣したWF型開発や、ソフトウェア工場のプロセスでは、通常のソフトウェア開発よりもさらにステータスが多くなりがち。

たとえば、開発者がバグ修正してコミットしても、テストサーバーにアップするには、構成管理担当者に連絡してアップしてもらい、別のテスターに検証してもらう、といった手間がかかる場合は、「構成管理担当者によるリリース待ち」「リリース終了・テスト検証前」のようなステータスがないと、誰がボールを持っているのか、混乱しやすい。

とは言え、現状を表したステータスをつけて、ワークフローを作るべき。

別の話では、リーン開発の考え方により、バリュ・ストリーム・マッピングの手法を使って、複雑になりすぎたワークフローをリファクタリングしてプロセス改善しましょう、というやり方もある。

【3】ボトルネックになるステータスの前に、キューを置け

役割ごとにステータスをアサインして実際に運用すると、ボトルネックとなる作業者の前に仕掛作業が滞留し、ボトルネックとなる場合が多い。
その原因を探ると、単純に、WIPが少ないからだけではない。

たとえば、受入ステータスのWIPが4になっているが、常に受入可能なチケットが埋まっているわけではない。
基本は、受入可能なチケットがあれば、担当者はすぐに検査・テストして、リリース可能と判断できれば、運用待ちステータスへ流す。
しかし、WIPが4より小さいと、テスターは常に張り付いて作業しないといけないが、出張や会議などで不在の時は対応できない。
一方、WIPが4より大きいと、テスターがフィードバックを戻す前に、開発者は別の作業に仕掛中になってしまって、すぐに対応してくれなくなる。

よって、受入フェーズでは、バッファとなる「準備完了」と、実際の「作業中」でステータスを分ける。

つまり、何らかの理由で制約がある工程の前にキュー(バッファ)を置くことで、ワークフローの一連の流れが停滞しないようにする。

キューの役割は、作業の流れを平準化することだ。
すなわち、フローの中で、流量(つまりタスク)のばらつきを抑える役割を果たす。

一般にキューは、ボトルネックとなる作業の前後で置かれる場合が多い。
たとえば、ToDo、開発準備完了、開発完了、テスト待ち、リリース待ち、レビュー待ち、受入待ち、などの呼び名がある。

キューの有無を判断するには、ステータスの入出条件、退出条件から考えればいい。

【4】カンバンは奥が深い

キューは、アルゴリズムの基本の一つ。
FIFO。
ワークフローを作る際に、流れが悪い場面で使う事が多いと思う。
ふりかえりでプロセス改善する時に、思いつきやすいと思う。

カンバンが面白いのは、2つある。
一つは、ワークフローの改善に役立つこと。
もう一つは、メトリクスやKPIを採取しやすいので、プロセス改善の材料に簡単に昇華できることだ。

なぜなら、カンバンはフロー管理に特化しているので、流量を速度にたとえれば、チケットの枚数で計測化しやすい。
完了ステータスとなったチケットはアウトプットなので、生産性にたとえられる。

カンバン仕事術」では、下記のKPIを紹介している。

リードタイム:1枚のチケットが最初のステータスから最後のステータスに入るまでにかかった時間
スループット:一定期間(例:1週間)ごとに完了したチケット数

こういうKPIはグラフ化すると分かりやすい。
たとえば、チケット完了日xチケットのリードタイム で散布図をプロットすれば、問題解決について、色々議論しやすい。
なぜ、このチケットはこんなに時間がかかり過ぎたのか?
そこからどんな原因が分析できるか?

たとえば、リリース週xスループットを折れ線グラフにすれば、納期遵守の工夫が見つかるかもしれない。

つまり、これらのKPIを開発プロセスにフィードバックすることで、各ステータスのWIPを減らしたり多くしたり、ステータスを統合・分割する解決法が見つかり、プロセスを改善する行動につなげられる。

元々、Redmineはカンバンと相性が良いので、どのKPIがプロセス改善に役立つのか、そういうノウハウも蓄積できるはずだ。
いろいろ考えてみる。

| | コメント (0)

2020/12/25

因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける

プロジェクト管理や要件定義、システム企画をやっていると、どうしても因果ループ図のような考え方が欲しくなる。
自分の気づきをラフなメモ書き。

【参考】
因果ループ図(いんがるーぷず) - ITmedia エンタープライズ

システム原形とは?複数の切り口で根本原因を探る | akibito

システム原型を知れば、課題に予め対処することができる ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方 ルール編 ? 変化から進化の物語へ/(株)Salt

因果ループ図の書き方 実践編 ? 変化から進化の物語へ/(株)Salt

「引き寄せの法則」はシステム思考で説明できる ? 変化から進化の物語へ/(株)Salt

システム思考がアマゾンを世界一のECサイトにした ? 変化から進化の物語へ/(株)Salt

ルールを覚えても、因果ループ図がうまく書けない理由 ? 変化から進化の物語へ/(株)Salt

新しいビジネスモデルの作成(構築)方法 ? 変化から進化の物語へ/(株)Salt

System Dynamics 日本未来研究センター Japan Futures Research Center

相殺フィードバックを再考: プログラマの思索

相殺フィードバック: プログラマの思索

【1】因果ループ図を使いたい場面はどこなのか?

ロジックツリーやWBS詳細化のように、既に確定した要件を分解していく時ではなく、輻輳した現状、混沌とした現状で使いたい。
問題の原因を掘り下げていく時に、単純ななぜなぜ分析では難しく、いくつかの要因が複雑に絡み合っている場面で使いたい。

プロジェクト管理で、進捗遅延が発生した問題、テスト工程でバグが噴出して品質が劣化している問題。
企画や要件定義で、利害関係者の要望が予算の上限枠に当てはまらない問題、要件定義やシステム企画が混乱している問題。
それらの背後には、数多くの因果関係が問題を複雑にしている。
単純な解決策では、応急処置に過ぎなかったり、逆に問題をさらに悪化させる場合もある。

【2】因果ループ図のメリットは何なのか?

問題の症状を定義して、その問題を増幅させる変数を複数個洗い出し、それを因果関係でつないで、一つのシステム構造として見てみたい。
そうすることで、問題の本質が見えてくる。

堂々巡りの議論ではなく、問題を一つの構造として洗い出したい。

【3】因果ループ図を書くコツは何か?

基本は、時系列グラフを収集して、変数を洗い出す。
時系列で見ると、何らかの目的変数が増大して、問題になっている。
顧客の不満、コスト、行動、利益、資源、など。

時系列グラフにはパターンがある
指数関数、S字型曲線、頭打ちの曲線、振動する曲線、振動しながら成長する曲線、成長するが最後に崩壊する曲線、など。
それらは因果ループ図が背景として構造を持つが、それを具現化したもの。

相関関係と因果関係は異なる。
因果関係→相関関係だが、相関関係→因果関係とは限らない。
統計学では当たり前の常識。

因果関係の間にある潜在変数は書き出す。
潜在変数があるということは、疑似相関があること。
因果の飛躍を避ける。

因果ループ図では、フィードバックという考え方が大事。
システム思考の構造が「システム」「情報」「制御」から成り立つ。
制御=フィードバックになる。
システムダイナミクスの創始者がフィードバック制御の専門家だった。

フィードバックして因果ループ図になる。
たとえば、因→果が正の相関であっても、果→因は負の相関の時もある。
この場合、バランスループ、均衡ループになる。

各ループが自己強化型かバランス型かを判断することが大事。
変化を強めているのが自己強化ループ。
抑制しているのがバランスループ。

拡張フィードバック⇒自己強化ループになる。
拡張ループとも呼ぶ。
雪だるま(スノーボール)が転がる絵を描く方法を指導している。

相殺フィードバック⇒バランスループになる。
均衡ループとも呼ぶ。
天秤の絵を描くように推奨している。

以前、「相殺フィードバック」という言葉が何故か頭の片隅に残っていたが、意味を理解できていなかった。
たぶん、相殺フィードバックはバランスループを表す。

ループ構造に名前を付ける。
因果関係のループには意味がある。
フィードバックの特徴を表す名前を付ける。
読者の直感的理解を促進する。

ストックフロー図に置き換える。
微分方程式に置き換えられる。
専用ツールで、時系列グラフに変換できる。
因果ループ図は定性分析。
ストックフロー図は定量分析に相当する。

【4】自己強化ループ、バランスループの区別するコツは何か?

2つある。
一つは、どこか任意の変数を出発点として、ループに沿ってぐるっと一周して、最初の変数の変化を強めるのか、抑制するのかで判断する。

他方は、マイナスループの合計個数で、自己強化orバランスに分ける。
奇数ならバランスループ。
偶数なら自己強化ループ。

【5】因果ループ図を元に、どんな解決策を実行するのか?

絡み合った因果関係の中で効果的な作用点=レバレッジポイントを発見するのが大事。
Amazonビジネスモデルの初期モデルは、顧客体験だった。
Kindleビジネスは、出版社だった。

割れ窓理論では「割れた窓ガラス」だった。
割れた窓ガラスを徹底的に無くすことで、最終的に犯罪件数が劇的に減った。

目的は成長させたい場合、
システム内の自己強化ループを強める施策を入れるなら、「ベゾスが考えたAmazonビジネスモデル」のように、別の自己強化ループを作る。

システム内のバランスループを弱める施策を入れるなら、「成功の限界」のように、制約を入れる。
「犯罪都市ニューヨークの割れ窓理論」のように、流量を抑える変数を入れる。

目的は現状維持なら、
システム内のバランスループを強める施策を入れるなら、制約や流量を抑える変数を入れる。
システム内の自己強化ループを弱める施策を入れるなら、別の自己強化ループを作る。

【6】感想

因果ループ図は使いこなすのが難しい。
因果関係となる変数を導くこと、それらを意味あるようにつなぐのが難しい。

一つのきっかけは、時系列グラフとセットで考えること。
そして、2つの変数のみでまずはループ構造を描いて、雪だるま式に自己強化ループを増やす。
あるいは、天秤のようにバランスループを書き出す。

ループ構造に名前を付けるのも重要。
この認識が以前はなかった。
売上増大ループ、顧客関係性強化のループ、とか。

因果関係と相関関係は違うのに、混同している時もある。
まずは書いてみては直す。

やりたいのは、問題となるシステム構造を描き出したい。
そうすれば、どこかの変数に制約を入れれば、流量が減るので、拡張ループは抑えられる。
成長させたい時は、別の拡張ループを増やるように、売上増加の別の戦略を打ち立てれば良い。

Amazonのベゾス、MSのビル・ゲイツも因果ループ図を使いこなしていた、と言う。
この考え方を実際に使ってみる。

| | コメント (0)

2020/12/11

プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある

プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある、という言葉に惹かれたのでメモ。
論理性のないラフなメモ。

【参考】
「曖昧さへの耐性の旅」が近い - 金融そして時々山

(引用開始)
「プロジェクトマネージャーの資質として重要なものの一つに『曖昧さへの耐性』がある」という部分でした。これは「世界一わかりやすいプロジェクトマネジメント」という本にでてくる話なのですが、受講者の皆さんはこれまであまり聞いたことがなかったのかもしれません。
(引用終了)

「曖昧性とのたたかい」より抜粋したプロジェクトマネジメントのチェックリスト - takuya0206's diary

(引用開始)
提案依頼書に要求仕様などの詳細が書かれていることはまずない
完璧で完全な契約にこだわりすぎると、顧客に嫌がられ失注する恐れがある
曖昧さが残る状態が避けられない以上、この曖昧性をいかにコントロールするかがプロジェクトマネジメントの最大の課題である
(引用終了)

プロジェクトの曖昧さは不確実性のコーンと同じと思う。
曖昧さが残る状態から開始するのは避けられない。
その曖昧さをどうコントロールするのか?

ウォーターフォール型開発では段階的詳細化によりスコープを狭めたり、QCDが合致切り目られた計画を元にQCDの予実管理で差異を事前に検知しながら、曖昧さをコントロールしていく。

一方、アジャイル開発では、短期間のスプリントでスコープをコントロールしながら、漸進的に品質を高める。
また、ユーザーストーリーはプロダクトバックログの優先順位でふるい分けられて、その時々の状況を織り込みながら、変化を取り込む。

エンジニアであるからには、ソフトウェアであれ、ハードであれ、要件とQCDの実現性のバランスを取るのが顧客から期待されている。
でも、曖昧さとQCDのトレードオフのバランス感覚は、いつになっても難しいと思っている。

プロジェクトマネージャに必要な能力は、そのトレードオフの感覚がいちばん重要なはず。

そういうトレードオフの技法をエンジニアリングとして形式知化してきた。

他方、特にソフトウェアのエンジニアは曖昧性に弱い。
結構自分の裁量が大きいので、作った後でユーザに見せると、全く違う、とよく言われる。
ソフトウェアはいろんな実現方法があるので、1つのロジックを複数のプログラムで表現できるために、コードクローンも発生しやすい。
その分、バグも出やすくなる。
似たようなコードが沢山発生するので、技術的負債はリリース直後から発生し、リプレースするまでその重みで保守すら難しくなる。

曖昧さのコントロールは、PMBOKでもアジャイル開発でもその難しさは変わらない。
QCDでコントロールするのか、スコープでコントロールするのか。

| | コメント (0)

2020/12/05

ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説

「チケット駆動開発がまわりはじめるまでの取り組み」のAdventCalendar記事を読みながら、ツールとプロセスの因果関係や、良い組織文化を生み出すきっかけは何なのか、を改めて考えてみた。
ツールで定義したプロセスが組織文化を作り出すのではないか、という仮説を持っている。
ラフなメモ書き。

【参考】
マインドセットに至るまでの話 - TypeError:

#ssmjp Advent Calendar 2020 - Adventar

タイムテーブル「チケット駆動開発がまわりはじめるまでの取り組み」 | Redmine Japan

【1】僕がすごく興味を惹かれて、同感したのは下記の言葉。

(引用開始)
ゴールの明文化し全体像・規模感を見通し 「誰が」「どこまで」「何を」するのかの明確化しチームで同じゴールを目指して進めていくということに対してチケット駆動開発が非常に強力なツールであることを最後に改めて実感しました。
(引用終了)

困難な状況に直面しているプロジェクトを運営したり支援する立場にいると、技術やプロセス云々ではなく、まず火消しを行って、チーム全員が地に落ちたモラールに火を付けて、プロジェクトのエンジンを回す所から始めるのが必要な時がある。
しかし、火消しはできるが、メンバーのモラールを高めるのは割と難しい。
色んな事情や背景はあるだろうが、何をやっても駄目じゃないのか、みたいな負け犬みたいな雰囲気が出たり、それは私の仕事や責任範囲ではないですから、みたいな縦割り組織の雰囲気があったりする。

それを解決する手法は色々あるし、既に知られているものも多いだろうが、僕は、結局は、ショートカットせずに王道のスタイルを貫くしかないのだ、と思っている。
プロジェクトリーダーはリーダーシップを発揮して、共通目的を掲げてメンバーと共有し、メンバーに権限を委譲し、業務と責任を一致させて、メンバーと目標を共有して、目標を達成するための意欲を引き出す、という王道の方法しかない。

そういう状況において、道具立てとしてRedmineがあって、そういう組織文化を生み出すプロセスとしてチケット駆動開発を当てはめると、メンバーのモラールを向上させる仕組みが整った、という事例ではないか、と思っている。

【2】ツールがプロセスを明確に定義し、プロセスがメンバーのモラールを引き出し、プロジェクトの推進力を加速させる。
たぶん、そういう仕組みを作ることが、プロセス設計であり、プロジェクトリーダーが本来やるべき仕事であるはずだ。

そういう方法を実現する為に、チームビルディングの手法が特にアジャイル開発では数多く生み出されてきているし、参考にもなっている。

ツールでプロセスを透過的に設計して、メンバーにはプロセスを意識させずに運用してもらうが、実はそのプロセス設計にチームビルディングの手法やアジャイル開発のプラクティスを植え付けておけば、自然に、メンバーの自発的な行動を促し、チームはどんどん加速していく。
そういう仕組みを本来は作りたいはず。

スケジュールを厳格に予実管理してメンバーを半ば脅して、進捗遅延の責任を取らせる管理手法がやりたいことではないはずだ。

【3】では、メンバーの貢献意欲やチームの活性化を促すのは、ツールなのか?プロセスなのか?

以前の僕は、Redmineでいかにアジャイル開発というプロセスを実装するか、に興味を持って色々試行錯誤していた。
その結果を振り返ると、結果的にメンバーの自発的行動を促し、チームは活性化するという気付きが得られたが、当初は、Redmineというツールがチケット駆動開発を生み出し、Redmineがチームを活気にさせる仕組みを生み出している、と思っていた。
つまり、ツールがプロセスを生み出し、そこからチーム運営が上手くいく結果が得られたことから、ツールこそが全てだ、と思っていた。

しかし、考え直してみると、アジャイル開発というプロセスが、メンバーに責任感と自律性を促し、チームを活性化させたのではないか、と思う。
アジャイル開発にはプラクティスが豊富で、チームビルディングの手法が様々にあるので、メンバーやチームに自然に影響を与えて、自然に良い行動を促すように仕向けることができる。
すなわち、ツールはプロセスを生み出すが、プロセスの良し悪しがメンバーの貢献意欲やチームの活性化に大きな影響を与えているわけだ。

【4】以前の僕は、官僚化した日本企業がもたらす組織構造によって、Redmineというツールで実装したプロセスがどんどん複雑化する点に興味を持っていた。
「アーキテクチャは組織構造に従う」というコンウェイの法則が、実は、Redmineにも見られる、という点に驚いて、非常に興味深かったからだ。

一方、最近では、メンバーの貢献意欲やチームの活性化を促す組織文化はどうやったら生まれるのか、に興味を持っている。
そもそも、プロジェクトリーダーや中間管理職、経営層にとっては、会社を活性化させる組織文化を作り出す方に大きなインセンティブがあるはずだ。
彼らは、最終的に、戦略に基づいた事業に利益をもたらすための組織文化をいかに作り出すか、に腐心している。

今の仮説は、ツールが定義したプロセスの設計が上手くはまれば、メンバーの貢献意欲や責任感、チームの一体感や使命感を生み出すことは自然にできるはず、というものだ。
では、どんなプロセスで設計すると、メンバーの貢献意欲やチームの一体感を生み出すことができるのか?

この仮説を色々試してみたいと思っている。

| | コメント (0)

より以前の記事一覧