  |
はてなキーワード: 仕様書とは
ＳＩによくあるリプレイスの案件で、数百ページもある既存システムの仕様書を渡されて「あとはよろしく」と肩をたたかれた。
この仕様書がWordのファイルなんだけど、恐ろしいことに章ごとにファイルが分けられていて、総数が百以上になっている。目次もない。
ソースコードを読むときもそうだけど、こういうのはとにかく読むしかない。
はじめのうちは、その分量に恐れおののいて「Wordを結合するツール」とか「Wordを検索するツール」とか使って効率化しようとするんだけど、ぜんぜん作業が進んだ気がしないので、適当な所にあたりをつけてぶつぶつ言いながら（「書いた奴氏ね」とか）とにかく読み込んでいく。
そのうちに全体の輪郭がぼんやりと見えてきて、何となく目星が付いてきて、（そこそこ）効率的に読めるようになる。
そんな連休２日目。
うちは小さい会社だけど上から下まで自前で全部作ってる。
作ってるソフトは専門的であまり大規模なものじゃないんだけど。
1:お客さんが『大体こういうものが欲しい』とか言ってくる
2:機能の詳細や背景の数学的な理論などを調べる。あるいはアイデアを捻り出す
3:設計する
4:仕様書を作る。お客さんとネゴって詰める
5:作る
7:ドキュメントとか作る
こんな感じかなあ。
入って1年経ってないんでアレだけど。
新規業務かどうかは特に拘らないってことですね、わかります。
引き受けたら仕様書は自分と付き合って行くうちに築けばいいものね。
アイスクリームを買うときに大安かどうか程度には気にする派ですが、殆ど
確かにこれは差異を感じない。
アイスクリームを買うときに大安かどうか程度には気にする派ですが、殆ど
「CD返しに行ったら友人が適当に出したお茶に茶柱が立ってたかどうか程度には気にする派」と同じです。
新規業務の場合は開発環境とPCのスペックと求められるスキルを明確にして、
後は仕様書じゃなくて要件定義ていうか欲しいもん聞いて、出来るだけ高めに見積もった場合から3種類位だして
あれだなー、落ち込むなー。
世に言うデスマーチと比べりゃ、今月生理なかったけどヤバいかしら！！くらいの落ち込みなんだろうが。
なにが悪かったんだろうか。どうすればよかったのだろうか。
データの入れ替えが、上手く行っていなかったんだ。社会人二年目のぼくは、係長とタッグを組んで、お客様の現行システムのデータを、新システムの仕様にあわせて変換して、テーブルに移し変える、いわゆるコンバート作業を言い渡されていた（本当はデータ変換プログラムを作るだけだった）。
とりあえず係長の用意した仕様にあわせて……いや、違う。仕様書はなかったんだ。旧データと新データの項目の対応付けだけ、言い渡されたんだった（データ型も項目長も違っていた）。
まずプログラムの作りからして、間違っていた。実行前に踏むべき手順が、この作りだと多すぎる。とっととパンツ脱がしてズッポシ行きたいのに、昭和臭いコートから脱がしてあげなきゃならん作りになっている。手間がかかりすぎる。要は旧データをCSV吐き出し⇒CSVをSQLLorderで取り込み⇒取り込んだワークテーブルをプログラムで実データに変換⇒やっとInsert、なんてことをしなくちゃいけない。
それから変換プログラム自体のパフォーマンスだ。2年分のデータを取り込む、という作業に耐えられていない。ってか2年分もあるんスか係長、ぼくまだ学生だったころのデータなんスけど。とか言ったら鼻で笑われた。ともあれ、実行するだけで一晩かかるような処理を4本抱えていて、それを一日でやれというのだから、土台無理な話だ。時をかけるリーマン(With生成データ)にならないといけない。もっと早く動くものを作るか、もっと早く元データが用意されていなければいけなかった。
そして、作られたデータも正しくなかった。
コンバートした後で、新システム上で正常に動かなかった。これは、きっと事前にチェックできていれば回避できた。ぼくはそれをぼくの仕事ではないと思っていたし（言われたとおりのデータが用意できたかどうかの確認までしかしなかった）、他の人にしても、それを確かめる余裕がなかった。
あー。問題としては、
こういうことか。特に、重い処理を一晩で終わらせたい、というあたりと、ミスが多いというあたりが今回ぼくの三連休を奪った原因の主たる部分だな。殺す。
じゃあどうすればよかったのか。
三連休は昼も夜もなくセックスする予定だったのが、すべて駄目になった。けれどもまあ、こういう経験もいつの日かプラスに作用する日が繰るかも……
「明日から戦争だから」
「マジスか！！」
山を越えられる気がしない。
なんて羨ましい会社だ。
半年もやる気がある社員をゴロゴロさせておくなんて、普通できないぞ。
コーディングまで二年なんてのんびり育成計画、初めて聞いた。
今のうちにもっと自分に投資するといい。
飼殺しになるかは、自分次第だ。
俺なんて、半年経過した頃なんてコーディングはもちろん、仕様書バリバリ作成してもずっとバイトだったぜ。
けど、気持ち的に増田よりは楽に充実してたろうな。
まあ、どのみち半年じゃ経験にカウントされないから、大丈夫だ。
少なくとも、最低三年は経験積めよ？な？
頼むから。
ミィーティングは必須なんだが、相手が大阪なんだワ。当方、東京で、その移動を考えただけでも、欝。
月に１度ぐらいは出かけてるんだけどね。
こっちが仕様書書いて、確認はとってるんだけど、後から後から、こんな状態があるワ、とか言い出されると、どうにもならなくなる。
近場の仕事なら、直接言い返せることもあるんだが…
それでも、頑張って相手の言い分聞いて、つぶれないよに頑張ってるよ。
今のうちに勉強しときな。
上の人が書いてる仕様書やコードは読めるなら読んどけ。机上の理論だけでは済まない現場のノウハウが入っているはずだ。「ここはなぜこうしてるんだろう」と思うところがあったら覚えておけ。きっと何かの理由がある。
上の人の机に立ててある技術書のタイトルを見て、どういう分野が必要とされているか見当をつけろ。自分の知らない技術に関する本がたくさん並んでいるとしたら、それに関する(自分に理解できる)範囲の技術書を買ってきて勉強しとけ。必要な技術がプログラミングに関するもので、開発環境に触れる状況なら、自分でその分野のプログラムを組んでみるくらいまでやっとけ。
Chance favors the prepared mind. 明日、責任ある業務が上から降ってきたとして、君は自信を持って引き受けられるか? そうでないならまだ準備不足だね。
肩書としてはソフトウェア開発。
だけど、ソフトウェア開発なんてやったことはない。
SEのように設計するでもなく、コーディングするわけでもない。
部内のサーバ運用もちょこちょこやってみるが自分でもスキルのなさ具合に吐き気がする。
わからないから誰かのまねごとをするしかない。
スクリプトも真似ごと。
テストの内容も真似ごと。
ちょっと改造しただけ。
とりあえず、他のところが公開してる資料とかWebで調べたのとか見て同じタイプのテストを導入してみる。
さすがに何もわからないと嫌なので。何でやるのか休日に本を漁りにいって意味を調べてみる。
……ダメだ。広大すぎて埋もれそう。
問題起きたら調べてねー、と言われてソースの中を漁る。
cscopeとタグジャンプはそのうちにやっと覚えた（最初から知っとけ、恥ずかしい）。
とりえあえず現象が発生してる原因はわかった。
だけど、それが問題なのかどうか調べないといけない。
でも日本語版は古くて中の記述がこっそりかわってたりする。おのれ。
えーと、なんとなくやっぱり原因はわかった。
だけど、仕様って何それ？ 周りも誰もしらない。
だからまた放浪の旅に出る。
……やっとわかった。だけど、やってる人からすれば当り前のこと。
自分じゃなかったら一瞬でわかるんじゃないだろうか？
プロジェクト管理もまともにできてない。
テストなんて本で書いてることなんて眩しすぎる。
理念はなんとなくわかる。そうしたい。
だから自分のやってることのギャップがとてつもなく苦しくて惨めだ。
そんなことをいっぱいつなぎ合わせてなんとか今の仕事をしてる。
2000年以前はCGI全盛期だったのでPerlスクリプトを作ったり改造したりしてたときは楽しかった。
Perlですらもうついていけないだろう。
知ってるのはCとシェルだけだ。しかもまともな開発経験なし。
入社時にみんなで研修で作ったのが最後。
あの時はプログラム組める奴が少なかったけど、今じゃすっかり逆転してるだろうなぁ。
設計したい。
でも、俺の知識で作れるものなんてないんだ。
読んでもわからない。永遠に差は縮まらないような気がする。
挫折しそうだし、誇りも持てない。
隣の開発してる人たちを横目でみながら、みんな眩しくてよいなと思う。
自分もそっちに行きたい。
行きたいけど経験がない。
経験を積むためには技術が居る。
でも、もう遅すぎる。
ちょっと疲れた。眠って起きたらまた少し頑張ろう。
たとえ遅れていくとしても、歩むのを止めてしまうとあとは沈むだけだろうから。
自分には何が足りないんだろう。自分と凄い技術者の差はなんだろう。
埋められるものではなくとも、その原因を知りたいと思う。
ほい、やります。
コーダーやプログラマになるつもりはさらさらないんで、元増田みたいにコードばかり追いかけるつもりは無いけどねえ。
コーディングなんてのはアイデアを実現するための集団に過ぎないと思ってるので、あくまで重要なのはアイデアですね。
ただ、この業界にやってきて未だ数ヶ月なので、アイデアを高速で実現するだけの技術力が足りない。
というわけでしばらくはせっせと技術を蓄えなければいけない…。
ちなみに平日は自分で書いた仕様書に従って実装しております…。
未だに泥がどうたらこうたら言ってるやつは
http://anond.hatelabo.jp/20080717201617
平日は他人の書いた仕様書通りに実装して、土日は参考書通りにデモ実装して喜んでる暇があったら、自分の頭で一からアイデア考えて、すべての工程を自分でやれ。
土日に他人のWEBAPI使ってちっさいコード書いて自己満足してる暇があったら、フルスクラッチで大きなアイデアを実現してみろ。
ライブラリが使えるだけなのにプログラミングが出来ますって言っちゃっていいのかな？なんて引け目感じてる暇があるなら、さっさと自分で新しいライブラリ書いてみろよ。
ワンライナーが、コンパイラ依存が、言語仕様が、とかム板やブログで無駄な煽りをやってる暇があったら、何か他人に役立つものを自力できちんと最後まで作れ。
RSSリーダーの更新ボタン連打してる暇があったら、まだやられていないアイデアを目を皿にして探せ。
梅田モチオさん最高っとか余裕こいてる暇があったら、自分で起業して玉砕してみろ。
お前らのモヤモヤした悩みはお前らの行動によってしか解決されないんだよ。
起きてる間ずっと自分の頭で考え、決定的なアイデアに集中し、わき目も振らずに最後まで実装できたやつだけが、
偉そうにふんぞり返ってるアホをぶちのめせるんだよ。
