マネジメント

作成日時：2024-08-01以前
更新日時：2024-09-29

結局いかにして曖昧性を排除するかの話

背景の周知
根本的原因の特定
何故それをするか
シフトレフトによる早期のレビュー
プロトタイプの作成による合意形成

品質の作り込み

品質が上がればアジリティが上がり、生産性が上がる。

出来るだけ早期にユーザーを巻き込む

現場からの声
シフトレフト(UIなど)
手戻りの防止

指摘をする時

個ではなく体制を
自分の事は棚に上げる
SBIモデル

提案を出すマインド

不知の自覚
「何故」のマインド
探求心
自分の事を棚に上げる
どう思われてもいいや

トヨタ生産方式

リーン
誰が来てもうまく運ぶ体制づくり
無駄のない基盤

人を介すと情報はロスト/変質する

変質しないなら伝言ゲームは成り立たない。
認知負荷を下げろ
曖昧な伝達をするな
ドキュメントを書け
- ロストしないから
- リファクタリングもできる
会話中に別の話を始める
- だいたい元の話に戻ってこれないので、今の話を終わらせてから話す。
あやふやな表現
1つの文章で複数の受け取り方ができるような表現はNG。
答えの出ない質問
ゴールのない質問
そもそも聞く相手が間違っている質問
主題が無い質問
話の主題がコロコロ変わる
具体性に欠ける質問
文章を全部読まないと主題が分からない上に冗長な質問
文章に主語 / 目的語がない。

能動的開発

❷ 受動的作業から能動的開発へ
人は誰でも受動的な仕事よりは、
自分から積極的に関わろうとする能動的な仕事の時のほうがモラルが向上するのは当然。
システムインテグレーターの仕事は顧客の注文に応じて仕事を請け負うことになるため受動的作業が多くなる。
しかしながら、だからといってすべて受け身の作業ということではない。受注活動時は当然のこと、
受注後も、顧客に積極的に関わりながら、具体的な提案や議論を積み重ねて、プロジェクトをまとめてゆくのは能動的作業であり、
創造的仕事でもある。しかし担当者、特にユーザープログラム開発担当者の中には、
顧客あるいはSEから言われたとおりにものを作らされていると感じる担当者もいるのも確かである。
こうなると受動的作業になってしまい、モラルを維持することは困難になる。
ユーザープログラム開発担当の人たちも、積極的に仕様決定プロセスに参加し、
設計方式についても積極的に提案を行い、顧客とも直接議論する機会を増やすべきである。
ユーザープログラム開発で培ったノウハウは、必ずやそこで活かされるはずである。

名内泰藏 著, 曖昧性とのたたかい ～体験的プロジェクトマネジメント論～, 翔泳社, 2005

その他

学習性無気力
KPT
- Keep→Try
  - こういういいことがあった→この仕組みを全体に波及させる
- Problem→Try
  - こういう駄目なことがあった→改善する
ToBe(理想)-AsIs(現実)
「他人は変えられないが自分と体制は変えられる」とコヴィーもカーネギーも言っとる
- 他人を変えるより自分を変えた方が早い
- 他人に期待すんな

CHANGELOGを書け

どこに何が入っているかが明確でなければならない。
ブランチがぐちゃぐちゃで、リリース管理もまともじゃないところとか。

シフトレフトの思想

早い段階で”動くもの”を見せて認識をすり合わせる。
設計書を作成する前にプロトタイプを作成しレビュー。

狩野モデル

狩野モデル - Wikipedia

部下の不満を取り除く

離職のトリガーは軽い

不満が溜まりに溜まった状態だと、軽いきっかけで離職しかねない。
太陽がまぶしかっただけで辞めるかもしれない。

組織はトリガーを除去することができない。
不満という火薬を除去することはできる。

アジャイル

軽量プロセス。

スクラム⇒管理寄り
XP⇒開発寄り

ハイブリッドな感じで。

XP

価値

コミュニケーション
シンプリシティ
フィードバック
勇気
リスペクト

価値、プラクティス、原則

価値を得るためにプラクティス(活動)を行う。
原則はプラクティスを行う理由、理論、原則を指す。

主要プラクティス

全員同席
チーム全体
情報満載のワークスペース(作業場所)
いきいきとした仕事
ペアプログラミング
ストーリー
週次サイクル
四半期サイクル
ゆとり
10分ビルド
継続的インテグレーション
テストファーストプログラミング
インクリメンタルな設計

導出プラクティス

本物の顧客参加
インクリメンタルなデプロイ
チームの継続
チームの縮小
根本原因分析
コードの共有
コードとテスト
単一のコードベース
デイリーデプロイ
交渉によるスコープ契約
利用都度課金

スクラム

2020-Scrum-Guide-Japanese.pdf

価値基準

確約：お互いにサポートすることを確約
集中：スプリントに集中する
公開：作業や課題を公開する
尊敬：メンバーは互いに尊敬する
勇気：問題に取り組む勇気

3つの責任

プロダクトオーナー
開発チーム
スクラムマスター

5つのイベント

スプリント
スプリントプランニング
デイリースクラム
- スタンドアップミーティング
スプリントレビュー
レトロスペクティブ
- KPT

3つの成果物

プロダクトバックログ
スプリントバックログ
インクリメント

各種プラクティス

インセプションデッキ
- プロジェクト憲章的な物
ユーザーストーリ
プランニングポーカー
朝会
バーンダウンチャート
タスクかんばん
ペアプロ・モブプロ
TDD
リファクタリング
CI/CD

ビッグバンリリースはやめろ

QCD+S

Q:品質
C:コスト
D:納期
S:スコープ

QCDの中で、何かを得るために何かを犠牲にするくらいならば
スコープを変更してQCDは何も犠牲にしない方がいい。

組織の学習

⇒ピープルウェア　32章「組織の学習能力」