同じプロジェクトで仕事していた外注さんが亡くなった
あまりに突然の事で僕は何も言えなくなった

胃癌の転移で亡くなった事に遺族が初めて気付いたそう

どんなに無理なお願いでも「大丈夫」
夜が遅くてキツイ日々にも「大丈夫」
その一言に安心しきって変化を見逃していた

痛くなかった筈が無い
辛くなかった筈が無い
「大丈夫」だった筈が無い

でも彼はいつも笑顔を絶やさなかった

僕はきっとこの日が来る度に自分を責めるだろう
そしてその度に彼の事を誰かに話すだろう

死んだら自分の事なんか誰も話してくれないから
僕はそうしてあげることしか報いる事が出来ない

ただ1つ彼に言いたかった事は全てが終わったら墓前で言おうと思う

「色々ありがとうございました　またあなたにお会いしたいです」

-05:30
担当アプリがオンライン開始2時間30分前に、上流からのインターフェースが終わらないし、ABENDすると言う事で運用に叩き起こされる。資産の棚卸関係情報が多すぎてB37。データセット2次割り当てが少なすぎた。最低な起こされ方をする。

-08:00
家でABENDフォロー後会社へ。

-10:00
プロジェクトの進捗ミーティング。上海チームは電話で参加。2つのプロジェクト、5つのチームがあるので、そのうち自分が掛け持っている3チーム分の部分のスケジュールと、統合テスト計画について進捗報告。PMが掛け持ち過ぎて、周りが見えなくなっていたがようやく状況を把握し始めた模様。

-10:30
自分担当分のコーディング開始。最大の難所、価格計算ロジックをコーディング。プログラムの神様が降りてこなかった為、20分程度は大苦戦。BigDecimalは面倒だ。

-12:00
いつもの定食屋で昼食。PMや同じ部署の人の会社の愚痴の聞き役

-12:45
お客様とミーティングの為、豊洲へ。前月までは川崎だったので行くのはかなり楽になった。メインフレームチームの外注さんのSE人生について聞く。アセンブラ時代からSEである大先輩。外注さんは軒並み、自分よりスキルもキャリアも年齢も上。いつも自分がリーダーやっていて恐れ多いが、「いやいや、AXISさんが開発も兼ねつつ、キチンと纏めてくれているからですよ」と初めて言われて嬉しかった。

-14:00
豊洲にてミーティング。出荷関係の要件変更と、データ移行・受け入れテストに関するミーティング。相変わらずのらりくらりのお客様に「出来るのか？出来ないのか？」攻撃。ハード関連のホスティング費用に関する宿題を持ち帰る羽目になる。

-17:00
帰社。早速チームメンバーのコーディングをレビュー。オンライン開発は経験少なめ（僕もそうだが）のメンバーの為、かなり細かく見る。やはり例外処理の甘さと、繰り返し処理の無駄が目立つ。細かく指示を出す。

-19:00
価格計算ロジックをコーディング。ここ1日、2日これにやられっぱなし。条件が多すぎるので、喫煙部屋に30分立てこもりロジックを整理する。これが一番いい。

-23:00
上流システムを開発しているU.S.チームとのミーティング。朝早かった上に、深夜に英語での会話は、多少自信があっても本当にきつい。しかし、未だに夜間ジョブ処理のスケジュールとOPCリンクすら決めていない事を聞かされ吼える。他のプロジェクトだと思って聞いていればいい気になりやがって。日本が属国ではないことを思い知らせる。対応窓口のKさんはちょっとひいていた。

-25:00
テスト計画を立てるドキュメント類を作り管理する側の仕事をするのは開発以上に頭を使う。テストケースの多さに少し眩暈を覚える。

-26:30
本日終了。別チームのリーダーと共に夕飯。二駅離れた中華料理屋（朝4：00までやっているのが嬉しい）へ行く。軽くラーメン等を食べる。この頃には疲れ切っているのであまり会話もない。

-27:00
別チームのリーダーを車で送り届け家路へ。

-27:30
家到着。嫁はぐっすり寝ている。軽くシャワーを浴びて、ベッドにもぐりこむ。寝ぼけた嫁が近寄ってきたので、頭を2，3回撫でておく。安心した顔をする嫁。寝ぼけても気遣ってくれている嫁に感謝しつつ眠りに付く。

こんな日々を送っています。

同じTeamで、「無停止メンフレ」（IBMのeServer zSeriesとかの無停止機能搭載のメインフレームの事。休みでもオンライン、しかも扱っている全てのミドルウェアに詳しい事から命名）の異名を持つKさんが、帰宅後パッタリと倒れ救急車で運ばれました。風邪＋過労だそうです。

そんなわけで、いよいよ今年も大詰め、プロジェクトも保守も佳境に入って参りました。年度末の決算処理は全世界のエリア上げてのお祭り騒ぎ。そこらかしこで、US相手にスピーカー音量大にして、英語で電話会議している光景で殺気立っております。
プロジェクトと保守が並行している同じ部署の3つのTeamのメンバーは続々とヤラレテオリマス。僕も深夜の喫煙部屋で気を失っておりました。

まだまだよわっちろいな、俺。

そんなわけで気合を入れるべく、先日更に髪を染めてみました。アッシュがかっているので、その辺の職無しのお兄ちゃんよりは真面目に見えますが、会社では十分不良です。周囲からは「グレた」と言われる日々でございます。
そんな感じの毎日ですが、恐ろしくスキルが付いてきた気はするのですね。HOSTとWEBを並行して開発・管理出来るのは暫定的に僕だけなので、ちょっと頑張る気が沸いてきます。

やっぱり小さな成功体験の積み重ねが、大いなる自信になると思うのですね。その為に今は死ぬ程頑張っております。でも救急車はイヤだな…。

纏まりのない文章ですが、今日はここまで！

僕の日記をお気に入りにして頂いている方の中でも、SE・プログラマーと呼ばれる職種の方が多くいらっしゃいます。
その方々の日記でも垣間見えるとおり、システム開発にはその開発工程に応じて様々な方が携わる訳ですが、その役割同士は非常に軋轢が生じやすい構図が存在します。

特に営業・開発・運用という見方でそれを俯瞰するとその軋轢が顕著になります。

営業の意見
「開発のやつらはさー、2言目には『技術的に難しい』だの『工数が膨らむ』だの言いやがるじゃん。もっと大きな目線でお客様の成功を考えて欲しいよな。俺たちが仕事取って来てるんだから仕事できるって事を解ってないよなー。」

開発者の意見
「営業は（お客様に）夢見させすぎだよ。技術も知らないくせに無理いうなって。安定稼動するシステム作る為には、それなりに要件を満たす以上の工数がかかるっていうのに…。『出来るか？』じゃなくて、やれるだけの金を持って来いよな、値引きばっかりしてないでさ。」

運用者の意見
「開発は作りっぱなしでいいけどさ、メンテナンスする身にもなってみろよ。ろくに仕様書も作らないで、挙句にシステムはバグだらけかよ。それを始末するのは誰だと思ってんだよ。24時間稼動？俺らはロボットじゃねえんだよ。」

システムも車と同じようにProduct Lifecycleが存在します。当然その各ステージ毎に担当者が居て責務を全うする事で、システムが初めて安定稼動するのです。逆にこういう状態が起こるのは、
?責務の範囲が明確でない（業務の完了基準が明確でない）
?それぞれの立場での（成功と定義されたマイルストーン到達の）チェックポイントが明確でない
?コミュニケーションが上手く取れていない
という辺りが主要因となっているようです。

システムに携わる会社は大抵この担当者が別の部署に居る事が多く、?は非常に難しい問題といわざるを得ません。しかし、?・?に関して言えば、「共通言語」の確立と、明確な権限責務の定義は急務であるといえるでしょう。

うちの会社はおおむね、その辺に関しては良好な関係を保てる体制と方法論を備えているのですが、やはりこの構図から抜ける事の出来るレベルまでは至っていません。
しかし、それを最小化するべく、外部設計レベルから運用担当者を交えて定期レビューを実施する等、自分のレベルで出来る範囲の事を心がけています。

こんな人も居ますので、アプリ側の人をいぢめないでくださいね（笑）

南国から帰ってきた僕を待っていたのは大量の仕事の山といろいろな問題でした。

?本番環境の不具合
自分が作ったモジュールが不具合を起こしていてその対応に追われました。まさしく自分のまいた種、しょげている暇もありません。どうも入力ファイルデータのバイナリを復元する時のエラーから始まって、DBアクセスのエラーが頻発。半べそかきながら深夜の作業が続きました。

僕は会社では設計者・開発者ですが、プライベートでは使用者になるわけで。ユーザーの気持ちもわからなくは無いですけど、「そんなデータ入れるなよー」と思いたくもなる瞬間ではあります。っていうか、データ移行の要件と実際のデータ違うじゃん！

?プロジェクト難航
後期のプロジェクトの要件の1つが肥大化し、いつの間にか新規アプリケーション開発の流れに…。お客様とのミーティングに出つつ、「要員さんどうしよう？」「コスト計算しなきゃ」と頭はマルチプロセッシング（並列処理）。
しかも、同時並行で設計までやる始末。仕様書のドラフトに埋まっていると、周囲から「大丈夫？」的な声が…。笑顔で答えてはみるものの、要件を纏めて大枠の仕様詳細に落としながら、作業を進めていくと仕様書の数がさりげなく半端じゃない事に。
でも、ちょっと「俺なんでも出来てるみたいジャン」とか深夜の会社で思う辺りが重症です。
でもこのままでは本当にマズイ。というわけで、要員計画を見直す方向で見積もりを持っていくと、プロジェクトマネージャが一言。

PM「○○○○さん（外注さんの会社）のWEB開発要員切ったから」

僕「○＃＄％＆△■＄％＆△」

ええ、声になりませんでしたよ。まあ、この期間までに何人でいくらという契約をしていたのに、要員が確保できなかったという事もあり、契約違反で切られたのはしょうがないですけど…。
一から要員計画建て直しで、かつ僕の設計作業は何時まで続くのかも見通し立たず、目の前が真っ暗になる感覚を覚えました。

幸い僕の所属部署から（泣きついて）人を確保し、部署のリーダーも別の外注先を探してきてくれました。これで一安心…かな？

よく「悪い事は重なる」って言いますけど、本当に重なるものです。来週からもがんばっていきます。

今回のプロジェクトは今まで避けてきた（笑）、海外のチームとの協働プロジェクトです。開発はUS、実ユーザー・オペレーションはUzbekistanと、なかなか香ばしい基幹システムとインターフェースを持つシステムを作るのがメインの要件です。

なぜ避けてきたかというとですね、英語が…。いや、嫌いなわけじゃないんですよ、人並みに話せますし。でも、実務用語が解らんのですよ。

問題：「（実地）棚卸」「減価償却」を英語に直しましょう。

…10秒の思考時間

解答：「(Physical )Inventry」「Depreciation」

やっぱり英語は使っていないと日々衰えていきますね。この10秒に改めて日々の鍛錬の重要性を思い知ったのでした。
まあ、でも昔取った杵柄といいますか、三つ子の魂百までといいますか、Telephone Conferenceを数回やる内に、段々スラスラ出てくるようになるんですね、不思議と。

最近では、US Teamで僕の要件を担当してくれている、通称Jazz SingerのClarenceさんとは、Meeting前に「Miles Davisは"kind of Blue"の時が全盛期か？」という世間話をするぐらいまで回復しました。

英語は中級レベルで重要なのは勉強じゃなく、「集中力」と「慣れ」なのだと不思議な感慨に浸ったのでした。

子供ができたら、絶対英語を習わせようと思う今日この頃です。

後半のプロジェクトがまさに始まろうとしていた矢先、前のプロジェクトのプロジェクトマネージャであり、ディズニー好きの子煩悩のKさんの下に一通の郵便が届きました。
送り主はプロジェクトのオーナーでもあるお偉いさん。封筒には一言、「チームの皆さん、本当に感謝」と書いてありました。

「うまいものだといいなー」
「食べ物を普通便（社内便を経由していた）で送りますかね？」
そんな話をしつつ、Kさんが包みを開けると・・・。

「感謝状？」

そこには小さな額が4つ、そしてその額の中には『感謝状』が。今回のプロジェクトが、自部門のビジネス、ひいてはお客様のお客様にとって大きなベネフィット（利益・利便）をもたらしたと書いてありました。

関連会社を相手にしているうちの部門では、感謝されるという習慣があまりありません。これはどのお客様にも当てはまることですが、結局「お金を払って仕事しているのだから成果がでるのは当たり前」と考えるのが普通なので、感謝等あまりある光栄なのです。

ただ、万人がそう考えるとは限りません。「こんな紙切れ1枚で休日も睡眠も犠牲にした日々が報われるか」と思う人も居るはずです。もしそう思うのなら、僕はシステムエンジニア・コンサルタント問わず、サービス業で働く事をお勧めしません。

システムエンジニア・コンサルタントは常に二つの利益を考えなくてはなりません。「お客様の利益」と「自社の利益」です。お客様から頂いたお金で仕事をするのは「自社の利益」の為であり、やって当たり前の事です。しかし、ある種のROI（投下資本回収率）を考えた時、その当たり前に「お客様の利益」が入ってくるのです。

その精神はボランティアに近いものがありますが、これを考え、当たり前の事としてその実現に注力する人間こそが、本当の意味で『報われる』のだと僕は思っています。

ちょっと纏まりがないですがこの気持ちがうまく伝わっていると嬉しいです。

先日、今年前半のプロジェクトの慰労会がありました。
自分の父親ぐらいのユーザー部門の方（後に本社の理事さんだと判明）と、サーフィンの話で盛り上がるという予想外の事態もありつつ、楽しいお酒を飲む事ができました。

その時にふと気付いてしまったのです。
僕はこのプロジェクトに関しては、どのようなタスクであっても、与えられた期限とリソースの中で最大限、お客様の事を考え、とにかく真摯に自分も納得行くまで取組むようにしていたのです。
でも、実は、お客様が一定の満足感を得られたならば、それ以上の努力は、費用（工数？）対効果が悪くなる、ということに気付いてしまったのです。勿論、その飲み会のように、頑張ったら頑張ったなりに、心境的には「良かったよ」というような差を感じてもらえるにせよ、一定の満足ラインを超えたアウトプットの差は実は、自分にしか分からないのだという事なのです。

この事は言い換えると、自分なりにある程度の時間と工数を掛け、最善であると信じてやってきた事も、そういう他者の評価との「臨界点」に達した後は、あくまでも「自分がこれだけやっているのだから良い物にちがいない」という自己満足に成っているという事に他ならないのです。

これって高校のバスケ部時代にやっていた、基礎トレーニングに似ているなと思ったのです。走力強化の為の持久層やドリブル等、自分に適正な負荷が掛かっている分には、その成果が自分にも試合にも見える形で現れてくるのですが、ある一点を超えると、疲労が蓄積したり、最悪怪我をしたりしてしまうのです。

元々、（仕事に関しては）何でもキッチリやらないと気が済まない性分の自分としては、これは非常に画期的な発見でした。
こういうと不真面目に聞こえるかもしれませんが、プロジェクトの作業でも「これはあんまり誰の為にもならないな」と思う時は、そのシーン固有の及第点を取れる「臨界点」でセーブし、わざわざ、嫌な思いをして無駄な努力をする必要はないのかもしれないと思うのです。
日々が自分との葛藤に成り立つ今の仕事の中で少し癒される発見だと一人想うのでした。

ようやく開発したモジュールが本番環境で稼動し始め、プロジェクトが終了しました。
昨日まで苦いとしか思えなかった、安いカップのコーヒーもプレミアブレンドに、眠気を避ける為に吸って咽るだけの煙草も、格調高いものに思えるから不思議です。
朝からお疲れ様メールが部署の上司や仲のいいお客様から来ていました。たったこれだけの事で、癒されてしまう自分が安いなーとか思ったりするのですが（笑）

今回は要件定義から移行までのほぼ全ての仕様書・設計書を1人で書き、1人でコーディングし、1人でテストしてきたので、本当に多くの事を学んだ気がします。
知識を売り、カタチにしていく仕事だからこそ、「学ぶ」という自己研鑽の大切さを改めて知ったような気がします。
今週は泥のように眠りながら、後半期のプロジェクトに入れたらいいなと思いながら、仕事で遅い彼女を待ちながら、1人発泡酒で乾杯の夜。

本体プロジェクトのシステム監査も漸く終わり、いよいよ、残存テスト項目の消化と本番環境への移管を残すのみとなりました。
これが終われば、システムテスト終了を以って自分で開発したモジュールの移管をし、プロジェクトがCloseになるわけです。

でもですね…出て来ましたよ、爆弾が。不発弾。

本体プロジェクトは現行システムの改良だった為に、要件定義の段階でいきなり機能を詰めていました。という事は、テストケースが要件の前方向を網羅していない可能性があるわけです。僕は本体プロジェクトに関して、最初から関与していなかったので知らなかったのですが、システム監査で色々調べていくうちに気付いてしまったのですよ。

もうね、何も言う気力が起きませんよ。

システムを開発する際には、様々な設計書を書く以前に、要件定義をします。これはお客様が持っている「システムにはこんな事をさせたい」という要求を、プロジェクトで開発する範囲としない範囲に分け（お金とか人員の都合も勘案して）決定するわけです。
要件が網羅されているかは、一番最後のテスト（システムテスト、受け入れテスト）でケースを作成する際の最重要項目です。
これで漏れがあったら目も当てられません。

怒涛の勢いで唯一の要件定義資料を見直し、ケースを書き起こしていきます。
そうすると出てくるわ出てくるわ、テスト漏れ項目が。
そして出てくるわ出てくるわ、バグが。

もう、ある意味「祭り」ですよ。

これが開発の現実なのです。次回のプロジェクトではリーダーになるので、Project Managerに同じ愚は冒さないよう諌言していこうと思ったのでした。

■報告資料が多くて纏めるのが面倒なんじゃないかと、部署のリーダーに言ったら、何とかしてとの事。藪から蛇とはまさにこの事です。
その日のプロジェクトの開発がそこそこ一段落した深夜、グループウェアの開発環境を立ち上げ速攻で開発してしまいます。簡単なものであればそこそこすぐ作れるようになってきたし、技術力が上がってきた事を実感しつつ、朝を迎えるのでした。

■モジュールを開発しつつ、単体テストの仕様書を纏め上げると、当然問題になるのがテストデータ。ハァ…。

■0時を過ぎると俄然集中力が上がるのでヘッドフォンで音楽を聴きながらコーディングをしています。最近の2時過ぎに聴くお気に入りは、宇多田ヒカルの「誰かの願いが叶うころ」。なんだか心穏やかに仕事が出来るので気に入っています。

■uefa.comのスポーツ速報はプロジェクト中の心のオアシスです。EURO2004が始まる頃には転居して、完全にBSがPCで見られるようにしたいと思う今日この頃。その時間に家に居られればの話ですが…。

「おっ、MQにQue入ってるよ」

早朝にホスト側の開発マネージャにMQを確認してもらった所、Queに過不足無くデータが入っているとの知らせを受け、ホッと一安心。
これで追加された要件の対応作業は終了となりました。空白部分だったテスト仕様書の結果データを書き込み提出。後は確認を受けるだけの状態となりました。
無事期限通りに仕上げ、なんとか本体プロジェクトの統合テストにも間に合いました。

最近解ってきたのは、コーディング能力が無いなら基本的なアイデアでカバーし、納期を守る方が遥かに「イケてる」という事でした。正直な話、自分はコーディングに関してはあまり創意工夫の乏しい、単純なコードを書く方だと思っています。ですが、創造的なコードは創造的な人しか保守できない事も事実であり、納期を守る事や品質を一定に保つという事に、多分に反する部分があります。
僕は「納期を守り」「要件を満たし」「保守も容易」なシステムを作る人が「プロ」なのかな、と考えています。
兎角開発ばかりに目が行きがちですが、保守も兼ねている部署だからこそ学べる事なのかな？と考えていました。

というわけで、今日は早めに帰ってきました。まだNews23やってるし。
明日からはまた、自分が担当している別要件の内部設計と開発が始まります。この仕様変更の作業が予想外であった為、スケジュールのバッファも、もう残り少なくなってしまいました。
たまたま煙草を吸う時に鉢合わせた部署長曰く、「予定が遅れないようにするにはどうしたらいいと思う？期限を延ばすんだよ」などと信じられない事を言っていたので、愛想笑いで返しておきましたが。

明日からまた頑張っていく為に、今日は少しゆっくりしてもバチは当たらないよね、と思うのでした。

今日は朝からかなり香ばしい展開でした。

他人事でフンフン聞いていたプロジェクト本体の仕様漏れの話、とうとう僕の所に作業依頼のメールが飛んできました。しかも大量に。
仕様書を確認してみると、上海の開発担当者に英語の説明メール書くより、手近の自分に話した方が明らかに早そうな仕様でした。
僕の担当する別要件の内部設計が、意外に進捗が早い事を見越しての止むを得ずの救難信号。朝からスマンという顔しかしないマネージャを宥めつつ、ソッコウ作業に取り掛かります。

大急ぎで各仕様書をガッシャンガッシャン、プリントアウト。
仕様書を画面で見るのは目がツライので紙出しです。
ホスト（メインフレーム）で稼動するプログラムにデータを渡す部分を除いて完了すれば良いとの事。見積もりでは数十箇所程度の既存Javaクラスの簡単なコード変更と考えていたのですが、データを渡すホストのMQ（※1）レイアウトの確認等に、予想以上に時間が掛かってしまいました。

確認が出来てからは、怒涛のコーディングと単体テストです。
来るなら来てみろ、条件網羅（※2）。
…とはいうものの、量的な問題は避けられず深夜作業へ。
深夜のメリットは、妙なテンションでお仕事が何故か捗る事にあります。人によっては歌い出す、小人が見える等のなかなかファンキーな効能（？）があります。
まして今日は金曜日（っていうか土曜日になってますが）、明日は（僕は）寝てられるという事から、テンションは否が応にも上がります。

しかし、深夜作業のデメリットもあります。
それは「集中力の低下」。

早朝。今日消化分の開発も終わり、テストも気合でクリア。
テスト方法・結果の文書とコードの改修ログを提出し、後はサーバにコードをアップするだけ。
ファイルアップをクリックして、背伸びを1つしてコーヒーを買いに自販機へ。
終わった〜という安堵感が漂います。
暖かいコーヒーを飲みつつ、席に戻ると…。

「あれ？」

確認しようとファイルを数個開くと、そこには変更部分が消えたコードが…。
もうパニックです。
というか言葉にもならない。
自分ではサーバにファイルをアップロードした筈が、自分の開発機にサーバの（変更前）ファイルをダウンロードしてしまったのです。

一瞬、頭が真っ白になりました。

結局、開発環境がコードのログを取っている事を思い出し、手違い以前のコードを復元し事無きを得ました。しかし、一部の圧縮したファイル等は元に戻らず、再度面倒な圧縮等の作業をするハメになりました。

【今日の勉強】
深夜の作業では、ポイントになる作業は一服等して集中力を取り戻し、細心の注意を払うべし。っていうか深夜作業は極力避けよう。

（※1）異なるシステム間でのデータのやり取りを、安定して実行、尚且つ管理までしてくれるステキなもの。
（※2）ある処理が行う可能性がある全ての条件で動作をテストすること。条件が異常に多い場合はその洗い出しが大変。

今日はお世話になっている部署に新人さんが来ました。
昨年入ったNさん（数日前の日記参照）の事もあり、かなり戦々恐々としている人も居ましたが、どうも普通そうな人で安心したようです。

…と、こんな事があれば、「自分の入社したてを思い出して…」とか書くのでしょうが、そんな事を考える余裕すらありませんでした。レビュー後に、お客様より相次いで届く外部仕様の変更要求。検収してもらうまでのガマンであります。

閑話休題。

この仕事に従事している方は薄々（というかほぼ明確に）感付いている方も居られると思いますが、もう数年すれば、一部の天才プログラマを除き、日本のプログラマは激減するはずです。理由は1つ、コスト競争力です。単純に日本人を雇うのは人件費が高いという事に他なりません。
インドは昔からオフショア（海外拠点）開発で有名でしたが、最近は中国や東南アジア等、様々な国がコスト競争力にものを言わせ、様々なIT企業の外注先になりつつあります。

上海の外注さんと時々会話する度に、そんな事を考えつつ、バベルの塔をぶち壊した神は、自分の保身の為にとんでもない事をしてくれたと感じるのでした。

−09:15am

今日はお客様とのミーティング。
一足早く川崎駅に着いたので、大急ぎで近くの喫茶店に入り、メールで送られた機能要件を素早く資料に落としていきます。
これで画面の仕様も固まり、内部処理に伴う制約条件に関してもご理解頂ける。この日の天気同様、上出来とも言える朝を迎えました。

−10:05am

プロトタイプと内部処理の仕組みのご説明を…何故か僕がしています。

本来ならプロジェクトマネージャが説明差し上げるのですが、既存システムの緊急保守で行けなくなったので頼んだとの事。直前の事で久しぶりに変な汗が背中を伝わっていくのが解りました。

でも、そこは頑張り所と踏ん張って、プロトタイプの画面を動かしつつ説明をしていきます。画面の方は使い勝手の点で、かなりお客様のご要望を引き出す事が出来ました。
この機能に対するお客様の改善要望の高さを実感した瞬間でした。
その後の説明も、基本的にWeb側の処理の仕組みは、自分1人で設計している為、それ程問題なく説明を行えました。幸いホスト側の開発マネージャにも同席して頂いていたので、データ周りの話も難なく進みました。

−01:12pm

プロジェクトマネージャが川崎到着。お詫びにトンカツをご馳走してもらいました。開発マネージャも「危なげなかった」と何故か少し満足げ。とりあえずは良かったと胸を撫で下ろしたのでした。

−02:16pm

会社に戻る電車で熟睡。ディズニーランドに行きたいな、と車窓を見ながら思い、また眠りについていました。乗り過ごし寸前で電車を飛び降りました。あぶないあぶない。

−04:40pm

怒涛の勢いでプロトタイプを修正。JavaScriptとHTMLを怒涛のように打ち込み、設計書をあらかた書き直す事に没頭。
こうして突然の緊張の1日は、ちょっとした充実感を残し、またいつもの深夜作業と共に暮れていくのでした。

たまには自画自賛もいい…よね？（笑）

近くの中華料理屋で夕飯を食べに行って帰ってきた0:15am。
どうも、自分の席に帰ってメールを見たらしいKさんが項垂れていた。Kさんは非同期処理の部分のプログラムをメインフレーム側で作ってくれているナイスガイ。原因はとりあえず解っているが、一応聞いてみた。

「どうしたんですか？」

「あのさ、例えばの話ね。ある夜バッチのプログラムが稼働日の日付をファイル名にして何らかのログを残すとするよね。で、翌日のバッチタイミングの時に、そのファイルを参照するとするよね。そしたらファイル名は何を指定したらいい？」

「…単純に考えたら、その日の前日の日付かそれを持つ変数ですよね。」

「それをヤツは4回説明しても解らないんだよな…」

Kさんの悩みの種は、通称「トリ」さん。「トリ」さんは僕がお世話になっている部署に昨年配属されたのですが、とにかく仕事が出来ないと評判です。特に以下の3つは良くないところ。

?同じ事を数十回繰り返して質問する。
?問題に対して自分で考えようとしない。
?自身の仕業で発生した問題を隠蔽しようとする。

ウチの同期にはなかなか居ない（というか絶対居ない）タイプの人なので正直驚きの連続です。今は仕事が被らない（というか仕事を振られない所まで来ている）ので、傍観者の視点で見ている傍ら、業務の指導をせざるを得ないKさんが不憫でなりません。

そして他人事ながら、今年この部署に入ってくる新人は全て院卒の優秀な方との事。「トリ」さんの仕事が、宴会の幹事のみにならない事を祈るばかりです。

先週からテスト環境を設定して以来、実はかなりの時間を費やしたのはコード解析でした。これには色々な深い事情がありまして。

今担当しているシステム開発は大きく分けて、メインフレーム（超大型汎用コンピューター）側とWebアプリケーション側の開発に分かれているのです。Webアプリケーション側は現在中国に開発をお願いしているのですが、設計書らしきものが無いんですね…。
その話を先輩にすると、「Javadoc生成すればいいよ」との事。
確かに今動いているコードは嘘はつきませんからそれが妥当なのですが。どうして設計書が無いのかは敢えて聞きませんでした。

設計書は謂わば、プラモデルで言えば組立説明書のようなもので、それさえ見ればどんなパーツや手順でモノを作ったかが解る様な重要なドキュメントです。
ただ、これだけだと「コード書くためのメモ」と勘違いされ、「コーディングしちゃった方が早い」なんて事になりかねません（研修中は僕もこんな感じでした）。
これだと、今回のパターンのように既存システムの機能変更の度に担当者が、エディターとニラメッコで1日を費やすなんて事になりかねません。
取り敢えず、スケジュールが余裕の内にコード解析を黙々とやっていこうと思います。

【今日の勉強】
設計書は意識合わせの為にも、後の人のためにも重要。信じられるような設計書はきっと後々役に立つ。

要件定義のヒアリングの為、朝から川崎でした。
今回の開発で僕の担当する要件は、現存するシステムの「ここが使えないから何とかしてくれ」と発生した機能の開発なので、ミーティング自体は確認事項に頷いて頂くだけの簡単なものとなりました。

システムの開発のステップはすごく大雑把に分けると「要件定義」「設計」「開発」「試験」「移行」に分かれます。「要件定義」はお客様の「こんな事をしてもらいたい」という要望をお聞きする、開発の中で最も重要なステップになります。
まして、今回の様に全てのステップを自分ひとりでやる事になると、尚更要件をきちんと把握する必要があるわけで、それはもうこの上ないぐらい緊張して望んだわけです。

ただ、今回先輩から、改めて学んだ事は「これは出来ません」という事も明確に定義しておくのは大切な事だという事。
ここをきちんと明確にしておかないと、後で「これはできないの？」なんて事になり兼ねませんし。1人で全工程をこなす以上、そういう事態に陥った時、自分でRecoverしなくてはイケナイわけですから、尚更真剣に確認を繰り返したわけです。

今週以降は設計の基礎の確認とプロトタイプの作成に多くの時間を費やす事になるでしょう。研修で学んでいない技術も多いし、勉強しないといけないなーと思いながら、帰りの東海道線で眠りこけていました。

【今日の勉強】
「要件定義」は出来る事だけでなく、出来ない事も明確にする開発にとってとっても大事なステップ。

研修も終わって明日からは仮配属になる。
家が近くていいけど、流石にJavaの開発に投げ込まれるのはいささか不安感が募る。
暫くはFORTRANとCOBOLの相の子みたいなPL/1の研修を受ける事になるが、インターフェースやビジネスロジックはJavaでの開発になる。WSADはEclipse以来の使いこなしっぷりなので大丈夫だとは思うのだが…。
でも、研修がそのまま仕事に転用できるなんて今までなかったなーなどと感慨に浸りつつ、明日以降一生懸命頑張ろうと思う。

それと同時にDB2エンジニアもWSADのディベロッパーの試験も間近に迫っているし、ソフトウェア開発技術者も地道にコツコツ。
転属して以来、必要とされるスキルが変わった分、自分も変わっていかなくてはと思い必死にやっている。今までのコンサルタント案件の経験はどうあれ、それらの結果を出してないから今は何も言えないけど。
お客様に変わる事を強いるなら自分が変わらなきゃ説得力無いでしょう、って思うんだけど。

今は自分の納得できる結果を出すまで一生懸命努力していこう。不言実行。その方がカッコイイ。

漸く長かった研修も今日で終了。本当に長かった。
UMLで作成したプログラム仕様書と説明資料、ExportしたWebプロジェクトをJARファイルにして一式纏めて、同年代のAdvisorに提出した。DBのスキーマも作っておいたし。
今回の研修で、改めてどれだけ自分がITやその周辺に対して無知で、それがどれだけDeadly Woundだったかを気付けただけでもかなり収穫だったと思う。

終業後は入社月の違う同期の打ち上げに参加。
入社月は違っても同じ大規模プロジェクトに居た仲間も、個人的な知り合いも多く、打ち上げというに相応しい飲み会だった。
個人的に平日飲みに行くとかという事はキライで、何かの節目や何がしかの達成感を得た時にワイワイ飲むのが好きだったりする。だって、しょっちゅう飲んでたら有難味無いじゃん。

そして、研修で再認識したもう1つ確かな事。何であってもQualityに関しては妥協してはいけないと思う。「必要最低限で十分」という事程見苦しい事は無い。最低要件を期限内で充たすのは当たり前。Delayするのが解っているなら、それを吸収するに足るBufferを自分で作っておけばいい。
その上でQualityが保証できる事が自分のスキル内、知識内に無ければ学べばいい。

何はともあれ色々お疲れ様みたいだ。言ってることも支離滅裂だし。今日は少しゆっくり寝るとします。