エンジニアリング
ボーイスカウトの原則
単一責任の原則
早計な最適化は諸悪の根源
YANGI
KISS
組織
ダンバー数
■分類
レポ ①有担保 ②無担保(債券貸借)
②モノを貸して、貸借料をとる。無担保のため与信が発生し、Dはやっていない。地銀などが利回りアップのために貸借をしている。
①GCレポ(モノを担保にする、資金貸借的な性格)とSCレポ(お金を担保にする、債券貸借的な性格)
■オーバーナイト
・①担保があるため、利子がそもそも安い
・用途：商品在庫の国債を買う場合、レポで資金調達を行う。
→在庫の国債が売れたら、利子を払うのは余計なコストになるので払いたくない。早く代金を返済したい。
→オーバーナイトの取引を行い、金額を日々調整することで、支払う利子を最小限にコントロールしている。オーバーナイトの取引をロールオーバー(ロール)して調整している。
・ブローカーが銀行などの資金の出し手を探してきてくれる
・そもそも銀行はなぜ資金を貸し出ししたいか：日銀に預けておくとマイナス金利となる。 cf.日銀当座預金・預金準備率・積み期間
→資金を市場で運用してマイナス金利の適用をできるだけ回避したい
→マイナス0.1%よりも利回りの高い短期国債を購入したり、国債を担保に現金を貸し出すレポ市場に資金を放出
レポディーラーは日銀の積み残に注意を払っている
http://www.central-tanshi.com/seminar/02-03.html
■ターム物
・月1兆だとして、5千億はタームでまとめて借りる。残りをオーバーナイトで借りるというような運用をしている。
・SCレポでレア銘柄を借りる場合、1日のみだと翌日に貸借できない可能性があるため、1週間などの期間で貸借し、その間にショートを解消するというようなことをしている。
・12月中旬、3月末などの四半期末や年度末などの決算期は、財務諸表を動かしたくないインセンティブが働き、オーバーナイトが減り、ターム物にするということが行われる。
■ディーラーの観点
①日銀の積み残、②期末かどうか、③日銀オペの実施状況 などを常にウォッチしている。
■評価点
今までのコミュニケーションに関する当たり前を見直して、組織目線であるべき姿を描き、その後、Teamsに関する施策を実行し効果を挙げた点を評価する。具体的には以下の通り。
・組織内における情報取引コストを削減
従前から存在した本社と常駐現場との間に存在するコミュニケーションの壁を取り除き、文字通り風穴を開けた。その結果、今まで見えていなかった、組織内における情報の取引コストを削減した。
・部全体で打席に立ち、組織コミュニケーションを活性化
個人の力ではなく、Eサービス部の各課有識者からナレッジを募り、各自の工夫を凝らした情報発信を行った。本社のメンバーに強く訴求する投稿もあり、いいねや感謝をいただいた。組織コミュニケーションの手触り感を実演でき、少なからず、組織コミュニケーションの活性化に寄与した。
・情報発信に対する心理的抵抗の軽減
当社初の組織横断チームで、Eサービス部が情報発信の先行事例を作ることで、組織構成員が抱く発信への心理的抵抗を軽減した。少なからずCoPというボトムアップの活動の布石になったと評価する。
■前提知識
[★日銀統計からみたGCレポ市場｜服部孝洋（東京大学）]
https://note.com/hattori0819/n/n0f126f2c4beb
[★レポの基本③：ターム物のレポ取引｜服部孝洋（東京大学）]
https://note.com/hattori0819/n/n3d6f1fe49aca
[★レポの基本⑫：レポと有担保コールの違い｜服部孝洋（東京大学）]
https://note.com/hattori0819/n/ne3ed1f969b5f
レポとは、国債を担保に借り入れることでしたが、これには大きく分けて、
①翌日物（オーバーナイト）と②1営業日を超えるターム物があります。
例えば、読者が国債を担保に私から1営業日資金調達をするのが翌日物です。一方、読者が国債を担保として私から1か月資金を借りる取引がターム物です
■質問
資金繰りを1日だけ行うという感覚があまり腹落ちしないです。
この度、小売り・流通業界の事業会社を親会社に持つグループのシステム企業(企画部門)に転職することを決意いたしました。
今まで、異動願いを受けてくださったり、システム開発に限らず、様々な経験(スクラム案件導入、Teams推進)を与えてくださった皆様には感謝しております。
■転職のきっかけ
・30代になり、同年代の人・友人を見ていると組織内キャリアだけではなく、中期的なキャリア(特に目先5-8年)を意識するようになりました。
・組合で自社のことを真剣に考えた結果、事業領域や商流レベルでできること・できないことを気付きました。
常駐現場で働くうちに、受注サイドではなく、発注サイドに移り、商流を変えて経験を積みたいと考えるようになりました。
■転職で挑戦したいこと
・システムの企画立案
そもそも、どのようなシステムを作るかの立案をしたい。
事業や組織レベルの目線で、全体最適で意思決定する立場を早期に経験したい。
リソースの配分・実現可能性など、手を動かす前の段階で考えることを経験したい。
・PM業務/PMO業務/PgM(プログラムマネジメント)業務
現在もPM業務は経験できます。立場が発注サイドになります。
B2Bもありますが、ECなどコンシューマー向けの大規模システム(AWSなど)に挑戦したい。
■覚悟
・金融からの業界チェンジです。学習コストは高いことは認識しています。
・「企画」は聞こえはいいですが、オレオレ企画を通すことでもなく、伝書鳩になることでもなく、
実際は多くのステークホルダーと合意形成を重ねることの積み重ねだと考えています。
いままで、自分自身、合意形成で失敗してきた経験があるからこそ、積極的に挑戦したいと考えています。
・今までシステム開発を通じ、開発をできない人が企画をできるはずがないという意識は強いです。
一方で、手段が先行してしまい、自身の担当範囲をこえて本質的にどうあるべきかという視点が欠けているなと、顧客と協働するうちに気づかされることがあります。
これは立場・守備範囲の違い上、見える情報が異なり当然のことですが、だからこそ、商流を変えないと経験できないことであると考えています。
■引継ぎ
■案件紹介 アジャイル開発案件
・契約：準委任、アジャイル開発契約枠 or 保守枠
→基本は常駐開発の基本契約に則るため、実質は手続き的な違いくらいか。
・業務
- Book Offのような在庫ビジネス
- セールス～ディーラー間のワークフローシステム
- Web APIで約定情報を基幹に連携する
- 【顧客(W/R)×商品(一般債/JGB/外債 etc,)×取引手法】 の軸でシステムを拡大
- MVPを特定したあとのPhase (0→1→7→【スクラム】→12くらいの感覚)
・スクラム体制
- SM：1名 元ディーラー
- Dev：2-3名(40.50代)
- PO：各課×2-3名(リーダー・サブ) セールス・ディーラー
- プロダクトバックログはPOの合議で決定(四半期に1回くらい 優先度1-10位くらい色付け)
(Product Backlog Item No/PBI Noで管理)
- スプリント：(要員≒コスト,期間3-4w,スコープ)=(定数,定数,短期的には定数/長期的には変数)
・開発の特徴
- SPOを活用、遠隔地での開発、情報の非対称性の削減
- VisualStudio C# WinForms 2層C/SのEUC(デスクトップアプリ1個・バッチ群7個)
- SoRとSoEの境界は曖昧だが、SoEライクなシステム
- 顧客との協調
MTGにてメンバー全員参加 一次情報に触れる
ニアメンバーのリーダーに窓口を任せる
ニアメンバーから提案をSMにする
顧客との金融勉強会
- Devチーム
さん付け、「ニアの方」など立場の差を伝えない
環境の差異を伝える ＋ データはマスクして渡す(専用のExcelフォーマット)
中間ドキュメント(顧客に価値を生まないOutput≠Outcome)は極力作成しない ※マスタドキュメントは作成する
ペアプロ・共通言語はソースコード・ソースの内部設計レベルでレビュー
(VisualStudioの使い方、命名・責務、オブジェクト指向、DDD etc.)
リファクタリング：ボーイスカウトの原則、認知負荷の削減
保守で使う便利ツールを新規で作成してもらう→新規で内部設計を覚えてもらう
●伝えたいポイント 制御する変数は何か？定数は何か？
・【全般】アジャイルは現場のステークホルダーとの関係性次第なところがある
[アジャイル開発はなぜ失敗するのか？ ｜ 月額制受託開発の株式会社mofmof]
https://www.mof-mof.co.jp/blog/column/why-agile-fail
・【スコープ】作りすぎない、オーバーエンジニアリング 100徳ナイフ
リファクタで変更容易性を確保する
・【コミュニケーション】
役割の差を設けると→情報の非対称性を生む→それぞれの立場で合理的に行動する(限定合理性)→取引コスト発生(防御のための見積バッファ等)
※役割を設けないとは言っていない
※タックマンモデル 走り出しの頃・混乱期は相当マイクロマネジメントしたが、
お互い見えているものやコンテキストに違いがあると認識することが出発点であると認識するようにした。
・【チーム】未熟練者を10人集めてもいいシステムはできない
→要員(≒コスト)がFixed・定数なので、要員のスキル・成長角度を向上させることにリソースを投資する・チーム形成活動が重要
(常駐メンバーが設計して、ニアが開発する といった役割の分断を、安定期に入るまでは極力うまないようにする)
結局、スキルの高い、コミュニケーションしやすいメンバーがいればなんとかなる という身もふたもない話に聞こえるが
これはリーン開発におけるリソース効率とフロー効率の話とも関連する
●思考実験 心理的安全性・対人リスク
(スキル,コミュニケーション)
(低,高) → 成長の余地
(高,低) → マサカリ・ ブリリアントジャーク・技術チンピラ
■構成
・設計思想
アジャイルに懐疑的な人が、二項対立の視点から新しい視点を得るために、学習棄却、思考の枠を外す
チェリーピックする
・導入：全体像など
点同士を線・面にする
・メンタルモデル
・システム開発に限らず価値実現を構造化
共通的なメンタルモデルを形成するために
・海外における概念の整理
・歴史的アプローチ・歴史認識の形成
・現象・現実問題からのアプローチ 【価値とは、不確実性とは】
・PMBOKという知識体系ガイドからのアプローチ
コンプライアンスの考え方：ルールベース プリンシプルベース
・社会の問題
・システム開発プロジェクトにおける問題
・アジャイルの階層性
・実践できる チェリーピック
このif文は価値を生むのか？
このドキュメントは価値を生むのか？
■価値
ビジネスモデルキャンバス
リーンキャンバス
バリュープロポジションキャンバス
顧客が本当に必要だったもの
リーン アジャイル 違い
リンスタ
design thinking agile lean
トヨタ生産方式
生産方式
製品開発
7つのムダ・リーン
在庫
ドキュメント・証跡・品質管理の結果
ソースは綺麗(拡張性はあるが)だが、ビジネス目的を半分しか満たさない
ソースは汚いが、ビジネス目的を満たす最小限のプロダクト
→時間軸の観点
[★完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita]
https://qiita.com/Haruyuki_Hirose/items/2ce5a2877bc5c66aa2b3
[★デザイン思考とリーン・スタートアップ、 2つのアプローチの違いと使い分け方 - D4V (Design for Ventures)]
https://d4v.com/jp/blog/zig-then-zag-when-to-use-design-thinking-vs-the-lean-startup-approach
ウミガメはシーズンごとに100個以上の卵を産みますが、孵化に成功し海へ旅立つまでに生き延びられるのはほんの一握りです。生き延びられる確率を高めるために、ウミガメの母親は自分の置かれた環境を把握し、なるべく多くの赤ちゃんを海へと送り出す。なるべく多くのプロダクトを世に送り出そうとするビジネスも同じ。つまり、新規事業を立ち上げることは、ウミガメの母親になることと少し似ているのかもしれません。
ウミガメの赤ちゃん、つまりあなたのビジネスアイデアを確実に成長させるためのアプローチが2つあります。それが「デザイン思考」と「リーン・スタートアップ」です。前者は「生き残る可能性が高い卵はどれかを見極めるためのアプローチ」で、後者は「ウミガメの赤ちゃんが無事に海へと旅立った後、大人になるまで生き延びる可能性を高めるためのアプローチ」です。
[★リーン | アジャイル | デザイン思考 その違いと使い分け方 デザイン会社 ビートラックス: ブログ]
https://blog.btrax.com/jp/validation-process/
[★組み合わせで理解しよう「デザイン思考、リーン、アジャイル」by Jonny Schneider - ワイクル株式会社：ブログ - Medium]
https://medium.com/waicrew/組み合わせで理解しよう-デザイン思考-リーン-アジャイル-76b59988447f
[★5分で分かるアジャイルムーブメントの歴史 拡大版 / Brief History of Agile Movement - Speaker Deck]
https://speakerdeck.com/fkino/brief-history-of-agile-movement
[★アジャイル開発の源流とソフトウェア開発手法の発展の系譜｜Satoshi | Founder & CEO of Artelligence]
https://note.com/artelligence/n/nbd7ab2490bae
[★Combine design thinking, lean startup, and agile? Beware of waterfall in disguise | by Marty de Jonge | Bootcamp]
https://bootcamp.uxdesign.cc/combine-design-thinking-lean-startup-and-agile-beware-of-waterfall-in-disguise-67f713530bb
[★リーン・スタートアップの理論と実践 - Speaker Deck]
https://speakerdeck.com/miz_kushida/rinsutatoatupufalseli-lun-toshi-jian
[★書籍でたどる「リーン」の本質：「リーン」と「アジャイル」の関係とは？（3/4 ページ） - ＠IT]
https://atmarkit.itmedia.co.jp/ait/articles/1311/15/news015_3.html
[★リーンスタートアップとアジャイル開発の進化/evolution-of-leanstartup-and-agile - Speaker Deck]
https://speakerdeck.com/osawatanabe/evolution-of-leanstartup-and-agile
[★リーンスタートアップ解説 - Speaker Deck]
https://speakerdeck.com/skyisfalling/rinsutatoatupujie-shuo
■不確かさ
＜PMBOK＞
事象リスク 非事象リスク
「不確かさ」「曖昧さ」「複雑さ」「変動性」「リスク」
[★リスクと不確実性の違い：Risk and uncertainty | あきと アウトプット]
https://www.a-output.com/risk-and-uncertainty
[★Uncertainty Performance Domain ~ PMP TIPS | PMBOK 7 STUDY]
https://www.pm-exam.com/2021/08/uncertainty-performance-domain.html
Risks: We already knew what are risks.
Risks are uncertain events or conditions that, if it occurs, have a positive or negative effect on one or more project objectives.
[★「○○年に一度」のリスク－確率分布が、正規分布ではなかったら、どうなるか? |ニッセイ基礎研究所]
https://www.nli-research.co.jp/report/detail/id=52839?site=nli
リスク管理では、どのような事象がよく起こるかということよりも、異常な事象がどのくらい発生するかということの方が問題となる。
事象リスク
非事象リスク
なんの不確実性
TOBE
ASIS
不確実性
時間軸以外＝他者があって初めて問題になりうる コミュニケーション
曖昧さ
相対的
時間軸＝未来 リスク・チャンス
アウトプット
アウトカム
戦略の正しさ
前提の正しさ ※制約と前提の違い
完成度の尺度
[★(64) PMBOK 第7版 キーワード ー その２ー - 豆検 MAMEKEN]
https://mameken.com/?p=4380
複雑性 複雑性 複雑性
[★ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog]
https://engineers.ntt.com/entry/2022/05/23/083118
[★複雑さに立ち向かうためのコードリーディング入門 - Speaker Deck]
https://speakerdeck.com/shiz/fu-za-sanili-tixiang-kautamenokodorideinguru-men
[★ふくおか Scrum vol.2 不確実性に立ち向かう！ - Speaker Deck]
https://speakerdeck.com/yyamada/hukuoka-scrum-vol-dot-2-bu-que-shi-xing-nili-tixiang-kau
PMBOK risk vs uncertainty
uncertainty
PMBOK 7th edition risk type
既知 未知 リスク
Risk vs Uncertainty
Monitor vs Control
事象リスク
0/1
非事象リスク
変動リスク
曖昧さリスク
pmbok uncertaity management
[★監視・コントロールプロセス群の「監視」と「コントロール」の違いについて | ITStudy]
https://it-study.info/monitoring-control/
[★プロジェクト管理におけるリスクマネジメント]
https://timekrei.tenda.co.jp/column/risk_management/
[★プロジェクト管理におけるリスクと不確実性 |]
https://pmstudycircle.com/risk-vs-uncertainty/
[★なぜリスクは不確実性と等しくないのか、そしてそれが投資家にとって何を意味するのか。 | インタールコン]
https://www.intalcon.com/magazine/risk-vs-uncertainty
[★How to Successfully Manage Reducible and Irreducible Risk – Roland Wanner]
https://rolandwanner.com/uncertainty-manage-reducible-and-irreducible-risk/
[★What is the Difference Between Uncertainty and Risk? – Roland Wanner]
https://rolandwanner.com/the-difference-between-uncertainty-and-risk/
■メンタルモデル
・仏教・禅・宗派
・新しい視点の獲得
・とはいえ、学んでも雲を掴むような話→アジャイルの本質論・抽象論だけでなく目の前の現象・泥臭さについても説明できる
・何かを創るという行為
役員報告資料：
・役員レビューで覆る資料
・普段無意識的に実行していることを言語化できる感覚
一方でアジャイル的な意思決定や行動、価値に貢献しない行動
・決められたことをやるのは楽→学習棄却、SECIモデル
・言葉の多義性・重層性・広義狭義
こっちではこう言ってた ようなコンテキストを無視した額面通りの理解・反論の道具
・価値の重心を変える 今までの価値を否定し分断を生むロジックとして使わない
アジャイルはポエムなのか？なぜ腹落ちしないのか？
抽象論はわかるが、理想論すぎて現象に適用できるのか？
顧客の詭弁なのか？ 顧客との協調など虚構ではないのか？
既存の人のアイデンティティ・イデオロギーを攻撃するロジックとして使う人が少なからず存在する
すぐ組織など自身でどうにもできない問題の所在の議論になり視座が揃わない
Apple to Apple でないものを比較して何かを貶める
世界的に権威あるPMBOKがダイエットした事実、これはただのポエムなのか
国家レベルでアジャイルを標榜するのはコンサルの入れ知恵、DX素人シャブ漬け戦略
今までのやり方を変えたくない、経路依存
生存バイアス
B29を竹やりで落とす
[★アジャイル開発はなぜ失敗するのか？ ｜ 月額制受託開発の株式会社mofmof]
https://www.mof-mof.co.jp/blog/column/why-agile-fail
VUCAというクリシェ(乱用の結果、意図された力・目新しさが失われた句（常套句、決まり文句）)
アルファベット・スープ(alphabet soup)、頭字語や略語が多いことを表す英語の比喩表現である。これは、アルファベットの形をしたパスタ（アルファベット・パスタ）を煮込んだ同名の料理に擬えたものである。
[★「新しいアイデア」はなぜ拒絶されるのか？（村瀬俊朗）｜英治出版オンライン]
https://eijionline.com/n/n259332026dff
食わず嫌い 自尊感情
外部のアイデアを拒絶する「NIH症候群」
[★なるほど、だからアジャイル開発は失敗するのか - REBUILDERS(リビルダーズ)]
https://rebuilders.jp/agile-story/
結論、アジャイル開発の「手法だけ」取り入れるのは、人間に鳥の心臓を移植手術するようなもので、うまくいかないのです。
[★日本にアジャイルが普及しづらい本当の理由 ～不確実性に向き合うマネジメント論～：新刊ピックアップ｜技術評論社]
https://gihyo.jp/book/pickup/2018/0014
問題を認識しないうちに知ってもありがたみがわからない
(例：コーディングしない人がリーダブルコードを読んでもありがたみがない、プレイヤーがマネジメントの重要性を認識しないのとのと同じ)
銀の弾丸・飛び道具・魔法の鏡はない
不確実性→価値
時間軸によって戦略、価値の重心は異なる：MVP特定までと戦い方、線形ではない
0/1/10
安易な二項対立(計画しない、ドキュメントは作成しない)の思考から脱却すること
コンテキスト・歴史認識
原則と例外：性弱説 何を主として従とするか
固有の事情という思考の枠に縛られず、部分的に取り入れる
計画主義者の人から見ると妥協的なマネジメントのように見えるかもしれない
マクドナルド理論
・要件定義書を見て懸念・要望あれば教えてください。
・動くものを渡すとメンタルモデルに枠ができる
・
[★不確実性を飼い慣らす 〜アンチフラジャイル型のプロダクトマネジメント〜 | ドクセル]
https://www.docswell.com/s/papanda/598W4Y-taming-uncertainty#p42
■システム開発における新たな視点を得る問
・安易にif文を作る=複雑度を上げるだけ、事業価値にコミットするか
・その中間ドキュメントは顧客と合意するためのものか
・その作業はチームに貢献するか
・合意は正しいが。違和感があれば、(言われたから・合意したからやる)という思考停止
■歴史認識
アジャイル開発だけではなくコンテキストを理解する
違いと共通点
逆を考える 価値にならないもの
誰にとっての
リーン：生産
↓
コンテキストが異なる、メンタルモデルが違う から共通認識を形成できない
見えているものが違う
https://www.ipa.go.jp/archive/files/000063652.pdf
藤本隆宏 site:ocw.u-tokyo.ac.jp filetype:pdf
[★Vol.5｜流行りの経営理論の源流にある日本の経営技術③：リーン・スタートアップとトヨタ生産方式｜経営コンセプトの力｜「理論」と「実践」の接続｜Link and Motivation Inc.]
https://lm-tmw.com/theory-and-practice/management-concept-leanstartup-toyotasys/
勝負が決まってから当たり馬券を買う
■比喩
顧客が欲しかったもの
100徳ナイフ
炭鉱のカナリア ソースからの不吉な臭い
技術のジェンガ現象 Team Topologies
黒ひげ危機一髪
just keep coding
カウボーイコーディング
犠牲的アーキテクチャ 式年遷宮
■PMBOK
情報システム学会 PMBOK
第6版
https://www.issj.net/mm/mm13/05/mm1305-pg-pg.pdf
第7版
https://www.issj.net/mm/mm17/03/mm1703-pg-pg.pdf
[★アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab]
https://little-hands.hatenablog.com/entry/2022/06/27/essence-of-agile
[★Agile Software Guide]
https://martinfowler.com/agile.html
[★新たな情報を得て不確実性がますます高まったら、どう対処すべきか 3つのタイプのどれに当てはまるかを見極めよう | 戦略｜DIAMOND ハーバード・ビジネス・レビュー]
https://dhbr.diamond.jp/articles/-/6911
[★ 生産的な組織・仕事の鍵となる「不確実性の正体」とは何か 『エンジニアリング組織論への招待』の著者が語る、モヤモヤの発生源
- ログミーTech]
https://logmi.jp/tech/articles/328504
[★ サービス開発における5つの“不確実性”パターン 曖昧さをコントロールするために、ユーザーストーリーを活用する
- ログミーTech]
https://logmi.jp/tech/articles/327320
[★PMBOK（R）Guide第7版変更|最新情報 | 日本プロジェクトソリューションズ株式会社]
https://www.japan-project-solutions.com/pmbok-7th
デザインスプリント(design sprint)
出力：価値・Outcome → 時間軸：正味現在価値、バッチサイズ、要員のアサイン
リソース：人間・チーム・組織 → 認知限界・限定合理性
制約：時間・予算→時間軸：計画
不確実性
＝確実ではない 確実とは？ →時間軸：リスク
価値にならないものは？＝7つの無駄、ブル嫉妬
本質論ばかりで現象に立ち向かう
戦略＝リソースの配分
価値をどう届けるか？
軽量開発プロセス
DDD
TDD
[★2kgから800gに激減、教科書「PMBOK」新版に何が起こったのか | 日経クロステック（xTECH）]
https://xtech.nikkei.com/atcl/nxt/column/18/00001/06192/
https://www.issj.net/mm/mm17/03/mm1703-pg-pg.pdf
PMBOK 第６版は、A4 判で近頃は目にすることも少なくなった電話帳のように巨大なもので、別冊の『アジャイル実践ガイド』も含めると９００ページ以上ありまし
た。一方、PMBOK 第７版は、一回り小さな B5 判で、ページ数も２７０ページと４分の１となりました。
[★【社内勉強会】PMBOK®ガイド第7版超速まるわかりガイド｜TSD公式エンジニアブログ「TSD CoLab」]
https://tsd.mitsue.co.jp/blog/2022-04-28-slide-about-pmbok/
[★【PMBOK第７版】デリバリー・パフォーマンス領域について解説 | Promapedia（プロマペディア）]
https://ssaits.jp/promapedia/concepts/delivery-performance-domain.html
[★(64) PMBOK 第7版 キーワード ー その２ー - 豆検 MAMEKEN]
https://mameken.com/?p=4380
■社会の問題点
人間の限界 認知・限定合理性 メンタルモデル
分断構造・非対称性・対立構造・力学
情報の不完全性
受発注の関係
[★「受発注の関係性」とは - today::エンジニアに憧れる非エンジニア]
https://rapidliner0.hatenablog.com/entry/2021/04/18/060000
国家・国民
投資家・経営
内部監査・事業体
顧客 開発 店員・客
役員・上司・部下
嫁・旦那
上位下達の意思決定
利害関係・イデオロギー
構造が生み出す問題
課題管理表を書いても認識に相違がある
作品のような証跡を作成する
ルールベース プリンシパルベース
■システム開発の問題点
＜開発サイド＞
手戻り
スケジュール遅延・不安：バッチサイズの問題
チーム内コンフリクト
合意が覆る
課題管理表を綿密に書いても期待する回答をもらえない
品質を代替指標・代用特性
リリースでエラー
開発スキルが身につかない
資源配分の失敗
＜顧客サイド＞
リリース後、目的を達成できない
→価値という視点がない
契約を持ち出され、方向転換できない
パラメータが複数ある
■認知フレーム
方向性がわかるPJ、わからないPJ
0/1思考
手順主義・チェックリスト主義：こうやればできる→手順を終わらせることが目的になる力学
成功体験・バイアス
比較可能性：固有のもの、Apple2Appleではないものを比較
視座・視野・視点
メンタルモデル
自分のことは自分がわかっている
学び・解空間 → 経験主義
[★DDDに関する論の主戦軸を整理してみた（2020年版） - Qiita]
https://qiita.com/tanaka9230/items/dd3ff0663a0295a47674
■結局
リソースは人間・情報
組織効力感
チーム認知モデル
https://www.panda.sys.t.u-tokyo.ac.jp/SysInnov2009/A-2_Kanno.pdf
チームの限界
コミュニケーション効率の低下
■価値
正味現在価値
■異なる不確実性
MVPを特定する前：
MVPを特定し市場に投入するまえ：設計
エンハンス：最適化
↓
手順主義的思考：このときはこうやればいい
正しさとは
探索・適応のcpability
[★アジャイル迷子のための「アジャイルの本質」。あとDDDとのつながり - little hands' lab]
https://little-hands.hatenablog.com/entry/2022/06/27/essence-of-agile
[★不確実性に打ち勝つOKR戦略/How to manage uncertainty with OKR strategy - Speaker Deck]
https://speakerdeck.com/navitimejapan/how-to-manage-uncertainty-with-okr-strategy?slide=25
[★不確実性に向き合うためにチームの アジリティを高める開発タスクの切り方 - Speaker Deck]
https://speakerdeck.com/tanden/bu-que-shi-xing-nixiang-kihe-utamenitimuno-aziriteiwogao-merukai-fa-tasukunoqie-rifang?slide=70
[★アジャイル開発の品質管理技法（前編） : 富士通]
https://www.fujitsu.com/jp/services/agile/featurestories/about-agile-02.html
[★アジャイル開発の品質管理技法（中編） : 富士通]
https://www.fujitsu.com/jp/services/agile/featurestories/about-agile-02-02.html
[★完璧な要件定義など幻想である。個ではなく、チームで作る要件定義 - Qiita]
https://qiita.com/Haruyuki_Hirose/items/2ce5a2877bc5c66aa2b3
■PM手法
[★いちばんやさしいアジャイル開発の教本を読んだ - Qiita]
https://qiita.com/yukiji/items/96017494ac0eb91a6609
見積
チーム形成：属人的依存 タスクの依存
[★アジャイル開発手法について、エキサイト株式会社で話してきました - GMOインターネットグループ グループ研究開発本部]
https://recruit.gmo.jp/engineer/jisedai/blog/excite_gmo_agile/
https://www.docswell.com/slide/598869/EKJNDL58/download
https://www.docswell.com/slide/Z4Q3NJ/NR74JL6R/download
[★正しいものを正しくつくる / Do the Right things Right - Speaker Deck]
https://speakerdeck.com/papanda/do-the-right-things-right?slide=50
■Agile Japan
site:2019.agilejapan.jp filetype:pdf
site:2020.agilejapan.jp filetype:pdf
site:2022.agilejapan.jp filetype:pdf
site:2022.agilejapan.jp filetype:pdf
■NOTE
[★番外編 PMBOK®7thの先へ プロジェクト・デザインでプロジェクトの発意・形成と実行をつなぐ｜中分毅]
https://note.com/nakawaketakeshi/n/nca88e79be338
■関連領域
デザインすプリンと BA
BABOK® ガイド v3:ビジネスアナリシスのグローバル標準
https://pdf4pro.com/amp/cdn/babok-v3-iiba-japan-org-3105c4.pdf
[★「エンタープライズ・アジャイル開発におけるビジネスアナリシス」－BABOKガイドアジャイル拡張版のご紹介ー（清水千博） - Speaker Deck]
https://speakerdeck.com/washizaki/entapuraizuaziyairukai-fa-niokerubizinesuanarisisu-nil-babokgaidoaziyairukuo-zhang-ban-falsegoshao-jie-qing-shui-qian-bo
