私が鬱になった経緯(2)

焦ると遅れる
毎日毎日急いでいるが、一向に仕様を確定することができない。我々開発者は仕様確定が遅れれば遅れるほど、開発のリスクが高まる。納品を遅らせることだけは絶対に許されないからだ。よって、仕様決定がスムーズに行くように顧客を誘導する必要がある。リーダーやプロジェクトマネージャーが仕様を取りまとめ、顧客や開発者に伝えるようにする。そうすることで担当者間の認識のズレが減り、組織の力をひとつの方向に向かせる事ができる。
私には、そもそも思考する時間が無かった。よって、資料作成の時間、顧客に事前確認する時間を減らすことにした。
しかし、これが裏目にでる。ステークホルダに対して十分なネゴを取らずに、会議で一発勝負になってしまう。これが原因で強く反発される事が多くなった。特に、こだわりの強いＫ氏との関係が悪化していたため、決定に至るプロセス自体がネックになってしまっていた。たとえ、正しい事を示していても会議の場で一発勝負は非常に危険である。なぜなら、皆、発言したことを覆したくない心理を持っているため、一旦反対意見が通ってしまうと、元に戻すこと自体が難しくなるからである。
これが次々に連鎖し、何をどう決めればよいのか、どんな提案をすればよいのか、全くわからない状況になっていた。

遅れを遅れると言えない状態
要件が決まらないので当然遅れているはずである。しかし、遅れを明確にすることが許されない。それは、要件定義が遅れていても、次の工程である基本設計をスケジュール通り見切り発車させるからである。それにより、見かけ上のスケジュールは要件定義が遅れていることにしかならない。普通のプロジェクトマネージャであればパンドラの箱に明ける程の決断を要するであろうが、過去に成功してきたＡ社のプロジェクトでは、常套手段だったから仕方が無いと考えていた。アサインした人の手を空けることは許されないのだ。
見かけ上、フィックスした要件定義書をもとに、見かけ上だけに意味のある基本設計書を書かせる。進捗報告では遅れは無し・・・と報告し続けていた。
遅れていると言えない理由は、すでにプロジェクト全体の動きが全く見えなくなってきていたからである。それを明確にできない限りは、ネガティブな状況報告は許されないのである。

不良在庫の山
基本設計書のレビューを開始しても、まだ要件定義は終わっていない。しかし、基本設計書が「できたこと」になっているため、顧客へレビューしなくてはならない。
要件定義の打ち合わせ地獄のさなか、基本設計書レビューをせざるを得ない状況となった。なぜなら、次のフェーズである詳細設計書の遅れを出してはいけないからである。
とにかく設計書のレビューを終わらせたい一心であったが、そうはいかなかった。内容につじつまが合わなかったり、単純ミスが多かったり、まともな資料になっていない。要件定義書に不備がある上、我々が忙しすぎて、まったく接点が無いのにまともなものができるわけがない。
しかし、遅れるわけにはいかない。レビューで顧客に怒られながら私が訂正を行っていった。

異変
この頃から体に異変が起きていた。

• （仕事の）悪夢にうなされる
• 汗かきな体質なのに手足が極度に冷える
• 手の皮がむけてボロボロになる
• 手が痺れる
• 食欲が無くなる
• 恐怖で顧客とまともに話ができなくなる
• 出社するのをためらう
• 気休めで栄養ドリンクを大量に飲む
• 仕事に集中できず、ぼーっとすることがある

そう。うつ状態だ。このときは自分がうつになるとは思ってもいなかったため、疲れているとしか考えなかった。逆にもっと頑張らなければならないときに弱っている自分を責めた。

重大な決断
この状態が２週ほどつづき、私は心の底でもう限界だと叫び続けていた。全て私が悪いのだ・・・と。こうなったら、ギリギリまで頑張っている姿を見せて、その後、責任を取るしかないと考えていた。ここでいう責任とは、「退職」それで許されないのであれば「死」である。
ある日プロジェクトマネージャに呼び出された。
とうとう私を見捨ててくれるんだと思った。これで終わりだ。終わってくれ・・・

プロジェクトマネージャの話は顧客のＫ氏をプロジェクトのメンバーから外すという提案だった。プロジェクトの混乱は彼に問題があると。私は更に混乱した。
彼らの要望に応えるため必死にやってきたのに、要望を出している側の問題があるというのなら、そもそも何をすべきだったというのか。そして、彼を外すことで、順調にプロジェクトが進むことを約束する・・・ということは私が主体でもっと頑張らなければならない。更にＫ氏以外の顧客メンバーからの仕返しが恐ろしい・・・わからない。どうすべきかわからない・・・私には決められない

私が鬱になった経緯(1)

自信に満ち溢れた日々
大手WEBサイトＡの開発でプログラマーとしてスタートし、４年後にはサブリーダーになった。その過程で様々な難題が出てきたが、全て成功できたことが、周りの信頼と己の自信につながっていく。このときの口癖「不可能といわれることを可能にする」

プロジェクトリーダー抜擢
経験と実績と人間性を買われとある大手ウェブサイト開発Ｂのリーダーを任された。このプロジェクト特徴は

• 新規顧客開拓
• 超短期間開発

である。この難題を解決する策として

1. 長年使い続けてきたフレームワークを使う前提
2. フレームワークに精通した経験者をメンバーに集める
3. 要件定義をスムーズに行う
4. ドキュメントは必要最低限にする
5. シンプルなアーキテクチャで実装
6. 難しいことは一切考えないマネジメントを行う
7. 優秀なプロジェクトマネージャが私のフォローを行う
8. 顧客の精鋭を集めることで開発リスクを抑える

今振り返ると、１以外はあまりに抽象的である。しかし、新規顧客開拓を成功させたいという情熱と期待に応えたい責任感から、積極的に引き受ける立場をとった。

要件定義スタート

まずは顧客とマイルストーンの認識合わせを行う。こちらが提示した内容で承諾されるが、一点気になった。ドキュメント作成の量と品質について、顧客が話している内容が微妙にずれているように感じた。更にアーキテクチャは顧客が考えているものが既にあり、それを引き継ぐように指示された。
前提と異なるが、新規顧客を開拓しなくてはならないため、嫌な顔はできない。
打ち合わせ後、プロジェクトマネージャと上司に相談したが、「問題ない」「仕方が無い」という答えが返ってきたため黙認した。

会議地獄
短期開発なので削れるスケジュールは全て削られている。よって要件定義は非常に短い。要件定義の関係者だけで３０人近くいるにもかかわらず、1ヶ月という強行スケジュールだ。効率を高めるために会議は分単位で一日中詰め込まれた。朝１０時から終電まで、昼食も抜きで全て会議ということもあった。
当初は決まっている要件のまとめ作業を彼らと共に行うのみと聞かされていたが、実態は全く異なった。顧客の精鋭の考えは日々刻々と変わる。外部から情報を得るたびに次々と変わってゆく。その度にシステム的に矛盾が無いか、スケジュール内で終わるのかを頭の中でシュミレーションする必要がある。しかし、シュミレーションに専念する時間は無い。よって会議中に考えるしかなかった。
このときから当初の認識と異なるため、ヤバイと感じていたが、今更前提と異なるなどと言えるような状況ではなかった。
こんなギリギリの状態で続けているため、顧客の相談に乗る余裕は全くない。顧客が決定事項やアーキテクチャの前提からずれた話をもってくる度に門前払いするしかない状況になっていた。

顧客との喧嘩
顧客の精鋭の中にこだわりの強い人（以下Ｋ氏）がいた。彼の言っていることは確かに正統なのだが、今回のプロジェクトでは時間的に不可能な要求ばかりであった。よって早期に歯止めをかける必要があったため、寝る時間を返上して彼が考えている課題に率直に回答する資料を作っていった。
翌日、彼に説明をすると見る見る顔が赤くなっていった。できない根拠を明確に示せと言われる。こちらとしては余裕がないため、その根拠を示す時間すらない。堂々巡りだ。
これを機に彼と不味い関係になる。

To be continued...

Iteratorパターン

デザインパターンのIteratorパターンだが、このパターンだけ、なぜ「数えあげる」という具体的な行為が決められているのか、どうもしっくりこない。
クラスの利用者に実装の詳細を（インタフェースで明示されたメソッドを提供することで）隠蔽することが目的なのではないか。
名前で思考の幅を狭められているような気がしてならない。

増補改訂版Java言語で学ぶデザインパターン入門

オブジェクトデータベース

来月からオブジェクトDBの評価も兼ねて社内システムの開発とのこと。Javaの開発を始めて半年くらいでオブジェクトDBを評価しなくてはならないこの現状。忙しい世の中である。
まあ、気楽に楽しもう。

クロスブラウザ

仕事に余裕ができたので
http://www.cross-browser.com/
なるページよりクロスブラウザ対応のJavaScriptライブラリを使ってみる。
非常に便利。使ってみるとわかるが、非常に簡単である。
さらに
firefox+Venkman JavaScript Debugger
を使って開発するとJavaScriptの開発効率がかなりあがる。
InternetExplorerの実装はとても適当なので、Firefoxで開発後にIEの動作確認をするのがよいと思う。

記憶力の差は優劣ではない時代

人はそれぞれ持っている素質が違う。その違いにより振る舞いが変わる。
記憶力の違いでふと思った。

記憶力が優れている者
何もかもを自分の頭の中に詰め込んでいく。そして詰め込んだ情報は自分の知識として形成する。自分の身の回りにはこのタイプが多い。日本の教育は記憶力を要求するものばかりなので、おそらく国全体でもこのタイプが多いだろう。

記憶力が劣っている者
自分の頭の中に詰め込むことができない。よって、取り込む必要のある情報のみを記憶するのではなく、考えて考えてやっと自分の知識として形成する。自分がそれだ。

良し悪しの問題ではなく、それぞれの特性を認識して改善していこう。
記憶力が優れている者は、深く物事を追求することが少ない。答えを導くことができれば終わりになってしまうことがおおいのではないか。現代は他人も持っている情報を記憶しているだけでは価値としてみなさない。深く理解し人に伝えたり、新しい発想を導くレベルに達しない限り価値が出ない。記憶力を行使しながら何事にも深く深く追求するように努めよう。
記憶力が劣っている者は、焦る必要はない。記憶力が劣っていると感じている分だけ、他の能力が鍛えられているはずである。
まずは自分の悩みや考えをどんどん発散しよう。そして脳細胞の組織を発達させるかのように、人々を巻き込みながら体外の組織を発達させればよいのだ。