# 数億円規模のプロジェクトをたった二人で開発させられた話
先日、関わっていたプロジェクトを抜けることになりました。
原因はもちろん炎上によるものなんですが、これがもう炎上すべくして炎上したようなぶっ飛んだプロジェクトでしたので、 ここで吐き出させて下さい。
この記事で書かないこと
- 個人・企業・団体などの個人情報
- 契約など法律に関わること
# 20数名のメンバーの一人だったはずが、いつの間にか総勢一人になっていた
僕の仕事のスケジュールに空きができ、週３日程度の仕事を探していた頃、Twitterから開発案件の依頼がきた。
内容はよくあるシステムのリプレース案件。
開発メンバーは既に５人程度集まっており、その後２０人ほど合流するとのことで、総勢２０名以上の開発メンバープロジェクトだ！こんな規模の新規開発なんて初めてだからワクワクするぞ！
と思っていたら、PHPの案件なのにほとんどがJavaの人だったのでメンバーとして数えられず、参画する前に去っていってしまった。
合流すると言っていた２０人の話もいつの間にか無くなってる。
更に、追加で集まったメンバーにはプロジェクトの話題をしない。 いったいこれは何のために集めたチームなんだ？
結局、いつのまにか僕一人だけが開発メンバーということになっていた。マジか。
TIP
他社の見積りでは数億円規模と見積もったものを、4分の1の価格で半年で開発するという話。
もともと今回の依頼者が納品したシステムだったため、既に内容を把握しているのが強みとされていた。
# SNSで開発者を募集するも大スベり
いくら依頼者が開発に参加するとはいえ、僕も集められたメンバーのうちの一人であって、総勢二人で開発なんてできるわけない。というか提供できる労働力はせいぜい月100時間程度。
とにかく人が集まらないと始まらない。依頼者もTwitterでエンジニアの募集をかけた。
しかしこの発言内容が最悪すぎた。
「時給なんて保証に甘える技術者は不要。超絶ブラックな環境で血反吐吐きながらでも、お客様に寄り添ったものを開発できるやつだけ応募してこい」 ※要約
この時代錯誤な発言が凄惨な程に大スベり・・・ｗ
そのカリスマ性で人気を博していた彼のタイムラインが急にシーーーンと静まり返ったのがタイムラインからでも手に取るように感じられた。 このご時世に全く刺さらないどころか、取り返し付かないレベルのミス。
「たくさんのご応募ありがとうございました。」
って言ってたけど、応募はもちろん０。俺も正直言って全力で逃げ出したかった。
けどまぁ、自分でもスベってるのに気づいて意気消沈してる依頼者を見たら、 ここは俺が支えてやる！ とか、 ここで逃げたら漢の恥！ とかいう謎の正義感というか同情心が湧いてしまい、残ってしまった。
結論から言えば残ったのは大失敗でした。
後日談
稼働できるのは80〜100時間だって言ったのにいつの間にかフルコミットする約束したことになってた。
ここで得た教訓
- 仕事に情を持ち込んではいけない。
- 炎上するのがわかっているなら、絶対に興味本位で近づいてはならない。
# 集まったメンバーを紹介するぜ！
最終的に、地元で知り合ったエンジニアさんに泣きつき、なんとか人が確保できた。いやできてない。
- PM - 依頼者
- 設計 - １名
- 開発 - ２名（Masaki含む）
まてまて、億の規模だぞ。開発者二人ってどういうこと？当然この後メンバー増やすんですよね？
PM「このメンバーが揃ったらもう安心だ！ガッハッハ」
PM「俺も開発には参加するからね。」
え、人を増やさないつもり？ガチですか？？？
いくら募集がスベったからっていじけてる場合じゃなくない？？？
なんか作戦があるんかな。 まぁ俺なんか集まった中でも一番のペーペーなわけで、百戦錬磨のベテランエンジニアであるPMが大丈夫と言ってるんだし、俺が口を挟む場面でもないんだろう。
後日談
結局秘策も作戦もなく、普通に僕がフルスタックにタスク抱えることになり、 何度も人を集めてくれってPMに訴えたんですが、 結局もう手遅れになるまで人員の追加はされませんでした。
手遅れになってから人員追加しても遅いんですよ。手遅れなんだから。
# デメリットの大きすぎた技術選定
ひとまずメンバーが集まった！顧客企業さんに赴いてキックオフもされた！何故か15人も開発陣がいることになってるけど。
さぁ、次はどう動く？
3日ほど音沙汰なし。
おかしい。半年で数十の機能を揃えなきゃならないってのに、出だしが遅すぎるんじゃないか？ 技術選定もまだだし、現行システムの共有もされてないし、タスクの割り振りも説明もなんもなし。
せっかちなMasaki、さすがに耐えかねて聞いてみる。
僕「見本というか、使いまわせるプロジェクトのテンプレ的なソースはあったりしますか？」
PM「・・・（無視）」
僕「現行システムのソースとかあれば共有いただけるとありがたいんですが・・・」
PM「・・・（無視）」
後で気づくんですけどこのPM、肝心な質問は全部スルーするんですよ。しかも重要なことを何も決めない。
その割にアメリカのン千万の案件を取っただとか、今朝は3時間で仕事を終わらせたなんてツイートはせっせとしてる。 いやいや、これあなたのプロジェクトですよ。誰がマネジメントするんですか。
とにかく、このまま待っていても埒が明かないので、こちらで枠組みを作って提案してみることにした。
以前にPMがLaravel+Vueでやりたいと言ってたので、ボイラープレートを使って見本を作って見せてみた。
僕「例えばLaravel+Vueならこんな感じのが作れますが、開発実績のあるテンプレなどがあるならそちらの方がいいかもしれません」
PM「これで行こう（即答）」
正直、Laravel+VueのSPAはメリットも多いけどデメリットも多い。 SPAの管理画面はあくまで僕が開発実績として持ってるというだけで、あくまで提案段階のつもりだった。
例えばCakePHP+jQueryとかの枯れた技術だけどみんな使えるフレームワークがあるならそちらを採用してくれてよかったんだ。jQueryも扱えるんで。 他にないならこれでいくつもりではあったんだけど、まさか議論もなしに決定されてしまうとは思わなかった。
で、結局Vueを扱えるのは俺だけという事態になり、デメリットばかりが目立つ結果になってしまった。
TIP
Laravel+VueのSPAで開発をするメリット・デメリット
# メリット
- バックエンドとフロントエンドで分かれているため、分業しやすい
- APIを通じてデータのやり取りを行うため、比較的ソースがスッキリしやすい
- ページの読み込みが発生しないため、高速に動作する
- モダンなUIが提供しやすく、見た目的に顧客を満足させやすい
# デメリット
- MVCとは思想が異なるので、慣れてないと開発が遅くなる
- Vueの学習コストが高い
- 扱えるエンジニアが少なく、単価も高い
後日談
ちなみにこの技術選定も俺が決めたことにされてたらしい。
提案するのと決定するのとでは全然意味が違いますし、 いくら俺が一人称で動くタイプだからって上長の承認も得ずに勝手に決めるようなことはしません。
ここで得た教訓
- 技術選定の前に、メンバーがどんな技術を持っているのか確認する。
- 提案はあくまで提案であることを強調する。
# 先行して環境構築
相変わらず遅々として何も決まってないプロジェクト。 ただでさえ短い納期なのに、このままじゃ後が詰まってしんどくなるのは明白。
せっかちな僕としては、しんどい部分は最初に持ってきたい。 ということで、先に開発環境・検証環境の構築を済ませることを提案し、先に基盤を整えてしまうことにした。
- 環境構築の方法をREADMEにまとめる。
- Gitにアップし、開発メンバーを招待
- 環境構築の方法を全員に共有。環境ができるまでサポートを行い、その手順をまとめ
- PMに検証サーバを契約してもらい、CI/CD環境の構築
- サーバ情報をPMに共有
- 設計者さんの方も、ドキュメントをまとめるファイルサーバを用意し、設計書や仕様書はそちらにまとめる方向になった。
これはすごく正解だった。
Gitの運用ルールを押し付けてしまうことで、開発のフローを統一させることができたし、 自動デプロイがあることで、誰でも検証環境にアップができ、手順が簡単になった。
正直、Vueの辛いところってビルド時に色々とエラーが起きることなので、これを先に解決してしまったのは大正解。
一つだけ誤算だったのは、開発者でもあるはずのPMが、環境構築すらしてなかったこと。
サーバ情報も渡したはずなのに保存すらしてなくて、いつの間にか僕がサーバ管理者にされてしまいました。納得いかん。
# プロジェクトが始まるも、共有される情報量が少なすぎる。
さぁ、やっとまともに開発が出来るようになりました。
このプロジェクトは、もともとPMが開発して納品したシステムとのことで、その知見が活かせることが強み。
・・・なんですが、なんとPMがその知見を共有してくれない。
ドキュメントはもちろん、現行で動いているソースコードも、DBの中身どころかデータの構造すらも共有してくれない。
共有があったのは現行の検証環境のURLとログイン情報のみ。 いや、どう進めろと？
もちろんこちらからも情報を催促するんですが、無視される。 初めのうちは海外の案件やらで忙しいのかな―とか思ってたけど、そんなの言い訳に過ぎないし、どんなに忙しかろうと情報の共有は後回しにしないでしょ。
とにかく、現行の検証環境を確認しながらUIを作るしかない。しかし誰だこんなクソみたいなUI作ったやつは。
小言
動作を確認しながら実装したものの、ユーザーから「現行と違う」と指摘が入った。 よくよく聞いてみると、本番と検証環境で内容が違う。
現行すらも共有出来てないじゃねーか。
# PM「この機能は俺がやる」→やりませんでした。
さて、マスタ系のUIの基本形はできた。
ただ、DBの構造も仕様も不明な状態で組んでるので、何故この作りになってるのか？何故編集できない項目があるのか？など不明点がいろいろ出てきます。 UIをモダナイズするのは良いとして、DBはできるだけ現行に合わせておきたいし、そこが流用できなければこのチームで受注したメリットが一切ない。
そこで内部ミーティングでPMに確認です。
僕「ここの項目は編集不可となってますが、どういうデータ構造になってますか？」
PM「あーそこは結構複雑なんだよ。このマスタに関しては俺がやるから置いといて。」
うーん、欲しいのは現行のDBなんだけど・・・と思いつつ、PMがやるというのでおまかせすることにして、担当者に設定してガントチャートに線を引く。
メイン機能に関しても、やはり複雑な機能は自分がやるというので、それもPMを担当者にしてガントチャートに線を引いておく。
さて、ガント上で着手日になっても動きを見せないPM。
僕の感覚からしたら、触ったことのないソースはまず 編集→アップロード→デプロイ までの手順を一通りやっておかないと、 変なところでつまづくし、無駄な時間を消費するが、もちろんそんなことをやっているそぶりもない。
ってことで、心配になって声をかけてみる。
僕「例のマスタ、今週から着手になってますけど、やり方わかります？」
PM「・・・（無視）」
僕「もしVueの使い方わからなくて遅れるとかなら、HTML渡してもらえたらUI組み上げるくらいはこちらで出来ますんで言ってくださいね！」
PM「・・・（無視）」
複雑な機能ということは、複数のDBが絡んでいたり、データが他の機能にまたがるような重要な機能であったりします。 PMの担当しているマスタも、やはり多数の機能の根幹部分を担っているもので、これが完成しなければ他の何も完成しないと言っても過言ではない。
焦る。
設計者さんはもう呆れて「もう知らね」状態になってる。
とうとうガント上の締切を過ぎた。僕の方はメイン機能の開発にまで着手しており、そのマスタが関連する部分以外はざっくりと動く状態にしていた。
僕「メイン機能に関してですが、マスタが完成しないとここから先が開発できない状態です。今進捗はどうなってますか？」
PM「・・・（無視）」
もはやこれ会社員ならば無断欠勤でクビにされても文句言えないレベルでしょ。報告も連絡も相談もなし。PMが。
結局、このままでは開発が進まないので、僕が巻き取ることになった。（仕様は共有されないまま）
TIP
DB情報は後日共有されたものの、既に主要なマスタはスクラッチで作成済み。 むしろ既存のテーブルとごちゃまぜにされてしまって訳が分からないことになってしまった。 しかもマイグレーションで管理してるDBを直接いじるもんだからマイグレーションもCIもぶっ壊れた。
そして現行のソースコードは最後まで共有されなかった。
ここで得た教訓
- やると言ったことをやらなかった人間を一切信用してはならない。
- 信用できない人間とは仕事をしてはならない。
- 最初から丸投げして来るなら工数が読める分まだマシ。早い段階で「無理」と言える。
# PMが会議欠席、連絡無視して海外旅行・飲み会・トークショーざんまい
プロジェクトが始まって1ヶ月もした頃から、PMが内部ミーティングどころか顧客とのミーティングにも欠席し始めるようになった。
- その日は予定がある
- その日はアメリカです
- その日はシンガポールです
- その日は沖縄です
- 倒れてました
- その日は病院です
あらゆる理由を付けて、会議を欠席する。 こちらからの質問も無視する。 それどころか、顧客からの問い合わせを3日以上放置する始末。
倒れていたなら仕方ないかもしれない、病院もそう。けどアナタ、毎週飲み会にトークショーに海外にって遊び呆けてるでしょ。
それで 「客からの電話が鳴り止まない」 なんて愚痴ったところで自業自得以外の何物でもない。 顧客の方から僕らにまで 「PMさんと連絡付きますか？」 と連絡が来るんだからこっちにもいい迷惑。内にも外にも迷惑かけてる自覚を持ってほしい。
それでも顧客企業訪問はきちんと行ってたみたいです。 旅行帰りのその足で。
こっちの進捗を何も確認してないのに何を説明しに行くのか？って思うでしょ。情報共有してくれないからわからないんですよ。
顧客からの無茶な要求などに対して、 「このタスクは仕様が矛盾するから調整してくれ」 と頼むこともあったんですが、 PM「わかった、明日話してくるよ」 と言ったところで話してこないし、決めてこない。 「これはやらないことに決まったはずでは？」 みたいな話で顧客との認識齟齬が生まれる。
そして二言目には 「顧客に寄り添え」ですよ。
いやいや、対話もせずにただ平伏するのは寄り添ってるとは言わないでしょうに。これじゃ顧客に媚びへつらってるだけやん。
# PM「俺はPMじゃない、設計者がPMだ」→設計者「もうキレた。PJ抜ける」
一切仕事をしないPMの代わりに動いてくれていたのは設計者であるNさん。
僕の作成したUIに対して、足りない部分やこうすべきと言った指摘をくれたり、 顧客との調整や進捗の管理なども行ってくれてました。
顧客からの連絡を無視し続けた結果、おそらく 「このプロジェクトの責任者は誰だ？」 とでも問い詰められたんでしょう。 PM「PMは俺じゃない、N（設計担当）がPMだ」 と言ってしまったらしいPM。
そこから顧客はNさんに対してPMとしてのタスクを押し付け始め、 「NさんがPMなんだからちゃんと責任取れよ」 などと迫りだしました。
これにキレたNさん 「もう仕事やらねえ。契約があるから設計書は作るけど、それ以外もう一切PJ関わらないから」 と言い残し、 それから先は定期的に資料作りのために確認しに来るだけで、ほぼPJには関わることはなくなりました。
# 顧客「今月中にリリースしろ！！要件は出さないがな」
時は少し戻り、基本的なマスタの開発に目処が立ってきたところで、顧客からメイン機能の一部を先行してリリースしてほしいとの要望が出た。
関連機能の開発などもあるため、基本的にはガントチャートの流れに沿った形に進めたいけど、そこはある程度顧客の希望に対して柔軟に対応するのも必要なのかもしれない。
そうと決まればやるしかない。 基本部分の機能はおおよそ想像つくし俺が作れる、ただこちらが想定している以外の要件があるかもだし、それは教えてもらわないといけない。
僕「基本的な機能はこちらでなんとか作るので、それ以外の要望はテストの工数もあるので早く教えてくださいね。」
ってことで、大量アクセス時の挙動やデバイスごとの違いなどの品質に不安がありつつも、なんとか基本部分は動くようになりました。
僕「とりあえず動くようにはなったんですが、これ以外の要件ってありますか？」
PM「おーいいじゃん。これでいいと思うんだよね」
僕「いいんですか？顧客から指摘も指示も受けてませんけど・・・」
ダメでした。
顧客側もどういうフローで動いてるのか不明ですが、納品後にどんな機能が欲しいかのレビューを集めて要望として投げてきました。
機能追加に関しても 「ユーザが納得しなければ納品したことにならない！」 の一点張り。PMも 「お客様に寄り添ったものを作れ」 と全面的に受け入れる方針。
ただ、不具合を出してしまっていたのでこれについてはあまり強くは言えませんでした。
大量アクセス時に不安定になるであろう予想はついていたんですが、 今回は本稼働ではなくアクセス数も少ないことから一旦はこれでしのぎ、 本稼働までにリファクタする方向にしようと考えていましたが、予想以上に不安定になるしきい値が低かった。
反省点としては、タスクが全て並行になってしまった点。 UI作成、ガント上で複数機能が開発フェーズに入ったこと、 そして割り込まれた機能の開発と、全てのタスクを僕が抱えてしまってました。
まぁ他のタスクを後ろにずらしたところで、リソースが足りない時点で後から同じ状況になったのは目に見えているので、 結果的にあまり変わらなかったかも知れません。
結局、不具合箇所と比較的すぐ実装可能な追加機能に関しては対応、 画面の追加が必要なものなどに関しては対応を保留という形になりました。
ここで得た教訓
- 開発〜納品までの流れは必ず顧客との間で決めておくこと。
- 必ずゆとりを持ったスケジュールを組むこと。（余裕なんて始めから無いけど）
- 何を作るか、どこまでやるかは事前に合意を得ておくこと。
- 能ある鷹は爪を隠す。フルスタックエンジニアを自称した者は死ぬ。
# PM「やるかやらないかは俺がまとめといてやる」→全部受け入れることになりました。
いよいよプロジェクトも香ばしく炎上してきたところで、開発者Bさんの申し出で改めて内部ミーティングを毎週やることに決まり、 さすがのPMもミーティングには出るようになりました。
もはや顧客はガントチャートなどお構いなしに機能のリリースを要求、要件定義が甘いのを盾に次々に追加機能の無償対応を迫り、 不要だと言っていたものを無くしたら不具合だと言い、対応すればやっぱり別のやり方に変更。 明日までにやれ、できなければ次の日が納期といった状態で、もう僕らでは止めることの出来ないモンスターと化していました。
僕「場当たり的に出てくる要望をそのまま実装しても矛盾が生じますし、このままだと無限に対応する羽目になりますよ。」
PM「わかった、このタスクの中からやることやらないことは俺がまとめておくから」
はい、もちろん取りまとめなんてやってきません。どこまでやってある？じゃねーよ、それはこっちのセリフだ。
# とうとう俺限界。人員追加するも・・・
決まらない要件、止まらない要求、短すぎる納期、仕事しないPM...
連日の深夜・徹夜作業で体力も精神も限界になってしまい、とうとう僕は懇願しました。
僕「PMさん、これ以上無理です。無限にタスクが積まれて限界です。お願いだから月末までに要件決めてきて下さい。じゃなきゃ機能一つも完成しませんし、本稼働なんて間に合いません。」
そこで返ってきた答えは
PM「ごめんごめん、今まで無理させて済まなかった。人を集めるから。これからは俺も開発に参加するから。」
いや、要件決まらなきゃ人増えても絶対に完成しないと思うんだけど・・・まぁ増えないよりはマシだが・・・
ちなみに開発に参加するっていうから念のため聞いてみたら、 案の定環境構築すらしてなかった。 環境構築の方法から再度教えるも、途中からシカトぶっこいて、翌日には 「開発するなんて言った覚えはありましぇ〜ん」 とばかりにすっとぼけてた。 もはや平常運転すぎて驚きもしなかったけど。
そんなこんなで集められたメンバーに、残っているタスクを振ることに。
というか なんでちゃっかりPMが自分の担当タスクまでなすりつけてんだ とは思ったが、 それよりも Vue未経験の人にその機能は重いんじゃないか？ という機能を任せることになった。
大丈夫かなぁというか、無理だろうと思ってはいたけど、なにせ僕の手はもう一杯一杯なので、彼に頼むしかない。
PM「Cちゃんは天才だから大丈夫」
と太鼓判を押すし、とりあえずこっちは自分のことに集中集中・・・
納期３日前のC「進捗ダメです」
PM「Cはアイツ何やってるんだ、使えねーな」// 見事な手のひら返し
ソースを見た俺「(ｱｶﾝ)」
納期にとにかく間に合わせろというので、なんとか手を空けて手伝いに入る。。。のつもりが、 いつの間にか俺とBさんで全部巻き取ることになってた。 これ、PMが自分でやるって言ったまま１ヶ月以上放置してたタスクなんだが・・・
とうてい3日じゃ巻き返せるようなものじゃない。そもそも仕様がわからない。と思っていたら一部の仕様書をPMがやっとくれた・・・
なんだこのクソコードの切れ端みたいなドキュメントは。
どうやら現行のソースコードの一部をコピペしてコメントを入れてるようだけど、まずプログラムのコメントなのか機能の説明なのか境目が分からない。 つまり .txt にしても .js にしても使えないゴミを渡されて、これを見て実装しろってわけだ。 ソースが汚いのは仕方ないにしても、こんなゴミを渡されても解析する工数も取れない。
俺「いやこれどう考えても間に合わないですよ。」
PM「とりあえず不具合があっても動けばいいから」
それならばとBさんのフォローもありなんとか徹夜でやるも、もはやテストなんてやってる暇も無し、動いてるように見えるってところまでで終了。
PM「Masakiありがとうな、後は任せてくれ！」
といって、意気揚々と顧客企業に説明をしに行くPM。
そして帰ってきたPM・・・
PM「なんでこんなに不具合があるんだ」
いや、間に合わないし不具合あるって言いましたやん・・・
何故か俺の責任みたいな雰囲気になってるし。納得いかん。
後日談
以前に人を追加しようとした際・・・
俺「手伝ってくれそうなエンジニア見つけてきたので、参加させてください！」
PM「いやそんな予算降りないぜ？こっちも半分出してやるから折半でお前も金出せ」
ここで得た教訓
絶対に無理なタスクは巻き取らないに限る。
# 初めて仕事をしたPM！！→できませんでした（笑）
さて、リプレース案件ですからDBの移行が必要になります。
かねてよりDBが得意だと豪語していたPM。ここぞとばかりにデータ移行をやりますと申し出たので、どうぞどうぞとお任せすることに。
そして、データ移行の納期当日の朝。
いよいよデータ移行を決行します！！（ここ笑う所ですよｗ なんで納期当日まで放置してるんだｗｗｗ）
まずサーバの接続方法がわからない！！！！ｗｗｗｗｗｗｗ
Bさんを通じて僕に問い合わせが入る。 てか本番サーバの環境組んだのは僕じゃないし、てか資料共有されてるわけで、それ読んだら全部書いてあるんですよ。
何でもこっちに聞かないと動けないって駆け出しエンジニアかよ。
なんとか接続に成功したので仕切り直し。
いよいよデータを移行します！！
失敗しました！！！！ｗｗｗｗ
そりゃそうよ、現行DBくれないからスクラッチでDB書いたんだもの。 現行と互換性ないし、事前に検証もしていないのになぜぶっつけ本番で出来ると思ったんだろう。
結局データ移行は間に合わず、顧客からお叱りを受けながら、Bさんに介護をされながら作業をやったとのこと。
ここで得た教訓
- 余裕を持ったスケジュールを組むこと。
- 本番リリースの前には十分に検証をすること。
- データ移行という最も大事な作業をぶっつけ本番でやらないこと。
# クソDB
PMが初めて仕事をしたと書いたけど、それ以外にもやってくれてたことはありました。 DBの作成です。
本人もDB屋を名乗ってるわけだし、こちとら仕様も分からずUIだけとりあえず用意してる状態。 マスタに関しては画面を見ながらなんとかこちらで作成したけど、機能となるとまずDBありき、仕様ありき。
というわけで、
僕「DBないとなんもわからないので、作って下さいー！」
PM「作っといたよ（もちろんDB直いじり)」
見てみると、これ俺が別機能のために作ったテーブルのコピペじゃねーか！！
しかも着手してる機能と俺が作った別機能は関連性もない全くの別物。
僕「これどう使うんですか？使われ方が全く想像出来ないんですけど・・・」
PM「Masakiがこないだ作ってたテーブルと同じ構造だよ。」
そ ん な こ と は わ か っ て ん だ よ 。
作成したUIとの親和性もゼロだし、こっちで描いていたイメージとかけ離れたテーブル構造だから聞いてるんだ。
無理やり頭の中でデータをこねくり回しても、一向に機能が動作するイメージが湧かない。
しかしPMはこれで行けると言ってる。ベテランのDB屋が言ってるわけだ。できるんだろう。
SNSではPMがドヤ顔で「昼前に今日の仕事終わり。みんなもこのくらい出来ないとダメだよ」とか講釈たれてる。
幸いなことにこの機能は俺の担当じゃない。俺の想像力が足りてないだけかもしれない。担当者に任せるしかない。
担当者「よくわからないけど作ってみました。」
PM「なんだこのクソDBは」
なんのギャグだよｗｗｗｗｗｗｗｗｗ
# 「不具合を直すのにお金なんて払う必要ある？」
納期も残すところあと１ヶ月、ほとんどの機能は一通り動かしはしたものの、どれもこれも要件が決まっておらず仕様が右往左往し、完成してる機能は０。
一体何を作れば完成になるのか、おそらくPMも顧客も既にわからなくなってる状態。
顧客の言うことを全て盛り込めば矛盾だらけで不具合が起きる。 矛盾した仕様をまとめる人間もいない。 毎日が納期。 睡眠不足で集中力も無くなっている。
そんな中、何の脈略もなくPMからこんな発言。
PM「Xの機能なんだけど、このライブラリ組み込んだら簡単そう？」
このXとは、当初から外注に出すと言っていた機能で、今の開発チームではやらないと決まっていたもの。
言い方からは "簡単にできるものかどうか？" を聞いているように見えるが、これに答えれば自動的にこちらに担当を振ってくるのは目に見えてる。
このタイミングでこちらに振ってきたということは、今まで全くの手付かずだったわけだ。 どんな要件かは知らないが、一般的なことを言えばかなり重い。この機能一つでシステムを組むレベルだ。
僕「それ外注に出すって言ってた機能ですよね？普通にこの先ずっと手は空かないし、僕らにはできませんよ」
流石に断った。気合や根性ならもう使い切ってる。これ以上の無理は効かない。自分のケツくらい自分で拭け。
PM「何にそんな時間がかかるんだ？」
僕「品質担保のためですよ。仕様変更の連続であちこちに不具合が出てます。品質を上げるために修正とリファクタに十分な工数が必要です。」
PM,SNSにて「不具合を直すのにお金なんて払う必要ある？」
名言出ましたｗｗｗ
当たり前の話ですが、プログラムは何を作るかをまず決めなければ完成しません。
僕らプログラマーは提案はできますが、顧客＞PM＞作業員の縦割りがある以上、 上流で決めて貰わない限り、それはあくまで "PGが勝手にやったこと" にしかならないわけです。
だからこそ不足してる情報は都度問い合わせしましたし、 忙しいことを考慮して返答しやすいように、出来るところまでのUIを作り、 出来る限り2択の提案を行い、 フィードバックを行いやすいように務めてきたわけです。
睡眠を削り、嫁に泣かれながらでもプロジェクトの完成を目指し、遅れている作業も巻き取ってきたわけです。
で、そこまでやっても仕様が決まらないのだから、完成のさせようがありません。
仕様の矛盾を解消してもらえないから不具合も無くせないし、 それ以前に「バグがあってもいいから」と言われて実装を優先してきただけなので、 こんな状態の品質で出せるわけがない。
そして、その作業をやるには当然ながらお金が必要です。
早い話、自分で吸収できなかった仕事を外注するなら金払うのが当然ですよね。
チームで仕事をする以上、それぞれがプロジェクトの成功に向けて自分の役割をきちんとこなす責任があると思いますし、 末端の僕はいくらでもカバーが効くかも知れませんが、PMかつチームの決裁権者が一切仕事しないとなれば、 代わりどころかカバーのしようもありません。
支払いを渋っていた件は直接言われたわけではありませんが、金を払う気のない人間と一緒に働くわけにはいきません。
これ以上は付き合いきれないと判断し、
- その月の請求はこちらから辞退する
- 不具合に関しては、どう直せば良いか具体的に示してもらえたら対応する
- 引き継ぎの資料は用意する
ということを伝えた上で、Bさんとともにプロジェクトを抜けることにしました。
まぁ抜けると言っても引き継ぎはしますし、不具合は対応すると伝えたんですが、 その発言は削除された上で、そのままルームを退室させられてしまいました。
ここで得た教訓
- 金の絡まない仕事はしない
- 虚言・妄言は治らないので、見切りは早く付ける
# あとがき
プロジェクトを抜けてからもずっともやもやしていて、どこかで吐き出すタイミングを見計らっていたんですが、 今回やっと記事を公開することができてホッとしていますｗ
後日談も色々と聞けてるんですが、その中から少しだけ話すと、 僕らが抜けた後、程なくしてリスケを行い、ソースコードも全部捨てて仕切り直しになったみたいです。
新しいメンバーできちんと回ってるなら素直に喜ばしい限りですが、 おそらくそう綺麗に解決する話では無い気がしています。
フリーランスで活動をしていく以上、何かしらのトラブルは避けられないとは思いますし、あまりに保守的過ぎても前進はできません。
それと同時に、あくまでフリーランスである以上は自分の身は自分で守るもの。
キナ臭かったり焦げ臭かったり、異臭を感じる案件からは身を引くというのも大切な自衛手段ですので、みなさんにはぜひ習得するようにしてもらいたいと思います。
てか、書いてるうちに思い出したんですけど、 僕今までに二人ほどこのタイプの人間に遭遇したことがあるんですよ。
このタイプの人の特徴
- 外ヅラが非常に良い
- 口が達者で息をするように嘘をつく
- 異性によくモテる
- 自分の手は一切汚さない
- 責任は死んでも取らない
- 絶対に謝らない
- 世話焼きの手下を付ける
- 都合が悪くなると逆ギレする
- 金回りがいいときは湯水のごとく金を使う
- 金回りが悪くなると全力で取り返そうとする
生活の中でこのタイプの人と出会っても関わらないのが最適解なんですが、 なにせこのタイプの人の人は外ヅラの良さだけは天下一品でして、初対面から気づくのはなかなか難しい。 天性の詐欺師ですからね。
さらにしつこいからたちが悪い。過去に出会ったこのタイプの人には幾度と無く軟禁されてひたすら罵倒されるという拷問のようなことをされましたし。 これは結構濃くて面白い話なんで、またいつか別の機会にでも書きますｗ
ダラダラと長い文章を最後までお読み頂きありがとうございました。
おまけ
ミルクボーイ「メテオフォール型開発」 クソワロタｗ