Moonmile Solutions Blog

PMBOK ってのは、プロジェクト マネージメントなので、管理者側(management)の視点から書かれているのがご存知の通り。な訳ですが、実際、ソフトウェア開発をする上では、開発(development or impliment)の作業が必須なわけで、SWEBOK が良いというかというとそうではなくて、managment から見た pmbok 配下の開発工程プロセスの手薄さは、プロジェクト自体の破綻を招くのではないかッ!!! とかいうことをあえて【妄想】してみて、100 項目ほど挙げてみます。

ま、7月頭だし、たまにはコーディング以外の頭も廻すということで。

一応、アジャイル開発も意識していますが、PMBOK ベースなのでウォーターフォール開発中心のプロセス/tipsになります。

・いわゆる「software factory」状態にすること(最近の microsoft ではやらないが)
　文章中、人＝機械となっているのは、このためです。
・ムリ・ムラ・ムダを気に掛けること。
・完了しないリスクに対して、最大限対処すること。
　→　開発工程については設計に沿っての【完遂】が優先事項であるため。

■進捗関連
001 開発工程の初期に「巡航速度」を把握する（平均的なコーディング量、生産性を把握する）
002 巡航速度に従ったときに、開発工程の納期が間に合うかを定期的にチェックする。
003 間に合わない場合は、増員を準備する（この時点で「生産性」を上げることは難しい）
004 間に合わない場合は、生産量を減らす（設計工程の手戻りとなる）
005 間に合わない場合は、ムダな作業を減らす（自動化できるところを自動化する。ただし、設計工程の手戻りとなる）
006 巡航速度よりも早い場合は、燃え尽き症候群に注意する。
007 巡航速度よりも早い場合は、不用意なコピー＆ペーストに注意する（全体の生産量が上がってしまう可能性がある）
008 巡航速度よりも早い場合は、不具合の発生率が高くなる（不良品の混入率が高くなる）
009 巡航速度よりも早い場合は、勤務時間に注意する（単位時間あたりの巡航速度を守る）
010 巡航速度よりも早い場合は、嘘の報告に注意する（意図的に生産性を挙げている可能性がある）

■不具合関連
011 開発工程の初期で不具合発生数を最初に決める（不具合を直す時間をとる）
012 不具合発生率の高い人員を見つける（人＝生産機械と考えると、不具合の多い機械ということになる）
013 不具合発生率が高い場合は、巡航速度を下げる（不注意なバグが減る）
014 不具合発生率が高い場合は、コード量を減らす（不具合の発生しやすい箇所をひとつにまとめる）
015 軽度な不具合は、発生率としてカウントしない（xUnit 内での不具合をカウントすると時間コストがかかる）
016 軽度な不具合は、コーディングの生産量を抑えて調節する（xUnit を用いて、コード＆テストを一体化する）
017 重度な不具合は、周知する場所を作る（軽度/重度を区別する）
018 重度な不具合は、修正サイクルを遅く廻す（すぐに修正しようとすると、コーディング自体が止まってしまう）
019 修正サイクルを遅く廻すには、不具合票を取り回す（あえて、重たい紙の不具合票や、手順が多い不具合票にする）
020 重度な不具合は、コーディング＆テストのサイクルに含めない（コーディングの速度を不意に上げ下げしてしまう）

■規約関連
021 コーディング規約は、周知できるものにとどめる（開発者のスキルにあわせる）
022 コーディングスタイルを合わせることも規約のうちに含める（初心者が多い場合は、ベテランが修正する可能性が高いので）
023 平易に書けるコーディング規約にする（IDE などの規約にあわせる）
024 規約に合わせるリファクタリングを許す（巡航速度の範囲で）
025 規約には例外があることを周知する（規約は「ルール」や「モラル」でしかない）
026 規約のための問い合わせを減らす（コミュニケーションコストを減らす）
027 テンプレートを随時用意する
028 一度、テンプレートに従ってコーディングをしてみる（コーディング時の規約による負担がわかる）
029 多すぎる規約は、減らす（規約に頭を取られるのは問題）
030 コーディング状態に合わせて規約を追加する（コーディングの現状にあわせる。最大公約数を使う）

■品質システム関連
031 開発工程の途中で、開発物をチェックする時間をとる。
032 チェック自体は形式的でもよい（「チェックする」こと自体が重要）
033 重度の不具合は常にカウントし、監視する（多くならないようにする）
034 重度の不具合を発生箇所(人)を監視する（多くならないようにする）
035 重度の不具合について、「理由」を明確にする（理由があればOKとする）
036 監視作業はできるだけ管理者自身が行う（虚偽の報告を減らすため）
037 監視作業はできるだけ自動化する（人手を減らす、あるいは人的理由で進捗の進退が変わらないように）
038 監視作業は、監視されているこを意識させないようにする（計測されることに注力されてしまう）
039 リスクが減ったら、監視自体をやめてもよい（単純なモニタリング作業に戻す）
040 「監視されている」という意識だけを植え付けて、実際監視作業はしなくてもよい（モラルの問題、性善説風な性悪説手法）

■稼動率関連
041 定時の作業を監視する（巡航速度を守るためムリな徹夜、残業をしない）
042 定時の作業量を監視する（一定の生産量を計測する）
043 休日に関しては、あらかじめ確保しておく（週単位の進捗量ではなく、日単位を監視する）
044 休出に関しては、時間をカウントする（巡航速度を守るため）
045 残業に関しては、時間をカウントする（巡航速度を守るため）
046 生産性は、人単位で計測する（人＝機械の生産性のばらつきを考慮する）
047 難易度が異なる場合は、大枠で生産量をカウントする（早くなったり遅くなったりをカウントするのを正確にカウントするとコストがかかる）
048 別作業が割り込みであった場合は、時間を減算する（巡航速度を守るため）
049 月20日、8時間/日の 160h/月でカウントすると大枠で正しい。
050 開発工程を完遂することが目的なので、そのほかの稼動率は考慮しない（細かいところにコストを掛けない）

■コミュニケーション関連
051 コミュニケーション自体には「コスト」があることを意識する（会議にはコストがかかっている）
052 会議コストは、開発工程の初期に計上しておき、生産性から外す（巡航速度を計測するため）
053 会議コストは、主に資料集めにある（管理者は例外）
054 会議コストは、物事が決まらない場合は「最大値」となる（いわゆるムダな会議となる）
055 進捗報告は、監視側（管理者側）が抽出した資料をもとにする（虚偽を防ぐため）
056 進捗報告は、常に開発工程の完了を意識する（目的を明確にする）
057 軽度の遅れの見込みは、無視してよい（会議コストが上がるため）
058 進捗のムラに関しては、長期的な監視の対象とする（巡航速度が下がっていなければよい）
059 開発自体にムリがないことを確認する（ムダな作業が、貴重な時間を押しつぶしていないか）
060 開発自体のムダを省くように管理者は注力する（ムダな作業で、貴重な時間を使っていないか）

■人員関連
061 マイナス生産者を外す（他開発者への邪魔となるため）
062 マイナス生産者を隔離する（他開発者への影響をさげるため）
063 マイナス生産者に規定の作業を与える（作業見積がしやすい、超過がわかりやすい）
064 マイナス生産者に定期作業を与えるとプラスに転じる（定期作業は不具合のリスクが低いため）
065 初心者には定型作業を与える（巡航速度が把握しやすい）
066 初心者にはシンプルな作業を割り振る（不具合が発生しにくい）
067 ベテランには複雑な作業を割り振る（開発工程全体の生産性をあげるため）
068 ベテランには不具合発生率の高い作業を割り振る（重度不具合の対処など）
068 ベテランは、初心者のフォローに廻るだけでもよい（不具合の対処、ライブラリ作成など）
069 ベテランは、時には生産性を考慮しない（巡航速度だけを守るため）
070 開発スピードは標準的な開発者を集めた場合を考慮する（巡航速度を守るため）

■制約条件関連
071 外してよい制約があれば、即外してしまう（ムダな規約、細かすぎる進捗報告など）
072 制約は時間依存である（時間経過により状況が変わると、制約が変わる）
073 制約は前提依存である（前提条件が変わると、制約が変わる）
074 制約を見つけたあとは、その制約を利用すると（見かけ上）生産性があがる（ムダが減るなど）
075 取り除けない制約には、ベテランを配置する（生産性が一番高い人を配置する）
076 ベテランを、長期に縛る作業に割り当てない（変化する制約に対処させるため）
077 ベテランを、休ませない（常に働かせる状態がよい）
078 他の作業が止まりそうな不具合は即対処する（他作業がとまってしまうので）
079 他作業が止まらない作業にはベテランを配置しない（キーとなる合流プロセスで利用する）
080 インプットとアウトプットを固定して、内部を変化可能にする（契約プログラミングなど）

■モチベーション関連
081 人＝機械ではないので、プロジェクトが終わった後の人を意識する。
082 不定期なガス抜きを考慮する（定期的なガス抜きは時には負担になる）
083 一定量のコーディングをしたら、その日は帰る（ムリな作業はしない）
084 一定量の不具合をつぶしたら、その日は帰る（ムリな作業はしない）
085 効率化を求める場合は、3 倍以上のスピードになることを確認する（2倍以下では全体に大きく関わらない)
086 手作業ではなく頭を使う作業をする（疲れるが、そのほうが作業効率がよい）
087 手作業が必要な場合は、時間を決めて作業をする（開発者自身の作業効率を知る、巡航速度を守る）
088 使い捨ての道具「治具」を作る時間を確保する（一時的に作業量が減る）
089 「治具」は過度に高度化させない（所詮、使い捨てなので過度に自動化させない）
090 プロジェクト内に過度に「遊んでいる」人を作らない（ばらつきはあってもよいが、他の人のモチベーションに関わる）

■コスト関連
091 人的コストよりも、既存ソフトウェアコストのほうが安い（購入できれば、それを使う）
092 セキュリティによる制約コストは高い（ウィルススキャン、フリーソフトの導入不可など）
093 調査コストは非常に高い（インターネットで探せればそれに越したことはない）
094 書籍コストは非常に安い（人的コストに比べると安い）
095 複雑化されたコードよりも、単純化されたコードのほうが保守コストが低い。
096 人依存でないコードのほうが、保守コストは低い。
097 製品寿命を考慮したコーディングをするほうが、開発コストが低い。
098 管理されたリスクに対しての対処コストは低い（管理されてないリスクに対しては非常に高い）
099 コード量が少ないほうが、保守コストは低い
100 保守コストが高くなる場合のみ、開発期間を延ばしてよい。

と、ざっと書き下しましたが(2時間程度)、プロセスでなくて、チェックシートみたいになってしまいましたが、ひとまずこれで up することにします。機会があれば、もうちょっと手直しをするということで。
リスク発生 → 対処方法 の流れがないといけないし、PDCA の Check → Action → Plan の繋がりがないと駄目ですからね。