プロジェクトマネジメント本振り返り

 

・工数見積でタスク遂行能力を見極める

・担当者のスキルが低い場合はサブタスクレベルへの分解をサポート、しないと手戻りリスク大

・週一の定例だと時間が長くなり無駄な時間が増えるため、昼会や夕会を適度に入れるのが良い

 

・概算見積で一番安い企業に発注したらPJ炎上し、別の企業に再発注になるリスクあり。「安かろう悪かろう」

・工数見積において、5人日以上は5人日刻みで出すのがバッファ込みで自然

・工数見積において、適切なバッファはリスク小PJで係数1.2、リスク大で係数15

・見積は積み上げ式でやっておくと「何の費用？」「何を削れる？」に説明や調整可

・見積の前提条件は必ず記載

・追加要件や仕様変更の多いPJは追加見積として提示

・肝心なのは要件や仕様が変わると工数が変動しそれを見積必要があることを都度説明 

 

・なにをやるかが明確でなく見積が大きくぶれやすい要件定義や設計までを準委任(詳細見積が出せるまでの間)、何をなるかが明確になっていてブレが小さい実装/テストを請負契約にするのもあり

・「検収の条件」をあらかじめPJ計画で取り決めて文書化しておく、これをやっておかないと「これもあれも契約不適合」と無償対応を迫られ続ける

・経産省の「情報システム、モデル取り引き、契約書」では、損害賠償額は取引金額を上限とする事を推奨している

・準委任契約は業務を委任された側に「善管注意業務」がある

・準委任契約の見積のバッファは20%、請負契約は50%、これはリスクの違い

 

・要件定義の際はPJの骨格(やり直しがきかない要件)を見極る

・事前に意識合わせや検討打ち合わせを何回入れれる過考えておく、特にえらい人が参加するもの

・システム要件の項目

　-システムアーキテクチャ

　-機能要件一覧

　-非機能要件一覧

・要件定義は可能な限り図で表現する、日頃から抽象概念を図に落とすことに慣れておく

・要件定義はBefore(AsIs)After(ToBe)を明確に

・PJの各フェーズで「その時点で決まってる要件」を関係者に共有する

・発注者の要件ヒアリングが難しい際、提案型で要件を取りまとめる、2択程度にする

・要件定義の議論では「発散」と「収束」を意識し、今どちらの段階なのか明示しながら進める

 

・技術スタックの選定で意識すること

　-メンバが既に習得しているか

　-技術に汎用性があるか

　-技術に関する情報や知見はインターネットで入手しやすいか

　-マイナーすぎないか(メンバ召集に困らないか)

・十分な経験を積んだエンジニアであれば、新しい技術でも1ヶ月程度で足りることもある

・学習意欲の高いエンジニアは新しい技術を使いたがる傾向があるが、新しすぎるのもリスク

・世の中で十分使用されてる実績のある技術で有れば殆どバグ改修されえたり、バグ回避方法が確立してたりする

・技術選定の際はGoogle Trend等を使って流行度合いを調べる方法がある

・スケジュールの都合で設計書を作らず実装を進めるけーすもありますが、簡素でも必要最低限の設計は行った方が良い、合意形成の証拠にもある

 

・連携先システム担当のチームやベンダーとの調整がポイント、ここを甘く見ないこと

・責任の追求ではなく、対策を追求する

・真面目なエンジニアほどバグを出してしまったことに罪悪感を抱きやすい

・テストは出来るだけ多くの不具合を発見して効率的に対策し、本番でトラブルを起こさないのが目的、なので報告が多いのは悪くない

 

・リリース手順

　-日程と体制を調整

　-リリース計画を作成

　-リハーサルを実施

　-関係各所へ説明

 

・保守改善費用は松竹梅で考える

　梅 : 保守運用のみ

　竹 : 保守運用メインで改善少々

　松 : 保守運用 + 改善もがっつり