ＩＴのソムリエ・デジタリアン

設計開発編：構造化テスト（４）

Thu, 06 Dec 2007 00:12:35 +0900

トップダウンテスト法

　体系的、構造的にテストすることを目的にしており、
　構造化プログラミングの基本に従ってテストします。
　基本的な考え方は次の言葉に表れています。
　・Stepwize　refinement　（段階的精練法）
　・Devide　&　conqure　　　（分割統治法）
　
（１）方法
　・プログラムの頂上、つまり最初に呼び出されるモジュール（例えばmain）から
　　コーディングし、テストします。
　・下位のモジュールはダミーのプログラム（スタブと呼ぶ）を結合しておきます。
　・最初のモジュールのテストが終わったら下位のモジュールをコーディングし、そのテストを行います。
　　（場合によりコーディングが先行していても良いです。）

（２）長所
　・基本構造に関係の深い部分から先にテストするので、根本的なエラーを早期に発見できます。
　・上位とのインタフェースが早く検証でき、重大エラーの早期発見が可能。
　・細部の論理より全体の機能中心のテストができ、早期にシステムの全体像が把握できます。
　　顧客へのデモンストレーションも早めにできます。

（３）短所
　・スタブ開発が以外と面倒なことがあります。
　　入出力関係から先にテストするとデータ入力や結果表示が楽になります。
　・論理の複雑なモジュールや、性能に深く関係するモジュールが後回しになる可能性があります。
　　→重要なモジュールは先に単独でテストするなどの工夫が必要です。

設計開発編：構造的テスト（３）

Tue, 04 Dec 2007 22:08:20 +0900

テスト・カバーレッジ
　ホワイトボックス・テストの一種です。
　ソースコードの何％をテストで実施したかを示す網羅率で表わします。
　多くの場合１００％を目指すのが理想的ですが、実際には、そこまでやらない
　場合もあります。
　よく使う指標には次の２通りがあります。
　Ｃ０メジャー：全命令文網羅率・・・全ての命令文の何％をテストしたか？
　Ｃ１メジャー：条件判定網羅率・・・条件判定分岐の何％をテストしたか？

　この方式の問題点：
　　・仕様の不備や仕様の誤解による不良はチェックできない。
　　・実行したからと言って正しいとは限らない。
　　・コーディング漏れは発見できない。
　　・測定ツールが必要。

設計開発編：構造的テスト（２）

Sun, 25 Nov 2007 11:55:13 +0900

不良件数見積もり
　過去の例から何ステップ当たり何件のバグがあるかを予想します。
　そのためにはプロジェクト毎の開発ステップ、バグ件数などを把握しておくことが大切です。

　組織的に経験の積み重ねが必要となります。
　例えばCOBOLのアプリケーションプログラムでは単体テストで２～３００ステップ　に１件、
　システムテストでは２～３Ｋステップに１件の不良が見つかるようです。
　これは私の経験則なので、きちんとした理論があるわけではありません。

　チームのスキルレベルにもよりますが、これより大幅に多いと、開発品質が悪い
　と判断できると思います。
　開発者へ差戻すことなどの処置も必要です。

　バグの発生内容、原因、さらに動機的原因、つまり、なぜバグができたかを、
　その開発者の根本的な動機付け、間接的原因までさかのぼって分析することも大事です。

設計開発編：構造的テスト（１）

Tue, 20 Nov 2007 22:45:17 +0900

構造的、体系的にテストすることで少ない手間で効果的なテストができる。

１．テストの目的

テストはいったい何のためにやるのでしょうか？

E.W.Dijkstra（ダイクストラ）は次のように言っています。
「テストでプログラム中のバグの存在は示せても、バグが存在しないことは示しえない。」

つまり、プログラムが正しく動作することを証明する手段はないということです。
いくらテストしても、プログラムが正しく動作することの証明にはなりません。
そもそもプログラムの仕様自体が間違っている場合もあります。
でも、誤り（バグ）は、それを示せば、存在を証明できます。

テストで見つけられるのはプログラム内の誤りだけなのです。

ただ、言えるのは誤り（バグ）を見つければ見つけるほどプログラムの品質が向上したことになり、
誤動作する可能性が減ります。
これがテストの目的なのです。

たくさんの誤り（バグ）を見つければ見つけるほど、テストは本来の目的に貢献しているのです。
これはちょっと盲点ではないでしょうか？

さて、効果的なテストは多くのバグを見つけることだとすると、いくつかの問題が出てきます。

・テストにおける問題点１：
　　プログラムにバグがないように作るのと、テストでバグを見つけることは矛盾する行動です。
　　積極的にバグを見つけることをプログラマに動機付けできるでしょうか。
　　誰しも自分の作品にケチを付けるのはイヤなことです。
　　できればバグが少ないことを確認したいと思うでしょう。
　　これではテストの目的は達成できなくなります。

　　この解決法は？
　　プログラム開発者（または組織）とテスト担当者（または組織）を別々にします。
　　これならテスト担当者は張り切ってバグを見つけるはずです。
　　それがテストのミッションだからです。
　　またプログラマも他人がテストするわけですから、コーディングに緊張感がでます。

・テストにおける問題点２：
　　テストでバグがもう見つからないとき、
（１）プログラムの品質は高いと確信できるでしょうか？
（２）テスト方法に問題があり、バグを叩き出せないのではないでしょうか？
　　　どちらかなのか判断できないという問題があります。

　　　この解決方法はちょっと難しいです。
　　　プログラムの品質が、もうだいじょうぶという判断材料を与える手段は
　　　色々あります。

（１）検査進捗曲線・・・テスト進捗状況と品質の判定ができます。
（２）不良件数見積・・・テストの終了判定の指針を与えます。
（３）カバーレッジ・・・機械的にテスト完了の判断材料を与えます。
　ただし、最初に述べたように品質を保証する完璧な方法は存在しません。
　これらの方法は各々、欠点も持っています。
　使用に当たっては経験者の判断が必要であることを忘れないで下さい。

・テストにおける問題点３：
　　バグをたくさん見つけるには、どのようなテストをすれば良いのでしょうか？
　　何をどうテストすればよいのでしょうか？
　　またテスト件数の目標値はどの位が妥当なのでしょうか。

　　この解決方法として、いくつかの効果的なテスト手法があります。
　　ここでは私がいつも実践している手法を御紹介致します。
　　　・トップダウン・テスト法・・・プログラムを上位機能からテストします。
　　　・効果的テスト手法・・・・・・最も効果的なテストケースを設計します。

　　特に効果的テスト手法はいくつかの方法論をカスタマイズし、
　　私が実際の開発で使用しているものを次回以降、御紹介致します。

設計開発編：外注管理の心得

Sun, 18 Nov 2007 14:41:58 +0900

プログラムの開発を外注へ任せる場合、キチンと設計通りできているかをチェックすることが大事です。

　完璧な設計書を渡し、完璧なプログラム作りをしてくれるならば理想的ですが、
　現実には、そのようなことは期待できません。性悪説に立つわけではありませんが、人は過ちを犯すものであり、
　コミュニケーションミスもあるので設計者の考えている通りのものができることはないと考えてよいでしょう。

　テストフェーズでチェックすればよいと考える人もいるでしょうが、
　それでは手戻り作業が増えますし、テスト漏れすることもあるので遅すぎます。
　プログラムのコーディング途中でもチェックすべきです。
　では、どのようにしてチェックするかを次に挙げます。

　（１）ソースコード・ウォークスルー
　　　　　プログラム・ソース・コーディングをプログラマが説明し、参加者全員で見てチェックして行きます。
　　　　　説明する人が話しながら、自らの間違いを発見することも多いです。
　　　　　全てのソースコードを見る必要はない。設計上の重要ポイントや性能上、問題になりそうな所だけをチェックします。

　（２）テスト項目リストのチェック
　　　　　ちゃんとテストしているかを見るにはテストチェックリストを見せてもらえば、すぐにわかる。チェックリストを作っていなかったり捏造していたりしていないか確認します。

　（３）コーディング現場の見学
　　　　　委託した最初の段階で作業現場を見せてもらいます。
　　　　　ただ見るだけですが、その効果は大きい。
　　　　　しっかりチェックする顧客だと思われるだけでも、相当なプレッシャーになるはずです。
　　　　　もちろん、人がいなかったり、現場を見せてくれない場合には、より厳重に進捗確認をしていく必要があります。

設計開発編：設計の基本はわかってもらうこと

Sat, 17 Nov 2007 11:03:20 +0900

とかく設計書というと形式ばっていて、難しくて、書くのが面倒と思われています。
　できれば書かないで済ませたいと思っている人も多いのではないでしょうか。
　あるいは、逆に、やたらと形式的に厳密で複雑な設計書を書いている人もいます。
　何か自己満足的ですらあります。
　最近は特に様々な設計技法が紹介されていますが、基本を忘れ、表記法のみに溺れると、
　余り役に立たない設計書ができ上がります。

　設計書の基本は書くことより伝えることをより大切に考えます。
　書きたいことを書くのではなく、読み手の気持ちになって書いてあげることです。

　もちろん、厳密さが大事ではないと言っているわけではりません。
　設計書には細かなこともきちんと規定すべきではあります。
　しかし、数学的厳密さを極限まで追求すると、それはプログラムと同じレベルにまでなってしまい、
　かえって判りにくくなってしまします。

　設計書を書く上で注意して頂きたいことは次のことです。
　（１）機能（何をどうするか）を中心に”わかりやすく”書く。
　　　　次工程の開発者やレビューする人に理解してもらうことが第一です。

　（２）網羅的に検討しておく。
　　　　正常時だけでなく異常時、例外事項、制約条件など広い範囲を網羅して検討しておきます。
　　　　異常状態はできるだけ全ての組み合せを記述することは不可能ですから、
　　　　考え方を整理して記述することがポイントです。
　　　　異常状態と、そのときのアクションを表現するにはマトリクス（表）の形で記述すると判りやすくなります。

　（３）図表だけでなく、デモ画面などのように動きのある媒体を含めて
　　　　総合的に”設計”を考えます。
　　　　要するに設計の狙いまで含めて理解してもらうことが大事なのです。

　（４）設計対象以外の周辺との関係にも配慮しておきます。
　　　　・一番大事なのは”人の動き”です。システムを操作する人がどのように
　　　　　動くのかが設計書から見えてこないといけません。
　　　　　時間を追った動きが必要になる場合もあります。
　　　　　センター運用者の操作も忘れないようにします。

　　　　・次に他のシステムのと関係です。つながりのあるシステムは何か、
　　　　　タイムフローやインタフェースが記述されています。

　（５）その他の考慮点
　　　　性能や信頼性、セキュリティ、移行システム、移行作業も検討して
　　　　おきます。

　設計書の作成がプログラム開発の後回しになることも、しばしばあります。
　設計書作成が後回しになると、他人への説明がついつい疎かになり、
　プログラム・コーディングの表記を変えただけで設計書に代えてしまうことがありがちです。
　でも、これでは紙数が増えただけで、内容的には意味がありません。
　プログラムが修正されても設計書が変更されないことがあると、かえってトラブルの元になります。

　特に外注業者に設計書作成も委託するときは、このような本末転倒のコーディングの翻訳に
　ならないように気を付ける必要があります。

設計開発編：単純明快なシステムを作る

Wed, 14 Nov 2007 21:45:27 +0900

システム開発においてはできる限り単純でシンプルなシステムにした方が良いです。
　単純明快なシステムであれば、次のようなメリットがあります。
　（１）理解が容易であり、部外者にも判り易い。そのため、利用者や支援者を
　　　　増やし、稼動率を上げ、業務に貢献できる。
　（２）機能の独立性が高く、追加拡張が容易である。
　（３）他のシステムとのインタフェースが簡潔であるので、
　　　　外部要因の影響を受けにくい。

　誰も進んで複雑怪奇なシステムを作ろうとは思わないでしょう。
　でも、できあがったシステムは訳の判らないシステムになっていた、
　ということが良く起こります。
　それはなぜでしょう。
　原因としては次のようなことがあると思います。
　（１）システム間の連係が当初想定していたより困難であった。
　（２）新規開発ではなく既存システムを改造のため複雑になった。
　（３）意見調整が難航して仕様が肥大化した。
　　　　　関係者が多いとか、ユーザの意見が二転三転したなど。
　（４）一面的な方向でしか検討されていなかったため、もう一方の視点から
　　　　見ると矛盾が多い仕様になってしまった。

　これらの原因別に回避する方法を考えます。

　回避策：
（１）システム間連係の複雑さ
　　　　この場合、よく相手システムをブラックボックス化し、インタフェースを
　　　　橋渡しするモジュールを設けることがあります。しかし安易に仕様を
　　　　決めると、ブラックボックスのつもりがむしろ逆になることがあります。
　　　　内部の仕様を想像しながら、新しいインタフェースにマッピングして
　　　　使うという本末転倒したことに陥る可能性があります。
　　　　むしろ真正面から取組み、改定できる所は直し、無理な所は仕様を明確化
　　　　し、新プログラムで正式にサポートする方が、遠回りのようでも、
　　　　稼動後は安定します。

（２）既存システムの改造
　　　　既存部分の複雑な所もできるだけ改修することが基本です。
　　　　できない箇所は仕様を明確にし、文書化して残すようにします。
　　　　前項と同じように不用意にブラックボックス化すると、あとで苦労
　　　　します。

（３）意見調整が難航
　　　　プロジェクト管理の失敗が一番の理由です。特に初期のうちに
　　　　メンバー間で、プロジェクトの目的や狙いをきちんと合意していなかった
　　　　ときに陥りやすい。あるいは途中から参加したメンバーに、いわゆる声の
　　　　大きい、我を通す人がいると起こりやすいです。
　　　　もう一度、目的や狙いにたち戻って整理しましょう。
　　　　当初の目的から外れた仕様は思い切って削除するか、次ステップへ
　　　　回しましょう。
　　　　納期を考慮して、割り切って仕様を絞ることがプロジェクト管理では
　　　　一番重要なことです。

（４）一面的な検討
　　　　技術面に強いプロジェクトリーダにありがちなのが、作る立場でしか
　　　　考えないで仕様を決めてしまうことです。ユーザあってのシステムなのに
　　　　ユーザが見えないまま、あるいはユーザを無視してシステムを作ると、
　　　　ユーザにとって複雑でわかりにくいシステムとなります。
　　　　特にＧＵＩなどのユーザインタフェースでは十分考慮することです。

　　　　わかりやすいユーザインタフェース
　　　　ユーザにとってわかりやすいシステムとはどのようなシステム
　　　　でしょうか？
　　　　・アクションに対して必ず何らかの応答がある。
　　　　・システムの状態遷移が少ない。（モードが少ない）
　　　　・クイックに反応する。
　　　　・対象（オブジェクト）の種類と、その操作（メソッド）の種類が
　　　　　直交的である。つまり、
　　　　　　複数の対象に対して一様の操作ができる。
　　　　　　複数の操作が一つの対象に対して行える。
　　　　・操作のやり方、反応が統一されており一貫性がある。
　　　　・操作や対象が覚えやすい。
　　　　・反応（メッセージ）が理解しやすく、後処理に役立つ。
　　　　・情報が一覧できる。
　　　　・見たい情報が強調されている。
　　　　・情報が整理され、紛らわしくない。

企画提案編：効果的なプレゼンテーション

Tue, 13 Nov 2007 23:13:08 +0900

提案する相手をその気にさせる効果的なプレゼンテーションのノウハウをご紹介します。

１．提案ミーティングはショータイム
　　紙より自信に満ちた態度、声の大きさが大事です。
　　想定問答集を作り、質問には素早く答えること。
　　→パワープレイ（言語以外の説得力）

２．プレゼン資料はピラミッド型の構成にします。
　　ロジカルシンキング、MECE（モレなく、ダブリなく）で考えて、
　　批判的に読んでも納得できる論旨を展開すること。

３．各ページが全体のどこに位置するのかを分かりやすくする。
　　→ページの右肩に小さくナビゲーションマークをつける

４．一番最初に、かがみ文として、エグゼクティブ・サマリーがあり、それから、詳細説明がある。
　　まず、そもそもの本質は何かから始まり、自社の論を展開する。
　　論理展開の途中でつまずくと、もはや、その先は読んでくれない。

５．主張には根拠（ファクト）を付けること。
　　数値データやグラフが望ましい。
　　手持ちのバックアップ資料（ちら見せ）も用意しておく。

６．顧客の業務用語など独自のキーワードを使う。
　　独自のキーワードを使っていないと、オリジナルのものであるのか、
　　他の提案書の流用ではないかという疑義を持たれる。
　　事例で使用する数字は実際にありそうな数値、単位でなければならない。

７．誤字脱字、目次の章立て数字の間違いなど初歩的なミスは絶対避けること。
　　このようなミスは一箇所見つかると、他の細かいところまで探す人が必ずいる。

８．顧客を突き放したような否定形の文章は避ける。（「～できません」など）
　　　→安心感を与える肯定形にする。（「～ならないように、～しておきます。」など）

９．全てを語らず、相手自身が気付くように誘導する。
　　　→より印象に残る。

１０．全ページカラーで、かつ、見開き２ページを１枚として見せ、見開きごとに完結させる。
　　最初にヘッドライン「説明文」があり、その下に「絵」があり、わかりやすい構成にする。

１１．経験・実績のレファレンスは具体的にする。
　　　体制図には人材紹介（スキルや実績）の説明をつける。

１２．「最終成果物」のイメージを明確にする。
　　管理職の習性として、「期日までにちゃんとしたもの（成果物）があればよい」のであり、
　　その「最終イメージ」がつかめるように書く必要がある。

１３．成果物に至るまでの「手法」、「解析法」を取り入れることについて、できるだけ列挙する。
　　　ただ評価方法の全部に対して細かく数値化したものは主観が入り、
　　　人によりブレるので逆に印象は悪い。

１４．手法、専門的な項目など読んでいてインターネットなどで調べないといけない知らない単語を
　　　　適度に散りばめらておくと、都度、調べる手間をかけることにより印象を深くする。
　　　　興味を引くポイントを考える。

１５．顧客の現在のアクションプランとの関係や、作業後の展開や構想まで記述していると評価される。

企画提案編：真の目的を達成する

Sun, 11 Nov 2007 09:32:17 +0900

仮説をたて、検証を繰り返すことで、真の目的から外れないプロジェクトにすることができる。

　ユーザーの声を元に設計し、開発しても、期待される効果をあげられないばかりか、
　結果的にユーザーから使い物にならないと評価され、最後には、使われなくなるシステムが実は非常に多いのです。
　なぜ、そのようなことが起こるでしょうか？

　それは使う人の存在を忘れ、システム開発が目的になってしまったからです。

　システムは操作する人間がいて初めて成り立つものです。
　人の動きを忘れたシステムはいくら優れた機能を持っていても意味がありません。
　「このシステムは機能が優れているから、それを使った人は大変便利だ」という独りよがりの
　思いに陥ることがあります。ほんとうに使う人に便利なのでしょうか？
　ただ、根拠もなしに、「当然そのはずだ」と思い込んでいないでしょうか？

　なぜ、そのような独善的な考えに陥ってしまうかと言うと、「運用面での検証不足」が原因です。
　運用している現場をじゅうぶん理解せず、頭の上で考えたまま開発してしまう場合がそうです。
　このようなシステムでは運用に入って、現場の人に使ってもらう場面になって初めて使えないことが判るのです。

　独善的な設計者はよく「ユーザーが望んだものを作っただけだ。使えないのは正しく要望を言わなかったユーザーが悪い」と主張します。
　しかし、使う人（ユーザー）も実際の動くシステムを見るまでは想像で話しているわけですから、
　最初からピタッと的を得た要望を出すことができないものです。
　設計者と同様、ユーザーもすぐにはシステムの姿を定義できないのです。

　さらに難しいのは最近のシステムが企業の経営戦略や情報戦略支援に変わってきていることです。
　単純な業務コスト削減だけが目的ではないので、従来通りの考え方では失敗する可能性が高いと言えます。
　ユーザーの立場からも見ても、システムの目的が複雑で判りにくく、
　どのようなシステムを開発すべきかが見えてこないのです。

　このような状況を回避するために「仮説と検証」をお奨めします。
　頭で考えた設計は単なる仮説だと考えて見ます。
　仮説が正しいかどうかは検証して見ないとわかりません。
　従来は設計の正しさは本稼動時に初めて検証されることが多いでした。
　設計した成果物を使って、できるだけ早く、できる限り本番に近い形で実地検証します。

　システム開発における仮説検証の注意点：
　・検証期間は各フェーズの最後、１割程度の期間を想定します。
　　例えば３ヶ月の設計期間ならば１週間程度です。
　　検証の結果、設計の見直しや修正を行う可能性がありますから、日程的に少し余裕を見ておきます
　・設計のすべてを検証することは、ほとんど不可能ですから、検証内容は絞り込みます。
　　システムの目的の中で最もキーになる機能、あるいは初めての機能を中心に検証します。
　・検証の具体的な作業内容はケースバイケースで特に決まった方法があるわけではありません。
　　プロトタイプ的なミニシステムができれば良いですが、無理ならば紙と鉛筆でもできます。
　　現場の運用も本番をシミュレートできるのが理想的ですが、
　　だめなら仮想的な机上の検証ですませるしかない場合もあります。
　　本番に近い状況であれば、あるほど検証が効果は高くなります。
　・検証によって仮説（設計）を修正することを忘れないようにします。
　　検証は設計の正しさを証明するために実施するのではなく、
　　仮説の問題点を洗い出し、改善するためにやるのです。
　・システムの目的、プロジェクトの狙いが達成できるかを検証項目に入れておきます。

　こうすることで、プロジェクトの真の目的を外さない様にシステムを開発することができます。

企画提案編：プロジェクトマネージャーはコンサルタントでもなく、ＳＥでもなく、情報戦略のプロデューサです

Sat, 10 Nov 2007 09:47:37 +0900

情報処理システムに関するプロジェクトマネージャは現実のプロジェクトを実行し、成功へ導く先導者であり、傍観者的な評論家でも、言われたことだけする請け負い作業者でもないということです。
　情報戦略を見極め、多くの人と金をプロジェクトへ巻き込みまがら、実効ある成果をもたらすようにしなければなりません。
　まさに「情報戦略のプロデューサ」だと言えるでしょう。

　エバンジェリスト（伝導師）的な巻き込み方を目指しましょう。
　プロジェクトは決して一人で、できるものではありません。
　ほとんどの場合、多くの人々の知恵や力を結集する必要があります。
　多くの人をプロジェクトへ巻き込むには、プロジェクトの目的や意義を、情報戦略と絡ませて説いて回る必要があります。そのためには、自らがしっかりと情報戦略や目的を理解してべきです。
　メンバーの意志を一つのベクトルへ集中させることがプロジェクト成功の秘訣です。メンバーにプロジェクト成功への動機付けができれば、自らの意志で積極的に力を出してくれるので最高にパワフルなプロジェクトになります。

ユーザー、ベンダーを巻き込みながらしっかりした体制を創るべきです。
　プロジェクトに作る人、使う人の区別をつけない方が良いです。「使う人が作る」のが一番ベストであり、最も良いものができます。使う人に作る楽しさや大変さを理解してもらえば積極的にアイデアを出してくれたり、無用に機能を膨らませることも少なくなります。
　またベンダーと言えども人の子ですから、金を出せば何でもやってくれるという発想ではなく、プロジェクトの目的を正しく理解してもらい気持ち良く仕事ができる環境を作ることが大事です。

　またプロジェクトへのファンを増やすことも大事です。
　メンバーの上司や関係部門の人にプロジェクトの存在を知らせ、よき協力者になってもらうことができれば、色々な面でスムーズに進みます。
　メンバーの所属部門の中での立場を有利にするための広報活動にも注意を払いましょう。

　プロジェクトマネージャは管理だけでなく、実作業にも積極的に手を出しましょう。メンバーの仕事をきちんと正確に把握しておくことが大切です。
　そのために自ら経験のない仕事は手伝って理解しておくことです。
　ただし、実作業にのめり込んで本来の管理作業がおろそかになってはいけません。