真面目で優しいシステムエンジニアは損をする②～プロジェクトスタート～
どうも！ヒグッティです！
twitterやっています！よかったらフォローしてください。
ヒグッティ＠システムエンジニア私の実体験を元に真面目で優しいシステムエンジニアが損をすることについて書いていこうと思います。 これはフィクションです。とあるシステムエンジニア、ヒグッティの物語です。
前回は私がシステムエンジニアになるまでの経緯などを書きました。
今回以降は私が経験したプロジェクトの話となります。
プロジェクトスタート？
今までの仕事ぶりが認められプロジェクトリーダーとして仕事をすることになりました！プロジェクトのスタートに向けて期待と不安がありつつもワクワクし、謎の自信がありました！そんな中、プロジェクト開始前に事前の説明会がありました。お客さんからプロジェクトの概要を聞きました。
○新規プロジェクトの概要
・現状
要件定義までは完了。（以降の設計工程からの作業をうちの会社でやる）
・やること
1.DB（データベース）をOracleから別のDBに変えたい。
2.新しいサービスの追加
3.サーバの老朽化対応
4.極力自動化してほしい
5.その他諸々。Web画面の改修など。
6.データ移行
・期間
1年4ヶ月（7月から来年の8月まで）
・納期
来年8月
・詳細
DBをOracleから別のDBに変えたい理由は維持費の削減です。Oracleはライセンス費用がとにかく高い！規模にもよりますが、年間数百万とか1千万円とか取られます。その分、使いやすい機能やサポートが充実しているのでなんとも言えませんが、技術に弱い人や知らない人からすると無駄なコストとして見られちゃうようです。この要望に対してはAWS（アマゾンウェブサービス）のRDS（AWSのDBサービス）であるAurora（postgresql互換）を使うことになりました。お客さんの話では、OracleからAuroraに変換するツールがあるからそれを使えばすぐにできると言われました。
新しいサービスの追加は他システムとの連携するデータが増えるというものでした。このときはデータのフォーマットなどの資料もなかったので、そーなんだくらいにしか考えていませんでした。聞いたところだと増えるデータは5件くらいと聞いていたので、あまり深く考えていませんでした。
サーバの老朽化は今本番環境で使っているサーバのバージョンが古いので新しくしたいとのこと。サーバの準備は他のサーバ構築チームがいるからやる事はないと言われました。
自動化についてはテストやモジュール管理、など極力自動化してほしいとのこと。具体的何をやるとかは決まっていなかったです。
データ移行は既存DBのデータを新しいDBに持っていく方法を考えるというもの。
お客さんからは全体的にスケジュールの余裕があるし、ラスト3ヶ月くらいは作業がないので他システムとのテスト支援をしてもらうとのことでした。
・私が思ったこと
けっこう余裕じゃん！プロジェクトリーダーとして最初の仕事にはもってこいと思っていました。DBをツールで変換して新しい機能を追加するだけ！あとはラスト3ヶ月はのんびり過ごせる！っと楽観的に考えていました！
・全体的な予定
7月〜12月∶設計、環境構築、DBの変換、新しいサービスの追加、あとはひたすら単体テスト、結合テスト
来年1月〜来年3月∶システムテスト、性能テスト、データ移行設計
来年4月〜来年8月∶Web画面の改修、諸々の細かい開発、データ移行テスト、他システムとのテスト支援
だがしかし…
しかし、プロジェクトは7月に始まりませんでした。理由はお客さんの社内で新規プロジェクトの承認がOKにならないとのことです。プロジェクトの金額が大きすぎて審査に時間がかかっているとかなんとか…
開始が遅れている間にも様々なことがありました。
お客さんから再見積もりの依頼が頻繁に来ていました。プロジェクトの見積もりは上司がやってくれましたが、今思うと私も見積もり作成に加わればよかった…
プロジェクトの開始が遅れているのはお客さんのせいなのに頻繁に見積もり依頼が飛んできている事に疑問に感じていました。再見積もりにかかった工数のお金はもらってないのに頻繁に見積もり依頼が来て、しかも見積もり資料の納期は明日までとか短期でした。うちの会社は無料見積もり依頼し放題の慈善団体じゃねーか！でもそーゆーことを無料でやることにより仕事を受注できたり、新しい仕事を紹介してもらっているので強くは言えないです。
一般的にはどうなんだろ？割と普通なのか？ちなみにうちの部署はエンジニアが営業もします。なので本来は営業が見積もりとか出すところを現場のエンジニアが見積もりや提案書を出しています。上司も他に仕事ある中、見積もりも作ってすごいなーと改めて尊敬していました。上司は複数人いるのですが、基本的に同じ現場の上司が見積もりしていました。違う現場にいる上司も見積もりに参加できればいいのに。Sierをやっていると感じるのですが、会社への帰属意識が低下し、他の現場にいる人への興味がなくなってきます。複数いる上司の中ですら、管理などせず、ほぼ丸投げ状態、任せっきりということも珍しくありません。俗に言う縦割り社会…いざ問題が発生してその現場のメンバだけではどうしようもなくなった時どうするんだろ？
やっと！
そんな中、やっと見積もりが承認されました。8月の上旬でした。お客さんと上司が色々と見積もりした結果、何とか承認をもらえたらしい。
どうやって見積もりが承認されたかというと、プロジェクト全体の見積もりを2つに分けて作ったそうです。元々、3000万円くらいの見積もりを1500万円,1500万円に分けたとか。それで承認が通るんだ…ちょっと不思議でしたけどこれで作業できます。ちなみに開始は遅れましたが、納期は変わらず、、、その分、人を追加することで調整していたようです。
プロジェクト開始前の準備
私は新規プロジェクト開始の前日まで別プロジェクトで作業していました。なので新規プロジェクトのための準備はほとんどできていませんでした。仕様書やソースも見れず…一応、新規プロジェクトのシステムが何をしているかをざっくりと理解するため、既存システムの説明資料や要件定義書を読んでいたくらいでした。
プロジェクト開始が決まってからは、チームを作るためメンバの採用活動を始めました。別会社の営業さんにお願いしてエンジニアを呼んでもらい面接をしました。面接ではスキルシートを元にそれまでの経験やスキルを確認しました。面接ではみんな、できます！やります！しか言わないんですよね、、30分程度でその人がどんな人なのかなんてわからないですよ、、なので良いエンジニアを採用できるかは運ゲーです。経験的にはあまり喋らない人が結構当たりです！黙々と作業してくれるし、問題があればすぐに報告をしてくれることが多かったです。
あとはお金の問題もあります。いくら良いエンジニアがいても単価が高いと採用できません。営業さんからこの人はシステムエンジニアなので月80万円とか、プログラマーなので月60万円とか話してました。ビジネスなので金額も気にしなければいけません。もちろん高い人ばかり雇えないので都度、上司と相談しシステムエンジニアは何人、プログラマーは何人と人と金額を相談しました。
そんなこんなで、人の採用も終わりました。5人採用し私含め6人体制でプロジェクトをスタートすることになりました。途中で採用した人が国に帰ることになったりして再度、面接したりしましたが、何とか決まりました。
チーム的には以下こんな感じです。名前は言えないので本ブログでは仮のあだ名をつけて以降のブログでも記載していきます。
○お客さん
仲間さん∶仲間由紀恵に似ているから。このプロジェクトの総監督的な立場。
PMさん∶プロジェクトマネージャだから。
○チームメンバ
ボウズさん∶ぼうず頭だから。技術力が一番高いと言われて採用した人。経験年数は15年くらい。
ウーバさん∶最初の挨拶で「私、ウーバイーツで配達やってたんですよー」と言っていたから。この人も技術力が高いと言われて採用。経験年数も8年くらい。
美容師さん∶元美容師だから。プログラマです。経験年数は2年くらい。
パーマさん∶パーマかけているから。物静かですが、以前の現場でプロジェクトリーダをやっていたりと経験豊富。経験年数は8年くらい。
メガネさん∶メガネしているから。経験年数は4年くらい。
ヒグ∶ヒグッティこと私です。プロジェクトリーダ。経験年数は9年くらい。
○私の会社のメンバ
優男さん∶優しく時には厳しい。尊敬する私の上司。会社内では課長的な立場。このプロジェクトではアドバイザー的な立場。
他にも登場人物はいるのですが、その時、都度、紹介していきます。
そんなこんなでプロジェクトの開始が本来よりも2ヶ月ほど遅れてしまいましたが、8月の下旬から開始となりました。
まとめ
- プロジェクトを開始することは大変。
- 見積もり作成は基本無料（何回でも）でやる。
- Sierは会社の帰属意識が薄れがち。良くも悪くも自由。
- メンバの採用は運ゲー。物静かな人は期待している。