真面目で優しいシステムエンジニアは損をする③～怒涛の始まり～
どうも！ヒグッティ(ヒグッティ＠システムエンジニア)です！
私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回はプロジェクト開始までの経緯などを書きました。
今回はプロジェクト初期の話となります。 ではお楽しみください。
■登場人物
前回記載した内容ですが、登場人物を以下に記載しておきます。
○お客さん
仲間さん∶仲間由紀恵に似ているから。このプロジェクトの総監督的な立場。
PMさん∶プロジェクトマネージャだから。
○チームメンバ
ボウズさん∶ぼうず頭だから。技術力が一番高いと言われて採用した人。経験年数は15年くらい。
ウーバさん∶最初の挨拶で「私、ウーバイーツで配達やってたんですよー」と言っていたから。この人も技術力が高いと言われて採用。経験年数も8年くらい。
美容師さん∶元美容師だから。プログラマです。経験年数は2年くらい。
パーマさん∶パーマかけているから。物静かですが、以前の現場でプロジェクトリーダをやっていたりと経験豊富。経験年数は8年くらい。
メガネさん∶メガネしているから。経験年数は4年くらい。
ヒグ∶ヒグッティこと私です。プロジェクトリーダ。経験年数は9年くらい。
○私の会社のメンバ
優男さん∶優しく時には厳しい。尊敬する私の上司。会社内では課長的な立場。このプロジェクトではアドバイザー的な立場。
登場人物は他にもいますが、都度、紹介していきます。
プロジェクトスタート！
さぁ！いよいよプロジェクトが開始となりました！
プロジェクトが開始したのはいいですが、プロジェクト開始前から私の中では懸念点がありました。
○懸念点
1.プロジェクトで開発するシステムについて知っている人がいない。
2.採用したメンバ同士がみんな初対面。
3.うちの会社で使っている独自のテストツールなどの知識が私しか知らない。
4.いきなりシステムエンジニアやプログラマを呼んだけど作業内容が決まっていない。
この懸念はすぐに問題となって厳しい現実に直面することになりました。そんなことも露知らず、私は意気揚々と作業を開始しました。
怒涛の始まり
プロジェクト初日、チームメンバ同士と軽い自己紹介をし、プロジェクトの説明や、システム全体の説明、今回やりたいことなどを共有しました。その後は各々、仕様書やソースを見てもらうことにしました。今思えば具体的な作業がわからなかったので指示できる内容もフワフワしていました。かく言う私も仕様を理解するため、仕様書などの読み込みから開始しました。
そんな時、お客さんから連絡が入ります。
PM∶16時から会議できますか？今後の進め方についてヒグさんと相談したいのですが。会議室で待ってます。
ヒグ∶わかりました。私もPMさんと色々と相談したかったです。
会議の内容は至って普通でした。軽く挨拶をしてから、いくつか作成してほしいものがあるとのことで、その説明を受けました。依頼内容は以下でした。
・うちの会社が作成した見積もりを元にスケジュールを作成してほしいとのこと。パワーポイントで資料を作り、矢羽根を引いてスケジュールを可視化したい。
・作成したスケジュールを元にWBSに落とし込んでほしい。WBSは作業内容を分割して最小のタスクにし、いつまでに何をやるかなどを明確にした資料のことです。今回は納品物と工程ベースでWBSを作成することになりました。
スケジュール作成などは私もやらなければと思っていました。しかし、これが地獄の始まりでした。
ヒグ∶スケジュールについて作成するものは理解できました。チームメンバとも共有したいので2日ほどお時間頂けますか？
PM∶いえ、明日の午前中までにお願いします。明日の午後から他チームとスケジュールについて会議します。その時までに作成しておいてください。
ヒグ∶えっ…すみません。まだシステム全体も理解していないですし、やることや方針も具体的に決まっていないのにその短時間では無理です…
PM∶決まっていないなら決めて下さい。見積もりを作成した段階で方針などはそちらである程度決まっていたのではないですか？今まで何をしていたんですか？
ヒグ∶…（今までって、昨日まで別プロジェクトで作業していたんですけどっ！）※（）は心の声と思ってください。
PM∶明日の午前中までにお願いします。
ヒグ∶わかりました…
この会議が終わったのが17時30分。これから資料作りして、とりあえず形になるものを作れば何とかなると
思っていました。細かいところは作業を進めながら決めようと考えていました。
会議が終わって自席につくと、チームメンバから色々と質問がありました。仕様書が格納されているフォルダに権限がなくて見れない、ソースを見たいけどSVNのユーザ、パスワードがわからない、ちなみにSVNとはソースのバージョン管理ツールです。ソースが格納されているところみたいなイメージです。
怒涛の質問ラッシュでした…フォルダの権限が私のアカウントしかないようなので、一旦私のPCにすべて仕様書などをダウンロードし共有ディレクトリとして公開したり、権限を付与してもらえるようにお客さんに依頼したりしました。SVNもログイン情報をお客さんに確認したりしました。
他にもチームメンバから今後の進め方を確認したいと言われ、サーバの構成やアプリの改修について意見交換をしました。
色々と一段落して、この時すでに20時。
プロジェクト初期だし、しょうがないかーと思いながらようやく自分の作業に着手できました。
見積もり資料を見ながらスケジュールを作成、WBSにも落とし込み、誰にどの作業をやってもらうかをざっくりと決めました。細かいところは明日の午前中にやろう…
この時、22時30分…今日の作業は切り上げて帰宅することにしました。初日から色々あったけど、これから方針などを決めていけば何とかなりそうだし大丈夫だろ！！と思いながら、帰宅。帰宅後は、youtubeで東海オンエアの動画を見て就寝！東海オンエアは相変わらず面白かったし明日も頑張ろう！！と思いながら眠りにつきました。
早く言ってよー
昨日、お客さんから依頼されたスケジュールとWBSを引き続き作成していました。加えて、チームメンバと何を調査しなきゃいけないかなどを相談していました。午前中はあっという間に終わりました。
とりあえず、当面のやること、作業分担を決めました。納品物と工程を元にスケジュール、WBSを作りましたが、WBSに書いたタスクの量がえげつない。タスクの量が100個くらいになっていました。これでもまだ足りないくらいでしたが、先輩が作成した見積もりを元につらつらと書いていきました。WBSの項目はDBの変換、変換に伴うテスト、追加機能の設計、開発、単体テスト、結合テスト、システムテスト、性能テスト、データ移行、その他諸々。納品物は80項目くらいありました。今思うと作成しても意味のないドキュメントが半分くらいありましたし、何を記載して良いか謎のドキュメントもありました。概要設計書、単体テスト自動化計画書って何？www。あとWBSはお客さん先のフォーマットを使いましたが、とにかく使いづらい…フォーマットのExcelに色々と数式が入っていましたが、行を挿入するだけでも式がエラーとなったり、Excelの式でタスクの前後関係は特に紐付けられていないため、行の途中でタスクを挿入すると、以降のタスクの日付などを全て変更しなければならなかったりと効率が悪すぎました。一応、日付が自動で紐づくように自動化しましたけど！
そして、午後13時、お客さんとの会議が始まりました。
会議ではこのプロジェクトに関わるチームの代表者が集められました。
チームはこんな感じ。
プロジェクト統括チーム∶PMさんがいるとこ。主にプロジェクト全体の管理をする。メンバはPMさんと仲間さん。
アプリ開発チーム∶私のいるチーム。今回のプロジェクトで主にアプリ開発を担当する。
インフラチーム∶サーバやネットワークを担当。メンバは2人。
運用チーム∶サーバの監視や定期的なバッチ処理の管理や障害が発生した時の対応をする。メンバは1人。
既存保守チーム∶今の本番環境で動いてるシステムを保守している。メンバは4人。
ちなみに立場的にはアプリ開発チーム以外は全てお客さん先の会社のメンバ。既存保守チームは裏で他会社のSierを雇っている模様。
PM∶では会議を始めます。皆さんスケジュール、WBSは作成してもらえましたか？
ヒグ∶はい。ざっくりとですが、一応。
他の人達∶まだ完成はしていませんが一応作りました。
PM∶ありがとうございます。では確認していきましょう。ヒグさんの資料からお願いします。
ヒグ∶見積もりを元に作成しました。このタスクの開始は何日で〜
説明した内容は各タスクがいつ終わるのかがメインでした。15分くらいで説明を終えるとPMさんから衝撃の一言。
PM∶説明ありがとうございました。資料を作ってもらったのはいいのですが、参考にしてもらった見積もりは社内の承認を得るために作った資料です。見積もりに書いてある作業より実際の作業はもっと多いはずです。作業内容の見直し、見積もりからやり直して下さい。
ヒグ∶えっ…どういうことですか？
PM∶先程言った通りです。例えば、DB変換の作業があるでしょ？見積もりだと3ヶ月で終わると記載しましたが、DB変換してその後、テスト完了までが3ヶ月です。私は今のシステムがどのくらい機能数があるか知りませんが、3ヶ月でテストまで完了できるようにWBSに詳細を追記して下さい。また、作業内容や見積もりを再作成した時の根拠も、もちろん用意して下さい。
ヒグ∶…わかりました。全体を把握したいのでお時間いただけませんか？（聞いてないよー！！承認を得るためだけに作った見積もりって何だよー！意味あるのか！？そんな大事なことは早く言ってよー！）
PM∶わかりました。再作成する資料はいつできますか？
ヒグ∶えー、それは本日中に報告します。（まだこのシステムの全体もわからないのにいつまでにできるかなんてわかるかー！！）
PM∶わかりました。早めにお願いします。その見積もり次第でマスタースケジュールが変わるのでお願いしますね！
ヒグ∶はい！頑張ります！
PM∶開発チームの他の人はこのWBS通りに作業しているんですか？
ヒグ∶はい。
PM∶わかりました。引き続き作業は進めてください。
ヒグ∶…（いやいや、作業内容が変わるんだから引き続き作業を進めるも何もないだろ…）
PM∶では、他のチームのスケジュールを確認しましょう。
そんな感じで会議が終了。2時間ほどかかりました。他のチームのスケジュール説明を聞いていましたが、WBSのタスクが10個くらいしかなかったです。3ヶ月くらい作業して後はテスト支援だけ。うちのチームやること多すぎないか？加えて、まだ作業が増えるだと？しかも他のチームでWBS作成自体していませんでした！みたいな人もいたり、中々のグダグダ具合でした。
私は見積もりを作ったことはあるけど、この規模の見積もりは作ったことなかったです。1年間の作業を全て見積もり直すとは。まぁプロジェクトリーダだし、このくらいできないとな！自分の成長のためにも頑張ろう！とやる気になっていました。
さて、どうしよう
会議が終わり自席に戻りました。私はチームメンバに会議の内容を共有。全体の見積もりを再作成することを伝えました。そこでまずはシステム全体でどんな機能があるのかを書き出すことにしました。機能一覧的な資料があればよかったのですが、お客さんに聞いたらそのような資料はないと言われました。
仕様書から機能を列挙するように指示を出した後、私は上司の優男さんと相談することにしました。
ヒグ∶優男さん、ご相談があります。
優男∶おー、いいよー、順調？
ヒグ∶まだ慣れないですけど、なんとか。今はチームでシステム全体の理解を進めてます。
優男∶そか！で何？
ヒグ∶優男さんに作成してもらった見積もりですが、お客さんから承認を得るためだけに作成したものと言われました。これは本当ですか？
優男∶あー、金額がデカいから見積もりを2つに分けてくれーとは言われた。
ヒグ∶そうなんですね。DB変換とそのテストの期間が3ヶ月なんですけど、これはどうやって3ヶ月って決めたんですか？
優男∶特に根拠はないけど、経験的に決めた。簡単なプログラムばっかりだったから1機能あたり1日で開発と単体テスト終わる感じかなーって思って！他の人とも話して大体いいーんじゃないってことになった。機能数はソース見たけど100機能くらいだから大体3ヶ月かなって感じで見積もった！
ヒグ∶了解です！ここから相談ですが、お客さんから見積もりやスケジュールを再作成してくれと言われて…どうやって見積もりしようかと考えています。まずはDB変換の見積もりは、全体の機能数を出して、1機能あたり何日くらいテストが必要か見ようと思います。お客さんに報告するまで、時間ないので全部の機能は目を通せないですが、2~3機能くらい見てテストに必要な日数を出したいと思います。
優男∶了解！それで良いと思います。でも再見積もりしてくれなんてひどいな(笑)
ヒグ∶ですよね(笑)ありがとうございます。これで進めます。
チームメンバに指示を出し、上司とも相談し見積もりの作成については大体やる事は決まりました。あとはみんなの作ってくれる資料を元に見積もりを作るかーと考えていました。
そんな時、ボウズさんから報告を受けます。
ボウズ∶Web画面の機能数を調査しているんですけど、問題がありまして…
ヒグ∶何ですか？
ボウズ∶Web画面の仕様書が2つあるんですよ。で、機能一覧のページがあってそこから機能一覧を作ろうと思ったんですけど、この2つの仕様書の機能一覧ページに書いてあることが全く同じ内容になっているみたいで…これは仕様書の間違いだと思うんですよねー
ヒグ∶えー！マジすか！了解です。すぐにお客さんに確認します。
私も仕様書を確認しましたが、内容が同じでした。違うWeb画面の仕様書なのに機能一覧が同じって…完全にコピペしたやつじゃん…すぐにお客さんに相談しました。
ヒグ∶すみません。仕様書について確認したいんですけど…
PM∶いいですよ。なんですか？
ヒグ∶この2つの仕様書の機能一覧ページで内容が全く同じなんですよ。多分、仕様書が間違えていると思うんですが何か知ってますか？別に仕様書があるとか？
PM∶あーそれね！昔からこのシステムって仕様書がひどくてさー！多分、仕様書の内容と実際の動きが合ってないこととかあるから、この件も昔からの名残りかなー(笑)今回、お願いしていることに仕様書の全体的なリファクタリングも要件に入ってるから！この機会に仕様書の不整合も修正してね！
ヒグ∶そうだったんですね…了解です。見積もりの再作成で機能一覧を作ろうかと思っているんですが、何を鏡にすれば良いか…
PM∶そうだねー、機能一覧は間違っているけど、仕様書で各機能を説明しているところは問題なさそうだから、そこを調査して一覧つくれそうだよ！
ヒグ∶本当ですね。間違えているのはぱっと見、機能一覧だけみたいですね。中身を見て洗い出します。
PM∶見積もりといい、仕様書といい、想定外のことばかりで大変でしょ？(笑)上司に文句言ったほうがいいよ(笑)
ヒグ∶ですね(笑)でもやることはわかったので大丈夫そうです。ありがとうございました。
PM∶いつくらいに見積もりとスケジュールだせそう？
ヒグ∶仕様書を細かく見なきゃいけないので2日ほどお時間いただけませんか？
PM∶了解です！ヒグさんはリーダだからあまり作業を持たないようにね！
ヒグ∶わかりました！
PMさんと初めて個別に話したけど、いい人そうでした。でも仕様書があてにならないって…
その後、ボウズさんやチームメンバと仕様書について共有して引き続き機能一覧を作ってもらうことにしました。チームメンバからは仕様書があてにならないなんてどうなの？と言われましたが、何とかその場は理解してもらいました。
リーダって伝言ゲームだなーと思いました。お客さんの意見などをチームメンバにわかりやすく噛み砕いて伝える。大変さを改めて感じました。
さあー！見積もりとスケジュール作るぞー！この日も21時くらいまで作業してから帰宅。リーダの大変さを考えながら東海オンエアの動画を見て就寝しました。
まとめ
プロジェクト初期は大変。仕様書の場所やソースの場所などはできるだけ把握しておきたい。
プロジェクトが始まってから大事な情報を知ることが多い。プロジェクトが始まる前に情報を集めておいたほうが良い。
見積もりが一番大事。プロジェクトが始まるとお金も工数も融通がきかないことが多い。
お客さんは無理なスケジュールや要求を出しがち。自分のためにも断ることが大事。残業をしてまで納期に間に合わせるといつか限界が来る。
リーダは伝言ゲーム。
東海オンエアは面白い！