太助のＳＥ日記

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

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

　イメージで書くと、

　　０８：４０　〜　０８：４５　　全体朝礼
　　０８：４５　〜　０８：５５　　チーム内朝会
　　０８：５５　〜　０９：３０　　その他非正味作業
　　０９：３０　〜　１０：３０　　チーム内進捗会議
　　１０：３０　〜　１２：００　　XX案件対応

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

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


以上

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

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

　＜人を動かす３原則＞
　　１．批判も非難もしない。苦情もいわない。
　　２．素直で誠実な評価を与える。
　　３．強い欲求を起こさせる。

　＜人に好かれる６原則＞
　　１．誠実な関心を寄せる。
　　２．笑顔で接する。
　　３．名前は、当人にとって、最も快い、最も大切なひびきを持つ。
　　４．聞き手にまわる。
　　５．相手の関心を見抜いて話題にする。
　　６．重要感を与える−誠意をこめて。

　＜人を説得する１２原則＞
　　１．議論に勝つ唯一の方法として議論を避ける。
　　２．相手の意見に敬意を払い、誤りを指摘しない。
　　３．自分の誤りをただちにこころよく認める。
　　４．おだやかに話す。
　　５．相手が即座に”イエス”と答える問題を選ぶ。
　　６．相手にしゃべらせる。
　　７．相手に思いつかせる。
　　８．人の身になる。
　　９．相手の考えや希望に対して同情を持つ。
　　１０．人の美しい心情に呼びかける。
　　１１．演出を考える。
　　１２．対抗意識を刺激する。

　＜人を変える９原則＞
　　１．まずほめる。
　　２．遠まわしに注意を与える。
　　３．まず自分の誤りを話した後、相手に注意を与える。
　　４．命令をせず、意見を求める。
　　５．顔を立てる。
　　６．わずかなことでも、すべて、惜しみなく、心からほめる。
　　７．期待をかける。
　　８．激励して、能力に自信を持たせる。
　　９．喜んで協力させる。

　＜幸福な家庭をつくる７原則＞
　　１．口やかましくいわない。
　　２．長所を認める。
　　３．あら探しをしない。
　　４．ほめる。
　　５．ささやかな心づくしを怠らない。
　　６．礼儀を守る。
　　７．正しい性の知識を持つ。


以上

　＜入力項目でのレビューポイント＞

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

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

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

　　　■照合検査
　　　→突き合わせで全てのケース（＜、＞、＝、≦、≧）
　　　　を考慮したか？

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


　＜出力項目でのレビューポイント＞

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

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

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

　　　■照合検査
　　　→突き合わせで全てのケース（＜、＞、＝、≦、≧）
　　　　を考慮したか？


　＜内部ロジックのレビューポイント＞

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

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

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


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

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


以上

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

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

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


　　　２．ボトムアップテスト

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


　　　３．折衷テスト

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


　　　４．ビックバンテスト

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


　　　５．一斉テスト

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


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

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


以上

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

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

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

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

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

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

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


以上

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

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

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

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

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


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

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

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


以上

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

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


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



以上

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

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


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

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

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


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


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


以上

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

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

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

　　＜レビューの役割＞

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

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

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

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


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

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

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

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

以上

　＜議事録の目的＞

　１．決定事項・未決事項・宿題内容の明確化！

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

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


　＜議事録作成のポイント＞

　　　【記載必須事項】

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


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

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

　　　【見直しのポイント】

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




以上