事業計画(project plan/project programming)
<この項は書きかけです。順次追記します。>
進捗管理(progress management)
計画を基準線(base line)を引いて、何日までに、何をしているかを記載する。
該当日に進捗状況を確認し、必要があれば何か対応を決定する。
三倍速が基本であり、教育・訓練の段階から、業界他社の３倍の速度で行うことを習慣づけている。
他社が２時間会議をするのであれば、４０分で会議を終わるようにする。
５日間の教育コースは１日半で終わり、残りの半日を教材の改定にあてる。
情報処理試験の問題は過去問を１回目は１倍速、２回目は２倍速、３回目は３倍速で行う。
当日は、試験会場で一番最初に会場を後にしよう。
「ああ諦めたんだな」という冷たい視線を後ろに、
「時間かけてやっていては競争に勝てないよ」と心の中で繰り返してみよう。
確率計画(plan with probability)
80%基準
ある仕事を、ある日までできている確率が80%だと見積もった場合に、予定日とする。
安全側に倒した基準である。100%基準を使わない理由は、100%として見積もったのに、できていなければ、挽回するための資源が残っていない状態であり、計画の意味がない。
80%基準で、予定通りできているばあいには、全体の60%くらいの確率で、先にできていることがいろいろある。
何が先にできているか、もっと優先すべきことはないかを確認するとよい。
50%基準
ある仕事を、ある日までできている確率が50%だと見積もった場合に、予定日とする。
80%基準との違いは、2回に1回は挽回しないといけない状態で、手を打つ感じ。
確率計画の経験が浅い方にお勧め。確率計画の経験が浅い状態で80%基準で動こうとすると、
計画が甘いのか、自分たちの実績が甘いのかの判断に資源を割く余裕がない可能性がある。
結果として判断を誤る可能性がある。
50%基準であれば、計画が甘いのか、自分たちの実績が甘いのか、見直すゆとりがある。
30%基準
ある仕事を、ある日までできている確率が30%だと見積もった場合に、予定日とする。
業界平均の三倍速を原則としている事業では、30%基準で見直すとよい。
３回に２回は、挽回しないといけない状態で、早く手が打てる。
三倍速でやっていると、無駄なことも三倍やる可能性がある。
3分の１の段階で見直すとよい。
経験が浅い段階ではお勧めできない。見積もりが駄目だったのか、能力の把握が不十分だったのか、仕事の分担がよくなかったか、どれが原因か見極められないことがある。おかしな変更をしてしまうかもしれない。
百点満点の三十点を目指しなさい。
参考資料(reference)
機敏(agile)
公開算譜は機敏だ＜完全版＞(open source is agile ＆名古屋のIoTは名古屋のOSで
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e
顧客指向のプログラミング(customer oriented programming)
https://qiita.com/kaizen_nagoya/items/6f3bc42253486b4b4818
分析(analyze)
効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446
安全分析（HAZOP）の際の声かけ
https://qiita.com/kaizen_nagoya/items/381649a6ea025ecba173
確率・統計(probability and statistics)
計画者(programmer)のための横顔(profile)入門 (1)「お金のセンスを測ってみる」on「確率論及統計論」輪講演習
https://qiita.com/kaizen_nagoya/items/c77cafd3fe47a558bfe5
確率論及統計論
https://qiita.com/kaizen_nagoya/items/89d0a91a56d33529e85c
科学四分類と算譜(program)
https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603
言語論と確率論
https://qiita.com/kaizen_nagoya/items/cc3730e4494e7d37ea4d
課題(issue)
open な issue がどんどん溜まる現象を解決するために
https://qiita.com/kaizen_nagoya/items/efe22d9a23ad2e9934d6
プログラマが英語で報告・質問する時のいくつかの事例・方法
https://qiita.com/kaizen_nagoya/items/9cf2ba858e52e9795b67
見直し(review)
Reviewerの数
https://qiita.com/kaizen_nagoya/items/36aefeea21fb190bf873
プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69
作業改善(process improvement)
プロセス改善が改悪へと突き進む
https://qiita.com/kaizen_nagoya/items/0f3a1174f81935bb6d85
ペアプロの３つの種類
https://qiita.com/kaizen_nagoya/items/5c80663799d99b807870
ITシステムの見積もりの見積もり
https://qiita.com/kaizen_nagoya/items/93a7d3ba13da0a7a9c15
作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab
ソフトウエアプロセスの改善に向けて ~SPIへの今後の取組み~ (ソフトウエア開発・調達プロセス改善協議会報告書の公表)
http://warp.da.ndl.go.jp/info:ndljp/pid/1368617/www.meti.go.jp/kohosys/press/0002639/0/020419spi.pdf
Qiita
2019年に入ってからのQiita記事の書き方
https://qiita.com/kaizen_nagoya/items/1786ed40dc5c73ed8b46
なぜ少しづつQiitaの記事を追記しているか
https://qiita.com/kaizen_nagoya/items/fa8b102a92d094437416
Qiita記事の最近の書き始め例
https://qiita.com/kaizen_nagoya/items/c37a680065010b3eab5a
楽しいQiitaの使い方 壁１０罠6つ技7つ
https://qiita.com/kaizen_nagoya/items/7828d0b1d47ad21b45c6
プログラマによる、プログラマのための、統計と確率のプログラミングとその後 統計と確率一覧（０）
https://qiita.com/kaizen_nagoya/items/6e9897eb641268766909
＜この記事は個人の過去の経験に基づく個人の感想です。現在所属する組織、業務とは関係がありません。＞
文書履歴(document history)
ver. 0.01 初稿 20190214 8時
ver. 0.02 参考資料追記 20190214 9時
ver. 0.03 みだし英語追記 20190214 10時
ver. 0.04 誤植訂正 20190214 午後
ver. 0.05 見直し, 分析 追記 20190214 夕
ver. 0.06 はてなURL追記 20190218
ver. 0.07 三倍速 補強 20191020
ver. 0.08 表記補正 20211015
ver. 0.09 いいね追記 20230714
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.
