2008年11月04日

仕事の記録

 いま、うちのプロジェクトでは「カイゼン活動」が流行って(?)います。
 ※トヨタのカイゼン活動です。

 まずは「見える化」が基本だ!ということで、自分が何時から何時まで
 どんなことをやっていたかを記録する。ということをやっています。

 イメージで書くと、

  08:40 〜 08:45  全体朝礼
  08:45 〜 08:55  チーム内朝会
  08:55 〜 09:30  その他非正味作業
  09:30 〜 10:30  チーム内進捗会議
  10:30 〜 12:00  XX案件対応

 ってな感じで、自分の仕事をまずは記録し、見える化しましょう!
 そして、記録した結果(事実)を振り返り、ムリ・ムダ・ムラを省きましょう!
 という具合です。

 まだまだ始めたばかりですが、なかなか面白いです。
 3K、5Kとも言われるSE業界ですが、少なくとも身の周りからはそんな
 SE業界事情を変えて行きたいと思ってます。


以上
posted by 太助 at 23:15| Comment(13) | TrackBack(0) | 日記 | このブログの読者になる | 更新情報をチェックする

2008年09月29日

人を動かす!


  名著「人を動かす(デール・カーネギー)」の丸パクリ
 ですが、とてもためになる言葉をご紹介します。

  上司・部下・顧客を動かすためにも、常に頭の中に
 INPUTしておきたい言葉です。

 <人を動かす3原則>
  1.批判も非難もしない。苦情もいわない。
  2.素直で誠実な評価を与える。
  3.強い欲求を起こさせる。

 <人に好かれる6原則>
  1.誠実な関心を寄せる。
  2.笑顔で接する。
  3.名前は、当人にとって、最も快い、最も大切なひびきを持つ。
  4.聞き手にまわる。
  5.相手の関心を見抜いて話題にする。
  6.重要感を与える−誠意をこめて。

 <人を説得する12原則>
  1.議論に勝つ唯一の方法として議論を避ける。
  2.相手の意見に敬意を払い、誤りを指摘しない。
  3.自分の誤りをただちにこころよく認める。
  4.おだやかに話す。
  5.相手が即座に”イエス”と答える問題を選ぶ。
  6.相手にしゃべらせる。
  7.相手に思いつかせる。
  8.人の身になる。
  9.相手の考えや希望に対して同情を持つ。
  10.人の美しい心情に呼びかける。
  11.演出を考える。
  12.対抗意識を刺激する。

 <人を変える9原則>
  1.まずほめる。
  2.遠まわしに注意を与える。
  3.まず自分の誤りを話した後、相手に注意を与える。
  4.命令をせず、意見を求める。
  5.顔を立てる。
  6.わずかなことでも、すべて、惜しみなく、心からほめる。
  7.期待をかける。
  8.激励して、能力に自信を持たせる。
  9.喜んで協力させる。

 <幸福な家庭をつくる7原則>
  1.口やかましくいわない。
  2.長所を認める。
  3.あら探しをしない。
  4.ほめる。
  5.ささやかな心づくしを怠らない。
  6.礼儀を守る。
  7.正しい性の知識を持つ。


以上
posted by 太助 at 23:30| Comment(0) | TrackBack(0) | SEの処世術 | このブログの読者になる | 更新情報をチェックする

2008年09月25日

テスト設計のレビュー


 <入力項目でのレビューポイント>

   ■データの属性
   →項目ごとに英数字、数字のみ、空白有無等の
    場合分けがあるか?

   ■範囲検査
   →項目ごとに取り得る範囲があるか?
    (日付論理検査、時刻範囲検査など)

   ■0件データ
   →入力データが0件の場合どうなるか?

   ■照合検査
   →突き合わせで全てのケース(<、>、=、≦、≧)
    を考慮したか?

   ■最大、最小
   →最大値、最小値が設定されている場合


 <出力項目でのレビューポイント>

   ■計算結果の検査
   →計算結果、合計計算結果に矛盾はない?

   ■件数検査
   →入力レコードと出力レコードの件数は一致
    するか?

   ■改行、改ページ
   →リスト出力での改行、改ページのタイミング
    を考慮しているか?

   ■照合検査
   →突き合わせで全てのケース(<、>、=、≦、≧)
    を考慮したか?


 <内部ロジックのレビューポイント>

   ■テーブル
   →内部テーブルの限界を全て考慮したか?

   ■作業領域
   →領域、添え字の限界値を考慮したか?

   ■演算
   →ゼロ除算、オーバーフローの可能性はないか?


 【失敗の実例】
  ある地銀の勘定系システムを、新システムへ更改した
 初日に、その悪夢が発生しました。
  NTTが提供するサービスを使って、エンドユーザ様の
 FAX等にデータを送る処理がかなりの割合でエラーに
 なったのです。
  原因は、移行データの不備です。具体的には、電文中
 のある項目に、「0〜9」までの数字を設定していれば、
 NTTのサービスで「XX支店」「XX本部」等に、変換してく
 れるのですが、そこに「スペース」が入っていたため、
 データエラーで電文を破棄されていたのです。
  オン中に人海戦術でDBパッチして、なんとかその場を
 しのぎ、その日の夜までにパッチPGを作成し、開発系で
 テストして、その日の夜中に本番系でパッチPGを流し、
 検証して、翌日のオンラインに立会い…。さんざんでした。

  当然稼動前に移行データを使って、NTTのシステムと
 の接続テストも実施していたのですが、該当の不備のあ
 るデータでテストできていなかったのです。
  接続テストで全データケースでのテストは、現実的には
 不可能ですから、移行データ作成時にNTTの規約と照ら
 し合わせて、不備を検出すべきでした。
  と言うわけで「テスト設計」とは微妙に違いますが、データ
 属性という観点での失敗談です。
 
  皆さんも注意してください…もうやだ〜(悲しい顔)


以上
posted by 太助 at 23:06| Comment(0) | TrackBack(0) | レビューのノウハウ | このブログの読者になる | 更新情報をチェックする

2008年09月23日

テストのイロイロ


  「万年テスト要員」と思われないように、テストの基本を
 振り返りたいと思います。

  以下は、代表的なテスト手法です。

   1.トップダウンテスト
     
     →最上位モジュールから開始し、順次下位のモジュールと
      結合しながら実施するテスト。
      下位モジュールが完成していない場合は、「スタブ」と言わ
      れる下位モジュールの代行版を用意する。


   2.ボトムアップテスト

     →最下位モジュールから開始し、順次上位のモジュールと
      結合しながら実施するテスト。
      上位モジュールが完成していない場合は、「ドライバ」と言わ
      れる上位モジュールの代行版を用意する。


   3.折衷テスト

     →トップダウンテストとボトムアップテストの両方を使って
      実施するテスト。


   4.ビックバンテスト

     →単体のテストが完了したモジュールを、一斉に結合して
      実施するテスト。


   5.一斉テスト

     →単体テストをさぼって、結合テストイメージを実施する。


  まずは、自分がどの(どれに近い)テストを行っているかを常に
 意識することが必要。メリット/デメリットを頭の中で整理し、今
 このタイミングでこのテストを実施する目的・効果・背景を理解す
 る必要があります。わからなければ、わかるまで(納得できるまで)
 調べましょう(聞きましょう)!

  私もいまだに「スタブ」と「ドライバ」を混同してしまいます。
 下位の代替は「スタブ」。上位の代替は「ドライバ」。覚えよう…。


以上
posted by 太助 at 22:58| Comment(0) | TrackBack(0) | レビューのノウハウ | このブログの読者になる | 更新情報をチェックする

2008年09月21日

テスト結果の分析(勘所)


 レビュー、テストの最終目的は品質の確保です。
 レビュー、テストを一生懸命がんばっても、その結果を分析し、正しく
 対処しなければ個人のスキルup、プロジェクトの成功はありません。

 具体的には、以下のような観点での分析(振り返り)が必要です。
 もっと言えば、注意が必要です。

 それは、
  ■適度なエラー(バグ)率になっているか?
   →目標値もしくは他の類似案件と比較し、摘出すべきエラー
    件数が摘出されているか?
    「品質がよいからエラー(バグ)がでない!」のもありますが、適
    切なテストを実施できている?の観点で疑うのもありかも…。

  ■テスト項目の設定率は妥当か?
   →システム規模に応じた適切なテスト項目数が設定されて
    いるか?

  ■エラー率とテスト項目消化率は妥当か?
   →テスト実施中でのテスト項目消化率に対するエラー摘出
    数の推移から、エラーの収束状況をwatch(注視)する。

  ■障害対応は大丈夫?
   →障害の発生件数とその障害を対応スピード・精度をwatch
    (注視)する。フォローは早くしないと、取り返しがつかなくなる。

  ■根本原因分析は必須!
   →レビュー記録票(レビューした内容、指摘箇所等がわかるもの)を
    残す習慣をつけ、障害発生の根本原因を調査可能にする。
    おもいきった人数を集めて原因の深堀(何故何故会)を実施するの
    も効果的。


以上
posted by 太助 at 22:53| Comment(0) | TrackBack(0) | レビューのノウハウ | このブログの読者になる | 更新情報をチェックする

2008年09月11日

効率的なテスト項目のレビューには…

テスト項目のレビューのお話です。
よく聞く「ホワイトボックス」と「ブラックボックステスト」を再整理します。

 <ホワイトボックステスト>
  プログラムのロジックに着目して、テスト項目を抽出する。

  利点:テスト項目の抽出が容易。網羅性が高い。
  欠点:仕様の漏れを検出できない。設計の良し悪しを判断できない。

 <ブラックボックステスト>
  元々の要件からテスト項目を抽出する。

  利点:要件、仕様との一致を確認できる。利用者側の立場での検証
      が可能。
  欠点:網羅性の検証が出来ない。内部的な境界に依存する障害の
      検出が困難。


 テスト項目を、効率的にレビューするには、両方の長所・欠点を押さえ
 ておく必要があります。
 あまり難しい話ではありませんが、すべての状況で、ホワイトボックス
 テストとブラックボックステストで抽出しテストを実施するのは、時間的
 な制約で困難です。両方のバランスをうまく取るのが、SEの腕の見せ
 所です。

 ブラックボックステストは全て行い、ホワイトボックスの観点は「境界」
 を意識するところだけ!というのが、理想なのかな〜と思います。
 網羅性という観点では、使われ方に着目し、現実的にありえないもの
 は机上検証のみとします。(経験談)

 10年先まで動いても不具合のでないシステムにするために、その
 テスト項目で何を確認できるのか、そのテストで何を確認すべきな
 のかを常に意識し、レビューのやり方も常に見直す(疑ってみる)必
 要があると思っています!
 +「効率的なレビュー」。これを目指して日々精進したいものです。


以上
posted by 太助 at 22:38| Comment(0) | TrackBack(0) | レビューのノウハウ | このブログの読者になる | 更新情報をチェックする

2008年09月10日

レビューイとレビューア

 レビューを実施する上で、心掛けたいことを書きます。
 (少々反省もいれつつ…)

  <レビューイ>
    ・背景、目的、工夫した点、確認した点等、自信を持って説明できる
     ように自己レビューをしっかり行う。
    ・問題点、不明点、気になる点を、はっきり提示する。
    ・レビューアからの指摘事項は、素直に認める。変な言い訳はしない。
    ・レビューアからの指摘事項は、レビュー記録として残し、確実に対応
     する。


  <レビューア>
    ・レビューイ自身が「気付く」ように工夫する。
    ・レビューイの誤りについては、以後同じことがないように、そこに至った
     考え方をヒアリングし、根本の誤り、思い込みを取り除く。
    ・レビューが収束しそうもない大きな問題が発生した場合は、その問題を
     取り除かないと先に進めないのか、先に進んでも問題ないのかを判断
     して、限られたレビュー時間を有効に使う。
    ・自分が気付いてあげなければ、本番障害が発生する!という意識で
     集中力をもって、しっかりレビューする。
    ・「細かいことにうるさい…」と思われることを恐れず、うるさいくらい、
     ねちっこくレビューする。



以上
posted by 太助 at 23:16| Comment(1) | TrackBack(0) | レビューのノウハウ | このブログの読者になる | 更新情報をチェックする

2008年09月09日

レビューのイロイロ


 レビューと一言で言っても、そのやり方はさまざまです。

 <自己レビュー>
  文字通り、作成者自身が行うレビューです。
   ・誤字
   ・脱字
   ・文法誤り
   ・規約違反
  基本的には、ここで(バグを)潰す覚悟が必要です。
  逆に、しっかり裏が取れている箇所を把握し、不安な観点を
  抽出し、以降のレビューにつなげれば、効率化が図れます。


 <回覧レビュー>
  関係者全員で集まる必要がないのが、メリットです。レビューア
  が忙しい場合は、よく取られます。
  資料だけが頼りなので、資料の精度を上げるには有効です。
  また、「ちょっと知っておいて欲しい」人にも情報を伝えることが
  できるのもメリットです。

  デメリットは、レビューアの意識次第では漏れがでやすい点です。
  

 <対面レビュー>
  最もポピュラーです。
  「レビューアの時間と場所を確保する必要がある。」のが、困難
  ですが、それを除けばいいことばかりです。
  例えば、
   ・レビューイが説明することによって、レビューイ自身が誤り
    に気付ける。
   ・レビューアのノウハウを伝え易い。
   ・コミュニケーションが容易に図れるので「漏れ」るリスクが
    かなり低くなる。
  などです。これまでの経験で言えば、自席とはちょっと離れた
  (邪魔が入らない)場所でやるのが、効果をあげるポイントです。


 <会議レビュー>
  関係者全員が集合することによって、レビューの効果が非常
  に高いです。様々な立場からの指摘がでるためです。
  ただし、関係者全員を同じタイミング・同じ場所に集める必要
  があるので、開催するのが大変です。
  工程の区切り、重要な場面で適宜開催するのが良いです。


 どのレビュー形態も一長一短です。完璧なものはありません。
 だから難しいのですが…。
 ただ、個人的には「自己レビュー」の精度が一番、品質に密接
 に関係してくると思います。
 


以上

posted by 太助 at 22:38| Comment(0) | TrackBack(0) | レビューのノウハウ | このブログの読者になる | 更新情報をチェックする

2008年09月08日

レビューの役割とは…


  レビューとは...ネットで検索すると、以下のような言葉が出てきます。

   ・批評
   ・検証
   ・成果物を確認し、修正指示や承認を与える
 

  レビューは、我々SEの世界では、テストと並んで品質を確保するための
 作業の一つです。
  ボクが認識するレビューの役割として、以下に挙げます。

  <レビューの役割>

   確認:生産物(ソース/ドキュメント/定義体etc)の正当性を
       第3者の目で確認し、間違いがあれば修正する。
       また、第3者に説明することで、作成者本人が自分の誤り
       に気付く機会となる。
       
   改良:機能、性能、品質、効率などの観点で、システム開発の目標
       と照らし合わせて、よりよいものにする。

   継承:生産物(ソース/ドキュメント/定義体etc)を、作成者以外の
       メンバに理解させる。

   教育:有識者のスキルを、メンバへ展開し、メンバのスキル向上を図る。

   保証:個人の(ソース/ドキュメント/定義体etc)を組織の生産物と
       して認める。
 
   管理:表面的な作業の進み具合だけでなく、作業の内容・方向性を把握
       し、次の作業を指示する。


  システム開発のさまざまな工程では、色々な生産物が作成され、色んな
 観点で色んな人がレビューに参加します。

  レビューをする側→レビューアー
  レビューを受ける側→レビューイ

  今までの経験だと、レビューは受ければ受ける程、品質はよくなります。
 また、レビューをすればするほど、知識が増えていきます。

  今後、この「レビュー」に焦点をあてて書いていこうと思います。
 

以上

posted by 太助 at 22:19| Comment(0) | TrackBack(0) | レビューのノウハウ | このブログの読者になる | 更新情報をチェックする

2008年09月06日

議事録のポイント

 <議事録の目的>

 1.決定事項・未決事項・宿題内容の明確化!

 2.会議に出席していない人でも、「1.」の要素が理解できること。

 ※全員で認識をあわせることができるように!


 <議事録作成のポイント>

   【記載必須事項】

     →会議名称、議題、日時、場所、出席者、作成者、承認者


   【本文の作成のポイント】

     →項目ごとに整理する。
     →各項目について、箇条書きにする。
     →決定事項、未決事項、今後のアクションについて、
      誰が?何を?どのように?を明確に記述する。
     →出席者の発言内容以外は記載しない。

   【見直しのポイント】

     →漏れはない?
     →誤字脱字はない?
     →承認者にチェックしてもらう!




以上
posted by 太助 at 22:53| Comment(0) | TrackBack(0) | 会議のノウハウ | このブログの読者になる | 更新情報をチェックする

広告


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

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

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


×

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