「仕様書」を含む日記 RSS

はてなキーワード: 仕様書とは

2017-11-21

バグを見つけてしまったが

今書いてるコードは同じような処理をしてる箇所があるからそれを参考に作業してる。

外部仕様書しかなくて内部ロジックは「ここを見て書け」という指示だから

で、参考にしてる箇所にバグを見つけた。

select coalesce( sum( XXX ), 0)・・・

select sum( coalesce( XXX, 0 ) )・・・

上が現行の書き方だけど、たぶん下のように書かないと正しい結果にならない。

1) 「元ソースバグってますよ」と申告する

2) バグに気づかなかったことにして、自分の書いてるコードも同じバグを入れる

3) 申告なしで、自分の書いてるところだけバグを治す

どれにしても面倒くさいんだよな。

(1)は「こいつまたよけいなことをしやがって」みたいな反応されるだろうし、(2)もバグが見つかったらめんどうだし、(3)だって「お前の書いたところは他の箇所と挙動が違う」ってことになったら面倒だしな。

テスト仕様書を書くのも俺だし、バグはまあ隠蔽できるだろうから(2)が一番無難か。

2017-11-17

日本システムコストの8割は監査対応

具体的な例は示せないがこんな印象。

システム監査業務監査対応するために設計書や議事録は残さないといけないし、テストテストコードでは監査エビデンスにならないから(監査人が読めないか監査OKの判定を出せない)、神Excelテスト仕様書と吹き出し付き画面キャプチャのセットを作らないといけない。

監査のために隅々までログ管理者機能を作らないといけないし、運用が回っていることを証明するための分析機能も作らないといけない。

昔取り入れられた内部統制なんちゃらのせいで、職務分掌絶対とされ、開発者が本番環境を触ることが出来ない。開発者が本番環境プログラムリリースするために独自構成管理システムも作らないといけないし、運用部隊を通じて本番環境調査するための申請システムも作らないといけない。

本番稼働が始まったら開発者一人居れば回るような規模なのに、開発担当、開発責任者運用担当運用責任者の4名が必要となる。

10年前に米国から輸入されたSOX法のしがらみが続いている日本ではDevOpsなんかあり得ない。

システムが動くことよりも、監査に堪えられる仕組みを作ることが重視されている。

監査対応上場企業であれば必要となる。所謂Web系のベンチャーが「上場準備」を始めた段階でシステム対応スピードが大きくダウンするのもこのためである

2017-11-08

SIerで2年余りずっとテスターやってる。抜け出したい

新卒SIer入社して2年余り。

ずっと客先常駐で、ひとつ現場仕事をしてきたんだけど、これまでにテスト以外の仕事をした期間が3か月ぐらいしかなくて、もう本当に嫌になっている。

画面を操作して、スクリーンショットを撮って、エクセルに張り付けたり、確認したところを四角で囲んだりね。

基本的に、単純作業だろうがなんだろうが、きちんとこなしていくのは元々好き。

私がやってるようなテストばかりしていると、退屈で死にそうになる人も世の中にはいると思うけれど、私にとってはそれほど苦痛ではない。

けどいい加減辛くなってきたよ~。

歳だけ取って、単純なテスト実施しか出来ると言えることがないのが辛いよ。

家庭の事情で、これから転勤or転職も考えていかないといけないし、子供も欲しいか産休育休に入ることもあると思う。

ただでさえも知識も実績もないのに、それがこれからリセットされて、無になるのが恐怖。

できることが何にもなくて、歳だけ取って既婚者で。

こんな自分を受け入れてくれる場所がほかにあるだろうか?怖くて怖くて不安で辛くて仕方がない。

でも今の場所に居続けるのは自分のためにならないんじゃないかとも思うけど、出ていくのも怖い。

いくら簡単仕事しかしてないとはいえ、残業が多くなることもあるし、

上流工程のしわ寄せがきて振り回されるゆえのストレスも多い。

コンスタント業務外で努力できたらいいけれど、心身ともに疲れる期間があれば、そのあとは回復のための期間も必要なわけで、

仕事に余裕があるからといってバリバリいろんなことを頑張れるわけではない…私は。

仕事でも私生活でも、なにか作業や娯楽に没頭していれば大丈夫なんだけど、

ふと頭を冷静にすると、不安とか焦りとか後悔とかで涙が出そうになる。

この状況を抜け出したいし、負けたくないー。

まずは普通に仕様書通りにプログラム書いて、それをテストできるような、

本当に普通に仕事振ってもらって、苦労しながらでもそれをこなせるぐらいになりたい。

やるぞー。

でも何を…って感じ。

2017-11-03

引用

>今大企業で開発にいますが、ソフトウェア設計がロクにプログラムも組めない人たちが作っているせいでシステム全体の見通しも出来てない(細かいところの整合性がない)、無理に作るとバグの温床になるみたいなのたくさんある設計仕様書見させられてげんなりしてます

>要素検討チーム外国ソフトばかり作ってアルゴ理解していないので、ソフト範囲を越えれないし、勉強会?みたいなのひらいてるやつらはフィルター設計とかしょうもないし、こっちが作っても年齢が若いから参考にされずにgmみたいな企画を推進するし、いらいらしてます

2017-10-30

プロトタイピングで時間稼ぎ

ウォーターフォールで進めているなら…

一番最初モックを作る。

リボテのモック(見た目だけ。画面だけ。中身の機能実装してない)を用意して、仕様不明点をつめておく。(以後の仕様変更納期の延長が必要

 

リボテで仕様を詰めておく 

作品を見せる『プロトタイピングモデル

比較的小規模なシステムでは,まずプロトタイプ(試作品)をユーザ提示し,システム機能操作画面・出力される帳票などの確認をしてもらい,ユーザ要求を始めの段階で明確に把握するプロトタイピングモデルが用いられます

プロトタイプ作りから始めますので,手間と費用がかかりますが,ユーザの具体的な意見設計段階で取り入れられるため,修正などの手戻りが少ないという利点があります

 

 

傾向と対策

リボテのモックだけでも用意して、仕事してますアピール。(小出しにして、仕様確認と称して時間を稼ぐ)

実装はいろいろ問題があって、進捗が遅れていると報告。(相手素人なら専門用語を連発して煙に巻く)

なるべく早めにリスケ納期延長)を依頼する。

2017-10-21

むやみに抽象化?するのやめてほしい

え、半日で変更差分が 3 行と 5 行と 20行程度しかないんだけど・・・ じゃないんだよ!

あれこれ調べて試して最終的にそれだけの変更ですんだんだよ!!


引き継ぎもなく会社辞めた人が作ってたシステムコードを渡されてこの修正依頼対応してね、とか言われても作りが意味不明

有名ドコのフレームワークライブラリならともかく、見るからにその人自作らしいもので作られてる

愚直にイベントに対して、あれやってこれやってそれする、って書いてたり、変な上書きはせず UI コンポーネントプロパティ変えればそのまま反映されるようなら簡単に直せそうだったのに、

複雑に継承を重ねたコントロールクラスちょっと見た目変えるだけでも一苦労

値を変えても反映されずに親クラスで変な制御ついてたりするし、現状のものフィットさせすぎてちょっと操作性変えるだけでも大規模に変更が必要そうに見えるし、どこから手を付ければいいのかって状態だし

どこで値が変えられてるとかが追うのだけで時間が過ぎていく

どこがどういう仕組になってるとか、こういう変更ではここを変えればいいとかいう手引きがあればまだましだが、そういうのは全くない

余計なことせず単純にコントロール並べて、単純にデータ取得や保存する作りで作られていたなら1日もあればで終わったであろう簡単修正依頼が1日で1割程度しか終わらない

作った本人はこの方が楽だったんだろうが、他の人が使えないもの作るのはやめてほしい

というか、ファイル名が連番でどのファイルがどの画面に対応してるからすら開いてみないとわからないレベルだったのだが作った本人はこれで苦労しなかったのだろうか・・・

仕様書対応表があったのかもしれないが今あるのはこのコードだけだ


最後まで面倒見れないなら、世間一般の作りに合わせるとか有名どころのライブラリ情報があるものを利用してほしい

退職のつもりなくても、病気とか怪我で代わりの人に任せるとかはあるだろうから出来る限り、独自の作りはやめてほしい

有名どころのOSS並に丁寧なドキュメントFAQとか作れるなら別にいいけど

2017-10-14

あと5年もすれば昔を知る人が居なくなり日本中で同じ事が起こるだろ



あと5年もすればいよいよ昔を知る人が居なくなり日本中で同じ事が起こるだろ

技術者を軽視してきた経営側・管理側の招いた負の遺産となるだろう。

Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。

こういった無意味な人事ローテーションをやめて、スペシャリストをしっかり身内に育成してきていれば良かったのに

残念なことに、「属人化は良くない」といった言い訳で、専門家を軽視してきた。

Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

みんな沈む。

https://anond.hatelabo.jp/20171012165214

2017-10-13

俺は役所側のシステム担当だけど

https://anond.hatelabo.jp/20171012165214

うちのプロジェクト普通に成功したので特に面白い話はない。

つーか失敗が稀だからニュースになるのであって、実際は成功するのが大半だよ。

そもそも入札してもらえないと始まらないので、仕様書にあまり無茶なことは書けない。

開発中に新規要件が出ることはあるけど、こっちだって完成しないと困るから適宜調整するし、無理な分は来年度以降の課題ということで先送りする。

その結果市民からは「不便すぎる役所死ね」と叩かれることもあるけど平謝りするしかいね…。

なので京都市ほどこじれるのはうちの役所では考えられん。

まあメインフレームはどんどん消えてくし、異動があるとはい組織内でのノウハウは蓄積されるし、特許庁みたいな反面教師を挙げて庁内を説得できるようにもなったし、どこも段々と良くなってくんじゃないかなー。

公務員から成功しても失敗しても給料は(ほぼ)変わらんけどな。

https://anond.hatelabo.jp/20171012165214

Q3.使いまわしってどうやってやるの?

言語への移植は、自動的にやるととんでもないソースコードが吐き出されるから

普通は以下の手順ではなかろうか。

1.旧言語ソースを見て仕様書を起こす

2.人間実装しなおす

2017-10-12

anond:20171012165214

しばらく前に8年くらい前のろくに仕様書が残ってないPHPシステムの移行見積もりやったけど

新規に作る場合の1.4倍くらいの金額になったなぁ

もちろん受けずに済みました

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

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汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-10-10

SI屋の元締めの人たちは設計書を元にシステムができていると信じている

いや仕様書設計書の通りに(少なくともそれをもとにして)作られているべきでしょうよ

そうなっていないのはある意味怠慢なのだから、そこで威張って無知こき下ろししても仕方がない

2017-09-23

仕様書カキカキ 事務書類カキカキ

何だか全く成長してる気がしないぞい

いくら繰り返しても会社ローカルルールに少しずつ詳しくなっていくだけで、他の会社行ったら経験値0からスタートになりそうな状態のまま時間けが過ぎていくぞい

日本人会社クビになったら路頭に迷うのってこういう意味のない仕事をやってる人だらけだからなんだろうな

2017-09-11

職業プログラマーに向いてそうで向いてない人の5つのパターン

すまん5つと言ったのは適当だ。

から考える。

まあ3つは既に思いついているのでそれを書きつつ残り2つを埋めるとしよう。

コミュニケーションが苦手な人

まずはこれだ。

職業プログラマーってのは仕様書に従う仕事だ。

そして時には仕様書にはよく分からない内容が書かれている。

「青い色をした黄色ピーマンを作ってくれ」

みたいな感じ。

なんかこうよく分かんないよね?

それを「こういう意味でいいんですか」と言えなきゃ駄目だ。

いきなり青いパプリカを作って持っていき、相手から「俺はピーマンが欲しかったんだ!それも青と黄色の斑模様のな!」と言われてから急いで作り直すのはプロとしてよろしくない。

コミュニケーション力は必須だ。

グーグルプレイストアに広告付きアプリや有料アプリを並べてコツコツお金を稼ぐパターンを狙うなら無くてもどうにかなるかもだけど

物事本質をどこまでも追求したがる人

これも駄目だ。

プログラムってのは全部が論理的完璧って訳じゃない「コレなんかおかしくね?」と感じる部分が多少はある。

本質本質本質まで追求し続けようとしたらそのうちプログラムなんて書けなくなる。

趣味でやって突然ドツボにはまるのならそれは個人勝手だけど、仕事場でそれをやるのはいただけない。

体力のない人

散々言われすぎてかえって馬耳東風になってるだろうけどこれはガチだ。

プログラマーはかなりの体力勝負だ。

ガテン系仕事なら熱中症対策事故対策という言葉の元に休めるタイミングでもIT土方は休めない。

自分はそんな会社はいかない!と宣言できるほど運がいいならFXでもやったほうがいい。

ネガティブな人

疑心暗鬼になって細かい所を気にする性格プログラマー向きか。

NOだ。

かい所を気にするよりもトライエラーを繰り返すのが正解だ。

10歩進んで9歩戻るのを繰り返す内に10歩進んだのに6歩しか戻ってないぞ!、ってなるのがプログラム世界だ。

1歩ずつ進もうとする事は実はリスキーだ。

クリエイティブな人

プログラマーに求められるのはクリエイティブさじゃない。

プログラミング言語様と仕様書様に忠誠を誓って淡々とその責務を果たせることだ。

クリエイティブアイディアなんて言語様も顧客様も求めてない。

平凡かつ従順でいることが最大の美徳だ。

そしてそれらは半端なクリエイティブさを発揮することよりもよっぽど難しく才能がいるんだ。

ちょっと独創的なだけなのにそれを才能だと思って大事にしてるようじゃ職業プログラマーには向いてない。

よっし5個埋まった!

後半の2つはその場ででっち上げるつもりだったが、前々から考えていた事を思い出してしまったのでそれをそのまま書いた。

ああ最後に1つ言わせてくれ、5つとも当てはまっているがそれでも職業プログラマーを目指したいと勉強中の君はそのまま頑張ってくれ。

何より大事なのは自分から勉強することだ。

それさえ出来てるのなら、無数の困難も乗り越えられたり乗り越えられなかったり乗り越えてるのはホーム黄色い線だったりだ。

頑張って

2017-09-08

2週間やる気が出なくて辛い

やる気が出ない。

ホントでない。

出ない原因は何かと問われると仕事がないから。

その流れで仕事がきたけど仕様が決まっていない。

お陰で更にやる気が出ない。

仕様FIXしたとお知らせが来た。

よし!やるぞ!

仕様書を開くと、難解な項目の羅列に難解な説明分。

私「おめー!これ仕様書として書いたのか?初めて見る人でもこの資料をみて、作業ができるようになっていて、誰が作っても同じようになるよう誘導するもの仕様書なんだよ!」

FIXマン「い、忙しいんです。。。」

なんで忙しいかというと、この仕様書書いてるやつが散々サボってきてからだ。

それでも、とりあえずポチポチ作業を進めてみると。。。

この項目とこの項目一緒じゃね?それにこれも辻褄合わないよな。。。

私の理解が追いつかないのかもしれないから聞いてみよう。

私「こことここの項目一緒じゃないですか?」

FIXマン「待って下さい。」

・・・

FIXマン「問い合わせます

なぜ問い合わせるかというと、お客さんから言われたとおりにそのまま転写しただけのようだ。

FIXマン「一緒らしいのでこっちの項目消しますね。」

よろしこ。

ふ〜。。。。

私「ここのところの項目辻褄合わないように思うのですが、こういう意味であってますか?」

FIXマン「問い合わせます。」

・・・

こいついなくてもいいんじゃね?

そんなこんなで私が仕事していないみたいで辛いです

まぁ、他のところポチポチしてるからとりあえずは。。。

やる気でね〜!

2017-09-06

エンジニア経営者単純労働者の脛を齧って生きている

働かざる者食うべからず、働かずに金や地位で金を生むだけの奴らは社会邪魔だ。

そう言ったのはどっかの時代の真っ赤な頭の共産主義者だったとか。

そんな事は置いといて、俺たちは最低の人間かも知れない。

俺はエンジニアにも単純労働者にもなれてないまま経営者の指示通りに彼らに鞭を振るだけの仕事をしている。

表面上は必死に頭を下げて、心の中でも頭を下げて、それでも彼らに報いようとはしていない。

面倒くさいから、そんな事しなくても暮らしていけるから

頭を下げて経営者命令通りの仕様書押し付けていきゃいい、そんな俺達の態度に経営者はご満悦だ。

辛い。

俺達はまともに生きている人や価値生産している人間の前に転がった石ころだ。

そんな可愛いものじゃない。

もっと重たくて鬱陶しくて、相手おんぶ抱っこで押しつぶすような、そうだ、子泣きじじいだ。

俺達は社会の子きじじい。

石ころ程度の価値しか無く、赤子のようにわがままで、無力な癖に握力だけは鍛えに鍛えた老害だ。

俺達はそこまでして生きたいのか。

生きたいのだ。

生きたい。

何もしなくても生きていけるならこんな事もうやめたい。

だけど俺たち無能が今更ちゃんと働けないんだ。

技術者になれるような知能はない。

単純労働者になれるような根性はない。

肩書以外は何もない。

働かないほどの金も、働かずに稼げるような地位もない。

ただほんのちょっと肩書きだけで無理やり生き延びているんだ。

ニート遺伝子が半分一緒だという理由だけを印籠にして実家居座り続けているのと何も変わらない。

ダニだ。

俺達はダニだ。

でも死にたくはねえんだ。

ダニでもいいから生きていたい。

2017-08-23

愚痴

愚痴である

完全な愚痴である

読みたくない方は帰られたし。

事の発端は社畜歴3年ほどの俺がひょんな事から先輩社員に指示を出す立場になったことから始まる。

最初はヒイヒイだった仕事も段々と(手を抜く)コツを覚え、ある程度は臨機応変対応可能になった頃だ。先輩社員担当していた作業が諸事情ストップしてしまい、なんやかんやで「お前のとこで仕事何かないか」と俺のところに話がまわって来たのだった。正直一人でも対応可能だったが作業が軽くなる分にはありがたい。諸々のスケジュール調整やら、仕様書やらを割り込みで作った。

作業に入ってもらう段になった。

今までは指示をされる側だったから少し不安だったが、とりあえず自分作業する時に聞いておきたいことを伝えときゃいいか、と思い

工数は何日か(リカバリ可能なように少し多めに見積もり)

・どういった意味合い商品になるか

データの重さの目安

クオリティレベル(既に出している商品サンプルとして共有済み)

等々、仕様は思い付く限り細かく伝え、他に不明な事があったら聞いてほしいと言う旨は伝えてあった。

これで「大分余裕出るぞー!」と思ったのも束の間、クライアントとの連絡で手違いがあり、仕事が急に増えてしまった。「いやぁ作業手伝ってもらってて助かった」と思いつつ作業を進めていたらいつの間にか先輩社員の下にお粗末さんが誕生してしまっていたのだ。

勿論、都度チェックを取らなかった俺が悪い。そこは完全にこちらに落ち度がある。

から終電帰りも早めの出社も休み時間返上も、まぁ不満には思ってない。(普段仕事+上手く回すのも役目だと思っている。段取りが悪かった俺が悪い。)

ただどうしても「もう少しなんとかならないのか?あんベテランなんだろ?」と思ってしまう。もう少しプロ意識と言うか、仕事に対してもう少し真摯になれないのだろうか。俺なんかは作るものには愛情というか執着というか、なんかよく分からない何かを込めてしまうんだけど、そういったモンはないのだろうか?(過度な要求なのだろうか?)

長文、乱文非常に申し訳ない。眠い中書いてるから朝読んだら支離滅裂で、読み直してジタバタしそうなきがする。(でも投稿はする)

なんかあーだこーだ書いてはいるが結局ケツ拭きも俺の仕事なのは変わりないし、そもそも他人に期待するのが馬鹿な話だっていうのもわかっている。でもさぁちょっとモヤモヤするじゃん。愚痴くらい言わせておくれよ。

とりあえず今日は眠すぎるしもう寝て明日に備えたいと思う。

どうするかは通勤時間に考える。

2017-08-22

裁量労働制問題プログラマエンジニアに呼び変えれば解決

https://news.yahoo.co.jp/byline/konnoharuki/20170821-00074756/

プログラマエンジニアと呼ぶようにし、みんな裁量労働制にしちゃえばいい。

テスト仕様書通りにテストするだけのテストエンジニアCSS書くだけのマークアップエンジニアなんて職種もあるのだし

Web系は仕様書を書かずにいきなりコーディングに入るのが主流だし

アジャイル開発を採用していれば無条件で裁量労働制適用もすべき。

2017-08-14

現場を知らないのに仕様書書いてる

新規採用半年

毎日せっせと共有サーバー内の古い仕様書コピペしてはツギハギで新しい仕様書を作る仕事をしている。

自慢じゃないが自分現場の事は微塵も分からない。

たまたま入った会社たまたま入った部署がそういう所だったか仕様書を書いてるだけだ。

この分野に特に興味もない。

最初から全てに興味がなかった訳ではなくて、全体の中の一部には興味があったが、それも半年働いて実は自分の興味がある系統とは違っていた事に気づいた。

まりは今現在仕事について興味のある部分は何もない。

何の興味もない分野の何してるのかよく分からない仕事仕様書コピペパッチワークで量産する毎日だ。

関連する業者からの連絡事項もほとんど意味が分からない。

上司の所に持っていって上司が出した裁定をそのまま投げ返すことでキャッチボールをかろうじて成立させている。

こんな仕事のやり方でいいのかと疑問はあるが、上司も周りも特に何も言わないし、失敗すると「自分最初はこうだった」と言うしきっとそういう物なのだろう。

自分は今何をやって、どうしてこんな適当仕事給料が貰えるのか一切わからない。

でもきっとそういう物なのだろう。

2017-08-09

仕様書がふんわりすぎるんだが

柔軟剤使っただろ?

2017-07-23

メンヘラお金がかかるという話

メンヘラは、お金がかかる。

治療費がかさむだけではない。

ここでは、自殺就労不可になる問題に隠れているメンヘラ経済問題について述べたい。

うつ病になるリスクが少しでも知ってもらい、

そういった事態になるまで自分を追い詰めてしまう人のブレーキになれたらと考えている。

自己紹介

私は、10年来のうつ病患者である

大学時代からずっとうつ病の処方を受けている。

処方薬は、ジェイゾロフトデパスだ。

数年前に、ブラック職場につとめることで、それが悪化した。

その会社で、ゲーム開発のプロジェクトマネージャーをしていたのだが、企画を補佐してくれるものがいなかったため、

PM兼、プランナー兼、アートディレクター兼、クラアント対応といった業務までしていた。

平日だけでは業務が終わらず、土日もメール対応仕様書を書いていた。

そういった無理がたたり、たまにできた暇な時間も体調が悪く遊びにいくことも家事をすることもできなかった。

メンヘラの基礎支出

まず治療費である。通院代、処方箋代がかかる。

自立支援医療制度という精神疾患を患っている人を支援する制度があり、

それらの費用が通常の自己負担額3割から1割になるとは言っても、一回行くごとに1500円、月2回行くので3000円かかる。

ついでにいうと、その手続には、診断書必要であり、その発行に5000円かかる。

最寄りの病院でない場合は、それに合わせて、交通費必要になる。

それに加えて、一番大きいのがカウンセリング代による支出である

私の行くところは、40分で6400円ほどかかる。

カウンセリングなんて、役に立つのかと健康な人は思うかもしれない。

だが、処方箋なんてものは、所詮対処療法であり、心理的問題解決することはない。

また、人に話すことで楽になることはたくさんあり、しかカウンセラーしか言えないこともある。

例えば、「死にたい」「殺したい」といったワードである

見ず知らずの人に、そんなこと言えるだろうか? 困られせてしまうだけである

というわけで、私はカウンセリングにて、毎月2回20分受けていたので、月6000円が飛ぶ。

しかも、カウンセリング代は、医療費として認められていない。

そのため、医療控除の対象外となる。

というわけで、病院とその処方箋で9000円かかる。

東京在住で年収300万いかず、奨学金の返済にも苦しんでいた私には、

それだけで貯金をする余裕を奪うには十分な威力であった。

家事ができないことのしわ寄せ

家事ができないことは、とても大きな経済的な損失につながる。

例えば、部屋が片付かないため、何を買ったが判断できなくなる。

すると、同じようなものを何回も買ってしまう。洗剤や歯磨き粉が複数ストックされる。

そして、掃除サボることにより家の汚れが取り返しの付かないことになることも、大きな損失になりうる。

引っ越す時に敷金がもどってこないどころか、6万円近くのクリーニング代などを要求されるてしまことを、

思考がどうかしているうつ病患者の私には想像する気力もなかった。

お金を使うか否かの適切な判断ができない

うつ病になると、冷静に考えてお金を使う判断力が失われ無駄な買い物が増える。

場合によっては、ストレス発散のために、高い買い物をしてしまうこともある。経度の買い物依存症である

そして、あらゆるめんどくさいことを、お金解決しようとしてしまう。

私の場合引っ越しの時にそれが訪れた。

ブラック職場から脱出した私は、引っ越しを決意していた。

からも遠かったため、少しでも心理的負担がかからない場所引っ越したかたからだ。

部屋汚れや不要ゴミ処分業者に頼んだ。

上記の様な状態の私はただでさえ貯金がない状態であり、引っ越しにかかる費用クレジットカードを利用した。

転職先でのボーナスなどをあてにしていたこともあった。

そこらへんの判断も、今ふりかえればどうかしている。

だが、明らかに思考力がまともじゃなかった私には、なんの疑問も感じなかった。

そして、引越し後のクリーニング代の請求である

新たな引越し先への敷金礼金以外にも、20万以上つかってしまっていた。

■まとめ

うつ病になる→治療費がかかる&働けないのでお金が稼げない

という流れは広く知られている。

だが、それだけではない、

うつ病になる→判断力が失われる→不必要支出が増える

うつ病予備軍の人は、上記の様なうつ病になる大変さを理解して欲しい。

すでにうつ病の人は、私の様な自体に陥らない様に気をつけて欲しい。

私はこれの様なリスク理解していなかった。この過ちが、後に、大きな不幸をまねくことを私はまだ知らなかった。

その不幸については、また今度投稿する。

2017-07-20

なんでもできて、なんにもできない。

35歳定年説なんてのが、IT業界だと実しやかに言われてた。

当時20代だった自分は35歳定年説をなんとなく信じていて、

毎日が焦りの連続だった。



新しい開発言語が今後のトレンドになると聞けば焦って勉強し、

マネージメントの力が無ければ35歳を乗り切れないと言われればマネージメントの講習を受け、

現場プログラムを書くだけじゃ将来的に困ると言われクライアント営業になり、

営業をやるのであればマーケティングもわからなければと講座に通った。

全部35歳以降の自分の姿が見えなかったので、

ただただ焦っていたんだと思う。

そしてその焦りから、色々な物に手を出してはみるものの、

「その知識だけでは食っていけない」

と思い込んでしまい、次へ次へと追い求めてしまった。

気づけば中途半端知識経験が山のように手元に残った。

プログラミングはできる。でも、同年代エンジニア一本の人と比べたら雲泥の差。

要件定義仕様書も一応書ける。でも、ちょっと大規模なものになったら全く歯が立たない。

新しい知識も追いかけた。でも、若い世代のすごい子と比べたら知ってるというのもおごかましいレベル

営業マーケティングもやった。でも、コンサルになれるほど突き詰めてはいない。


そして、35歳になった。

転職活動をしている。業務経験は実に多種多様ものが揃った。

でも、どれもとても短く浅い。

「○○という業務はやった事ありますか?」

という質問に「はい」と答えた後に繰り出される

面接から少し突っ込んだ質問

どれも浅薄知識しか答えられず、

すぐに面接官に見破られてしまう。

流行りのフルスタックエンジニアなんて言えば聞こえは良いが、

レベルの低いフルスタックは「なんでもできて、なんにもできない」だ。

俺を買ってくれる人は今日も現れなかった。

2017-07-19

anond:20170719142651

なんと具体的な回答が!

なるほどね。食ってかかるようで申し訳ないが、

それで7割減は大げさでないの?

自分もずいぶん前にドキュメント作成方法についてはいろいろやってみた。

から「7割減」に食らいついたんだけど、

例えばjavadocのようにコンテンツ記述のみ行えばよくて

デザインレイアウトは決め事という方法をとっても7割減はむりだろ。せいぜい3割減だと思う。

要件定義書インフラ設計書なんかは書式的に面倒なことは少ないと思われるので、(詳細設計書は自動生成として)

おそらく面倒なのは基本設計書、テスト仕様書と結果報告書だと思うが、

それらにはjavadoc方式(内容と書式の分離)では表現が不足して実用にならないだろう。

というわけで元増田ドキュメント生成ツールを開発して無償でつかえるようにしてくれ。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん