とあるＳＥ（システムエンジニア）の奮闘記
この短編小説は職業小説企画参加作品です。
ごくごく普通な(オタク要素含む)21歳の青年が、仕事を通して感じた自分の職業について考える。僕はこの会社で頑張ってやると意気込む物語。
この物語は実話を元にし、少しファンタジっぽく仕上げたフィクションです。
趣味でファンタジっぽく仕上げていますが、展開等は現実世界と同じような書き方をしています。
また、一部登場人物の会話の中に専門用語も含まれていますので、予めご了承下さい。
それでは、職業小説企画 短編『とあるＳＥの奮闘記』始まります。
僕はシンジ・シラカワ。
ＦシステムズというＳＥ会社に勤めている。
年は21で情報科学校の高等部卒業後にここに就職した。この4月で丸3年。社会人としては4年目に突入した。
入社当初は周りから若きＳＥと言われていたが、まだまだヒヨッ子でＳＥと呼べるのか怪しい4年目だ。
ちなみに、僕が就職したこの会社。この世界では結構有名な会社の子会社である。
Ｆシステムズは科学と魔法学の二つを活用したシステム開発が行われ、僕が勤める子会社ではそのシステムの適用やカスタマイズと言った作業を行っている。
余談になるが、僕たちＳＥは開発を行うＳＥと、各ユーザを回ってシステムを適用していくＳＥに分かれる。
そして僕たち各ユーザを回るＳＥのことをフィールドＳＥと呼んでいる。
―Ｆシステムズ・6Fオフィスー
ここは僕が配属された医療チームのオフィス。
といってもこのフロアの半分以上は事業部の人が占めている。
有名な会社とはいえ、ここに勤めている社員は約200名と本部に比べれば小さい。
それに、ここは大きく3つの部門に分かれていて、メインは金融、それに付随するように学校や地域福祉に関するシステムを扱う公共。そして僕が配属している医療の3部門である。
僕の居る医療には会社全体の1割しか人数が居ない部門で、同期が1人で後は全員年上。
後輩も1人居るが、その後輩も大卒で入社している。そのため、未だ部門内では最年少である。
「おい、シンジこの報告書どうなってる、見直したのか」
また、いつものことながら上司から提出した報告書で呼び出しを受けた。
「はい。見直しました」
「これ、何したかはわかったけど、次どうするだ？ スケジュール調整してるのか？」
「来週プログラムの修正をして、翌日立会いします。あっ、その後メンテナンスで」
「それくらい報告書にまとめろ」
「すみません……」
とまぁ、四年目とは思えない状態だ。
とは言うものの個人ではわからないが大分仕事を任せてもらえるようにもなった。
2年目までくらいは基本、1人では作業を行ってはいなかったし、1人で社外に出ることもなかった。でも今は指示を受けての作業であるが1人で行うようになった。
これだけを見れば成長したんだなと思うが、1人でやらせるのは怖いと言われることが多い。
「シンジ少し教えてもらえないか？」
「はい。何ですか？」
「このプログラムで帳票出力の制御入れようと考えてるんだけど、前別ユーザで触ってたよな？」
「あぁ、はい。それなら設定ファイルで帳票ごとに制御しましたよ。後はマスタで端末ごとに対象を絞り込むとか。このユーザならマスタが良さそうかと」
「そうか。なるほどわかったありがとう」
「いえ、お役に立てて嬉しいです」
たまにこういう時がある。
自慢にはならないが、僕たちが扱っているシステムの機能にある帳票関連に関してはそれなりに自信を持って修正や機能追加が行える。
そのため、帳票ならシンジという言葉まで出来た。大変ありがたい話だ。
この帳票に関して頼られるようになったのは2年目の秋から受け持ったプロジェクトで担当したのが切欠である。また一番「ＳＥの仕事」ということを考えさせられた時でもある。
★♪★♪★♪★
―総合医療センター―
ここは病床数360床程あるそれなりに大きな病院である。
また特殊であり、患者のほとんどが女性か子供と普通の病院とはまた違った環境だった。
今回僕がここを担当することになった理由が、現行システムのリプレースのためだ。
「凄い病院……」
「そう？ まぁ、確かに他の病院に比べれば少し特殊かもしれないからその点では凄いかな」
今、僕の呟きに答えたのは、医療部門の先輩、ナオ・フジモトさん。
先輩は僕の5つ先輩で年齢も5つ上である。年齢からもわかるように先輩もまた高卒で入社した人である。
「それじゃ、早速始めようか。まずは現行システムの解析から。シンジくんは今回の仕様書から現行踏襲する箇所の検索と収集。後は踏襲箇所でわからない術式があったら教えて」
「あっ、はい」
とまぁ、結構バリバリな先輩の下作業が始まった。
今回僕が担当したのは現行踏襲箇所。メイン処理よりサブ処理に当たる帳票系の出力やサブ機能、検査データの排他制御、患者の呼び出し機能等を新システムに組み込むところだった。
ある日、踏襲箇所でどうしても新システムに移行できない部分があり、それを先輩に相談しに行ったときの話しだ。
「先輩、この帳票なんですけど術式が新システムとあってないのでエラーが出て移行できないです」
「造りこみ？ 一部コードの変換とか無理かな？」
「いや、無理じゃないですけど」
「折角だしカスタマイズしてみる？ もちろん帳票レイアウトのお客様との打ち合わせも必要になってくるけど」
この時初めてカスタマイズと言うのを行った。
半分以上が現行踏襲で対応可能であったが、残りは自分で術式を組むほか無かった。それに何度か行った定期ＷＧでお客様から帳票のレイアウト変更と帳票追加の依頼があった。大まかなレイアウトを貰い、それに従いサンプルの作成をしたが、ないよう確認の都度、ああして欲しい、こうして欲しいと要望が挙がった。
ついには仕様を固めようといていた矢先に表示項目を現行と同じように出力してほしいと要望が挙がった。断ろうとしたが、その要望が思った以上に重要な項目であり、帳票出力部分の作成だけでなく、項目の元となるＤＢの追加を行う羽目になった。
「どうシンジくん。上手く進んでる？」
「あっ、はい。何とか」
「そういえば、追加するＤＢの見積もり取った？」
「いや、まだです」
「いつやるの？ それしないとＤＢ作れないし、データも取得できないから術式組めないよ？」
パニックに陥るところだった。
プログラムの構築、レイアウト調整、DB作成。大枠な作業は他の人に比べれば少なかったが、一つ一つの作業が思った以上に細かく、てんやわんやになりほとんどが中途半端なところで停滞し始めていた。
そしてついに先輩から声が掛かった。
「シンジくん、帳票できた？ 明日の夕方期限だけど確認の必要あるんじゃないの？」
「もう少しで出来ます」
「後どのくらいかな？ 1時間？」
「もう少し掛かります。多分2時間弱……」
「はぁ、わかった。今日はもう終わり」
「えっ？」
「今日は終わり、帰るよ」
突然先輩から帰ると言われた。
いつもなら終了ラインを決めて作業していた先輩がラインを決めずにいきなり帰ろうと言ってきたのだ。
作業を続けようとしたが強制的にシステムを落とされ続行不可となり止むを得なくその日は帰る事にした。
その帰りの道中、先輩になぜ作業途中で帰るなど言ったのかを聞いてみた。
「あの、先輩？」
「ん？ どうしたの」
「いや、何で急に帰るなんて言い出したのかと思って」
「あぁ、簡単な話、帰りたかっただけ」
「へっ？ それだけですか」
「うん。それじゃ聞き返すけど、さっきの作業まだ2時間弱掛かるんだよね？」
「はい。あの分量を考えればそのくらいで――」
「残業代」
「えっ？」
「残業代。その分ここでの作業に使えるお金が減っちゃうんだけど？」
この会話だけでは意味が伝わりにくいから、説明を入れる。
この時、時間は20時を回るところだった。
労働基準法により人は原則8時間労働と定められ、それ以上を残業としている。僕の会社の勤務時間は8時40分から17時30分までの合計7.9時間。休憩時間を含め残業は18時から計算されることになるため、既に2時間の残業をしたことになる。
通常勤務で消費するお金、通称「単金」と言うのがあり、1時間あたり担当ユーザ（ここでいう病院）から貰っているお金のことだ。
残業をすることでそれが余計に消費されていると言うことになる。そのため先輩が言ったように今回の作業で使えるお金が減ると言うわけだ。
余談になるが移動費や宿泊費、いわゆる旅費もその作業で必要なお金と言うことで作業で使える分から引かれている。
それで先輩が言いたかったことと言うのは、今僕が行っている作業が後2時間弱で終わると言うこと。そしてこの提出期限が翌日の夕方であると言うことだ。
結論。翌日の午前中に先輩レビューまでを終わらせれば良いと言うこと。わざわざ残業にせず、通常勤務で出来ることならそのタイミングで行ってしまうと言うことを先輩は僕に伝えた。
「そうですね。すみません全然考えていませんでした」
「まぁ、仕方ないよ。思った以上にお客さんも無理言ってきてるしね。だからと言って手を抜くことは禁止だよ」
「はい。それはわかってます」
「それじゃ、ついでに聞こうかな？」
「何をですか？」
「ＱＣＤわかるよね」
「えっ？ あぁ、はい」
「それじゃ順番に言ってみて」
ＱＣＤ。
単語くらいは聞いたことのある人も居るのではないだろうか。
Ｑ(Quality)：品質
Ｃ(Cost)：コスト、価格
Ｄ(Delivery)：納期
この三点について僕は問われた。そして答える。
「うん。そうだね」
「で、このＱＣＤが何か？」
「言ってて気づかない？ 今回のシンジくんの作業納期がギリギリになってるんだよね」
語らなかったが実は今回の作業、納期を延ばしてもらっている。
何が言いたいかと言うと、ＱＣＤのバランスが悪いと言うことだ。
元来、このＱＣＤは3つの要素によりそのプロジェクトが問題なく進んでいるかを見るもである。そしてこの要素は何処かを良くしようとすると、別の要素が悪くなると言う特徴も持っており、バランスを保つのが難しいのである。
「今回、シンジくんの場合は品質(Quality)を良くしようとして納期(Delivery)を遅らせた」
「そうなります」
「納期を遅らせるとどうなる？」
「その分、余分なコストが掛かります」
「わかってるじゃない。つまり今回、シンジくんは1つの要素を良くしようとして2つの要素を崩したことになる。これじゃ、いくら品質が良くてもお客さん納得しないよね？」
「……はい」
「あぁ、シンジくんを責めてる訳じゃないんだよ。品質を良くしようとしてくれていることは重要なこと。ただそればっかりに目が行って、他の事に手を付けられていないからそこに注意して欲しいってこと」
「すみません。気をつけます」
「でもねシンジくん。これって思った以上に難しい事なんだよ？」
「難しいことですか」
「うん。やっぱり私達みたいなＳＥって言うのはこだわりがあるんだよ。それにお客さんも」
「こだわり……」
「そう。考えてみて」
こだわり。
それは自分の技術を活かした仕様に仕上げると言うこと。
また、元来の仕様の良さをお客さんに伝え、それを提供すると言うこと。
これが僕たちＳＥの持つこだわりの一部。
逆にお客さんのこだわりが、現行機能を全て踏襲することはもちろん、要望に挙げる内容を全て実現してもらえると言うこと。
これがお互いが考える『こだわり』と言うわけである。
こだわりは叶えたいけどとても叶えにくい事でもあると言うことをここで知った。
「考えればそうですね。自分も相手もこうしたい、ああしたいって考えがありますよね」
「うん。だからこそ私達は可能な限り両者のこだわりを叶えられるようにしないといけないの」
「こだわりを叶える……」
「そのためにも、ＱＣＤのバランスを保たないと、互いのこだわりを叶えることが出来ない」
「どうすればいいですか？」
「それは自分で考えないと意味ないよシンジくん、2年目なんだから、教わることと自ら学ぶこと両方始めないといけないよ」
「自ら学ぶ……。わかりました頑張ります」
「いい返事だね。明日からまた頑張るよ」
「はい」
こうして僕は改めてＳＥと言う作業について知ることが出来た。
★♪★♪★♪★
先輩との会話から僕は再度今回のこちらが提供しようとしている仕様と、お客さんから言われている現行仕様について見直しを行い、実現可能なところは構築。実現できないところは代替案を持ってお客さんへの説明を何度か繰り返して行うようにした。
しかし、問題はまだ山積みだった。
こちら側の代替案で納得してもらえる部分もあったが、やはりこの機能はあった方が良い、これを追加して欲しいとの要望が挙がった。こちらとしても可能な限りは実現したいが、人員的、費用的な面でも厳しいと言うことを先輩からも話をして頂き、何とか仕様決定まで行き着くことが出来た。
仕様を決定させたのは良かったのだが次はそれを構築するところで行き詰る。
「どうしたのシンジくん？」
「あっ、いや。この帳票なんですが、出力用に新しく術式組まないといけないかなと考えてたんです」
「ふぅん。ちょっと術式見せてもらっていい？」
先輩は僕が組んだ術式を順に確認していく。
その時、先輩が大きな溜息を吐いた。
「シンジくん。その帳票、他のものと共通してる箇所とかない？」
「共通ですか……。出力項目くらいですね」
「だったら、前に協力会社さんが構築した出力プログラムがあるでしょ？ それ流用できるんじゃない？」
「えっ？ あれって専用の術式じゃ……」
「そうだけど、出力項目同じだったら、後は検査種別で出力帳票判定させれば良いんじゃないの？ それに専用術式でも起動させる引数がちゃんとしたものを渡せれば動作するんだから」
「そういうことですか……。わかってなかったです」
「まぁ、今回は発見が術式構築前だったから良かったけど、もしこれ術式組んでたら、無駄に同じ処理を書いたプログラムを実行することになってたんだよ？」
「でも、それでも可能なんじゃないんですか？」
「処理上はね。けど私が言いたいことはそこじゃない」
「へっ？」
「ここのメンテナンスって誰がやるの？」
「それは、僕が」
「全部？ 急なトラブルでも」
「いや、それは他の動ける人に頼む時もあります」
「でしょ？ それじゃ聞くけど、もしこの出力部分を新たに術式を組めば、シンジくんは修正箇所等が直ぐに探せるけど、他の人は難しいよね？ けど専用術式を共有化させていたらどうかな？」
「確認する箇所が減ります」
「そう言うこと。術式を組むってことは、そこまで考えて行わないといけないの」
資源の共有化。これが新たに考えさせられた内容だ。
共有化とは名の通り、あるものを別々のものが一緒に使用すると言うこと。
今回の場合で言うと、ある検査種別で出力す帳票と、また別の検査種別で出力する帳票の出力処理を同じ術式を使って処理を行うと言うことだ。
この共有化にはポイントがある。
その1つが、処理の簡略化。
簡単な話、似たような処理を新たに構築するか、類似処理に判定処理を追加して使い分けるかの違いである。この場合、簡略化はもちろん後者である。
この簡略化を行うことで、無駄な構築時間を無くすだけでなく、他の処理箇所への流用性も増す。
そしてもう1つの点がメンテナンスのし易さだ。
これは先輩も言っていたが、メンテナンスは確かにそれを構築した人が行えば何の問題はないが、偶然メンテナンスにいけなくなり、その他のメンバーに頼まざるを得なくなった場合、共有化させている場所に関しては、内容も見やすく、また原因きり分けの際に共有している箇所としていない箇所での切り分け簡単に行えると言う点が挙げられる。
このことから、ただ単に機能を実現させるのではなく、実現させることによってメンテナンスを行う可能性もあり、それが直ぐにわかるようなことか否かも重要となってくると言うことを知った。また、派生になるが、自分が新たに構築した術式も可能な限り共有化できるような仕組みで組むように心がける必要があると言うことを知った。
そして僕は試行錯誤の上、先輩や協力会社さんの協力もあり、無事完成させお客さんに提出するところまでたどり着いた。
「これが今回作成した帳票のテスト画面です」
「何度もごめんなさいね。このレイアウトで結構です」
「後、この部分の仕様については、現行通りに自動算出とデータ取得を行ってこちらの方に印字する形式を取らせて頂きました」
「おぉ、そのままだ」
「データはどうなってるんですか？」
「データの方は新システム稼動に合わせて、現行システムからそのまま移行して使えるようにします」
僕は、手持ちの資料と口頭説明で何とか今回の追加、踏襲箇所の説明を行った。
そして説明が終えた最後に、僕によく要望を挙げていた人からある言葉を言われた。
『ありがとう』
この一言。
この『ありがとう』という一言だけだったが凄く嬉しかった。
初めて自分の中で仕事をしたと感じた時でもあった。
何気ないこの一言が今も自分の中で残っている。何ヶ月と言う期間かけて行ったプロジェクトだがやって良かったなという気持ちにもなれた。
★♪★♪★♪★
あれから2年。
大きなプロジェクトもなく、ほとんどがメンテナンス作業となった今でも自分はあることを忘れないように心がけて作業を行っている。
とは言うものの、相変わらずこれはどうなっている、いつになったら終わる、何でもっと早く言わない……etc. と言われる毎日が続いている。
ナオ先輩からも今は別作業で指示とかは無いがたまに小言を言われている。
そうそう、僕が心がけていることは3つ。
まず1つ目は、
・その作業は自分が出来ることか。
依頼をされた作業でも自分の技術料や知識量で対応可能かどうかを判断すること。
2つ目は、
・作業に必要なものは足りているか。
その作業を行うに当たって資料や資源が手元にそろえること。
最後の3つ目が、
・時間が掛からない作業なら、確認は人がいる間に行う。
これは1つ目に付随するが、作業によっては自分だけでは解決できない案件もあるため、それに特化した人に確認を取らなければならないため、なるべく確認は人が居る時に行うこと。
この3つが常に心がけていることだ。
あの2年前に体験したことは今までの中でも大きな体験であり、また今後の作業での土台にもなるものでもあったため、決して忘れてはいけないことだと改めて感じている。
そして現在も、
「シンジ、ここのメンテなんだけど手伝ってくれるか？」
「あぁ、構わないけど。メンテ内容は？」
「お前の好きな帳票だ」
「別に好きじゃないって。まぁ、得意分野ではあるけど」
「んじゃ、手順書作成とか頼むわ」
「了解」
唯一の同期とも作業について会話を出来るほどに。
まぁ……、
「おい、シンジ。この前の資料見たが、どう言うことだこれは」
「えっ？ 何か間違ってましたか」
「間違いじゃない、これは誰に提出する資料だ？」
「オペレータにです」
「この説明はＳＥ用であってオペレータ用じゃないだろ、見直せ」
「はい……」
とまだまだダメな姿も晒してる。
こんな4年目の僕だが、これからもこの会社でＳＥとしての技術、知識を磨き、お客さんに喜んでもらい、そしてあの一言『ありがとう』を言ってもらえる仕事が出来るように頑張っていこうと思う。
数多の壁にぶち当たることもあれば、剣山のような刺々しい道を進むかもしれない。けどそれを乗り越えてこそ、本当の意味でＳＥと呼ばれるのではないかと考えている。
決して1人で乗り越えられるものではなく、仲間との協力があるからこそ成り立つ職業でもあるこのＳＥ。そして一番はお客さんとの関係。これが築けていなければそもそも仕事として成り立たなくなるため、人間関係もまたＳＥとして重要なスキルである。
最後にこれはＳＥだけに留まらない話でこんな僕が言うのも失礼に当たるかもしれないが、今自分が持っている肩書き(ここで言う職業)に誇りを持って取り組んで欲しいと思っている。
繰り返しになるが、僕も前向きに、常に前進し続けるＳＥとして、そして「自分に感動、お客様に感動(喜んでもらえる)ＳＥ」になれるよう頑張っていこうと思う。
とあるＳＥの奮闘記 ―完―
読者の皆さま始めまして、ご存知の方はどうもです。作者の白河シンジです。
この度は、職業小説企画で投稿させて頂いた短編『とあるＳＥの奮闘記』を読んで頂きありがとうございます。
そして、今回の企画、主催者であります近藤義一様、沢木香穂里様、そしてスタッフ一同様、このような投稿企画を開催して頂いてありがとうございます。
さて、今回のお話如何でしたでしょうか。
私はここで「魔法少女リリカルなのは」と言う燃えアニメの二次制作を書かせて頂いておりますが、これとはジャンルが異なる作品を書いたのですが楽しんで頂けましたでしょうか。
まぁ、ジャンルが異なると言っても、登場キャラ等の設定をファンタジっぽくしているのであまり変わりませんね(笑)
一応、前書きにも書きましたが、今回の物語は実話を元にしたフィクションです。
始めは本気でリアルな内容を書こうと思いましたが、完璧自分の思いと愚痴を綴った作品にしかならなかったため、急遽内容変更を行いました。
テーマは「チームワーク(会社とお客様)」(ちゃんと伝わったのだろうか……)
私達ＳＥは個人技能も必要ですが、一番はこのチームワークです。
しかも、そのチームワークはＳＥ同士だけでなくお客様(私の場合病院様)との連携も良くないと必ず何処かでズレが生じて上手く進めることが出来ません。
今回はそれを皆さんに伝えたく小説として書かせて頂きました。
「ＳＥはシステムを作る人」から
「ＳＥはお客様＋自分が互いに納得しあったものを提供する人」
というイメージを持って頂けたらなと思います。
一読して頂いた方、最後までじっくり読んで頂いた方ありがとうございます。
これからも、仕事、小説を両立して進められるよう頑張りたいと思います。
では★
