成功に嫉妬する妻
今読んでいる本に出てくる話のひとつ。成功話の本かと思いきや、失敗と不幸話がメインだ。自分の身に降りかかるかと想像すると回避したくなる事ばかり。でもその落とし穴には確実に落ちるというのだから恐ろしい。事前に分かっていれば回避できるっしょ。なんて思ってる主人公がことごとくハマっていくのだから救いが無い。
成功し、努力し続ける夫に置いていかれたような気がして、妻との距離はどんどん離れていく。実際に自分の身にも似たような覚えがあるので、これは現実として十二分に起こりうる事なんだろうなと思った。そして事例として上がっているものが、どれもこれも現実味がありすぎてのめりこむ。世の中にはこんな法則もあったのかと、怖いもの見たさで読み進める。ひさびさにストーリー性があって楽しめる不幸話をつづった本。ゆっくり読んでいるつもりが、少ない通勤の電車内で半分以上読み進めてしまった。もったいない…。
次の次の次の次の次くらいの本においコーが待っているので早く読み終えたい気持ちもあったりなかったり。順番待ちしてるんだから、浮気はいかんです。自分で決めた順番で読むのです(笑)
息を抜くタイミングは煮詰まった時やゆとりある時か
今の私は結構忙しいと思っています。だからといって、息抜きをしたいとは思っていません。むしろ、今は息を抜きたくないと思っています。漠然たる恐怖感があって、息を抜こうとは思えないのです。
本当に一杯一杯の時に息抜きをすると、パンパンに膨らんだ風船の口を手放した時のように、一気にしぼんでしまう気がするのです。そして丁度良い張り具合になるまで時間がかかると思うのです。それが現実だとやる気が無くなったり、仕事が手につかなくなったりしそうで怖いのです。一言で言えば燃え尽きてしまいそう。
追い風に乗ってとにかく走り続けている時、休憩しようと立ち止まったら最速で走っていた時の追い風に背中を押され、もう一度走り始めようとした時に足がもつれて転んでしまいそう。そんな想像も浮かんでいます。
じゃぁいつ息抜きをしよう？と考えてみると、煮詰まった時かなと。がんばってがんばって最後の詰めだ！という結論が出そうな時、もしそこでゆとりがあるなら息抜きしても良いかなと。そしたら煮詰まったと思っていた事に、+αで新しい事が思いつくかもしれない。
あとは本当にゆとりがある時。ゆるやかな追い風に吹かれている時はふと立ち止まってその風に吹かれてみても良いと思うのです。押し倒される事もなく、無理やり歩かされる事もない。だけど、走り始めればちゃんと背中を押してくれる。そんなゆとりある追い風が吹いている時。
しかし、ガス抜きは別。余計なガスは爆発する前にフシューっと抜いた方が良いと思います。飲み会を催すのは息抜きというよりガス抜きの意味が強いかも。というわけで、今の私はまだ気を抜くことができないようです。
34℃の朝！
おはようございます！起きた瞬間の感想。「暑い！」もうこれしか言えません(笑)温度計を見ると室温が35度超えています…なんなんだ私の部屋は…いくら風通りが悪いからってこれはあんまりだろう。とか思いつつ、パソコンがあるからしょうがないか♪とパソコンのために部屋の暑さを許してしまう自分もいた(笑)
外に出ると太陽の光が熱い熱い。地面からの照り返しも熱い熱い。ビルの上に出ている電光掲示板には「只今の気34℃」と出ている。昨日の30度はまだまだ涼しかったのだなぁと思った。こんな調子で夏本番がやってきたら、どれだけ暑くなってしまうことやら(^^;。でもこの調子で暑さが続けば、暑さにも慣れちゃうかなと思っています。ここでいきなり寒くなったりするから、例年体調しそうになるんですけどね。
本当は朝っぱらからビールをぐびっと飲みたい所ですが、仕事が終わってからの方がもぉーっとうまい！ということで、今日も一日がんばりましょー！
仕様書の質は、仕様書の書式である程度決まる
X年前に作成された仕様書の書式で、今回のJavaのシステムの設計書を書いてください。と言われ、その設計書の書式を見てみると中途半端にJavaの事が書いてある。パッケージ名とかクラス名とかメソッド名とか、JavaBeansの変数名だとか。それはプログラマが実際に書く時に決めれば良いだろうにと思いました。
大規模システムで画面とかがコード管理されている場合は、機械的に記入しても良いんですけど、そうではないので変数名を考えている時間がもったいない。いつ時点での仕様書かにもよりますが、まずは実現すべきことを自然言語オンリーで書けば良いと考えています。
中途半端に書くとプログラマは"その通り"に書くので、実際にメソッドを分割したり、クラスを分割したりする事をしなくなり、1つのクラスが莫大に大きくなったり、共通化をしようとしなかったりする。そうならないために、フレームワークがあり、フレームワーク内ではどのようにプログラムを作るべきか。そういう開発指針的なものは仕様書とは別に共通の資料として用意する必要があると思っています。
仕様書の読み方、仕様書からプログラムの作り方、プログラム構築の指針。こういう資料はあると無いとで最初のとっかかりが随分違いますし、後々の品質の均一化にも影響が出ます。特に限定するわけではありませんが、オフショア開発を例に取ると指針が無くて自由自在にプログラマに開発を行わせると一貫性の無いプログラムが大量生産されて、受入テストが大変だったり、保守性に乏しくなったりしました。
表題に戻りますが、仕様書の質はある程度仕様書の書式で決定されると思っています。書式によって書くべき内容が決定されますから、全部フリー入力でも無い限り書くべき内容というのが書式によって指示されます。その指示される内容が現在の開発スタイルには合わなかったり、情報が足りなかったりするとその半端な品質で仕様書が均等化されてしまいます。
機能の説明ひとつとっても、「機能詳細」という欄が一つだけあると、上から下まで細かく書いてしまい、読み手は概要を掴むのに一苦労します。そこに「機能概要」という欄があれば、ざっくり機能を掴んだ上で、詳細を読み進める事ができます。「機能詳細」についても、中に「イベント」という欄があれば、その機能が呼び出される元を記述する事ができます。
知りたい情報から書式が起こされたのが最初だと思うのですが、その書式を作ったのがX年前というと、今の開発ではちょっと役不足。COBOLの仕様書から起こしたんだなんていう資料は昨今のJava開発ではちょっと書きづらい仕様書だと思いました。例えば最初からStrutsを意識された仕様書だったら、ActionとFormに分けて仕様書は書くでしょうし、詳細に詰めるとメソッドの定義から機能の詳細、入出力項目からバリデーションの詳細と掘り下げて書く事ができます。プログラムレベルまで考慮された仕様書は、設計書と言った方がしっくりきますけど、ここでは特に意識して言葉を使い分けていません。
汎用的な仕様書というのは、フリーフォーマットくらいで、ある程度は言語やフレームワークに依存した形の仕様書が開発を楽にすると思います。書式に合わない事は書かないのではなく、フリー入力の欄に書き入れれば良いと思いますし、プログラマの足かせのためのフレームワークというものがあるのならば、仕様を書く人のための足かせが仕様書の書式だといえなくもないかもしれません。
ということで…「仕様書の読み方.doc」はとても重要！
