私が鬱になった経緯(1)
自信に満ち溢れた日々
大手WEBサイトＡの開発でプログラマーとしてスタートし、４年後にはサブリーダーになった。その過程で様々な難題が出てきたが、全て成功できたことが、周りの信頼と己の自信につながっていく。このときの口癖「不可能といわれることを可能にする」
プロジェクトリーダー抜擢
経験と実績と人間性を買われとある大手ウェブサイト開発Ｂのリーダーを任された。このプロジェクト特徴は
- 新規顧客開拓
- 超短期間開発
である。この難題を解決する策として
- 長年使い続けてきたフレームワークを使う前提
- フレームワークに精通した経験者をメンバーに集める
- 要件定義をスムーズに行う
- ドキュメントは必要最低限にする
- シンプルなアーキテクチャで実装
- 難しいことは一切考えないマネジメントを行う
- 優秀なプロジェクトマネージャが私のフォローを行う
- 顧客の精鋭を集めることで開発リスクを抑える
今振り返ると、１以外はあまりに抽象的である。しかし、新規顧客開拓を成功させたいという情熱と期待に応えたい責任感から、積極的に引き受ける立場をとった。
要件定義スタート
まずは顧客とマイルストーンの認識合わせを行う。こちらが提示した内容で承諾されるが、一点気になった。ドキュメント作成の量と品質について、顧客が話している内容が微妙にずれているように感じた。更にアーキテクチャは顧客が考えているものが既にあり、それを引き継ぐように指示された。
前提と異なるが、新規顧客を開拓しなくてはならないため、嫌な顔はできない。
打ち合わせ後、プロジェクトマネージャと上司に相談したが、「問題ない」「仕方が無い」という答えが返ってきたため黙認した。
会議地獄
短期開発なので削れるスケジュールは全て削られている。よって要件定義は非常に短い。要件定義の関係者だけで３０人近くいるにもかかわらず、1ヶ月という強行スケジュールだ。効率を高めるために会議は分単位で一日中詰め込まれた。朝１０時から終電まで、昼食も抜きで全て会議ということもあった。
当初は決まっている要件のまとめ作業を彼らと共に行うのみと聞かされていたが、実態は全く異なった。顧客の精鋭の考えは日々刻々と変わる。外部から情報を得るたびに次々と変わってゆく。その度にシステム的に矛盾が無いか、スケジュール内で終わるのかを頭の中でシュミレーションする必要がある。しかし、シュミレーションに専念する時間は無い。よって会議中に考えるしかなかった。
このときから当初の認識と異なるため、ヤバイと感じていたが、今更前提と異なるなどと言えるような状況ではなかった。
こんなギリギリの状態で続けているため、顧客の相談に乗る余裕は全くない。顧客が決定事項やアーキテクチャの前提からずれた話をもってくる度に門前払いするしかない状況になっていた。
顧客との喧嘩
顧客の精鋭の中にこだわりの強い人（以下Ｋ氏）がいた。彼の言っていることは確かに正統なのだが、今回のプロジェクトでは時間的に不可能な要求ばかりであった。よって早期に歯止めをかける必要があったため、寝る時間を返上して彼が考えている課題に率直に回答する資料を作っていった。
翌日、彼に説明をすると見る見る顔が赤くなっていった。できない根拠を明確に示せと言われる。こちらとしては余裕がないため、その根拠を示す時間すらない。堂々巡りだ。
これを機に彼と不味い関係になる。
To be continued...
