2005年09月26日

テスト観点のレビューを

納品の時期がやってまいりました。
夏休みの宿題よろしく納入直前に頑張っていますか。

協力会社にプログラムの発注を出すと,プログラムがバグだらけだったという苦い記憶はありませんか。
筆者は「なぜこんな簡単なテストを実施していないんだ」とよく思ったものです。 協力会社の技術レベルが低くてテストをテスト観点として気づかなかったこともありますし, 実は発注者の頭にしかない仕様を前提としたテストだったこともあります。
発注側と受注側の意識のズレを減らす方法を検討し,ひとつの結論にたどりつきました。

テスト実施前にテスト観点のレビューを実施するのです。

本当は単体テスト,結合テストのすべてのチェックリストを確認できればベストですが, チェックリストの量が多すぎてとてもチェックできません。 そこで,チェックリスト作成時の観点をまとめて提出してもらい, 発注側の意識とズレがないかを確認するようにしました。

たとえば,文字コードの変換を扱うプログラムでは文字コードのチェックがあるか確認します。
それも,「表示される文字が正しいか」といった抽象的な言葉ではなく,具体例を出して記述しているか確認します。
筆者であれば次の文字が入っているか確認します。

  • 「〜」(UnicodeとWindowsのSJISで扱いの異なる文字)
  • 「表」(SJISの2バイト目に'\'を含む文字)
  • 「ア」(半角カナ)
  • 「@」(NEC拡張文字)

この内容がチェック観点になければチェックリストに追加してもらいます。
こちらのテストしてほしい内容を事前に協力会社に伝えることでテスト漏れを減らすわけです。

お互いにWin-Winの関係を築けるように努力しましょう。



posted by まる at 00:31| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年09月19日

Red Hat Linux(Fedora Core)でのシングルユーザーモード起動方法

Red Hat Linuxでのシングルユーザーモードでの起動方法です。
画面はRed Hat Linuxですが,Fedora Coreでも同じ手順で大丈夫でしょう。
  1. 電源を投入すると次の画面になります。
    OSを起動される前に'e'を押して編集モードに切り替えます。
  2. 起動画面


  3. 起動方法を選択する画面となるので"kernel /vmlinuz..."という項目を選択し,'e'を押します。
  4. 選択画面


  5. 起動コマンドを編集できるようになります。末尾に single と入力します。



  6. 起動方法を選択する画面に戻ります。先ほどの"kernel /vmlinuz..."の末尾に single が追加されていることを確認します。
    問題がなければ'b'を押して起動します。
  7. 編集後の選択画面


  8. OSがシングルユーザーモードで起動されます。
    コマンドプロンプトが表示されればシングルユーザーモードでの起動は完了です。
  9. シングルユーザーモードでの起動画面


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

2005年09月12日

お互いに幸福になる値切り方

システム構築やプログラムの見積もりを依頼したら想定より高額な金額を提示されたことはありませんか。
高いという感覚だけで値切っても受注側も安くしてくれません。受注側にしてみれば生活かかってますから当然といえば当然ですが。
そこでどのようにしたら値切れるか(または発注側の意識を修正するか)になるわけです。

自分の想定した金額と異なるということは,発注側と受注側に意識のずれがあります。 意識のずれといっても,いくらでも払ってくれるからふっかけてやれという考え方から,発注側の見積もりミスまで原因はさまざまです。
筆者の体験では次のようなパターンがあります。

  1. 管理工数などの隠れた工数を見落としているから
  2. 依頼された分野に詳しくないから
  3. 発注側の想定しているアルゴリズムが受注側が想定しているものと違うから
  4. いくらでも払ってくれるカモだから
どのパターンの場合にも共通で言えるのは,見積もりの根拠を細かく提示してもらうことです。 見積もり根拠が明確であればどのパターンに当てはまるかの見当がつくでしょう。

1の場合は発注側が見落としていた作業項目が見積もり根拠にあるはずです。ありがちなのはシステム調査や仕様作成などの工数が漏れているとか,管理工数のつみ忘れといったあたりでしょうか。 作業項目ごとに要・不要を判断し,発注側の見積もりを高めに設定するか,受注側に作業を省いてもらうことで対応します。

2の場合は仕様作成の工数やコーディングの工数が発注側の想定より高めにでます。仕様の詳細や実装方法をヒアリングすれば受注側の理解度を判断できるでしょう。 しょうがないと思えばそのまま発注しますし,高いと思ったら他の会社からも見積もりをとりましょう。他の会社がよければそちらに出してもいいですし,他社の見積もり金額をネタに最初の会社に値下げ交渉をしてもいいでしょう。

3の場合も2と同様に仕様の詳細や実装方法をヒアリングします。遠回りなアルゴリズムを適用していないか,発注側の予想と異なるアプリケーションを使用していないかをチェックします。 違う場合は発注側の想定を伝えて費用を圧縮できないか検討してもらいましょう。
ITProでも『「より良いシステムをより安く」---そうならないのはなぜ? 』(購読には登録が必要)という記事がありました。

4の場合は1〜3のどれにもあてはまらない場合です。カモだと思われてます。他社から見積もりを取りましょう。

この方法で値切ろうとすれば発注側も技術力を要求されます。勉強していない人はカモにされるのが世の宿命です。勉強あるのみです。

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

2005年09月06日

徹夜の減らし方(実践編)

徹夜のご利用は計画的にでは余裕を持ってスケジュールを組めばよいと書きました。実際には余裕を持ったスケジュールはなかなか難しいでしょう。
そんな余裕があれば最初から余裕を持ったスケジュールを組むに決まってるでしょう。または部長や課長という名前のひとさらいがやってきてあなたの同朋や先輩,部下をさらっていくことでしょう。スケジュールに余裕があるなーとのんびり構えていたら,ひとさらいにさらわれてデスマーチ化したプロジェクトをいくつも知ってます。
ひとさらいの目を逃れつつ,自分たちのスケジュールを破綻させないためにはどうしたらいいか。

メンバーに予定よりも少しだけ早いスケジュールを教えるのです。

スケジュールどおりに進んでるのに喜んで残業する人はほとんどいませんが,スケジュールより遅れているとなると頑張って残業します。その心理を利用する非道の技なのです。

例えば9月末がデットラインだとしたら,9月の3週までに全工程を完了させなければならないと嘘を教えます。
メンバーがスケジュールをまったく把握してなければ,〆切を早めにいえばいいだけです。メンバーがある程度のスケジュールを把握しているのであれば,受け入れ検査があるとか,接続確認のために早期に提供しなければならないとか,別のプロジェクトに入ってもらわなければならないとか,適当な理由を考えてスケジュールを繰り上げるのです。
このようにすることで自分たちは目標とするスケジュールより進んでいないという危機意識を植え付けることができ,メンバーに進んで残業してもらうことができます。我ながらヒドい思考をするもんです。

注意事項を一つだけ。
今回の技は邪道です。10個のプロジェクトのうち,どうしても成功させたい1個にだけ適用すべきです。10個のプロジェクトのうち10個すべてに適用しているといずれ見破られます。リーダーとしての信用を失い,以降のプロジェクトは以前より厳しい立場となってしまいます。9個のプロジェクトの真実が1個のプロジェクトの嘘を補強してくれるのです。
立派な詐欺師を目指して頑張りましょう。

posted by まる at 07:15| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

広告


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

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

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


×

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