2004-10

先日行った修正に漏れがありました。
仕様書の見落としで、1つの機能を実装し忘れていました。仕様書はすみからすみまで目を通すようにしましょう。

<script type=~1></script>
 
<script type=~2></script>

この2行を忘れてました…

新潟中越地震のような大災害が起きると必ず電話がつながりにくくなる。被災地に全国からいっせいに安否を尋ねるコールがかかるからだ。固定電話にせよ、携帯電話にせよ、同じである。
そのたびにメディアは電話がかかりにくくなっていると報道するだけで、どうすれば安否が確認できるか、を報道しない。

junhara’s blog: ｏｕｔｂｏｕｎｄを優先せよからの引用。

詳細設計書にはどこまでを記述すべきでしょうか？

今のプロジェクトの詳細設計書には仕様についての記述より、その仕様を実現する為のコードレベルの記述が多く（例えば、この関数を使いましょうとかフラグが１の時にはほにゃほにゃみたいな）、ここまで書くのなら実装までしてもらっていいんじゃないの？と思ってしまいます。

プロジェクトの役割分担を、設計フェーズと開発フェーズに分けた場合、どこからどこまでが設計の責任でどこからどこまでが開発の責任でしょうか？

また、設計フェーズでそこまで詳細に書いてしまうと、開発は考える事なく作業が出来てしまいおもしろみがなくなります。人を育てるという意味でも開発方法は詳細設計書に記述するのではなく、コードレビューという形でフィードバックする方法が有効ではないかと思います。

あと、少し違う話なのですが、開発時点でテスト仕様書があると開発の助けになります。だから設計フェーズの段階でテスト仕様書も作成しておくということです。

■1 仕事上でやったミス全て
・仕事の進め方
・仕様の認識のくいちがい
・単体テストでのバグ
・納品したプログラムにバグがあった
・コミュニケーション不足による食い違い

■2 問題点を書き出す。仕事に関してイライラすることを残らず。他の人の不平でもＯＫ
・組織のまとまりがない
・組織としての目標がない
・モチベーションが低い
・コミュニケーション不足
・給料が安い
・ねむい

■3 仕事に関してやっていることすべてのことをリストアップすること。（報告書を書くというステップがあれば、その詳細までを書く。箇条書きでいいのでどうゆうふうに報告書を書くのか？どこで情報を手に入れるのか？など10or20or50になるかもしれないけれど）
・プログラミング
　　仕様確認
　　フロー作成
　　コーディング
　　動作確認
・単体テスト
　　仕様書作成
　　テスト
・ドキュメント作成
　　仕様決定
　　レイアウト
　　内容
・スケジュール作成
　　工数見積もり
　　作成
・ミーティング
　　資料
　　場所
　　スタイル
・ブログ閲覧
　　ツール
　　頻度
・ＮＥＷＳ閲覧
　　ツール
　　頻度
・実績入力
　　ツール
　　使用方法

気づいたこと1

ここのところ私の作るプログラムの品質の低下が目立ちます。
その対策として明日は全てを理解した上でプログラミングをすることにします。スピードは大切ですが、それ以上に品質が大切です。明日はソースを全て理解した上でコーディング作業を行います。

気づいたこと2

今日の業務中、８時間中4時間は寝ていました…明日は2時間で

気づいたこと3

挨拶をほとんどしていません。

http://rpc.blogrolling.com/pinger/

http://rpc.technorati.com/rpc/ping

http://api.my.yahoo.com/RPC2

http://ping.bloggers.jp/rpc/

http://ping.cocolog-nifty.com/xmlrpc

http://blog.goo.ne.jp/XMLRPC

http://ping.exblog.jp/xmlrpc

http://ping.myblog.jp/

http://www.blogpeople.net/servlet/weblogUpdates

http://bulkfeeds.net/rpc

ソースに &nbsp; なんていうよくわからないものがあったので調べてみると
&nbsp;=スペースみたいです。

まだまだ知らない事が多いです。

あと &amp; はなんでしょう？

TSUTAYA DISCAS 宅配DVDレンタル｜ツタヤ ディスカス

月額1344円で月4枚のDVDが借りられて、それ以上借りる時も2枚で693円！！
安すぎます、しかも便利そう。最近地元のレンタル屋さん（TUTAYA）が潰れて借りるところがなかったので、とびつきそうです…が、家計的にまよってます。

あとこのサービスのはしりはライブドアだったと思うのですが、ネームバリューと安心感でDISCUSの方がはやりそうですね。

・試すことに失敗はない
・必要は発明の母、偶然は発明の父

社会人１年目に読んだ時は、「そこそこ面白いかな」という印象でした。
でも社会人３年目になった今改めて読んでみると、まったく違う印象の本になっていました。

人々は、したくもない仕事をし、同時にそれを失うことを恐れているんだ

というくだりで引き込まれ、

明日は今日と違う自分になる

何を試してきたのかね

それはね、あるべき状態より、よくあることなんだ

などなど、これだけでは意味がわからないと思いますが本を読んで頂けると、価値のある言葉だとわかってもらえると思います。

最近、本というのは読み潰すのもいいけれど、ずっと手元におき人生の指標というか自分のチェックリストとして使う本があってもいいなぁと感じています。この本は私のビジネス聖書第一号です！！

仕事は楽しいかね?

posted with amazlet at 04.10.24

デイル ドーテン Dale Dauten 野津 智子
きこ書房 (2001/12)
売り上げランキング: 2,555
通常24時間以内に発送

おすすめ度の平均:

いい影響を受けました
環境・運のせいで、仕事が上手くいかないときにどうぞ。
読まなきゃ損！

Amazon.co.jp で詳細を見る

この本の最後の方に３つのリストを作れ！とあるので作ってみましょう＾＾
続きを読む

このプロジェクトの納期は３人日でした、調査、修正、テストで３日です。
作業をしながらずっと不安でした。私がテストを終了したものがそのまま本番環境で稼動するからです。そんなことは当たり前だと思われるかもしれませんが、完璧なテストをする自信がない私にとっては不安というか心配で仕方がありませんでした。

今まではそんな心配は感じたことはなかったのですが、ここ最近そういったことが心配で仕方ありません。これが成長なのか後退なのかはまだわかりませんが、最近はそんな感じです＾＾

結局テストは開発環境でテストして、tar.gzで固めて、それを結合環境で展開して、テストして、バグが見つかって、もっかい開発環境でテストして固めて結合環境でテストして、終了しました。バグはないはずですが、それでも心配です…

この心配をなくす為にはテストの経験値を増やし、よりバグを潰せるテスト手法を考え、我慢強く、慎重にテストするしかありません。開発の時は設計さえちゃんとしておけば、コーディングは比較的簡単ですが、テストはいつまでも気が抜けません。しかも重要度が超最大です。

仕事を覚えるにはプロジェクト全体を責めるより、１つのプロセスのプロになることから始めるのがいいかもしれないと今思いました。テストのプロ！ちょっといい響きな気がします。