AIが思考を代行する時代に人間が「知識を繋ぐ」固有の価値とは何なのか？

AIが知識ネットワークの構築すら代行する時代、人間が自ら思考する意義はあるのか。
AI時代の思考と知識ネットワークとは何なのか？
Obsidianによる暗黙知の可視化とAI連携の現在地を踏まえ、概念同士を自らの手で繋ぎ、世界観を深めていく「人間固有の思考行為」の本質と価値に迫る。

【参考】
Obsidian - Sharpen your thinking

AI世界で価値を持つ知識｜クロメル

【1】Obsidianは単なるmarkdownエディタ、アウトラインプロセッサと思っていたが、他人のObsidianを見ると、自分の思考の中身を見える化するツールだと思う。
Obsidianのネットワーク図は、自分の頭にある概念モデルを見える化したものだと思う。

Obsidianのネットワーク図とは自分の思考行為そのものだ。
たくさんの言葉、概念がバラバラにあったとしても、それを理解するために、自分の頭の中でそれらを関係づけることで理解を促進する。
概念そのものよりも、概念同士をつなぐ関連線、概念同士の関係が重要だ。
ネットワーク化が思考そのものだ。

僕は概念同士を関連付けるネットワーク化は、ビジュアル化、図示化と思う。
きちんと絵や図にできないが、空想できるもの。
目に見える形にしようとすると、雲のように消えてしまうが、それでも図示できるもの。

Obsidianのネットワーク図は、氷山モデルのうち海面下の隠れた暗黙知に相当すると考える。
氷山モデルのうち、目に見える氷山は、バラバラの概念。
それらの概念は関連付けられていないので、単なる石ころに過ぎない。
しかし、海面下では、それら概念は関連付けられて、思考の本棚に概念が整理されて片付けられて、いつでも取り出せるような形になっている。

Obsidianのネットワーク図は、SECIモデルでは、暗黙知から形式知へ変換するプロセスに相当すると考える。
バラバラの概念、暗黙的に隠された概念は、ネットワーク構造から、別の概念を想起させる。
それこそが、蒸留された知識、概念。
一つの概念で、全ての現象、事象を説明できる。
一つの概念から、芋づる式にすべての知識にアクセスできる。
そんなイメージを持つ。

たとえば、製造業における技能継承ならば、ベテラン技術者が持つ暗黙知に相当するだろう。
この工程では実は、温度は何度くらい、どんな明るさや色なのか、どんな感覚なのか、どんな音なのか、をベテランは直感的に知っている。
しかしそれらは言葉にされず、彼の経験の奥底に隠されている。
その暗黙知を具体化して言葉に出し、その言葉を関連付けることで、一つの概念を形式知に変換させる。

【2】では、AI時代ではObsidianはどのように使われているのか？
ある人の使い方が参考になった。
彼は、Obsidian上でメモやログをmarkdownでとにかく書いて保存する。
そのmarkdownファイルには、Open Knowrageフォーマットというタグを付ける。
このタグ付けにAIを使い、AIでタグ付けを自動化する。
すると、このタグに基づいて、Obsidianが概念を紐づけてネットワーク図を作り出す。

つまり、AI時代では、ObsidianとAIはとても相性がいい。
学習データを人間が作り出し、それを元にAIがタグ付けして、Obsidianというツールが概念同士の関係をネットワーク構造に自動化する。
それにより、概念の多次元ベクトル空間が自動生成される。

これこそが、オントロジーに相当するものだろう。
ドメイン駆動設計なら、ドメインモデルそのものになるだろう。

従来はオントロジーやドメインモデルは人力で作るしかなかった。
よって、そのモデルは陳腐化しやすかった。
しかし、AI時代では、AIが自動更新してくれるので、とても重要な資産になる。

【3】AIがObsidianのネットワーク図を自動生成するようになれば、人間の思考行為そのものもAIが代用するだろう。
AIは計算資源が豊富であれば、人間の思考よりもはるかに高速で強力だ。
人間の思考なんてあっという間にAIが追い越すだろう。

では、AI時代では、人間が思考する行為そのものに意味はあるのか？
全てAIで思考行為そのものも代行できるなら、人間の思考に存在意義はないのではないか？

この意見に反対する立場として、クロメルさんの記事が参考になる。

AI世界で価値を持つ知識｜クロメル

（引用開始）
大学で学ぶ目的って、この知識ネットワークを自分の中に作る事が一つあると思うんです。
知識を売る仕事は、いえ少なくとも僕のnoteの活動は、ここにまだ価値を生める余地があると思っています。
何か異なる分野や概念を探って「価値の高い」橋を見つけ架けるのです。

点と点を線で結ぶ価値は、AIに対して点自体の価値より比較的残るだろうと言う主張です。
（引用終了）

AIの方が概念の多次元ベクトル空間を作り出す能力がいくら高くても、人間が人力でネットワーク構造を作り出す行為そのものは意義がある、という主張だ。
僕も直感的に賛成する。

概念のネットワーク図を自分の頭の中に作り出す行為は、自分の世界観を深く、広くさせるもの。
その行為そのものは忘れたくない。

ビジネスモデルキャンパスの構造がようやく分かった

新規事業のアイデアはあるのに構想が進まない。
ビジネスモデルキャンバスの枠を埋めるだけでは説得力あるストーリーを描けず、手が止まるからだ。
その悩みを打破する鍵は、項目の「因果関係」にある。
既存フレームワークと繋ぎ、人を動かす事業構想に仕上げるキャンバス活用法を書いてみた。

【参考】
「事業計画に落とせるビジネスモデルキャンバスの書き方」、
「最強の戦略ツール　ビジネスモデル・キャンバス」

ビジネスモデル・ジェネレーション ビジネスモデル設計書 | アレックス オスターワルダー, イヴ ピニュール, 小山 龍介

ビジネスモデル・キャンバス徹底攻略ガイド 企業、チーム、個人を成功に導く「ビジネスモデル設計書」 | 今津 美樹

図解ビジネスモデル・ジェネレーション ワークショップ | 今津 美樹

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る | アレックス オスターワルダー, 関 美和

【1】今頃なぜ、ビジネスモデルキャンパスに興味を持つのか？

理由は、新規事業のスキーム、枠組みを考える時に、ビジネスモデルキャンパスのようなフレームワークが必要だからだ。
むしろ、新規事業スキームを考える時のフレームワークが今まで無くて苦労していたからだ。

最近、新規事業、新規営業をやってみたいと思うようになった。
しかし、今までに未経験だからどうやればよいのか全く分からない。
そこで、色んな本を読んでみた。
しかし、分かったようで分からない。
新規事業のアイデアはあるが、それを実現する手順が自分の中で確立していない。
だから、他人に聞きまくって、試行錯誤でやっている。
それがすごく無駄。

しかし、新規事業アイデアをビジネスモデルキャンパスで描くイメージを初めて掴んだので興奮している。
興奮した理由を今から書いてみる。

【2】では、そもそも今までなぜ、僕はビジネスモデルキャンパスを使ってこなかったのか？

理由は、ビジネスモデルキャンパスの9項目に文字を書くだけでは、ビジネスモデルがイメージできなかったからだ。
単なる箱ぐらいしかイメージできなかった。
「ビジネスモデル・ジェネレーション ビジネスモデル設計書 | アレックス オスターワルダー, イヴ ピニュール, 小山 龍介」本は有名だし、読んだが、ピンとこなかった。
9項目ごとに、何を書けがいいのかは教えてくれる。
しかし、実際の新規事業を書こうとすると手が止まる。
何を書けばいいのか、どんな粒度で書けばいいのか、分からない。

ビジネスモデルキャンパスを書いたとしても、しっくりこない。
理由は、単なる箱であって、それらがどんなストーリーを語ってくれるのか、見えないからだ。

自分のアイデアにストーリーがなかったり、因果関係が破綻していたり、論理が飛躍していると、他人は納得しない。
自分のアイデアをいくら語っても、相手が納得しなければ行動してくれない。
だから、いつも歯がゆく感じていた。

かと言って、新規事業計画書の目次に沿ってWordを書いていくのも何か違う気がしていた。
各項目の詳細に入り込みすぎて、全体像がつかめないからだ。

【3】では、ビジネスモデルキャンパスのポイントはどこにあるのか？

ポイントは、9項目もある各項目の流れ、因果関係、自己強化ループに着目することだ。
各項目の流れこそが、ビジネスモデルのストーリー、ビジネスモデルのナラティブに相当する。

ビジネスモデルキャンパスには流れがある。
①左半分はコスト構造、右半分は収入モデル、
②左半分は自社軸、右半分は顧客軸
に相当する。

ビジネスモデルキャンパスのポイントは、価値提案を中心に３方向に線を伸ばすことだ。
この線が因果関係、ストーリーラインに相当する。

ビジネスモデルキャンパスのストーリーラインは5パターンぐらいあると思う。

①顧客価値
　　[CS] 顧客の課題 → [VP] 解決価値 → [CH] 届ける経路 → [CR] 関係維持 → [R$] 対価獲得
②実現可能性
　　[VP] 約束した価値 → [KA] 必要な業務 → [KR] 必要な資産 → [KP] 外部補完 → [C$] 発生コスト
③マーケットイン型（顧客・価値起点ストーリー）
　　顧客の課題(CS) → 解決策(VP) → 顧客アプローチ(CH/CR) → 収益(R$) → 実行体制(KR/KA/KP) → コスト(C$)
④プロダクトイン / シーズ型（強み・リソース起点ストーリー）
　　自社の強み(KR/KA/KP) → 新たな価値(VP) → 適合する市場(CS) → 販路(CH/CR) → 収益とコスト(R$/C$)
⑤マネタイズ逆算型（財務・収益モデル起点ストーリー）
　　収益モデル(R$) → 適合する価値と顧客(VP/CS) →コスト上限(C$) → スリムな運営体制(KA/KR/KP)

【3-1】1つ目は、基本は、顧客価値実現のストーリーだろう。
CustomerExperience（CX）に相当する。
まず顧客セグメントCSに、ペルソナを設定し、各ペルソナが持つ課題、悩み、要望を書き出す。
その顧客課題の解決策が、価値提案VPになる。

価値提案VPこそが、ビジネスモデルキャンパスの一番の肝だ。
なぜならば、価値提案VPは独自性を保つ必要があるからだ。
つまり、VPは競合差別化、競争優位性を持たせる必要がある。
KPIとしては、顧客満足度があるだろう。

次に、VPを実現するためには顧客にアクセスする必要がある。
それがチャネルCHであり、新規顧客、潜在顧客にアクセスするためのルート、経路を表す。
たとえば、HP、SNS、ダイレクトマーケティング、対面販売など色々あるだろう。
一般には、AIDMA、AISASなどのマーケティングフレームワークを使うだろう。
ビジネスモデルキャンパスでは、チャネルの5段階というフレームワークもある。
KPIとしては、リード数、成約率、CVRが相当するだろう。

次に、新規獲得した顧客を継続維持していく必要がある。
それが顧客との関係性CRであり、顧客維持の施策になる。
たとえば、顧客とのコミュニケーション施策、対人プロモーションなどがあるだろう。
KPIとしては、リピート率、契約更新率などがあるだろう。

次に、獲得した顧客が維持できるなら、そこから売上が計上できる。
それが収益の流れR$であり、売上の手段、売上の項目になる。
KPIとしては、ARPU(1人当たり売上高：Average Revenue Per User)、LTV（顧客継続価値）があるだろう。

すなわち、一連の流れに沿ってストーリーラインがあり、顧客セグメントに対し価値提案して最終的には売上計上につながるストーリーが作られるわけだ。

【3-2】2つ目は、新規ビジネスモデルの実現可能性を検証するストーリーだ。
フィージビリティスタディに相当するだろう

まず、価値提案VPに対し、具体的にどんな施策が必要になるのか？
その施策は会社の事業活動や業務、つまり、主要活動KAに相当する。
たとえば、事業、業務プロセス、オペレーションになる。
新規事業なら価値提供するための活動になるし、既存事業であれば、リソース創出や生産性強化になるだろう。
KPIとしては、生産性、納期遵守率があるだろう。

次に、主要活動の施策を実現するための経営資源が必要になる。
それが、主要資源KRに相当する。
たとえば、機械のような物的資産、特許のような知的財産、優秀なエンジニアのような人的資源があるだろう。

一方、主要活動の施策を実現する経営資源が自社だけでは確保できないケースも中小企業では多い。
そこで、外部の協力者である主要パートナーKPに頼ることになる。
たとえば、提携先、販売代理店、仕入先があるだろう。
つまり、自社の弱みを補完する役割を持つ。

最後に、主要活動KAを実現するために必要なコストC$が確定することになる。
たとえば、主要資源KRから売上原価の各項目が出てくるし、主要パートナーKPから仕入原価も出てくるだろう。
KPIとしては、
・売上高売上原価率、営業利益率、販管費率
・顧客獲得単価（CAC：Customer Acquisition Cost）
・1ユニットあたり生産コスト（Unit Cost）
・インフラ・システム維持費（Infrastructure Cost）
があるだろう。
一般に、固定費、変動費で分けてCVP分析もするだろう。
2年分の原価項目、売上があれば、損益分岐点は自然に出てくる。
よって、新規事業のアイデアを実現するために、自社が耐えられるコストはどこまでか、を検証できる。

残り3つも同様の考え方だ。

【4】ビジネスモデルキャンパスを描く時に使われるフレームワークには何があるのか？

ビジネスモデルキャンパスには、数多くの経営戦略やマーケティングフレームワークが多数含まれている。
だからこそ、ビジネスモデルキャンパスは有効なのだ。
具体的には、下記があるだろう。

基本は、コトラーのマーケティングフレームワークであるSTPPだ。
具体的には
Segmentation　→顧客セグメントCS
Target　→顧客セグメントCS
Positioning→価値提案VP
4P　→価値提案VP、チャネルCH、顧客との関係CR、収益の流れR$
に対応付けられる。
つまり、CustomerExperienceを考える場合、一般的なマーケティングフレームワークSTPPを使えばいい。

4Pの裏返しである4C分析では、
CustomerValue　→価値提案VP
Cost　→コスト構造C$
Convenience　→チャネルCH
Communicaton　→顧客との関係CR
に対応付けられる。

SWOT分析では、
S　→主要資源KA
W　→主要パートナーKP、主要活動KA
O　→顧客セグメントCS
T　→価値提案VP
に対応付けられる。

アンゾフの成長ベクトルの観点は、顧客セグメントCSと価値提案VP、主要活動KAの組み合わせで考えられるだろう。

「事業計画に落とせるビジネスモデルキャンバスの書き方」、
「最強の戦略ツール　ビジネスモデル・キャンバス」
を読むと下記のフレームワークもビジネスモデルキャンパスに対応付けられる。

市場細分化変数（地理・人口・心理・行動変数）　→顧客セグメントCS

機能的価値と情緒的価値　→価値提案VP

ブルーオーシャン戦略の戦略キャンパス　→価値提案VP

VRIO分析　→主要資源KR

バリューチェーン　→主要活動KA

オープンイノベーション　→主要パートナーKP

参入障壁、ポーターの競争戦略、競争優位性　→価値提案VP、ビジネスモデルキャンパスのストーリーライン

自己強化ループ、システム志向　→ビジネスモデルキャンパスのストーリーライン

リーンスタートアップ（Build→Measure→Learn）　→ビジネスモデルキャンパスの検証

【5】結論として、ビジネスモデルキャンパスは有用なのか？

僕の回答は、新規事業の構想検討フェーズではビジネスモデルキャンパスはとても有効だと考える。
理由は3つある。

1つ目は、新規事業のアイデアをストーリーラインで説明しやすくなることだ。
特に、CustomerExperience観点でストーリーを語りやすくなる。
つまり、顧客起点のマーケティングを説明しやすい。
夢を語りやすくなるはずだ。

2つ目は、新規事業の実現可能性や収益確保をストーリーラインで説明しやすくなることだ。
経営者目線では、夢は分かるが、本当に実現可能なのか、収益を確保できるのか、が気になる。
しかし、ビジネスモデルキャンパスのストーリーラインで語れるので、経営者目線では、非常に理解しやすくなり、説得しやすくなるはず。

3つ目は、既存の経営戦略・マーケティングフレームワークを埋め込むことで、ビジネスモデルキャンパスの妥当性や根拠を強化できることだ。
各項目の要素は単なる思いつきの文言ではなく、各種フレームワークに依存しているならば、整合性や妥当性が自然に取れて、因果関係で説明しやすくなるはずだ。

この当たりのアイデアを使って、実際に使ってみる。

掃き溜めの鶴を活かすマネジメント、それは強みSと環境Oを組み合わせたクロスSWOT分析と同じだ

「人の強みSと環境Oを組み合わせるのがマネジメントの本質なのだ」という言葉を聞いてインスピレーションが働いた。
考えたことをメモ書き。
尖った専門性を持つスパイク人材を活かす鍵は、強み（S）と環境（O）を組み合わせるクロスSWOT分析の視点だ。
マイクロマネジメントを排し、個の能力が生きる環境を提供できるかがマネジメントの成否を分ける。
組織や人事の戦略論にも通じるS×Oの思考法を考えてみる。

【1】あなたのチームに取っつきにくい性格だが尖った能力や高い専門性を持つメンバーがいたとする。
あなたならどう扱うだろうか？

普通のプロジェクトリーダーなら、正直扱いにくい人材だ。
たとえば、進捗報告もしてこないし、こちらの指示にも従わない。
与えた仕事は自分の性分に合わないなら全く手つかずで、本当に自分がやりたい分野の仕事ならすごい成果を出す。

普通のプロジェクトリーダーなら、自分がコントロールできないメンバーは非常にやりづらいだろう。
なぜならば、一般的なリーダーはマイクロマネジメントしたがるからだ。

たとえば、リーダーは、自分の思い通りに、自分が描いた戦略通りに、各メンバーを動かしたい。
メンバーを駒のように使いたい。
なぜならば、リーダー自身も成果目標を義務付けられて、人事評価の対象になっている。
リーダー自身の成果を出すには、リーダー自身で考えた戦略通りに、メンバーが力を出して成果を出したいからだ。

しかし、尖った能力を持つスパイク人材は、そういう戦略に当てはまらない。
彼らは自由気ままで、わがままで、自由奔放だ。
彼らは極端にマイクロマネジメントを嫌がる。

スパイク人材は、環境が当てはまらなければ、掃き溜めの鶴と同じだ。
いくら能力が優れていても、その能力を生かせる環境でなければ、彼らはふてくされて、くすぶる。
いくらスパイク人材で能力が優れていても、自分に合わない環境にずっといると、能力を発揮できず、彼自身の成長も止まる。
スパイク人材自身も不幸だ。

【2】そんなスパイク人材をリーダーはどのように扱えばいいのか？

そういうスパイク人材、尖った能力を持つ人材、くすぶってふてくされて実力を発揮できない人材に対し、野村再生工場みたいに彼らを生き返させるにはどうすればよいのか？

リーダーは彼に合った環境を用意することだ。
つまり、彼の専門性、尖った能力Sという強みに対し、環境Oをぶつけて、SxOの組み合わせを考える。
すなわち、マネジメントする者は、SxOの組み合わせそのものを考える人だ。

SxOの組み合わせを考えるということは、クロスSWOT分析で考えることと同義だ。
結局、戦略論の基本フレームワークであるSWOT分析をチーム内にいるメンバーに対して実施し、彼らに合った環境を探す。

【3】ではその環境はどうやって探すのか？

マネージャが持つ既存顧客に対し、尖った能力を持つ彼がどの顧客に合うのか、品定めすることもあるだろう。
あるいは、マネージャ自らが新規営業して、新しい環境に尖った能力を持つ彼をアサインすることもあるだろう。

一方、新しい環境を営業で探す場合、マネージャ自身が探す必要はない。
営業チームに、こういう能力を持つ人材を活かせる環境はないか、を伝えて、それを目的として新規開拓させればいい。
むしろ、エンジニア向きではなく、営業向きの人材もいるかも知れない。
そんな人は、営業させると本来の能力を発揮できるケースもある。

つまり、マネージャは、それぞれの人材をいかに有効活用するのか、という問題を、人材の専門性という強みSと、人材を活かす環境という機会Oに分けて、SxOの組み合わせというクロスSWOT分析の問題に置き換えるわけだ。

【4】ITコーディネータ研修でも、経営目標から外部環境分析、VRIO分析、SWOT分析を経てクロスSWOT分析を実施し、そこからあるべき姿へのIT戦略を導くワークショップがあったのを思い出す。

クロスSWOT分析に出てくるSxOの組み合わせは正直無限大だ。
組み合わせなのだから、Sが３パターン、Oが３パターンだけでも、SxOは９パターンもある。
そのSxOの膨大なパターンから有効なケースを導くわけだ。

しかし、全てのパターンを吟味するのは工数的に難しいので、ある程度組み合わせを省き、実現性の高いケースや把握しやすいケースだけを考えることになるだろう。

実際は、それだけの組み合わせケースだけでも正直十分だろう。
SxOの組み合わせから得られる具体的な戦略は、割と意外性があったりする。
そこから、尖った人材と本来想定しない環境を組み合わせることで、彼は掃き溜めの鶴から脱却し、生き生きと動き始める。

【5】そんなことを考えると、組織戦略や人事戦略は、結局戦略論と同じくクロスSWOT分析という最も基本的なフレームワークに支配されていることが分かる。
人事戦略の目的は、社内リソースである人材をいかに有効活用するか、であり、人材はどこかの部署に配属させるのだから、人材の専門性Sと部署という環境Oの組み合わせからもっとも成果の出せるケースはどれなのか？という問題に置き換えられる。

組織論も、どんなチームで部署を構成すれば成果を出せるのか、が目的なのだから、チームと部署の役割範囲の組み合わせ、つまり、チームを形成する人材の専門性Sと部署の責任範囲という環境Oの組み合わせからどのケースが最も成果が出せるのか？という問題に置き換えられる。

つまり、組織戦略も人事戦略もクロスSWOT分析という組み合わせ問題に置き換えられるならば、自由な発想に基づいてマネージャは組み合わせ問題を考えればいいのだ。

ふりかえり手法にジョハリの窓を使って自己開示と他者フィードバックを得る

「ジョハリの窓」をどう活かすか悩んでいた。
「自己開示」と「他者フィードバック」を組み込んだふりかえりこそが、自分も知らない「未知の自分」を引き出す。体験学習の実践から見えた、自分の思い込みを捨て自己省察を深めるふりかえりの本質を考えてみた。

【1】ジョハリの窓というフレームワークの使い方を以前はよく分からなかった。
カンセリングで使うと聞くが、プロジェクトマネジメントにいるのかな？とか思ってた。

【2】FAJ関西の体験学習のラボトリーに4月から参加していて疑問に思ったことがある。
このプログラムにはふりかえりが2回も含まれているのは何故なのか？

スタッフから、ジョハリの窓の説明を聞いてその意図が分かった。
このワークショップのふりかえりでは、体験前と体験後の2回で、自己開示と他者フィードバックを故意に入れ込んでいるのだ。

【3】ジョハリの窓はカウンセリングで使われる技術と認識してる。
自分が知っている＆他人も知っているエリアをベースに、自分は知っているが他人は知らない自分を他者に自己開示する。
ここは、ふりかえりでは、自分の意見を述べるプロセスに相当する。
次に、他人は知っているが自分は知らない自分を、他者からフィードバックで得る。
ここは、ふりかえりでは、他者が自分の言動をどのように見ていたのか、をフィードバックするプロセスに相当する。

すると、自分が知っている＆他人も知っているエリアが縦軸と横軸より外側に広がることになる。
すると、自分が知っている＆他人も知っているエリアが外側に広がった領域では、自分も知らないし他人も知らない自分と重なる領域が現れる。
これこそが第4の領域、自分も他人も知らない自分である未知の領域だ。
つまり、何らかの体験という行動を誘発させて、自己開示と他者フィードバックにより、自分も他人も知らない自分である未知の領域を初めて外部に提示される。
この領域は自分も初体験なので、自分も初めての自分を経験するし、他人もこの人はこんな行動を取るんだなというフィードバックを伝えることになる。

【4】ジョハリの窓は、社内研修でもやった経験があり、個人的には非常に面白かった。
自己開示と他者フィードバックを経験できるので、自分の言動はこういうふうに見られているんだな、という気づきが貴重だった。
一方、FAJ関西支部のワークショップでは、毎回、自己開示と他者フィードバックが必ずあるので、他人から自分の振る舞いや言動がどのように見られているのか、を故意に見せつけられるのはとても貴重だ。
自分は、自分が思っているほどロジカルでもないし、卑屈でニヒリストっぽく振る舞っているわけでもない。
そういう気づきが貴重だった。

【5】FAJ関西で行うふりかえりは、コルブの経験学習モデルに近い気がする。
コルブの経験学習モデルは、自己省察を重視して、自分の体験を分析して知識化し、次の経験で活かす。
その流れがFAJ関西のふりかえりと似ている。
経験した事実に対し、自己開示と他者フィードバックにより、自己省察のレベルを深めることができる。
そんな体験を大切にしたいと思う。

Redmineのブロッキング機能で工程単位Redmine運用とトレーサビリティを解決するアイデア

かつてアンチパターンとされたRedmineの工程別プロジェクト運用。
だが、A-SPICEなど厳格なトレーサビリティが求められる現場では、ブロッキング機能（FF関係）による制御が強力な武器となる。
製造業の複雑な階層構造に挑む、Redmineの新たな運用アプローチを探る。

Redmineプロジェクトを工程別に分けて運用したい意図を理解したのでメモ。
ラフなメモ書き。

【参考】
Redmineのブロッキング機能はどこで使うのか？～FF関係で使うべきだ！: プログラマの思索

【1】Redmineプロジェクトを工程別に分けて運用したいケースがある。

WF型開発で要件定義、設計、開発、テスト、移行の順に工程ごとにタスクが分かっていて、各タスクは上位の工程から派生して関連付けられて追跡できる前提とする。
たとえば、組み込みソフトウェア開発において、ISO規格、A-SPICEなどの規格に沿って開発し、その結果を商標と残すべき要求があるとする。

特に、A-SPICEのソフトウェア開発プロセスではV字型モデルで定義されていて、各工程のエビデンスをきちんと残すことを義務付けられている。

では、Redmineではどのように仕組みを実装すべきか？

一つのやり方として、工程別にRedmineプロジェクトを作り、各工程プロジェクトにタスクを作り、下位チケットは上位チケットに関連付けて作成する運用とする。
たとえば、要件定義チケットがあれば、そこから画面設計、機能設計、I/F設計、帳票設計、DB設計などの下位チケットが作られるだろう。
それら下位チケットは、上位の要件定義チケットに関連付けたタイミングで新規作成する。
すると、下位チケットを作成するタイミングで作業開始出来たことが分かる。

一番重要な点は、トレーサビリティが確保できることだ。
設計、開発、テスト、移行工程の各チケットは、必ず上位工程のチケットから関連付けられて作成するので、たとえば、リリース後に不具合が発生すれば、過去のチケットから上位工程に遡って影響調査することが簡単になる。
また、A-SPICEなどの規格では、ソフトウェア監査においてトレーサビリティをすごく重視するので、関連チケットを追跡できれば監査エビデンスを探し出す時に非常に有効になる。

つまり、工程別プロジェクトの運用では、「下位工程の作業チケットは上位工程の作業チケットに関連付けた時に新規作成する」制約条件が発生する。

【2】では、この工程別プロジェクトのRedmine運用において、他の重要な制約条件は何があるだろうか？

最も重要な制約条件は「上位工程の作業チケットが完了していなければ、関連付けられた下位工程の作業チケットは完了できない」だ。

たとえば、外部設計において、一つの要件から画面帳票設計、I/F設計のタスクが関連付けられて、どれかのチケットが作業完了できる状態になったとする。
しかし、1つの要件のチケットにおいて、顧客要求から要件定義がきちんと完了し、要件チケットをクローズできなければ、次工程の作業を完了に出来ない。
なぜならば、顧客要求からまだ要件定義が完了できていない状態は、まだ漏れている要求があるかもしれないし、非機能要件の品質特性を全て洗い出したとは言えないからだ。
漏れている要求があれば、下位チケットにはその要求は反映されていないのは当然だ。
ソフトウェア開発において、機能の実装漏れが出てくる場合は、たいていこんな単純ミスから発生する。

よって、下位チケットをクローズする時に、上位チケットのステータスを見て、クローズ条件を制御する必要がある。

この条件は、PMBOKで言う「FF関係」に相当する。
つまり、「上位チケットが終了できなければ、下位チケットも終了できない」条件に相当する。

利用シーンとしては、ガントチャートでタスクの依存関係に「完了の同期」を強制させたい場合がある。

【3】では、この機能はRedmineではどのように実装されているのか？

具体的には「ブロック元のチケットがクローズできなければ、ブロックされているチケットはクローズできない」機能になる。
この機能はまさに、Redmineのブロッキング機能に相当する。

Redmineのブロッキング機能はどこで使うのか？～FF関係で使うべきだ！: プログラマの思索

関連するチケット ? Redmine用語解説
チケット同士の関連づけ | Redmine.JP Blog

たとえば、FF関係にある2つのチケットは、「ブロックしているチケット#11のステータスが終了でなければ、ブロックされているチケット#12のステータスを終了に変更することができない」例がある。

よくある例は、リリース判定レビューのチケットがあるだろう。
リリース判定レビューをクローズさせるには、もちろん、要件定義～移行までの全てのタスクを終わらせる必要がある。
たとえば、バグ修正が追いつかず、バグが1間残っています、とか、全部テストできておらず10件のテストケースが残っています、みたいな状態でリリースできるわけがない。

一方、炎上案件では、まだテスト中、バグ修正中だが、並行作業でリリース判定レビューを実施して、後追いでリリース判定の承認を得たい場面が割とある。
PMOレビュー事務局を経験した人ならよく分かるだろう。

すると、リリース判定レビューでは、テストケース残件が０件、バグ未解決件数０件ならばリリースを認めるといった、条件付きOKの判断が下る場合が多い。
案件のPMもPLも担当者も、リリース判定レビューの後も、必死になってテストしてバグを潰して、その結果をPMOレビュー事務局へ送って、その結果がOKならば、テストや移行作業のチケットが全て完了にできる。
そして、テストや移行作業のチケットが全て完了になった状態で、初めて後続のリリース判定レビューチケットをクローズできて、ようやくリリース承認が降りるわけだ。

このような制御をRedmineチケットに課すことで、実際の運用ルールを知らなくても、監査プロセスをRedmine上に実装できる。
僕は、Redmineのブロッキング機能をFF関係として使うケースを知らなかったので、本当に面白いなと思う。

一方、Redmineのガントチャート画面では、【FS】関係は、先行・後続の関係＝青矢印、【FF】関係はブロック元・ブロック先の関係＝赤矢印で図示される。
つまり、Redmine標準機能として、FS関係とFF関係の矢印の色が異なるように実装されているので、ガントチャート画面を見れば、チケットの依存関係を把握できる。
LycheeRedmineでは、ガントチャート画面上でマウスをD&DすることでFS関係を付けれる機能があり、そのタイミングで、ブロッキング機能をチェックするかどうか選ぶダイアログが出てくる。
つまり、LycheeRedmineでは、FS関係やSS関係を簡単につないで、まるでMSProjectみたいにガントチャート画面上で制約条件を正確に表現できる。

Redmineのブロッキング機能はどこで使うのか？～FF関係で使うべきだ！: プログラマの思索

Redmineはとても奥深い。

【4】以前の僕は、Redmineを工程別プロジェクトを作るやり方は悪手だと思っていた。
その理由は１０年以上前にたくさん書いた。
つまり、理由は、アジャイル開発のイテレーション、スプリントに紐づけることが単純でないこと、工程単位のプロジェクトが乱立して１人の担当者が複数のRedmineプロジェクトを渡り歩いて見る必要があってチケット管理が面倒になるからだ。

TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索

チケット駆動開発の適用範囲part5～どの工程をカバーするのかという質問: プログラマの思索

チケット駆動開発のFAQ: プログラマの思索

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン～親子チケットの功罪: プログラマの思索

チケット駆動開発の適用範囲Part2～チケット駆動開発の運用パターン: プログラマの思索

チケット駆動開発がもたらした新しい観点part1～Redmineプロジェクトへ案件や組織構造を反映する: プログラマの思索

Redmineをもっと強化できるポイントpart1～上流工程のトレーサビリティ強化: プログラマの思索

しかし、上記のように、Redmineブロッキング機能を使って各工程チケットのトレーサビリティを確保したい場合、工程別プロジェクトを作りたい意図は理解できる。
また、Redmineブロッキング機能は所詮、Redmineの関連チケットの一種に過ぎないので、担当者にとってもチケット操作は簡単であり、運用ルールに乗せやすい。

こういう使い方もありだなと思う

【5】一方、留意点としては、複数プロジェクトをまたいでチケット同士のブロッキング機能を使うには、「管理」→「設定」画面内「チケットトラッキング」タブ内の設定「異なるプロジェクトのチケット間で関連の設定を許可」を有効にする必要がある。
この設定がなければ、プロジェクト内で閉じたチケット同士でしか、ブロッキング機能が使えない。
先行・後続関係の機能も同様だ。

Redmineで異なるプロジェクトのチケット同士を関連づけたい ? Redmine.JP

他方、「異なるプロジェクトのチケット間で関連の設定を許可」を有効にするデメリットは、情報セキュリティの高い案件のRedmineプロジェクトのチケットが関連付けられてしまうケースが考えられる。
本来は、ある案件の親PJがあり、要件定義～移行の子PJが作られて、親子PJの関係が付けられている範囲内でのみ、ブロッキング機能を有効にしてほしいのだ。
製造業のように、製品開発の案件は機密性が高いので、情報セキュリティ上、他案件のチケットが無関係の社員に見せることはしたくないからだ。

すると、「プロジェクトツリー内のチケットはで関連チケットの設定を許可する」「プロジェクトツリー内でカテゴリ、カスタムクエリ、ユーザを継承できるようにする」機能が欲しくなる。
そのアイデアは既に書いた。

製造業DXを支える工程管理とは？Redmineの大規模プロジェクト階層化における課題：プロジェクトツリーの設定継承と関連チケット制限の壁: プログラマの思索

@g_maedaさんにXで聞いたら、そんな機能はありません、の一言で終わったけれど、正直実装してほしい機能だ。
なぜならば、製造業では、親子PJを使って階層化したRedmineプロジェクトが自然に出てくるケースが多いので、プロジェクトツリー内の各プロジェクトの各チケットに対し、親PJの設定を子PJへ継承させたいケースが多くなるからだ。

たとえば、製造業では、上記のように工程単位プロジェクトが自然に出てくる。
工程単位プロジェクトが自然な理由は簡単で、製造業では工程ごとに専門部署が割り当てられているからだ。
実際、プロトタイプ製品を作る企画フェーズならR&D部、設計工程では設計部門、製造工程では工場の製造部門や生産管理部門、試験工程では品質管理や品質保証部門、サービス保守では営業部門や保守部隊などに分かれる。
製造業は、高度に専門化された知識が必要なので、機能別組織になりやすく、工程別にノウハウを集約し蓄積する機能別組織になりやすい。

また、たとえば、複数の製品を組み合わせて一つのシステムを作り、それをパッケージングして販売するSystemOfSytems（SoS）のようなサービスも製造業ではよくある。
たとえば、医療システム、防衛宇宙システムの業界ならよくあるだろう。
すると、SoSの親PJが案件に相当し、子PJには各製品や各システムが作られて、さらに孫PJは工程単位のプロジェクトが作られる。
つまり、親子孫という３階層のプロジェクトツリー構造を持つRedmineが自然に現れる。
よって、SoSの案件をRedmineで運用する場合、かなり複雑な構造をRedmine自体が持つ。
実際、プロマネが１個のRedmineプロジェクトでチケット管理できないマネジメントレベルならば、そもそも３階層のRedmineプロジェクトを持つ高度なチケット管理はできないだろう。
すなわち、SIerで僕が経験してきたアジャイル開発のRedmine運用よりも、製造業のRedmine運用のほうがはるかに難易度は高いと考える。

製造業のRedmine運用がかなり難しい理由は、実はこんな点にあるのかなと思う。
今後も製造業のRedmine運用を探っていく。