skillup

技術ブログ

プロジェクト管理

プロジェクトでの頻出問題点と自分なりの対策など

投稿日:2022年12月17日 更新日:

エンジニアとして仕事をいろいろしてきまして、計画通りに進んだプロジェクトというのは(私以外の方もそうかもしれませんが)ほとんどありませんでした。

不確定要素が絡むためどうしてもしかたないかもしれませんが、よくある失敗例などと自分が想定した対策を書いておこうかと思います。

進捗把握不足

おこりやすい問題

今どのくらい仕事がすすんでいて、ゴールがどこかということですね。さすがにガントチャートなどが全くないプロジェクトはなかったのですが、以下のような点が多かったです。

  • 作り方があらく、細かいタスク量はまで把握できていない
  • メンバーのモラルがまずく、嘘の報告をする
  • 見えないタスクが漏れる(未検証の技術的な要素や単体→結合試験移行時のテストデータ作成や環境構築など)

対策

この点は細かく詳細にみていくことと懸念事項の洗い出しですかね。

  • 2-3日以内でおわるレベルまでのタスクに落とし込む(それ以上の場合、分割する)
  • 成果物(ドキュメント、コードなどの差分)を報告させる
  • 未検証技術の可視化
  • 過去の失敗例をもとに特にフェーズ感の移行での懸念事項を洗い出す

この点やはりウォーターフォールのタイプのプロジェクトのほうがややしっかりされているという印象です。(スケジュールへの意識が比較的高い。)

仕様不備関連

おこりやすい問題

これもほぼ必ず起こるかな・・という感じですね。

改善案に関して、ちょっと契約にもからんでくるのと、自分はここのフェーズで仕事をしたことがないので、対策としてどこまでできるかはわかりませんが・・・

お客さんと直接やりとりする範囲が多いのでコントロールできない部分も多いかもです。

  • 出来上がったものをある程度みてから、仕様不備が発覚する
  • プロジェクト途中での仕様追加が非常に多い
  • 開発メンバーがあやまって仕様を理解していた
  • どのドキュメントが正かわからなくなる
  • ドキュメントのミス(誤字脱字や細かいデータの形、配列とハッシュの違いなど・・・特にAPI連携。)

対策

  • 初期フェーズ段階で、簡単なモックを見せる、リリースを複数段階に分ける
  • 早い段階でユーザーにレビューに参加してもらう(一般的にプロジェクトが佳境にはいった後半段階でみてもらうことが多いため・・・こちらは最優先事項にしてもらう)
  • 普段の開発時から活きた(実務で使う想定の)データを使う
  • (可能かどうかはわかりませんが)契約を請負と準委任のフェーズにわける
  • 仕様変更を想定したプログラムの組み方をする
  • APIなどデータの受け渡しに関してはExcel,Wordだけではなく、ソースと関連した実データのサンプルをもらう(できればswaggerなどURLやレスポンスがあるものが理想)

テスト関連

開発がいざ終わってこの段階でいろいろ問題が起こり、見直しということが多かったですね・・・

おこりやすい問題

  • データ作成自体をタスクにいれていなかったため、進捗が遅れる(特にフェーズ移行時)
  • 想定したデータ量の桁が大幅に異なり、既存実装だと動かないため、プログラム修正多発(selectでのループを抜けて、groupingする、画面側でのpulldownをmodalにするなど)
  • テストの実行に時間がかかる(特に結合以降で、デプロイのたびにいちいちプログラムを書き換える、環境が限定される、一度に複数人で作業できない)
  • ローカルで実環境と同様のテストをするのが困難でテストができずにリリース(デプロイでためす)ということになりがち
  • 問題の発見に時間がかかる(ログが多すぎる、報告者と開発者のコミュニケーションが難航)

対策

個人的には技術力が大きく進捗に影響するのはこの領域かと思います。環境を考えずにコードを書くプロジェクトが結構あっため、この部分で環境を考慮されていると圧倒的に開発が楽です。

  • テストデータ作成を主要業務ととらえ、見えるタスクとする
  • 必要データを集めるのは難しいが、最低限桁までは確認しておく
  • 部分的で不完全でもいいので、テストコードの実装(難しければそれに類似するもの)
  • ローカル用と、本番用でプログラムを分ける(DIの活用が理想ですが、難しければ環境変数による条件分岐など)
  • 異常系テストの想定(メッセージ文言など)
  • 自動テスト送信ツール(Sentryなど)の活用、テスト報告者の伝達時のマニュアル化(ログ情報のテンプレート化など)

メンバー管理

おこりやすい問題点

  • 人間関係、負荷が高すぎるなどで嫌になって主要なメンバーが抜ける(過去、結合試験移行時に20人中7人がぬけたことがありました。)
  • 属人性の高い仕事ができてしまう
  • (進捗管理とも被りますが)モラルの低いメンバーのサボり
  • メンバーの不和
  • 明らかにスキルセットのちがうメンバーのアサイン

対策

  • アサイン段階で勤怠と好感度印象値(人として他人に嫌悪感をもたせないか)を重視する
  • コードレビューによるソースの可読性の向上(ソースを仕様書にするためにみやすいソースを。)
  • 問題人物の発見は最重要優先事項と考え、早い段階で見つけ出し、隔離する
  • タスク同様、メンバーのタスク進行度合いの把握(サボりの発見)
  • ドキュメンテーション、情報共有の徹底化
  • 複数人でタスクに当たり、単独での作業をさせない
  • 外部人材を信用しすぎない(特にフリーランス)
  • 稼働の監視(異常に負荷の高いメンバーがいないかの確認)
  • 外部メンバーには仕事以外のコミュニケーションを積極的には取らせない
    (現実的に職場のいいところを挙げる人物は少なく、負の感情が増大するため。この場合、テレワークだとコミュニケーションに限界があるため、結果としてメリットになるかも・・・)
  • 短期のプロジェクトであればスキルセットマッチを重要事項にあげる(できそう、地頭よさそうでとらない。逆に長期であれば自走力を重視)
  • メンバー間で議論をさせず、あくまでリーダーに意見をいってもらいリーダーが判断する
    (プロジェクトの改善意識を純粋にもっていて、相手を尊重して、建設的な議論ができる人間は現実的に多くない。問題意識はもっているが、議論はしない人物というのが現実的には理想では・・。)

-プロジェクト管理
-

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

no image

ファジープロジェクト対策 その2

前回に引き続き、大事だと思ったこと。一部単なるフレームワークの作り方的な内容になっているかも。 Contents1 テンプレート共通化2 バリデーション3 ログ出し4 異常系の処理5 新規プラグイン+ …

no image

スクラム開発をやってみて

アジャイルの定義に関してはエンジニアによって色々なものがあると思われますが、自分の場合一番綺麗に説明されているな・・・と感じたのは以下の記事でも紹介した書籍でした。 アジャイル開発について 現場ではた …

no image

手動テストと自動テストのメリデメについて

自動テスト環境で作業をするようになって1年近く経ちますが、現在の案件でも手動テストはやっております。 一般的には自動テストをがっちりと装備するのがいいと言われがちですが、やはり自動テストのデメリット、 …

no image

採用の重要性と一般的な採用の問題点について

私自身は現時点では経営者でも人事でもないのですが、学習塾運営スタッフ時代から講師の採用は少ししていたのと、以前の会社でも規模が小さいということもあり、多少関わらせていただきました。 そこで思ったことを …

no image

プロジェクトにおける改善(主にコミュニケーション関連)

今まで複数のプロジェクトに参加してきましたが、そこで大切なコミュニケーションについて書かせていただきました。 コミュニケーションって言葉、多義的であまり好きではないのですが(汗)現実的に伝わりやすいた …

アーカイブ