  |
はてなキーワード: 仕様書とは
IT業界は日本社会の縮図となっているんだよ - こうして僕らは腐る
http://www.byosoku100.com/entry/2018/01/13/212749
ITを学んでIT企業に就職して、この国のIT企業はきっとCIAか何かによって弱体化を図られたとしか考えられないと思いました。
自分でロジック組んだり、アルゴリズムを考えたりする仕事をさせてくれている会社もありますが、会社の規模がでかくなればなるほどそういう仕事は下流に任せる感が強い。まずこの構造が弱体化の出発点。
多重下請構造は、製造業日本ならではの伝統、下流＝低賃金が根強い。背広を着た人がその伝統文化を売り捌く。文化が短納期、安請け合いを生み、短納期、安請け合いにより、品質が下がり、雇用も安く済まされ、弱いSEしか集まらず、国際競争力はなくなる。この下請け構造文化を持ち込んだのは、他ならぬ製造業文化を固持してきたメーカー系ベンダーのように思えます。メーカー系ベンダーはCIAだからなんだかのスパイ行為に加担したのでしょうか？
実はそんなメーカー系ベンダーにもいたのですが、ぽっと出の強いSEもいます。ところが強さが仇となり、全容を把握している神扱いで一段上に据えられます。そして多忙を極め、ロジックやアルゴリズムをひねり出す知的生産力は、仕様書、指示書と呼ばれるエクセル方眼紙に図形や文書を書き殴る作業力へと変貌します。
指示は全て自社フォーマットの図面に書け！その図面、審査、承認を課長に貰え！え？予算の都合、本部長承認が必要？本部長いつ来るの？1週間後だって！？リスケだ！工数再見積もりだー…これは仕事ですか？それとも茶番ですか？こうして強いSEは弱体化します。強いSEほど自分の置かれた立場や環境に順応しようとする意識が強く、仕事ができる人間になるためにはお上に楯突かず、弱体化を受け入れようと考えます。
エクセルのvlookupを使うために、学生時代に関数型言語を学んだわけじゃないのに…と就職して思うようになったunix文化を学んだ強いSEが、思考停止している情シスによって管理しきれないものは全てセキュリティホールみたいな会社にいたら、「あいつはセキュリティを脅かす不良社員」のレッテルを貼られ、朝から晩までvlookup,vlookup...（いやそのエクセル脆弱性情報とパッチ出ているけど、いやお上のお達しを待て！的な茶番劇）せめてgrep,awk,sedくらい使わせてやれって、残業がなくなってボスも最近社長の思いつきで始めた健康経営者として表彰されるかもしれんよ？思いつきだから明日あるか分からんけど…。いつまでこんな寸劇をやればいいのやら。学んだことは活かせません。茶番寸劇の中心にはやはりこの国のIT業界を弱体化させ国際競争力を低下させるスパイが潜んでいるとしかおもえません。
ここで、IT業界に蔓延る日本の国際競争力をいちぢるしく低下させているスパイの特徴を述べておきます。
スパイの目的である国際競争力の低下にダイレクトにアプローチするスパイ中のスパイです。こいつがいたら即辞めないと国や社会のためにも良くないです。
・「よく分からないものはセキュリティの都合使えません」と思考停止している人
お前はそのツールのコミッターでそのツールの脆弱性を分かってそんな事を言っているのか？と、せめて同僚がツールの有用性を知りつつ使いたいっていうならそれなりのセキュリティ的可用性を示すのが情シスの仕事じゃねーのかと？まぁこの場合スパイなのでそんな調査は死んでもやりませんが…
スパイの常套プロパガンダです。明らかにおかしな言動なのでスパイの中では未熟者なのかもしれません。
そのままでは通用しないけど、出発点であるべき。でなければその空白を埋めるコストをどうしろと？そんな言葉をマジで吐く人間は出発点にすら立たせて貰えていない場合が多い。ただ言葉を吐くスパイは、スパイが故に企業内の立場は上のほうにいるかもしれません。出発点に立っていなかろうが
よく考えてみてください。遵法精神のあるスパイがいると思いますか？そもそもこのスパイが蔓延る構造は日本社会に根深く浸透しているので、法律を取り締まる側もうまく騙されていると考える方が自然です。労基法、下請法、派遣法…機能しないのも当然です。
あるSEさんが業務として、社内のデータを加工して一定の出力をする作業を上司から命じられたとする。
この作業をするにあたってSEさんは、独自の適当なプログラムを作成して作業を完遂した。そして作業の結果を上司に提出し、このタスクは終了した。
上司は作業と作業結果を求めていたが、プログラムの開発を指示したわけではなかった。当然発注書もなければ仕様書も運用マニュアルもない。
が、そのプログラムが開発されたあとは上司および社はその存在を認知しており、有用性を認め、同じようなデータ加工業務をその後何回かSEさんに指示し、それらすべては作業が完遂し上司に提出されなんの問題も起きなかったとする。
この場合、独自のプログラムは就業時間中に作ったから、会社の財産だといえると思う。該当SEさんが退職するにあたって、SEさんはこのプログラムを社に残したとする。
このプログラムに「一定期間ごとに特定のパスワードを入力しないと自壊する機能」が盛り込まれていたとして、それは何らかの法的な、あるいは倫理的な問題を起こすだろうか？
元増田、基本的には合理的だと思う。評価した方がいいから端的に評価したと。
発注側も受注側も完全にフラットな関係で、伝えるべきことを率直に伝えればいいっていうのが合意されてればそれでいいんだろうな。
で増田はその方がいいって思ってるんだろうなって思った。
しかし実際はだいだい受注側は発注側に対して立場が弱いんだよな。そういうときに、良好な関係を維持して、受注側にいい仕事（契約書とか仕様書に書ききれていない細かい気遣いみたいな部分とか）をしてもらうためには、発注側が気を使って偉そうに思われないように接するっていうテクニックが必要だったりするんだよ。ただのテクニックな。それはわかるんじゃない？「いい感じで受注側に仕事してもらうために、印象ポイントを稼げ」っていうアドバイスなんじゃない？
転職かぁ
今書いてるコードは同じような処理をしてる箇所があるからそれを参考に作業してる。
外部仕様書しかなくて内部ロジックは「ここを見て書け」という指示だから。
で、参考にしてる箇所にバグを見つけた。
select coalesce( sum( XXX ), 0)・・・
select sum( coalesce( XXX, 0 ) )・・・
上が現行の書き方だけど、たぶん下のように書かないと正しい結果にならない。
2) バグに気づかなかったことにして、自分の書いてるコードも同じバグを入れる
どれにしても面倒くさいんだよな。
(1)は「こいつまたよけいなことをしやがって」みたいな反応されるだろうし、(2)もバグが見つかったらめんどうだし、(3)だって「お前の書いたところは他の箇所と挙動が違う」ってことになったら面倒だしな。
具体的な例は示せないがこんな印象。
システム監査や業務監査に対応するために設計書や議事録は残さないといけないし、テストはテストコードでは監査のエビデンスにならないから（監査人が読めないから監査OKの判定を出せない）、神Excelのテスト仕様書と吹き出し付き画面キャプチャのセットを作らないといけない。
監査のために隅々までログや管理者機能を作らないといけないし、運用が回っていることを証明するための分析機能も作らないといけない。
昔取り入れられた内部統制なんちゃらのせいで、職務分掌が絶対とされ、開発者が本番環境を触ることが出来ない。開発者が本番環境にプログラムリリースするために独自で構成管理システムも作らないといけないし、運用部隊を通じて本番環境を調査するための申請システムも作らないといけない。
本番稼働が始まったら開発者一人居れば回るような規模なのに、開発担当、開発責任者、運用担当、運用責任者の４名が必要となる。
10年前に米国から輸入されたSOX法のしがらみが続いている日本ではDevOpsなんかあり得ない。
システムが動くことよりも、監査に堪えられる仕組みを作ることが重視されている。
監査対応は上場企業であれば必要となる。所謂Web系のベンチャーが「上場準備」を始めた段階でシステム対応のスピードが大きくダウンするのもこのためである。
ずっと客先常駐で、ひとつの現場で仕事をしてきたんだけど、これまでにテスト以外の仕事をした期間が3か月ぐらいしかなくて、もう本当に嫌になっている。
画面を操作して、スクリーンショットを撮って、エクセルに張り付けたり、確認したところを四角で囲んだりね。
基本的に、単純作業だろうがなんだろうが、きちんとこなしていくのは元々好き。
私がやってるようなテストばかりしていると、退屈で死にそうになる人も世の中にはいると思うけれど、私にとってはそれほど苦痛ではない。
けどいい加減辛くなってきたよ～。
歳だけ取って、単純なテストの実施しか出来ると言えることがないのが辛いよ。
家庭の事情で、これから転勤or転職も考えていかないといけないし、子供も欲しいから産休育休に入ることもあると思う。
ただでさえも知識も実績もないのに、それがこれからリセットされて、無になるのが恐怖。
できることが何にもなくて、歳だけ取って既婚者で。
こんな自分を受け入れてくれる場所がほかにあるだろうか？怖くて怖くて不安で辛くて仕方がない。
でも今の場所に居続けるのは自分のためにならないんじゃないかとも思うけど、出ていくのも怖い。
いくら簡単な仕事しかしてないとはいえ、残業が多くなることもあるし、
コンスタントに業務外で努力できたらいいけれど、心身ともに疲れる期間があれば、そのあとは回復のための期間も必要なわけで、
仕事に余裕があるからといってバリバリいろんなことを頑張れるわけではない…私は。
仕事でも私生活でも、なにか作業や娯楽に没頭していれば大丈夫なんだけど、
ふと頭を冷静にすると、不安とか焦りとか後悔とかで涙が出そうになる。
この状況を抜け出したいし、負けたくないー。
まずは普通に仕様書通りにプログラム書いて、それをテストできるような、
本当に普通に仕事振ってもらって、苦労しながらでもそれをこなせるぐらいになりたい。
やるぞー。
でも何を…って感じ。
え、半日で変更差分が 3 行と 5 行と 20行程度しかないんだけど・・・ じゃないんだよ！
あれこれ調べて試して最終的にそれだけの変更ですんだんだよ！！
引き継ぎもなく会社辞めた人が作ってたシステムのコードを渡されてこの修正依頼対応してね、とか言われても作りが意味不明
有名ドコのフレームワークやライブラリならともかく、見るからにその人自作らしいもので作られてる
愚直にイベントに対して、あれやってこれやってそれする、って書いてたり、変な上書きはせず UI コンポーネントのプロパティ変えればそのまま反映されるようなら簡単に直せそうだったのに、
複雑に継承を重ねたコントロールクラスでちょっと見た目変えるだけでも一苦労
値を変えても反映されずに親クラスで変な制御ついてたりするし、現状のものにフィットさせすぎてちょっと操作性変えるだけでも大規模に変更が必要そうに見えるし、どこから手を付ければいいのかって状態だし
どこで値が変えられてるとかが追うのだけで時間が過ぎていく
どこがどういう仕組になってるとか、こういう変更ではここを変えればいいとかいう手引きがあればまだましだが、そういうのは全くない
余計なことせず単純にコントロール並べて、単純にデータ取得や保存する作りで作られていたなら1日もあればで終わったであろう簡単な修正依頼が1日で1割程度しか終わらない
作った本人はこの方が楽だったんだろうが、他の人が使えないもの作るのはやめてほしい
というか、ファイル名が連番でどのファイルがどの画面に対応してるからすら開いてみないとわからないレベルだったのだが作った本人はこれで苦労しなかったのだろうか・・・
仕様書に対応表があったのかもしれないが今あるのはこのコードだけだ
最後まで面倒見れないなら、世間一般の作りに合わせるとか有名どころのライブラリ等情報があるものを利用してほしい
退職のつもりなくても、病気とか怪我で代わりの人に任せるとかはあるだろうから出来る限り、独自の作りはやめてほしい
あと５年もすればいよいよ昔を知る人が居なくなり日本中で同じ事が起こるだろ
技術者を軽視してきた経営側・管理側の招いた負の遺産となるだろう。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
こういった無意味な人事ローテーションをやめて、スペシャリストをしっかり身内に育成してきていれば良かったのに
残念なことに、「属人化は良くない」といった言い訳で、専門家を軽視してきた。
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
みんな沈む。
https://anond.hatelabo.jp/20171012165214
つーか失敗が稀だからニュースになるのであって、実際は成功するのが大半だよ。
そもそも入札してもらえないと始まらないので、仕様書にあまり無茶なことは書けない。
開発中に新規の要件が出ることはあるけど、こっちだって完成しないと困るから適宜調整するし、無理な分は来年度以降の課題ということで先送りする。
その結果市民からは「不便すぎる役所死ね」と叩かれることもあるけど平謝りするしかないね…。
まあメインフレームはどんどん消えてくし、異動があるとはいえ組織内でのノウハウは蓄積されるし、特許庁みたいな反面教師を挙げて庁内を説得できるようにもなったし、どこも段々と良くなってくんじゃないかなー。
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/
Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？
A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。
それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。
Q2.なんで新規で作らないの？
A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。
A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーごとに作っていてOSもベンダー謹製だよ。性能はいいけどメチャ高いよ。
システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。
オープンソースソフトウェアとは全然関係ないよ。
Q3.使いまわしってどうやってやるの？
A3.80年代とかに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語にコンバートしてリコンパイルするよ。
DBのデータも階層型データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。
あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。
コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。
COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。
Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん
A4.お金が無限にあればできるよ。今の時代にお金があった時代のシステムをフルスクラッチで再開発するととんでもない予算になって市役所内の決裁が通らないよ。
しかも汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから、費用はさらにかさむよ。
Q5.そんなんでよく運用できてたな
A5.当時はSEが汎用機の付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。
そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。
マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
Q7.なんで入札にしたの？ 現行ベンダに指名してやらせたほうが良くない？
A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。
随意契約（随契）は無理だし、入札業者を発注者が指定する指名競争入札は談合の温床になってたから最近はあんまりやらないよ。
（裏技としてRFPを指名したいベンダーに書かせて公募型指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね）
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
入札案件はRFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。
なので、技術点の項目に現行システムの調査にかかる項目を入れるとかして、現行機の開発・保守ベンダが高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。
もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社をめっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。
A9.ここまで述べたようにこの手のマイグレーションは火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。
A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね。
しょぼいSEだからここに書いたことは個人の体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。
(2017.10.13 追記）
Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。
あと、「オープン化」の定義が違くない？という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。
メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。
これに対しPCサーバは標準規格で作られているよ。こういう標準規格に基づくサーバをオープン系と呼ぶよ。
独自規格でクローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。
京都市で火中にいるシステムズさんのサイトの解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ
http://www.migration.jp/column/column01.html
完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。
H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。
すまん５つと言ったのは適当だ。
今から考える。
まあ３つは既に思いついているのでそれを書きつつ残り２つを埋めるとしよう。
まずはこれだ。
みたいな感じ。
なんかこうよく分かんないよね？
それを「こういう意味でいいんですか」と言えなきゃ駄目だ。
いきなり青いパプリカを作って持っていき、相手から「俺はピーマンが欲しかったんだ！それも青と黄色の斑模様のな！」と言われてから急いで作り直すのはプロとしてよろしくない。
グーグルプレイストアに広告付きアプリや有料アプリを並べてコツコツお金を稼ぐパターンを狙うなら無くてもどうにかなるかもだけど
これも駄目だ。
プログラムってのは全部が論理的に完璧って訳じゃない「コレなんかおかしくね？」と感じる部分が多少はある。
本質の本質の本質まで追求し続けようとしたらそのうちプログラムなんて書けなくなる。
趣味でやって突然ドツボにはまるのならそれは個人の勝手だけど、仕事場でそれをやるのはいただけない。
散々言われすぎてかえって馬耳東風になってるだろうけどこれはガチだ。
ガテン系の仕事なら熱中症対策や事故対策という言葉の元に休めるタイミングでもIT土方は休めない。
自分はそんな会社にはいかない！と宣言できるほど運がいいならFXでもやったほうがいい。
疑心暗鬼になって細かい所を気にする性格はプログラマー向きか。
NOだ。
細かい所を気にするよりもトライ＆エラーを繰り返すのが正解だ。
１０歩進んで９歩戻るのを繰り返す内に１０歩進んだのに６歩しか戻ってないぞ！、ってなるのがプログラムの世界だ。
１歩ずつ進もうとする事は実はリスキーだ。
プログラミング言語様と仕様書様に忠誠を誓って淡々とその責務を果たせることだ。
クリエイティブなアイディアなんて言語様も顧客様も求めてない。
そしてそれらは半端なクリエイティブさを発揮することよりもよっぽど難しく才能がいるんだ。
ちょっと独創的なだけなのにそれを才能だと思って大事にしてるようじゃ職業プログラマーには向いてない。
よっし５個埋まった！
後半の2つはその場ででっち上げるつもりだったが、前々から考えていた事を思い出してしまったのでそれをそのまま書いた。
ああ最後に1つ言わせてくれ、５つとも当てはまっているがそれでも職業プログラマーを目指したいと勉強中の君はそのまま頑張ってくれ。
それさえ出来てるのなら、無数の困難も乗り越えられたり乗り越えられなかったり乗り越えてるのはホームの黄色い線だったりだ。
頑張って
やる気が出ない。
ホントでない。
お陰で更にやる気が出ない。
よし！やるぞ！
私「おめー！これ仕様書として書いたのか？初めて見る人でもこの資料をみて、作業ができるようになっていて、誰が作っても同じようになるよう誘導するものが仕様書なんだよ！」
なんで忙しいかというと、この仕様書書いてるやつが散々サボってきてからだ。
この項目とこの項目一緒じゃね？それにこれも辻褄合わないよな。。。
私「こことここの項目一緒じゃないですか？」
・・・・
なぜ問い合わせるかというと、お客さんから言われたとおりにそのまま転写しただけのようだ。
よろしこ。
ふ〜。。。。
私「ここのところの項目辻褄合わないように思うのですが、こういう意味であってますか？」
こいついなくてもいいんじゃね？
やる気でね〜！
働かざる者食うべからず、働かずに金や地位で金を生むだけの奴らは社会の邪魔だ。
そう言ったのはどっかの時代の真っ赤な頭の共産主義者だったとか。
そんな事は置いといて、俺たちは最低の人間かも知れない。
俺はエンジニアにも単純労働者にもなれてないまま経営者の指示通りに彼らに鞭を振るだけの仕事をしている。
表面上は必死に頭を下げて、心の中でも頭を下げて、それでも彼らに報いようとはしていない。
頭を下げて経営者の命令通りの仕様書を押し付けていきゃいい、そんな俺達の態度に経営者はご満悦だ。
辛い。
俺達はまともに生きている人や価値を生産している人間の前に転がった石ころだ。
もっと重たくて鬱陶しくて、相手におんぶ抱っこで押しつぶすような、そうだ、子泣きじじいだ。
石ころ程度の価値しか無く、赤子のようにわがままで、無力な癖に握力だけは鍛えに鍛えた老害だ。
俺達はそこまでして生きたいのか。
生きたいのだ。
生きたい。
何もしなくても生きていけるならこんな事もうやめたい。
だけど俺たち無能が今更ちゃんと働けないんだ。
技術者になれるような知能はない。
肩書以外は何もない。
ただほんのちょっとの肩書きだけで無理やり生き延びているんだ。
ニートが遺伝子が半分一緒だという理由だけを印籠にして実家に居座り続けているのと何も変わらない。
ダニだ。
俺達はダニだ。
でも死にたくはねえんだ。
読みたくない方は帰られたし。
事の発端は社畜歴3年ほどの俺がひょんな事から先輩社員に指示を出す立場になったことから始まる。
最初はヒイヒイだった仕事も段々と(手を抜く)コツを覚え、ある程度は臨機応変に対応が可能になった頃だ。先輩社員の担当していた作業が諸事情でストップしてしまい、なんやかんやで「お前のとこで仕事何かないか」と俺のところに話がまわって来たのだった。正直一人でも対応可能だったが作業が軽くなる分にはありがたい。諸々のスケジュール調整やら、仕様書やらを割り込みで作った。
作業に入ってもらう段になった。
今までは指示をされる側だったから少し不安だったが、とりあえず自分が作業する時に聞いておきたいことを伝えときゃいいか、と思い
・データの重さの目安
・クオリティレベル(既に出している商品をサンプルとして共有済み)
等々、仕様は思い付く限り細かく伝え、他に不明な事があったら聞いてほしいと言う旨は伝えてあった。
これで「大分余裕出るぞー！」と思ったのも束の間、クライアントとの連絡で手違いがあり、仕事が急に増えてしまった。「いやぁ作業手伝ってもらってて助かった」と思いつつ作業を進めていたらいつの間にか先輩社員の下にお粗末さんが誕生してしまっていたのだ。
勿論、都度チェックを取らなかった俺が悪い。そこは完全にこちらに落ち度がある。
だから終電帰りも早めの出社も休み時間の返上も、まぁ不満には思ってない。(普段の仕事+上手く回すのも役目だと思っている。段取りが悪かった俺が悪い。)
ただどうしても「もう少しなんとかならないのか？あんたベテランなんだろ？」と思ってしまう。もう少しプロ意識と言うか、仕事に対してもう少し真摯になれないのだろうか。俺なんかは作るものには愛情というか執着というか、なんかよく分からない何かを込めてしまうんだけど、そういったモンはないのだろうか？(過度な要求なのだろうか？)
長文、乱文非常に申し訳ない。眠い中書いてるから朝読んだら支離滅裂で、読み直してジタバタしそうなきがする。(でも投稿はする)
なんかあーだこーだ書いてはいるが結局ケツ拭きも俺の仕事なのは変わりないし、そもそも他人に期待するのが馬鹿な話だっていうのもわかっている。でもさぁちょっとモヤモヤするじゃん。愚痴くらい言わせておくれよ。
どうするかは通勤時間に考える。
毎日せっせと共有サーバー内の古い仕様書をコピペしてはツギハギで新しい仕様書を作る仕事をしている。
たまたま入った会社のたまたま入った部署がそういう所だったから仕様書を書いてるだけだ。
この分野に特に興味もない。
最初から全てに興味がなかった訳ではなくて、全体の中の一部には興味があったが、それも半年働いて実は自分の興味がある系統とは違っていた事に気づいた。
何の興味もない分野の何してるのかよく分からない仕事の仕様書をコピペパッチワークで量産する毎日だ。
上司の所に持っていって上司が出した裁定をそのまま投げ返すことでキャッチボールをかろうじて成立させている。
こんな仕事のやり方でいいのかと疑問はあるが、上司も周りも特に何も言わないし、失敗すると「自分も最初はこうだった」と言うしきっとそういう物なのだろう。
自分は今何をやって、どうしてこんな適当な仕事で給料が貰えるのか一切わからない。
でもきっとそういう物なのだろう。
