2005年07月25日

仕様書から主観を撲滅しよう

仕様書を書くとなると小学校から高校で勉強した国語力が必要になると思う人がいますが,実際は少し違います。
仕様書は小説とは違います。一つの文に複数の意味を持たせたり,行間を読ませるような文章を仕様書として書いた場合,先輩からパンチをもらうでしょう。
仕様書に求められるのは名文ではなく同じ解釈しかできない文です。学校で習うのは小説の作法に近いので,仕様書を書く際には有害となることもあります。
夏休みの宿題として読書感想文を要求するくらいなら,一日の行動を淡々と文章で記録させるほうがプログラマとしては喜ばしいです。
感想をはじめとする主観に満ちた文章はプログラマにとっては敵です。
定性的ではなく定量的な表現で,誰にでも分かる文章がほしいのです。

筆者が駆け出しのころにやらかした失敗をあげてみましょうか。
次のような一文を書いて先輩に見せたことがあります。

・大きいデータを渡すと,しばらくたってからタイムアウトエラーを出力します。

筆者「これでどうでしょう。」
先輩A(仕様書をざっと読んで) 「ダメ。話にならない。修正して。」(仕様書を床に放り投げる。床に散乱する仕様書。)
筆者 (散らばった仕様書をかき集めて退場)
    :
    :
(先輩Bに仕様書を見せながら)
筆者「この仕様書のどこが悪かったんでしょうか。」
先輩B「うーん。いろいろまずいね。」
筆者「自分では大丈夫だと思ってたんですが…」
先輩B「この処理はfoo()というシステムコールを使うんだよね。」
筆者「そうです。」
先輩B「大きいって書いてるけど,どのくらいのサイズ?」
筆者「foo()がタイムアウトするくらいのデータです。」
先輩B「foo()は何秒経過するとタイムアウトエラーを返す?」
筆者「えーっと…(本を調べながら)…30秒って書いていますね。」
先輩B「foo()の処理で30秒もかかるのはどのくらいのデータなの?」
筆者「実運用環境で調べてないので分かりません。」
先輩B「タイムアウトエラーって書いてあるけど,ユーザに何か通知するの?」
筆者「【タイムアウトエラーが発生しました。】というダイアログを表示するつもりです。」
先輩B「今の回答には五点の問題があるよ。
    (1) 【大きい】【しばらく】という表現が主観の入る表現で,仕様書を読む人によって値が一定しない。」
    (2) 【大きい】と記述した場合のサイズが調査できていない。」
    (3) タイムアウトエラーという記述だけではユーザに何を通知するかが仕様書を読む人に不明確。」
    (4) ユーザの視点から考えるとタイムアウトエラーが発生する場合は渡したデータが大きすぎる場合である。
      ユーザに通知するメッセージとしては指定したデータが限界を超えましたといった内容が適当。」
    (5) ユーザが30秒間操作できないのは致命的で,foo()にデータを渡す前にサイズをチェックしてエラーにするほうが親切。」
先輩B「修正方針としてはこんな感じかな。
    (a) 実運用環境でfoo()に渡した際に30秒かかるデータのサイズを調べること。
    (b) (a)の結果に安全係数を見込んだ数値でエラーチェックをする仕様に変更すること。
    (c) 仕様書の主観の入る定性的な記述を数値を用いた定量的な記述にすること。」
筆者「わかりました。やってみます。」
といって出来上がったのが次の一文でした。

・1M以上のデータを渡した場合,【指定したデータが1Mを超えました】というダイアログを表示します。

最初に書いた文と比べると違いが一目瞭然です。
・大きいデータを渡すと,しばらくたってからタイムアウトエラーを出力します。



posted by まる at 23:59| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年07月18日

3人寄れば文殊の知恵

仕様書の前にメモの準備をでも書きましたが,筆者は仕様書のレビュー前にメモを用いて関係者とレビューします。
前回はメモを作成する利点を書いたので,今回は早期レビューのメリットについて考えてみましょう。

仕様を自分で書いて自分で決めるのがベストですが,実際は顧客や上司といった人が仕様決定権を握ります。
つまり仕様作成者と仕様決定者が異なるのです。仕様書をいくら書いても仕様決定権を握るキーマンに承認してもらわないと意味がないわけです。
新人の頃はキーマンに仕様書を一切見せずに書いたせいで,仕様書レビューで全ボツを食らい,泣く泣く全部書き直したこともあります。筆者は毎回レビューのたびにコテンパンにされるのが嫌でどうにかならんかと考えた末,メモを書くことを覚えました。人間痛い目にあえばどうにかしようとするもんですね。

実際にメモの段階でレビューをするようになって,早期にフィードバックを得られること以外にもメリットがあることに気づきました。
キーマンから仕様を却下される確率が激減したのです。
それもそのはず,アイデアの段階でレビューするということはキーマンのアイデアを仕様書に盛り込むことになるので,キーマンは自分の言い出した仕様を却下しにくいのです。 他にも顧客であれば顧客の観点からアイデアが,上司であれば今までの経験からの助言がもらえるので,自分ひとりで考えるよりも深みのあるアイデアとなります。

メモとセットでレビューもいかかがでしょうか。

posted by まる at 23:50| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年07月11日

仕様書の前にメモの準備を

筆者は仕様書を書く前に仕様のキモとなる部分だけのメモを書くようにしています。
仕様書は漏れなく間違いなく書く必要があるため,どうしてもキモとなる部分以外もいろいろと書かなければいけません。
そのため,仕様書をもってレビューすると,気がつくとアイデアではなく体裁のレビューになったりします。
そんなときは「なんで体裁のレビューをしなきゃならんのだ!!!」と騒いで会議室のテーブルをひっくり返したくなるのですが,そこは社会人。そんなマネをするとアブナイ人に見られるのでぐっと我慢します。
そこで筆者は確実にアイデアだけをレビューしてもらえるように,仕様書のキモとなる部分だけを抜き出してメモを書くように心がけています。

ちょっと無駄なようにも思えますが,前述の体裁のレビューにされてしまうリスクが減るだけで十分です。

しかも,メリットはこれだけではありません。
他にもこんなメリットがあります。

  • アイデアを早期に表明できるため関係者からのフィードバックが迅速に行われる(=仕様書レビュー時の無駄が少ない)
  • アイデアだけをメモとして残すため仕様書を読むよりも「なぜ」この仕様にしたか理由が分かりやすい(==他のメンバーの理解が深まる)

仕様書の前にメモを書く。あなたもだまされたと思って一回やってみてはいかがでしょうか。

posted by まる at 23:22| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

2005年07月04日

パフォーマンス チューニング(vmstat,iostat編)

topコマンドはシステム全体+個別プロセスを監視していましたが,vmstatコマンドはシステム全体の監視を行います。
topコマンドはシステムの状況をリアルタイムに監視するのに適していますが,vmstatコマンドはシステムの状況を一日中監視して異常値がないか監視するのに適しています。
vmstatコマンドは vmstat 監視間隔 監視回数 と指定します。次のコマンドは60秒ごとに監視結果を10回出力します。

# vmstat 60 10
procs                      memory      swap          io     system         cpu
 r  b   swpd    free   buff   cache   si   so    bi    bo   in    cs us sy id wa
 1  0  13140 2098256   2732 1392632    0    0     5     7    3     4  0  0  6  3
 0  0  13140 2098016   3032 1392868    0    0     7    15  114    69  0  0 96  3
 2  0  13140 1573064   3300 1393156    0    0     7    16  108    65 87  1 11  1
 2  0  13140  997036   3428 1393416    0    0     5     3  106    59 98  2  0  0
 2  0  13140  431236   3532 1393536    1    0     3     3  106    58 99  1  0  0
 1  2  49268   16748    840 1339900    1  603     2   606  110    69 85  1  1 14
 0  2 134352   16708    924 1173812   21 1430    26  1439  126   103 44  3  1 52
 0  2 167948   16544   1084 1120132   31  589    38   597  122    87 14  1  2 83
 0  2 205336   16672   1076 1049912   60  723    62   726  125   100 17  1  2 80
 1  3 237172   16628    872  975868  162  629   164   633  142   150 15  1  3 81

最初の出力はシステムの統計情報です。ボトルネックを探す場合は統計情報を見てもしょうがないので無視します。

  • 空きメモリ(free)が普段より小さくスワップへの入出力(si,so)が大きければメモリ不足により性能が出ません
  • free,si,soが普通でブロックデバイスへの入出力(bi,bo)が大きければディスクアクセスにより性能が出ません
  • CPUの稼働率(us+sy+wa)が大きければCPUパワーの不足により性能が出ません

iostatコマンドはどのディスクデバイスがボトルネックとなっているかを調査します。
vmstatコマンドと同様 iostat 監視間隔 監視回数 と指定します。

# iostat 5 3
Linux 2.X.XX-X (localhost)  200X年XX月XX日

avg-cpu:  %user   %nice    %sys   %idle
           0.59    0.01    0.11   99.30

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev8-0           11.87        64.78        87.85  212183814  287749240

avg-cpu:  %user   %nice    %sys   %idle
          62.14    0.00    3.40   34.47

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev8-0         2078.64     16921.68      4196.76      52288      12968

avg-cpu:  %user   %nice    %sys   %idle
           3.47    0.00    0.92   95.62

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev8-0          282.45      2248.16        11.43      11016         56

vmstatコマンドと同様,最初の出力はシステムの統計情報です。ボトルネックを探す場合は統計情報を見てもしょうがないので無視します。
iostatコマンドではデバイスがdev[メジャー番号]-[マイナー番号]で表示されます。 デバイスがどのファイルシステムに対応するかは /dev 以下のファイルと/etc/mtab(SystemV系の場合は/etc/mnttab)をつき合わせて調べます。/dev で ls -lを実行すると,5番目のカラムに[メジャー番号]が,6番目のカラムが[マイナー番号]が出力されます。 /etc/fstabではファイルシステムとデバイスの対応関係が分かります。

# ls -l /dev/
brw-rw----    1 root     disk       8,   0  9月 15  2003 sda

# cat /etc/mtab
/dev/sda2 / ext3 rw 0 0
none /proc proc rw 0 0
usbdevfs /proc/bus/usb usbdevfs rw 0 0
/dev/sda1 /boot ext3 rw 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
none /dev/shm tmpfs rw 0 0
/dev/sda4 /home ext3 rw 0 0

今回の例では/dev/sda*のいずれかのファイルシステムに対しディスクアクセスが集中しています。 ディスクを増設してアクセスを分散させてから再度iostatコマンドを実行することで,ディスクによるボトルネックを解消できるでしょう。

posted by まる at 19:29| Comment(0) | TrackBack(0) | プログラマ Chips | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。