おはこんばんちは！ゆるふわSEの「ゆるちょここ」です♪(*´ω｀*)
どんなプロジェクトでもドキュメントはつきものですよね！（唐突w）
皆さんは普段プロジェクトの中でどんなドキュメントを作成してどのような流れでプロジェクトを進めていますか？！
PM（プロジェクトマネージャ）やPL（プロジェクトリーダ）の立場でプロジェクトを進める際は、よくメンバの作成したドキュメントをレビューすることが多くなってくると思います。
今回は、そんなリーダの立場になったSEさんがメンバに資料を作ってもらうこと、レビューをすることの難しさについてちょっと考えてみたいと思いまーす✨(●´ω｀●)
インフラの構築案件や、プログラムの開発案件等、案件によっては若干流れが違うかもですが、一般的な？！プロジェクトで作るドキュメントの種類や流れは下記のよーな感じだと思っていますー。
プロジェクトのフェーズごとに必要なドキュメントの種類の例
※提案や見積もりのフェーズはプロジェクトが始まる前段階のフェーズ（基本は受注してからプロジェクトが始まる）なので省いてますー。
①プロジェクト管理
・マスタスケジュール、WBS
・課題管理、質問管理表
②要件定義フェーズ
・要件定義書
③設計フェーズ
・基本設計書（外部設計書）
・詳細設計書（内部設計書）
④構築フェーズ
・構築手順書
⑤テストフェーズ
・テスト設計書
・テスト項目書（単体、結合、総合、受入）
・テスト結果報告書
⑥リリースフェーズ
・本番移行手順書
・作業完了報告書
⇒システムのリリース(*´▽｀*)✨
また、ドキュメントの作成からレビューの流れは下記のような感じだと思っていますー。
ドキュメントの作成/レビューの流れ
①ドキュメントの初版作成
②内部レビュー、指摘
③内部レビュー指摘事項修正
④内部レビュー指摘事項修正確認/承認
⑤顧客レビュー
⑥顧客レビュー指摘事項修正
⑦顧客レビュー指摘事項修正確認/承認
⇒ドキュメントのリリース(*´▽｀*)✨
と、このよーな流れなのですが、リーダとして上から下までプロジェクトを担当、そして複数プロジェクトを抱えていると、プロジェクト管理、推進、方針の策定、関係者との調整、課題管理等でスーパー忙しく、自分でドキュメントを作るというよりは、メンバに作れそうもない超上流のドキュメント以外は、メンバに作ってもらったドキュメントをレビューしてプロジェクトを進めて行くケースが多いです。
今回のお話はそんな状況でドキュメントを作ってもらうときの難しさと、どーすればより良いものを作ってもらえるかというなかなか体系的に誰かが教えてくれることは少ないよーな気がするテーマを考えていこー(●´ω｀●)というお話です！！！
では、れっつらごー♪
ドキュメントを作ってもらうこと、レビューの難しさ
①想定していた通りのものが出てこない・・・(´・ω・｀)
そんなときのメンバとの関わり方は・・・？
私が思う、最高に良い関係のチームはリーダがメンバに対して「このドキュメントなんだけど、こんな感じで作ってちょー(*´▽｀*)」、というお話をしたら、メンバが「りょーかいっすー(｀・ω・´)！」って言って、出てきたものが想定通りのドキュメントっていう感じが最高です！が、こんなチームはめったにありません！！！w
長年一緒にやってきて、プロジェクトやドキュメントの作成経験も豊富なメンバであればリーダはこういうドキュメントを欲しがっているだろぉなあと察して「こんな感じ」ピッタリのドキュメントを出すこともできるかもですが、そんな阿吽の呼吸をみんなに求めるのは厳しく、人間きちんと伝えなければわかりませんw
恋人や家族ですらきちんと伝えないと、わかんなかったりするのにましては同僚なんていわんやおやですよw
なかなか、欲しいものが出てこないので、「もーいーよ(｀・ω・´)後はこっちで作っとくから！！！」と、納期の関係もあるのでしょうが、全てを任せずに自分でやった方が早いからと、自分で最後まで修正した経験がある方も多いと思います。
これを防ぐためには、「作る人」、「作ってもらいたい人」の間で認識の祖語を極力なくす努力をするのがとっても大事です！
上記より、メンバのスキルや経験にもよりますが私がメンバにドキュメント作成を求めるときは下記のような流れを汲んでいます。
■ステップ1：まずそのドキュメントがプロジェクトの中でどのような位置づけのドキュメントなのか考えてもらい、位置づけの認識をすり合わせる。
■ステップ2：認識があったら、まず目次を作ってもらい目次レベルのレビューをし、大枠記載する内容の過不足を確認する。
■ステップ3：目次が決まったら各章に記載する大枠の記述やその内容に関して表で書くのか、図で書くのか、箇条書きなのがマンガの絵コンテ的な流れをざっくりすり合わせる。
■ステップ4：詳細を記述してもらい、内容をレビューする。良い点はきっちり褒め、良くない点は根拠をもって説明する。
②どこまで細かくレビューした方が良いかの見極めわからない・・・(´・ω・｀)
そんな時は・・・？
このテーマは私が最近一番感じているとこなのですが、この見極めが難しいんですよね。一番良いのはレビューなので、作ってもらったドキュメントを隅から隅まで確認して、誤っている点を指摘する。改善点を直す。のが一番なのですが、いかんせんPM、PLは尋常じゃなく忙しいので、レビューにかけられる工数もそんなにないのですよ・・・(´・ω・｀)
なので、必然的にポイントを絞って確認し、核になる部分以外はメンバを信用してある程度は任せるっていうのが大事なのかもしれません。
少し前まで、メンバを信用していないわけではないのですが作ってもらったパラメータとかも全て確認していたんですが、これって効率がかなり悪いんですよねぇ。こればっかりは経験則で、他の工数とトレードオフを考えながら的確に確認する精度を上げていくしかないと思っています。
③メンバが「失敗するという経験」を摘んでしまう恐れがある・・・(´・ω・｀)
最近、メディアアーティストとして注目を浴びている筑波大学の助教授の「落合陽一さん」にはまっており本を読んだり、映像をみたりしているのですが、その時おっしゃられている一言にはっとしました。
それは、要約すると「あまりに、おんぶにだっこをしすぎると学生が失敗するという経験を摘んでしまう恐れがある」ということでした。
なるほどなぁ・・・(´・ω・｀)さすが落合さん・・・！！！とか思いましたw
私は担当するプロジェクトは絶対にうまくいくように、レビューの時点で誤っている箇所等は極力完全になくすよーにメンバに指摘をして、直してもらっていたのですが、これも例えば、「そのままの間違った手順で構築した場合にそのメンバは構築を失敗する」という経験を摘んでしまうことになるんだなぁと・・・(´・ω・｀)
む、難しいなぁ・・・
見つけた誤りを見逃すのは嫌だし、かといって失敗すると絶対にその個所の知識/技術は覚えるんで失敗させることも大事なんだよなぁ・・・でもプロジェクトはうまく進めたいしなぁとこれはなかなか答えが出ない悩ましい問題かもしれません。
まぁ、落合さんは企業と大学の研究が違うということもおっしゃっており、企業は失敗はできないけど、研究は失敗して色々覚えてなんぼって言ってたので、そーいう意味では会社の仕事ではきちんと指摘してあげた方が良いのかもしれません。
おまけ：レビューされる立場（メンバ）視点
私も今では、レビューする立場でプロジェクトを進めることが多いですが、以前はもちろんレビューされまくってましたw
その時は、「こんな感じで作ってちょ(｀・ω・´)！」とリーダに言われたものの、知識も技術も経験も浅かったので、「こんな感じって言われても、さっぱりわからないけど一生懸命こんな感じかなぁ・・・(´・ω・｀)」って、「レビューお願いしまーす(*´▽｀*)♪」ってお願いしたら、レビューで「全然できてないじゃん！もー後はこっちでやっとくから他のことやっといて！！！(｀・ω・´)」とか言われて、「こんな感じって全然わかんないなぁ・・・(´・ω・｀)」って思っていましたw
今はどっちの立場の気持ちもわかるので、新人ちゃんにもこんな感じを順序だって伝えれるようになりましたとさw
めでたし、めでたし・・・(*´▽｀*)
ということで、レビューに対する考え方とかってリーダさんそれぞれで、どれもその人にとっては正解なんだと思いますが、本記事が少しでも世界のどこかの誰かの参考になれば幸いでございます(*´▽｀*)✨
でゎでゎ☆彡
