＜EP_005＞社内クライアントの誕生
各部署から書類を集め終え、自席に戻った私は、まず「入力させるべきデータ項目」の選定に入った。
当然、PCの前で腕を組み、虚空を見つめているだけの私の姿は、O室長の目には「サボっている」としか映らなかっただろう。
「おい、清水。暇そうだな」
室長の冷ややかな声に、私は反射的に「すみません」と謝ってしまう。
「そんなに暇なら、これも片付けておけ」
追加の仕事を押し付けられ、私は重い足取りで本来の業務をこなしていった。
それからしばらくの間、仕事帰りの車中や自宅のベッドの上で、「何を、どう動かすか」という設計思想に延々と脳を支配される羽目になった。
悶々と悩み続ける間にも、無情に日は過ぎていく。
当たり前のことだ。本来なら数人がかりで、何度も議論を重ねて要件定義をすべき案件なのだ。それを、たった一人の「素人同然のSEモドキ」が背負い込んでいるのだ。
結局、私は仕様書の作成を軽んじたまま、入力フォームを形にして部署へと渡した。
モジュールを統合し、プログラム同士の衝突を防ぐためには、統一仕様書こそが「法の番人」として不可欠だ。
それなしでは、個々のプログラムが互いに牙を剥き、システム全体を崩壊させる。
当時の私は、そんな基本すら「自分一人で作るんじゃし、頭の中に入っていれば大丈夫じゃろ」という根拠のない自信で踏み倒していた。
広報の仕事を縫うようにして、黙々と統合プログラムを組み上げていく。
歩みは遅々としたものだったが、一ヶ月後、どうにか完成に漕ぎ着け、Kくんの部署へ「リリース」した。
これが、私の社内クライアントに対する初納入となった。
社内クライアントと言ったが、私には本来の「社外クライアント」も存在する。
広報部の人間として、本来向き合うべき相手だ。
私は、社内からは「システム構築」という重圧を、社外からは「広報としての責任」を同時に突きつけられる、板挟みの状況に陥っていた。
システムは、当初は順調に動いているように見えた。
しかし、組織の仕事は一つの部署だけで完結するものではない。必ず他部署との連携が発生する。
そうなると、特定の一部署に特化した「歪なシステム」は、瞬く間に破綻をきたす。
稼働から二週間も経つと、「おい、このシステムじゃ使い物にならないぞ」というクレームが、開発者である私の元へ殺到し始めた。
元々は、不慣れな新人であるKくんを救うために特化したプログラムだ。
彼に「複雑な他部署連携業務」などは回ってこないという前提での設計だった。
いずれ彼が成長し、そんな仕事を任される頃には、自分で管理できるようになっているだろう……という私の読みは、ベテラン勢が使う段になって裏目に出た。
業務の全容を把握している熟練社員にとって、新人向けのガチガチな制約は、ただの「足枷」でしかなかったのだ。
現場からは不満が噴出したが、一方で「ポンコツ（と周囲に思われていた）Kくんを立ち直らせた」という実績が、システムへの盲目的な期待を生んでしまっていたのも事実だ。
フォローしておくが、Kくんは決して無能ではない。
ただ適応に時間がかかるだけで、今では部署全員から頼られる中堅へと立派に成長している。
だが、そんな内情はお構いなしに、最悪の追い打ちが私を襲った。
私の窮状を知ってか知らずか、施設長から直々に「このシステムを全部署で使えるように統一しろ」という、地獄のような無茶振りが下ったのだ。
（嘘じゃろ……？）
目の前が真っ暗になった。それは、絶望以外の何物でもなかった。
