261

IT系のカンファレンスに参加した話などを書いています

プロジェクトに必要なこと

プロジェクトで必要なことを考えてみました。

書こうと思った理由は大体いきなりそいじゃよろしくって言われることが多いけど いきなり言われても困るので必要な情報をまとめておいて ベストプラクティスへとブラッシュアップしていけたらと思ったため。 適宜修正していきます。。

目次

  • 開始
  • 終了
  • 開発
  • スケジュール
  • 会議
  • 納品

開始

  • キックオフミーティングを行う。 キックオフミーティングを行う理由は事前にプロジェクトの概要、全体像を把握すること。
    急にプロジェクトに参加ね。とか言われることも多いけど、以下のことは確認しておいた方がいい。
    • プロジェクトのメンバーの確認
    • 顧客の確認
    • 担当者名、会社名
    • 納品物を確認する
      • 納品日はいつか
      • 制約はないか
      • 途中納品があるか?
      • 週報などを提出する必要があるか?

終了

  • 納品後、プロジェクトメンバーと振り返りの会を行う。
  • 次のプロジェクトへ経験を活かすためにも、他のメンバーがどう思っていたかを聞くためにも必ず行うべき。
    • 良かったこと、悪かったことを洗い出す。
    • プロジェクトで良かったこと、提案できたことの確認。
    • プロジェクトで失敗したこと、対策案などを確認、話し合う。
    • 長いプロジェクトだと昔のことを思い出せないことがあるので、当時の日報等を使って確認するのもいいかも?
    • 出来るだけ全員が発言できるようにした方がいい。
      例えばホワイトボードに全員が意見を書くとか。
    • 個人的にはKPT法は使い方が難しいと感じている…。
      理由は自由に意見を言えるように見えないから。

開発

担当者に確認が必要な項目または、開発で気になる点を列挙した

言語はなにか

  • 言語のバージョンは何を想定しているか
    • C89/C95/C99 C++/C++0x/C++11 Java 5,6,7? or script?
    • 今更ないと思うけどC99以降かどうか確認しておく。
    • C++はboost使うのかどうか、
    • Javaはバージョンの違いが大きいので以下の点を抑えておいたらいいかな?
  • スクリプト言語を使用して作業を効率化出来るか
  • 作業を自動化出来ることはないか
    • ビルド、テスト、コミット
  • 単体テストは整備されているか
  • 言語規約はあるか
    • 無いなら最低限の決め事を作るべき。
    • 特に無い上に今まで好き勝手やってましたというときは担当者と相談。#よくある
  • バージョン管理ソフトは使っているか
    • 出来ればgit
    • 次点でsvn 使ってないなら使うように提案
    • コミット時のコメントルールの確認
    • コミットタイミングの確認
  • doxygen/javadocは使えるか
    doxygen等を使う理由は詳細設計書を自動生成するため。 納品物で詳細設計書があるならdoxygenの自動生成でいいか相談
  • 横展開されたソースがあるか/あったならそのソースにバグがないか
    • うちの開発したライブラリを使ってくださいとかは気をつけること
    • バグも入ってるけど、使えるからとかクライアント様はイミフなことをよく言ってくる

コミュニケーション

  • 連絡事項をメールで流す
    • メールにはタイトルに接頭辞をつけておくと検索効率が上がる
  • 長期のプロジェクトならwikiを使用する。
    • 残したいことをwikiに書いておき、情報が埋もれるのを防ぐ
    • また、新規参加者への説明がwikiを参照してもらうだけで済む。
  • 顧客との連絡は窓口として代表が一人立つべき。
    複数人で対応するのは余計な混乱を生みかねない。

障害管理

  • 障害管理はツールの利用でもexcelでもなんでもよいが、何かしら用意して解消していないバグを残さない/忘れないようにする

スケジュール

  • 朝会 (朝会を行うかどうかはプロジェクトの文化による。)
    • 昨日やったこと、今日やることをメンバーと毎朝10分程度で確認する。 10分長くて15分で終わるようにする。だらだら続けるのは最悪朝会中止とかになる。。
    • 共有すべき問題点があるなら周知する
  • スケジュール管理

    • 可能ならRedmine/Tracなどのツールを使う。
      • 基本的にチケットは担当者が入力する。これをリーダーの仕事にはしない。
      • ツールを使うことでフィルタリングや、ガントチャートが容易に確認できる。 問題点はoutputや、スケジュール表示がツールのデフォルトでは貧弱なこと
    • excelで管理は入力する方も管理する方も労力がかかるのでおすすめしない。
    • 全体のスケジュールをメンバー全員が把握できるようにすること、

      プロジェクトのゴールがどこなのか全員が把握すること ゴールのわかっていないプロジェクトはメンバーにいつ終わるかわからないといった不安を煽る。

  • WBS
    Work Breakdown Structure(WBS)とは、プロジェクトマネジメントで計画を立てる際に用いられる手法の一つで、プロジェクト全体を細かい作業に分割した構成図。「作業分割構成」「作業分解図」などとも呼ばれる。 (出典:Wikipedia) スケジュールを立てるときはWBSで分解した作業項目を基に立てる。

進捗率

  • 進捗は基本的に0%か100%しかない。
  • 10%とか70%とか作業を行っている本人は言いたくなるけど、終わっていないなら0%
  • 例えば仕様書を書いて100%になり、レビューをした後指摘事項があれば、 進捗率は80%などになるのではなく、新規にレビューの反映という項目が生まれ、 進捗率は0%とし、反映が終われば100%になるようにする。
  • 進捗率をn%として示すならその根拠を明確にすること。 例えば機能が10個あって、5個実装されているなら進捗率は50%。

会議

  • どんなに簡単なものでもいいが、Agendaを用意し、そのこと以外については話さないようにするべき。
    会議が無駄に長くなるのを防ぐのと、何の会議をしているかを明確にするため。

  • 相手に説明が伝わっていない時

    • そもそも自分が説明することを理解していないのでは? →説明する時に図を書く。 #理解できているなら図に書くことができるはず。
  • 納品

    • 納品物は定例会があるなら毎回見せておく。
      • 見せられるようにしておくこと。
    • 納品物については納品前に担当者に確認をとっておく。