┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.108 2005/09/14
■ I N D E X
┃
┣【Topics】PM Conference 2005にてプロジェクトファシリテーション講演！
┣【Topics】オブジェクト倶楽部が紹介されました！
┣【設計】ソフトウェアのお言葉[8] - 生産性と品質は不可分である
┣【UML入門】デザイン理論とUML図 - 黄金比で美しく
┗【アンケート】気になるシステム業界 ホントのところ
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 PM Conference 2005にてプロジェクトファシリテーション講演！
〇 〇━━━━━━━━━━━━━ ━━・
翔泳社主催のPM Conference 2005(10/11、12)にて、オブジェクト倶楽部の平鍋
健児が、このメルマガでも連載しているプロジェクト・ファシリテーション(PF)
について分かりやすく解説する予定です。PFの話を同僚にも聞かせたい、と思っ
ている方、レコメンデーション、お願いします。
http://www.pminfo.jp/conf/
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 オブジェクト倶楽部が紹介されました！
〇 〇━━━━━━━━━━━━━ ━━・
E.I.S(組込み技術者向けのオンラインサイト)の中で、『SESSAMEメンバが語る
「組込みソフト開発の明日」』として、NECソフトウェア北陸、西川幸延さんの
インタビュー記事が掲載されています。その記事の中で、西川さんが当オブジェ
クト倶楽部のイベントを紹介してくださいました。「組込みエンジニアよ、社
外へ飛び出そう！」の熱いメッセージがあります。社外へ飛び出すきっかけと
して、社外へ飛び出してからの新しい知識の習得・交流作りとして、オブジェ
クト倶楽部がみなさんのお役に立てれば幸いです。
http://www.caravan.net/eis/ (左メニュー「EIS提携コラム」の3番目)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【設計】ソフトウェアのお言葉[8] - 生産性と品質は不可分である
こんにちは、天野勝です。
今回のお言葉は「生産性と品質は不可分である」です。書籍「ソフトウェア開
発201の鉄則」[*1]の3番目の原理として紹介されているこのお言葉を、今回も
筆者の独断と偏見で、解釈、解説してみます。
このお言葉が指すところは「品質を高めようとすれば、生産性が低下し、生産
性を高めようとすれば、品質が低下する」ということです。今回は、筆者がこ
のお言葉をどのように理解してきたか、その変遷をご紹介しながら、解説して
みます。
初めてこのお言葉を目にしたときは、「まさに、その通り」と思いました。時
間をかけなくては。品質を高めるためには、テストにじっくりと時間をかける
ことが必要だ、と漠然と理解していました。このころは「品質が高い＝バグが
無いこと」と信じていました。
しかし、テストファーストという考えに出会ってからは、この言葉に疑問を持
つようになったのです。「テストと言いながら、やっていることはデバッグ作
業なのでは」と思ったわけです。いわゆる「作ってから直す方式」ってやつで
すね。テストファーストに従ってプログラミングを進めていくと、プログラム
ができ上がった時点で、ほとんどバグが無いのです。プログラミングが終わっ
た後に、単体レベルでのテストを、改めて時間をとって行うまでも無いのです。
これは、衝撃的でした。そして、気づいたのです。
「品質を向上すれば、デバッグの時間が短くなるから、生産性も向上する」
そうです、今回のお言葉である「生産性と品質は不可分である」に疑問を感じ
るようになりました。さらには、ソフトウェア品質の定義である「ISO/IEC 9126」
を読んで、バグが無いというだけでは、品質としては不十分だということにハッ
とさせられました。利用者にとっての品質、開発者にとっての品質、というよ
うに、立場によって品質の捉え方が異なるというのです。品質というものに対
する考え方が変わりました。
開発者にとっての品質という点では、保守性という品質特性を重視するように
なりました。「修正しやすい」、「拡張しやすい」というのは、開発者の立場
で考えるとやはり外せないですよね。さらに、「テストしやすい」ということ
も重要であると思うようになりました。テスト工程にかかる時間を極力少なく
すれば生産性が向上するわけですから、設計の段階からテストしやすい設計を
心がけるようになりました。
ソフトウェアの品質保証という考えに出会って、また考えが変わってしまいま
した。「生産性と品質は不可分である」に納得してしまったのです。
「品質が高い＝バグが無いこと」では不十分なのですが、あえてバグを例にとっ
て考えてみます。バグが無いことを証明するというのは難しいという話は、皆
様ご承知の通りです。では、どうやってこのようなものを保証するのでしょう
か。現在の主流の考え方では、プロダクトに対して保証するのではなく、プロ
ダクトを作った過程を保証するという立場をとります。「はぁっ？」というの
が筆者の最初の感想です。作られたものではなく、作られる過程を保証すると
いうのが、理解できませんでした。製品を作る過程で、製品を何らかの観点で
チェックするということが決まっているならば、そのチェックが行われている
かをチェックすることで保証するというわけです。筆者にとっては、なんとも
奇妙な感じです。
正しいだろうと思われるテストを充分に行ったかということで、保証するので
す。多少歪んだ表現ですが、時間をかけてテストをすればそれだけ品質が高い
ということになります。確かに「生産性と品質は不可分である」のだなぁと、
納得してしまいました。
現在、他にも品質の保証の仕方があるのでは、と考えているところです。
皆さんにとっての「品質保証」とはなんですか？(天野勝)
[1]:http://www.amazon.co.jp/exec/obidos/ASIN/4822290026/xpjp-22
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=L001-7&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=L001-7&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=L001-7&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【UML入門】デザイン理論とUML図 - 黄金比で美しく
このシリーズでは、論理的・機能的側面よりも美しさにこだわった、一目見て
わかりやすい、見たくなる図を描くための要素を数回にわたって紹介しようと
思います。
黄金比で美しく・・・
まず、黄金比とは何ですか？という人もいるかもしれないので、簡単に説明し
ておきます。黄金比とは、古代エジプトで考案され使われてきた美の法則なん
ですね。この法則に従っていると視覚的にバランスが取れ、美しく見えるとい
うものです。ではなぜ美しいか・・・植物の花弁や貝殻の螺旋構造などさまざ
まな所でこの原理が見られるのです。黄金比は、多くの自然界に存在する有形
物が持つ比率であることが20世紀なって解明されました。ダ・ヴィンチのモナ
リザやギリシャの建造物に理想の美を感じるということは、人間がもともと自
然の形に美や調和を見いだすからではないかと言われています。ちなみに、大
人気となっているiPodの外観も黄金比になっていて、それが見た目にカッコい
いとか、美しいとかいう印象を与えているようです。つまり、黄金比は個々の
図形を美しく描くための基本的要素です。そこで、まずはクラス図におけるク
ラスの短径を黄金比で描くことで、誰から見てもも美しいモデルへの1歩目を踏
み出しましょう。
さて、黄金比って具体的にどういう比率なの？ということですが、短辺と長辺
の比率が1:(1+√5)/2 = 1:1.6180...となるものをあらわします。これってどっ
かで見たことあるなーという人はかなりの数学マニアか、ウサギマニアか。そ
うフィボナッチ数列の増加率に関係してますね。・・・あっ、話がそれました。。
では、実際にクラス図を描いてみましょう。クラスには名前、属性、操作を分
割する線がありますね。この分割線の高さによって全体バランスが悪くなると
美しさを失ってしまうのではないか？と思いませんか。そこで黄金分割です。
黄金分割とは、図形を黄金比の1:1.6180....で分割することです。クラスの名
前は1行固定が一般的ですので、分割の基準を属性と操作に注目してみることに
します。すると、どちらかの要素が多いはずです(稀に同じかもしれません
が・・・)。そこで、要素の多い方の高さを1.6程度に、少ない方を1として分割
してみます。どうですか？他の位置に分割線があるよりもしっくりきますよね。
また、全体のレイアウトという意味では、例えば印刷などをする場合、A4など
の紙は1:1.414...の√2だったりするわけです。紙サイズとのバランスを考える
と、黄金比の1クラスずつの配置に配慮したり、1:1.6180...の外枠線を描くこと
でバランスを保つ方法があります。図全体の配置バランスについては次回のネタ
になっていますので、楽しみに待っていてください。
この内容に興味をもった方は、黄金比で図を描いてみてください。今まで自分
の図はしっくりこないな・・・とボヤいていた人も、見たくなる図を描けるよう
になると思いますよ。
※私の知っている範囲でUML図が描けるGUIツールは、クラスの名前・属性・操
作の分割位置を指定できないため、本記事はツールの使用を前提としており
ません。もしそういう図が描けるツールがあるのならぜひ試してみたいと思っ
ていますので情報お持ちの方はお知らせくださいませ。(きしだ)
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=C004-0&choice=0
普通：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=C004-0&choice=1
イマイチ：
http://www.ObjectClub.jp/community/object_ml/estimate?vol=C004-0&choice=2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3 r d ■━
■
┗【アンケート】気になるシステム業界 ホントのところ
今週は「選挙に行きましたか？」のホントのところ。今回の選挙は投票率が67%
を超えましたが、メルマガ読者の方の投票率はどうだったのでしょうか。みな
さん、選挙には行きましたか？
もちろん行きました！
http://www.ObjectClub.jp/special/kininaru/vote?vol=74&choice=0
義務感で行っておきました。
http://www.ObjectClub.jp/special/kininaru/vote?vol=74&choice=1
行きたかったのに行けませんでした。。
http://www.ObjectClub.jp/special/kininaru/vote?vol=74&choice=2
興味なし！行きませんでした。
http://www.ObjectClub.jp/special/kininaru/vote?vol=74&choice=3
選挙なんてあったんですか？
http://www.ObjectClub.jp/special/kininaru/vote?vol=74&choice=4
次回は是非出馬します！
http://www.ObjectClub.jp/special/kininaru/vote?vol=74&choice=5
それは秘密です。
http://www.ObjectClub.jp/special/kininaru/vote?vol=74&choice=6
ちょっと語らせて！
editors@ObjectClub.jp まで詳細を！！
アンケート結果はオブジェクト倶楽部サイト上にて公開します。お楽しみに。
なお、前号「キーボードにどのようなこだわりがありますか？」の結果は公開
中。是非ご覧下さい。
⇒http://www.objectclub.jp/special/kininaru/vol73/PlonePopoll_results2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。連日世間を賑わせていた選挙が終わりましたね。選
挙当日に開票作業が始められ、明朝までには結果がでます。この迅速さってす
ごいですよね。読取機(処理能力480票/分)を導入している選挙区もあるそうで
すが、読取機の普及はまだ20％前後で、すべて手作業(！)にたよっている自治
体が多いそうです。迅速(Agile)であることは価値の高いことでしょうが、選挙
を裏で支える人たちも大変なんですね。
今週の強引な一言
*** 国乱れて忠臣見る（ことわざ）***
プロジェクトが混乱して初めて、リーダの資質が見えてくるというのも事実。
短いサイクルの繰り返し型の開発では、一度早いうちにプロジェクトを混乱さ
せてしまいましょう。そこから体勢を立て直せば、きっと強いチームになって
いることでしょう。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/community/object_ml/help/
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/community/object_ml/
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2005 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.