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

作成日時：2025-11-03
更新日時：2025-11-04

要件を詰めるのが自分の仕事だ

何も決まっていない要件定義を見ても怒るな。
疑問点を洗い出して質問しろ。

会話

声は大きくハキハキと。
汚い言葉は使わない。
伝わらなければ、意味が無い。

マイナス系の言葉を発するな。
声が小さいから誤解される。
なるべく喋んな。
黙して語ることなし。

顧客と正当化

顧客は正当化で洗脳する。
材料は超上流工程。
「本来の目的を達成するため」が材料となる。
「納期に間に合わないからスコープを減らしたい」ではなく「目標を実現するために、お客さんに現時点における最大限の価値のある製品を渡す」
前者だと請負契約を盾に攻撃してくる。

• 結局対人の仕事ならば心理学を学ぶか
• 人を動かすために正当化させる
• 自身が正しい行動をするために自分を正当化しない

サポート

サポートは担当者名ではなく「サポートチーム」を記載
個人の負担を減らすのと、担当者名の一貫性を保持しなくても済む

デイリースクラム

メンバーの話をちゃんと聞く
デイリースクラムに必要なのは、何かしらの不安や阻害要因の発見

プロマネ

• 越境
• 仕様を詰めるのが仕事
• 大きなタスクは認識の相違が発生する
  • 小さく管理する
• ユーザーインタビュー
  • スコープ管理
• 「スコープが想定以上に大きくなった場合は、対応を検討する」
  • 契約面
• デイリースクラム
  • やったこと、やること、阻害要因
• 無駄な機能は省く
  • 改修しづらくなる
  • 作成した機能はほとんど使われない
  • 本当に必要なものだけを
  • シンプルであれ
  • 圧倒的当事者意識
• ユーザーストーリー
  • 〇〇として△△が欲しい。なぜなら××のため。
• コンテキストの共有
  • 現場の声
• 期限をわざと短く伝える
  • パーキンソンの法則
  • 期限を過ぎたら負い目を感じさせることが可能

シフトレフト

さっさとプロトを作って、早い段階でユーザーに見せろ。

デスマーチ

デスマートは無茶なQCDSの要求から発生する。
ならば、どう防ぐか。

• アジャイル(XP、スクラム、リーン)
• 客との合意
• MVP(Minimum Viable Product)

不安

• 曖昧性まみれ
• 急なQCDSの変更
• レビューなし
• チケットを誰も見ない
• 合意形成なし

ドッグフード

作っているシステムを自ら使う。
チーム内からの要求分析。

OODA

• Observe（観察）
• Orient（状況判断）
• Decide（意思決定）
• Act（実行）

曖昧な状況下で使える。
PDCAは曖昧な状況下では計画が立てられない。

阻害要因をつぶす

提案型質問。

何をすれば”それ”は可能となるか。
何が必要か、何をしなければならないか。

レビューと報連相の重要性

システム開発は合意形成を繰り返す作業である。
曖昧なまま作業を進めてはならない。

誰とも合意を得ずに作業を進めた場合、それは手戻りや障害を引き起こしかねない。
自分だけが正しい作業だと思っていても、顧客/チーム/システムからすれば間違っている可能性がある。

故にレビューと密な報連相を行う。
自身の作業の妥当性を、他者を介して検証する。

全てに対して「本当に正しいか」疑い、少しでも怪しければ相談する。

スプリント中の障害

現在のスプリントを中止して即時対応。
重要度・緊急度が低ければ次のスプリントで修正。

チケット駆動開発

チケット駆動開発の本を読んだがあまり響かなかった。
当り前の内容だったため。

タスク管理の話だった。
スクラムにおける、バックログとタスクボード周りの話。
計測(障害要因分析とかリードタイムとか)に関してはレトロスペクティブあたり。

タスクをチケットに起票して管理するのは当たり前。
チケットの肝は如何に”わかる”文章を書くか。

ドキュメント・ライティングとスクラムの本を読んだほうがためになる。

合意形成とドキュメントライティング

システム開発は合意形成を繰り返す作業である。
正しく合意形成するには、コンテキストが漏れなく込められた文章を提供しなければならない。

ユーザーは不満を言わない

UI/UXがよほど悪いものでなければ、ユーザーは不満を言わない。
なぜなら報告するのが面倒だから。
それ即ち、UI/UXが悪いシステムをユーザーに使わせ続けることになる。

アンケートを取ったり、ヒアリングするなどして改善を行う。
応答時間などに関しては、常日頃からログを分析する。

スパイクイベントの把握

コンサルの概念

設計

何のために作る機能なのかを理解できなければ、適切な設計はできない。
視野が狭くなるから。

全体の流れを把握していなければ、これまたまともな設計はできない。
視座が低くなるから。

リードタイムが長い

• コンフリクトの発生
• 仕様変更
• 仕様を忘れる

スコープ

やること　と　やらないこと
話すこと　と　話さないこと
対象　と　対象外

コンテキストの共有

顧客との会話や仕様の決定など。
全部コンテキストの共有が重要では。

パラフレージング

相手の話を要約して相手に返す。
相手は受け入れられていると感じる。
ついでに確認、合意を得られる効果もある。

伝達に関して

声は大きく明瞭に。
汚い表現は使わず、正確に。
ドキュメントライティングと同じく、伝わらなければ意味が無い。

思想

システム開発とは合意形成を繰り返す作業である。

決して自分だけの判断で作業を進めてはならない。
それはシステム開発における最悪の愚行といえる。

スクラムとかアジャイル

知識の共有が大事。
目的意識とか。

• スクラム
• The New New Product Development Game
• 知識創造企業
• 野中郁次郎

SECIモデル - Wikipedia

プログラミングは価値提供の手段であって、目的ではない

UXや利益が目的。

DevOpsの重要性

インフラチームと開発チームに分けたら情報連携が遅い
もしくは対応してくれなかったり

何ができるか分からない人との仕事は曖昧性と恐怖を生む

スキル感が分からない状態で、適切な作業指示やアーキテクチャ選定ができるか？

• ドラッカー風エクササイズ