エンジニアとして仕事をいろいろしてきまして、計画通りに進んだプロジェクトというのは(私以外の方もそうかもしれませんが)ほとんどありませんでした。
不確定要素が絡むためどうしてもしかたないかもしれませんが、よくある失敗例などと自分が想定した対策を書いておこうかと思います。
Contents
進捗把握不足
おこりやすい問題
今どのくらい仕事がすすんでいて、ゴールがどこかということですね。さすがにガントチャートなどが全くないプロジェクトはなかったのですが、以下のような点が多かったです。
- 作り方があらく、細かいタスク量はまで把握できていない
- メンバーのモラルがまずく、嘘の報告をする
- 見えないタスクが漏れる(未検証の技術的な要素や単体→結合試験移行時のテストデータ作成や環境構築など)
対策
この点は細かく詳細にみていくことと懸念事項の洗い出しですかね。
- 2-3日以内でおわるレベルまでのタスクに落とし込む(それ以上の場合、分割する)
- 成果物(ドキュメント、コードなどの差分)を報告させる
- 未検証技術の可視化
- 過去の失敗例をもとに特にフェーズ感の移行での懸念事項を洗い出す
この点やはりウォーターフォールのタイプのプロジェクトのほうがややしっかりされているという印象です。(スケジュールへの意識が比較的高い。)
仕様不備関連
おこりやすい問題
これもほぼ必ず起こるかな・・という感じですね。
改善案に関して、ちょっと契約にもからんでくるのと、自分はここのフェーズで仕事をしたことがないので、対策としてどこまでできるかはわかりませんが・・・
お客さんと直接やりとりする範囲が多いのでコントロールできない部分も多いかもです。
- 出来上がったものをある程度みてから、仕様不備が発覚する
- プロジェクト途中での仕様追加が非常に多い
- 開発メンバーがあやまって仕様を理解していた
- どのドキュメントが正かわからなくなる
- ドキュメントのミス(誤字脱字や細かいデータの形、配列とハッシュの違いなど・・・特にAPI連携。)
対策
- 初期フェーズ段階で、簡単なモックを見せる、リリースを複数段階に分ける
- 早い段階でユーザーにレビューに参加してもらう(一般的にプロジェクトが佳境にはいった後半段階でみてもらうことが多いため・・・こちらは最優先事項にしてもらう)
- 普段の開発時から活きた(実務で使う想定の)データを使う
- (可能かどうかはわかりませんが)契約を請負と準委任のフェーズにわける
- 仕様変更を想定したプログラムの組み方をする
- APIなどデータの受け渡しに関してはExcel,Wordだけではなく、ソースと関連した実データのサンプルをもらう(できればswaggerなどURLやレスポンスがあるものが理想)
テスト関連
開発がいざ終わってこの段階でいろいろ問題が起こり、見直しということが多かったですね・・・
おこりやすい問題
- データ作成自体をタスクにいれていなかったため、進捗が遅れる(特にフェーズ移行時)
- 想定したデータ量の桁が大幅に異なり、既存実装だと動かないため、プログラム修正多発(selectでのループを抜けて、groupingする、画面側でのpulldownをmodalにするなど)
- テストの実行に時間がかかる(特に結合以降で、デプロイのたびにいちいちプログラムを書き換える、環境が限定される、一度に複数人で作業できない)
- ローカルで実環境と同様のテストをするのが困難でテストができずにリリース(デプロイでためす)ということになりがち
- 問題の発見に時間がかかる(ログが多すぎる、報告者と開発者のコミュニケーションが難航)
対策
個人的には技術力が大きく進捗に影響するのはこの領域かと思います。環境を考えずにコードを書くプロジェクトが結構あっため、この部分で環境を考慮されていると圧倒的に開発が楽です。
- テストデータ作成を主要業務ととらえ、見えるタスクとする
- 必要データを集めるのは難しいが、最低限桁までは確認しておく
- 部分的で不完全でもいいので、テストコードの実装(難しければそれに類似するもの)
- ローカル用と、本番用でプログラムを分ける(DIの活用が理想ですが、難しければ環境変数による条件分岐など)
- 異常系テストの想定(メッセージ文言など)
- 自動テスト送信ツール(Sentryなど)の活用、テスト報告者の伝達時のマニュアル化(ログ情報のテンプレート化など)
メンバー管理
おこりやすい問題点
- 人間関係、負荷が高すぎるなどで嫌になって主要なメンバーが抜ける(過去、結合試験移行時に20人中7人がぬけたことがありました。)
- 属人性の高い仕事ができてしまう
- (進捗管理とも被りますが)モラルの低いメンバーのサボり
- メンバーの不和
- 明らかにスキルセットのちがうメンバーのアサイン
対策
- アサイン段階で勤怠と好感度印象値(人として他人に嫌悪感をもたせないか)を重視する
- コードレビューによるソースの可読性の向上(ソースを仕様書にするためにみやすいソースを。)
- 問題人物の発見は最重要優先事項と考え、早い段階で見つけ出し、隔離する
- タスク同様、メンバーのタスク進行度合いの把握(サボりの発見)
- ドキュメンテーション、情報共有の徹底化
- 複数人でタスクに当たり、単独での作業をさせない
- 外部人材を信用しすぎない(特にフリーランス)
- 稼働の監視(異常に負荷の高いメンバーがいないかの確認)
- 外部メンバーには仕事以外のコミュニケーションを積極的には取らせない
(現実的に職場のいいところを挙げる人物は少なく、負の感情が増大するため。この場合、テレワークだとコミュニケーションに限界があるため、結果としてメリットになるかも・・・) - 短期のプロジェクトであればスキルセットマッチを重要事項にあげる(できそう、地頭よさそうでとらない。逆に長期であれば自走力を重視)
- メンバー間で議論をさせず、あくまでリーダーに意見をいってもらいリーダーが判断する
(プロジェクトの改善意識を純粋にもっていて、相手を尊重して、建設的な議論ができる人間は現実的に多くない。問題意識はもっているが、議論はしない人物というのが現実的には理想では・・。)
