  |
はてなキーワード: 定義書とは
闇の義務教育期間を過ごしてきたので愚痴と悪口がとにかく苦手かつ嫌い。その種の会話を聞いただけでも喉がすごく渇いて痛みがするし、心臓がばくばくと鼓動がはやくなる。ひどいときは一人になった途端に涙が溢れ、止まらなくなるレベルだ。つまり愚痴と悪口に対する耐性が超弱い。
また聞くだけではなく、わたし自ら悪口愚痴を言うことも駄目である。愚痴ってみたこともあったが、気持ち悪さで魂が死ぬ。むり。
と書いてきて、ここでいう悪口愚痴 の定義書いてなかった。書くわ。
大雑把に言えば、感情論による、結果がない他人の悪評。または議論。
まじで何を言いたいのかがわからない。ひたすらに負の感情をぶつけられるだけの会話。相手がこうしたらもっとよくなるのにと建設的提案がない感情論。悪口及び愚痴の共感だけがほしい会話。
それが超嫌いでほんとうに気持ち悪くなる。もう本当に涙が勝手に出てくる。鼻水がだらだら出てくる。鼻炎だからしゃーないけども。
あーほんとに、これ書いている時点でもう気持ち悪い。けど頑張ろうな、あと少しだ。
で、まあ愚痴悪口超嫌い、心身ともにまともではいられなくなるので、言わない聞かない触れないを徹するのだ。自衛だ、自衛。
この世のなか、愚痴と悪口だけでできているんじゃないかと何回も絶望したし、絶望することに飽きてるんだけどもな、まあ好きなことに没頭してたらどうでもよくなるんだわ。
大体愚痴悪口を意気揚々と話す人間に良いやつはいるわけねえし、わたしの知らないところでわたしの愚痴悪口を言っているはずさ。そんな人間にわたしの人生を、時間を、意識も感情もなにかも、向けたくないね。切り捨てるさ。心身を殺されたくない。
なので自衛。心にガード。
とまあここまでかいてきて、結構スッキリしたので終わりにする。
新しい技術も独学で追ってて、私のような技術力マイナス値のSEが書いた
こちらが考慮漏れしていた部分について聞いてくれたり対応方法を提案してくれたり…
とにかく彼らが私より給与が低いことがにわかには信じがたいほどに仕事ができる。
でもなぜかずっとうちにいてくれる。（正しくはうちの発注先でいてくれる。）
そこでちょっと見渡してみて思ったんだけど
やっぱり話すのが苦手っていう人が結構多いっぽい。
例えば自分の立場だと顧客と直で打ち合わせたり交渉したりお願いしたり
時には罵倒されながら色々雑用チックなこととか接待っぽいこともやる。
それが嫌だからうちの下に入ってくれてるのかもしれない。
彼らがもし重大なバグを作り込んだとしても、開発が間に合わないとしても
顧客に頭を下げるのは私達なのでその辺うまい役割分担なのかもしれない。
めちゃくちゃ尊重してるので無理な深夜残業とか休日出勤はほぼお願いしない。
時々土下座する勢いでやってもらう時あるけどもちろん自分も残業＆休出する。
実際ほんとは転職したいけど時間がないとか面倒とか思ってるのか
一度聞いてみたいような聞きたくないような。
なんでいつも、後で絶対設計からツッコまれて手戻り確定な、漏れ漏れの要件定義書いて仕事した気になってんの？
下請け以下は設計以降の仕事のためにいるんであって、お前らの尻拭いのために来たんじゃねーっつーの。
てか元請の仕事って、
だろ？最低でも年収500以上は貰ってるエリート様なんだから、そのカネに見合う仕事はしろよ。
こっちはどんなに設計がクソでも、その通りに実装してテスト通すという、最低限の責任は果たしてんだよ。
てか、デカい現場で一介のプログラマごときが創意工夫する余地なんて全く無いから、ライン工に徹してやってんだろ。
それで粛々とモノが出来上がったためしがないとか、本当にSIってクソな仕事だよな。
どうあるべきなんだろうね、と思うことがある。
私はインターン生として、とあるIT企業（本社の社員は15人くらい）で働いている。
僕の向かいのデスク群では、発注されたシステムの開発・デバッグ等が行われているんだけど、そこのチームはどこからどう見ても無能なメンバーしかいない。
報告連絡相談ができない、報告などをしても声が小さくて何を言っているか分からない、分かったとしても質問になかなか答えないし言い訳ばかりする。だからその部署のリーダー的な人はいつもカリカリとしているし、口調もかなりキツイ。例えば
部下「ゴニョゴニョ」
上「は？何？」
部「...通しました」
上「分からないところとかなかった？」
部「...なかったつもりです」
上「それでこの進捗？何してたん？」
部「すみません」
上「すみませんちゃうやろ、分からんとこでもあったんかクソが」
部「なかったつもりです」
上「分からんとこなくてこれならほんまに終わってんな、もうええわw」
みたいな感じ。
いや、確かに上司が言っていることは間違ってはいない。無能なのは部下くんだし、ミスしたのも部下くんだ。
でも、ですよ。俺がもし部下くんだったらね、仕事全然楽しくないし絶対やめたくなると思うんだ。これは甘えかもしれないし、単に部下くんがこういう仕事に適性がないだけなのかもしれないけど、せっかく採用してその会社で働くことになったんだから、ある程度上司って部下が楽しくやっていけるモチベーションとか環境とか用意していくべきなんじゃないか？と部下くんを見ていると思ってしまう。
毎日どんな仕事をしているんだろう？と思いながら毎日仕事しています。
IT企業とはやや遠い会社の中の、内製でシステムを開発する部門に配属されました。
情報収集のためにネット使っていろいろIT関係のことを調べています。
IT業界の人のブログとか読むと、キツイキツイばかり言ってる人とか、
ちょっと意識高すぎて、こいつマジでなんかわずらってんのか？って疑いたくなる人とか
ちょっとうちの会社の人の雰囲気とぜんぜん違うな…ってびっくりしますけど、
ああいうものをアップしてくれている人には本当に感謝しています。
システムエンジニアなんてなりたくてなったわけじゃないけど、
技術屋として降参するのは、クソムカつくからちょこちょこと勉強しています。
ふつうのIT屋さんが出来ることは、自分もできるようになりたいと思っています。
でもどう勉強したらいいのかよくわかりません。
一応システムを内製する部門なので、毎日コーディングしたりデバッグしたり、
お客さん（社内）から要望汲み取ったり…そういう仕事はしています。
いまだにまともな形の仕様書とか要件定義書を見たことがありません。
上司もこれまでの仕事でまともに仕様書を書いたことがないそうです。
社外のお客さんと喋ったこともありません。（電話応対しかない…）
一般的なSierとかがやってる仕事は何も出来ないような感じ…。
こんなんでこの先食っていけんのかなぁ…と日々思っています。
要件定義書を業者に作らせてその業者の息のかかった業者だけで入札とかこの業界あるあるだと思う
主にパッケージソフトの開発とカスタマイズを行っており、私自身は営業を担当している。
昨今の京都でのシステム入札の話を聞いて、ちょっと前に手掛けた話を思い出した。
数年前に取引先の某団体から、その団体の管轄官庁が出している助成金を用いて、システムを導入したいと話が合った。
話を伺ったところ、相見積もりが必要だとのことで、当社に複数社分の見積を用意して欲しい、とのことだ。
当時２０代半ばと若かったこともあり、この段階で「ん？」と思ったが、同席した上司は「手配します」と回答していた。
最終的には、某団体の要件定義書（当社のパッケージの機能から逆引きして作成）を当社が作成し、
それに対する当社の見積書、当社の協力会社複数社から名義を借りた見積書をもらって提出、という形になった。
当社は数千万円、協力会社Ａ社は１億円弱、協力会社Ｂ社は１億円弱の金額だった。
もちろん金額・仕様共に当社がずば抜けているという評価になるため、助成金され通れば確実に当社に発注が来る。
お陰様で助成金も決まり（申請額から若干削られた模様）、当社への発注も決まったが、
本来（以下の価格は目安）、パッケージ＋カスタマイズで３０００万円で済むところ５０００万円の見積もりを出し、
それを元に４５００万円の助成金が通るということに対して、罪悪感と違和感を感じてしまった。
また受注のお礼として、某団体へは１００万円単位の寄付金、担当者へも過分な接待を行っていることにも違和感がある。
それのおこぼれとして給与を貰っている身なので強いことは言えないが、
余談だが、コンプライアンス的なトラブルで人間関係が悪化し年末に転職する予定なので、
なんと具体的な回答が！
なるほどね。食ってかかるようで申し訳ないが、
それで7割減は大げさでないの？
自分もずいぶん前にドキュメントの作成方法についてはいろいろやってみた。
だから「7割減」に食らいついたんだけど、
例えばjavadocのようにコンテンツの記述のみ行えばよくて
デザイン・レイアウトは決め事という方法をとっても7割減はむりだろ。せいぜい3割減だと思う。
要件定義書やインフラの設計書なんかは書式的に面倒なことは少ないと思われるので、(詳細設計書は自動生成として)
おそらく面倒なのは基本設計書、テスト仕様書と結果報告書だと思うが、
それらにはjavadoc方式(内容と書式の分離)では表現が不足して実用にならないだろう。
指摘TNX
引用元には
という一節がある。ここは自分なら
「要求分析結果を元に、システムやソフトウェアに実装すべき機能や満たすべき性能などについて顧客と合意形成する工程を「要件定義」という」
と記述する。
引用元の言う「要求定義」は俺の認識するところの「要求分析」であり、要件定義工程に含まれる作業であると認識している。
{"要件定義":["要求分析","実現可能性分析","要件判定(顧客と折衝)","要件定義書(成果物)作成","要件定義書(顧客による)承認"]}
現場により少々の方言はあるだろうし、引用元が間違っているとは思わない。
ググってみると俺と同じ解釈をしている事例は出てくるわけだが個々の引用までは避けたいと思う。
(けんかを売ってるわけではないので誤解なきよう)
「うっ...どうやらおれはもうだめみたいだ。みんな、後は頼んだ...」
「ちょっと待ってください！」
「なんだ...おれはもう...」
「まだ引継ぎが終わっていませんよ」
「引継ぎ？」
「後任の方に対して残すべきドキュメントはどこにあるんですか？」
「ドキュメント」
「あなたがここまでどれだけ進捗したのか、それを管理しているガントチャートなりバーンダウンチャートなりはどこにあるのかと聞いているんです」
「ガントチャート」
「ないのであればPCを渡すので、その中にあるエクセルで作ってください。私のLet's Noteをお貸しします」
「お、おれはMac派なのに」
「Macだとエクセルとの相性が良くないんです。表計算からワイヤーフレーム作成、進捗管理まですべて行えるエクセルが使えないなんてMacは信用なりません。」
「あの、これなにをかけば」
「始まりの村を出発してから魔王を倒すまで、どういったスケジュールでいくつもりだったのか、もう後付けでいいのでスケジュールを引いてください。お客様とやり取りするためにドキュメントは絶対に必要です。ドキュメントがないと魔王討伐どころかソフトウェア開発も出来ませんよ。こんなの常識です。」
「えっと、この装備品一覧っていうシートは何をかけば」
「そこではあなたが今持っている装備を全て記して頂きます。ちゃんとIDをふってくださいね。」
「ID」
「IDをつける際にはお客様とのコミュニケーションで誤解が生じないようにあえてA-xxx-xxみたいにつけます。確かに番号にするとまるでわかりませんが、リモートコミュニケーションにおいて、例えばマサムネと言われた時にそれが武器なのか防具なのかわからないので、装備品定義書を用意してそれを確認しながらやり取りしたほうがいいんですよ。あえてコミュニケーションコストをあげることで証拠づくりをするんです。小規模なプロジェクトならわかりやすい文字列でもいいかもしれませんが、大規模プロジェクトになるとそうはいかないので、今のうちに意味不明なIDをつけられるようにしておきましょう。あ、ちゃんとIDと名称の対応表は作っておいてくださいね。あと、この資料は紙に出力するので罫線などは勿論しっかり整えてください。」
「...」
「あ、勇者がおなくなりに」
