ITプロジェクトで実施される定例について【IT業界未経験者向け】

この記事は•••

IT業界未経験者

現場の面談で担当者からこの単語が出てきた

「定例」という言葉は聞くけれど、具体的に何をしているのか気になる人

ITのプロジェクトで実施される定例会とは、プロジェクトチームや関係者が定期的に開催する会議のことです。定例会には社内メンバーだけで開催する内部定例会と発注元のお客様と開催する外部向けがあります。実際の現場では、「内部」や「外部」と付けずに、「●●定例」と別の名前で呼ばれていることがあるため、その都度判断してください。

内部定例会は社内のメンバーだけで進捗や課題を報告する会議です。この会議には発注元のお客様は入ってきません。主に参加メンバーにはプロジェクトマネージャー、PMO(プロジェクトリーダー)、エンジニアと社内でシステムに関わっているメンバーです。内部定例会の目的は、システムの開発や保守、移行において進捗に問題はないか判断することです。また、問題があった場合には、それはスケジュールに影響を及ぼすものなのかを顕在化し、早めに対策をとることで全体の進捗に大幅な遅れが発生しないようにします。外部定例会は、この内部定例会実施後、発注元のお客様へ報告内容がまとまってから開催されることが多いです。そのため、何を発注元のお客様へ報告するのか、何を報告しないのかを内部定例ですり合わせします。

外部定例会では、アジェンダと呼ばれる予定している会議内容のまとめがWordやPowerPointで使用され、そこには議題と目的、流れの把握ができるように箇条書きで記載されていることが多いです。プロジェクトの進捗状況や課題、リスク、次のステップなどが報告され、参加者が意見を交換し、意思決定を行います。問題が発生している場合には、お客様へ報告し、原因や今後の暫定対策などを話しあいます。例えば、お客様が実施する受入テストで障害が多発していた場合、何故単体テストや結合テストで障害を取り除けなかったのか、対策と再防止策はどのように実施していくのかを説明します。障害はわかりやすい例ですが、他の問題としては、環境が思っていたものと違い、うまく動作できなかったり、想像以上にスケジュール通りに進捗しなかったりと予期しないことが様々あるのがITにおけるプロジェクトなので、ここは念頭に置いておいてください。

内部も外部も、定例会の開催頻度はプロジェクトによって様々ですが、通常、週次、月次、四半期などのスケジュールで開催されます。

以下には、筆者が実際に参加していた定例会の例を2つほど記載します。

定例会の事例

保険システムの内部定例会(毎日開催・テスト工程)

PMO
PMO

それでは内部定例をはじめます。

本日は主に結合テストの進捗報告と、他に何か課題があれば共有したいと思います。

開発リーダーのAさん結合テストの進捗はいかがでしょうか。

開発リーダー
開発リーダー

はい。現状の進捗としてはオンスケで進んでいます。

ただ、今後の懸念点としては、テストの手順が複雑になってくるため、進め方がわからなくなり、手が止まるメンバーが出るかもしれません。あと、環境面でアクセスできない時があるため、こちらはどうしようかと考えているところです。

プロジェクトマネージャー
プロジェクトマネージャー

ああ、それでしたらテスト手順については、開発メンバーの方々は開発リーダーだけではなく、仕様に詳しいSさんにも聞くようにしてください。

あと環境面はデプロイ時間が重なるとアクセスができなくなるため、デプロイ係のDさんはその際周知してもらっても良いですか?

PMO
PMO

Sさん、Dさんよろしくお願いします。

その他に問題がなければこれで本日の内部定例は終了とさせていただきます。

ありがとうございました。

上記のシチュエーションは毎日進捗報告していることもあり、特に問題がない場合には、1会議30分ほどで完了します。会議の長さはプロジェクトマネージャー次第でもありますが、基本的にはこのような流れで進んでいきます。

イントラ管理システムの外部定例会(週1回・保守)

PMO
PMO

●●会社様(発注元)と弊社のメンバーが揃いましたので、定例を開始させて頂きます。

本日のアジェンダは以下となっております。

〜〜〜〜〜

・進捗報告

・課題管理

・先日発生した●●について

・その他共有事項

〜〜〜〜〜

発注元
発注元

はい。よろしくお願いします。まず進捗から聞かせて頂戴。

あと課題管理は飛ばして良いや。3番目のアジェンダが今1番の課題みたいなもんだし。

PMO
PMO

承知しました。ではまず進捗ですが〜〜〜〜でスケジュール通りです。

課題としましては、先日発生した●●についてですが〜〜〜

発注元
発注元

その発生原因って何なの?元からの仕様のせい?

▲▲機能ってどうなっていたっけ?あと★★機能も

PMO
PMO

発生原因としては〜〜〜のため、仕様とは関係ありません。

また、▲▲機能ですが、〜〜〜となっています。★★機能については、ええっと。。

プロジェクトマネージャー
プロジェクトマネージャー

★★機能は〜〜〜の仕様となっております。

そのため、先日発生した●●は、他に影響を及ぼさないものと調査できています。

外部定例会では、お客様からの質問が随時発生し、予想していなかった質問も毎度飛んできます。そのため、社内メンバーで協力して質問に答えたり、回答を導き出したりすることもあります。今回は、PMOとプロジェクトマネージャーが協力している例を出しました。

プロジェクトによっては、細かな仕様の説明をお客様にして頂きたい理由で、開発リーダーのエンジニアが呼ばれる場合もあります。実際にプログラムを書いているのはエンジニアにしかわからない仕様もあるためです。そのような現場では適宜管理とエンジニアで協力していきましょう。

まとめ

いかがでしたでしょうか?少しなりとも定例会のイメージがつけば幸いです。字面だけで見ますと、「何だか厳しそうだな」とか「話せるかな」と不安な点もあるかと思われますが、慣れてしまえば余裕なので心配いりません。エンジニアの場合は、期間内にやったことと目標に対してできなかったことを素直に話せば基本的には問題ありません。

PS

内部での進捗が遅れていた場合、「遅れている分どうすんの?」と当たり前のように言われますが、当たり前のように「残業して取り返します」ってやめたいですよね。残業にも限度がある(笑)

人を追加しても仕様が分からないから、結局現状のメンバーだけで製造、テストをするしかないという。。利益は大事ですけどね〜〜

まあ今は36協定が出たおかげで派遣されるエンジニアの勤怠時間はシビアになってきているそうですが。。役職がついたらその枷も外れて無限残業編の開始ですけどね(笑)仕事が楽しい人なら問題ない。根性とスキルが身につくし、気づいたらフルスタック寄りになってるのあるあるな気がするんですよね。

コメント