2009年10月22日木曜日

瑕疵について思ったことまとめ。ソフトウェアの欠陥といっても実は4種類ある。SWEBOK的に考えて。

請負契約でプロジェクトを始める前や、納品・検収が近づくと発注者・受注者間で必ずと言って良いほど交わされる会話がある。

  • 受注者「納品後にバグがありましたら瑕疵として対応いたします。」
  • 発注者「それは安心ですね。ところで瑕疵ってどの程度のバグは瑕疵ですか?」
  • 受注者「えーとですね、それは、、、仕様通りに動作しない箇所は瑕疵ですね。」
  • 発注者「そうですか。わかりました。」

このやりとり、もうちょっと掘り下げたい。

まず「仕様通りに動作しない箇所は瑕疵」というのは正しいが解釈としては乱暴。一口にソフトウェアの仕様といっても様々なレベルがある。たとえばシステムの機能要求に対するものもあるだろうし、明確なコーディング規約をもうけたにもかかわらずそれに従っていないのであればそれも仕様通りとはいえない。また非機能要求を満たせない状態も、非機能要求が仕様書のどこかに明文化されていればそれも含まれる。ユーザビリティは品質要求に含まれることもあるので、納品後に「なんだか使いづらい」とユーザから指摘をされたときも瑕疵として扱うのだろうか?

つまり瑕疵の前に、何をどのように作るのかといったことを発注者、受注者の間でしっかりとした共通認識がとれていることが前提条件となる。当たり前の話と言えばそれまでだが。

しかしプロジェクト開始前にしっかりとした共通認識をとっても、実際はそんな単純ではない。ソフトウェアの開発ではプロジェクト中に仕様が変わることは多々ある。スコープと品質でトレードオフが頻繁に発生することは当たり前で、お互いの妥協点を探りながらリリースを迎えるわけだ。ちなみに悲しいかな納期とコストはこのトレードオフに加わることが少ない。ビジネス上の制約は強いのだ。
変更というのは発注者側からされることが多い。作りながら考えることが多いため、仕様が動的になってしまうのは避けられない。そうなった場合、発注者側から瑕疵を主張するのには無理がでてくる。事前に定めた仕様を変えてしまっては、バグがでるのも仕方がないので、それを瑕疵と主張するのは無理がありませんか、と。

これは正とされる仕様がどの時点の何なのか、変更要求をしっかり行うしかない。地味で手間もかかるがそれ以外の回避方法はないだろう。
ちなみに私は、営業として参加したプロジェクトで、開発中にステークホルダーの同意の下で実装量を増やし品質を意図的に下げた機能について、プロジェクトが終了して数ヶ月後に発注側の担当者が変わってしまい「品質の不備について瑕疵として対応せよ」と主張されたことがある。メンバーは休日も返上して発注者の満足のために開発していたことを知っているだけに非常に悔しい思いをした。

話がそれたが本エントリー主張したいことは以下だ。

ソフトウェアの欠陥(バグ)と一口にいっても、実は4種類ある。これをきちんとするだけでも瑕疵に対する認識を明確に共有できるはずだ。

  1. エラー (error):"計算された結果と正しい結果との間に存在する差異"
  2. フォールト (foult):"コンピュータプログラムにおける不正なステップ、プロセス、またはデータ定義"
  3. 故障 (failure):"フォールトが及ぼす[不正な]結果"
  4. 間違い (mistake):"不正な結果をもたらす人のアクション"
 
まず、わかりやすい「4.間違い」について。これは単純だ。ユーザーの操作ミスによって引き起こされる欠陥(現象といった方が適切だと思うが)であり、運用上の問題である。
「2.フォールト」「3.故障」は場合によってはテスト中、検収中に発見するのは難しいかもしれない。プログラムレベルの欠陥が紛れ込んで発生するのが希少な場合は実際に使ってみるまで発覚しない。私自身はフォールトと故障こそ、ただしく瑕疵だと考えている。
「仕様通りに動かない」のであれば「エラー」も瑕疵に含まれるだろうが、これはちょっと考えてほしい。つまり「"計算された結果と正しい結果との間に存在する差異"」はテストと検収で十分、発見できるはずであるし、できないのであればその方法に問題がある。言い換えれば検収自体がエラーだ。

こういったことを頭の片隅に起きつつ、全段で説明した会話を思い出してほしい。もう少しつっこんで話すべきだし、双方、成果物の何を検証し、どういった役割分担でそれを行うのか、話すべきことはいくらでもあるはずだ。

  • 受注者「弊社では要求仕様書をもとにシステムテストを行います。御社で行われる検収もあわせて、システムの振る舞いが正しいかどうかは十分に検証できると考えますので、瑕疵はプログラムレベルで入り込んだ通常のテストでも発覚しないレアな現象が対象になります。したがって、機能要求通りに動いていないといった欠陥はテストミスおよび検収ミスとみなし、責任は双方にあるので費用は折半させていただきます。場合によっては全額御社の負担です。」

これくらい言っても良いのではないだろうか? いや、言えないんだけどさ(苦笑)。

ソフトウェアから欠陥を完全に取り除くことは現実、ほぼ無理だろう。だからといって欠陥の除去に対して怠慢でよいわけではない。仕様通りに動かなければ瑕疵、というのも間違ってはいないが、それを安直に受け止めて品質改善の努力を怠るのもよくない。
現状をより正確に把握できれば、効果的な対処方法も講じやすくなるはずだ。






多分ね~。

2009年10月6日火曜日

FlashとiPhoneアプリ

Building Applications for the iPhone with Flash


中学校2年生レベル以下の私の英文読解力によると、今年中にFlash CS5でiPhoneアプリの開発をサポート(パブリックベータ)する、というふうに読めるけど、あってるのかな?

Adobe MAXの時期だけ英文読んでいる気がするw。

2009年8月30日日曜日

もしも○○だったらみたいな話

もし私が何かのシステムの発注担当だったとする。
今まで付き合いのあるベンダー「J」は見積もりはドンブリ勘定で費用対効果の説明もほとんどなし。なにかっつーと追加予算を請求してきて発注担当としては苛立つことこの上なし。実際こけたプロジェクトもある。しかし他に請け負えそうなベンダーもないので仕方なく付き合い続けていた。

そんな中、ベンダー「M」がやってくる。MはJのやり方を古いと指摘し、業界でも話題の中心。でも実はMのメンバーの多くはJのスピンアウトだったりする。費用対効果などがものすごくわかりやすい提案書を持ってきて、ちゃらいんだけど声だけはでかい上司(Mとズブズブ)の推薦もあって、社内はMの採用にかなり前向き。でもちょっとまじめに提案書を見ると至る所でボロがある。1、2年は良いかもしれないけど、5年、10年たったらメンテに余計にお金かかるんじゃないの? そもそもおまえらちゃんと開発できんの?

あとさ、提案書にM社の代表さんの写真が至る所に印刷されてるんだけど、これなに?

そうしたら普段まともな提案書なんか書いたことのないJがMに対抗して提案書をだしてきた(Mの提案書だってまともじゃない)。あいかわらずドンブリだけど、10年後には業務効率がめっちゃ改善されると書いてる。それ信じて発注しても提案書作ったJの偉い人は10年後にはもういないでしょ。どうやって「責任」とるのさ?

不安に思ったから他のベンダーにも提案をさせる。
でもでてくる提案のほとんどは「J」と「M」の提案に対する批判ばかり。お前らの提案どうなってるの?
つってもね、しょうがない。どうしたってプライムやれるだけの技術も経験もないんだから。

でだ。本当に心の底からこのプロジェクトを凍結させたいと思う。
お金と時間の無駄だと言いたい。しかも職業意識が低いヤツもいっぱいいて、会議中に寝てやがる。1人月で100~200万とってるのに。そもそも会議の議事録も大事な会議の時ほどでてこない! しょーもない会議の時だけはしっかりでてくる。

でもね、発注担当は私一人じゃないから、発注されちゃうんだわ。JかMに。

恐ろしい話ですよ。ほんとに。

2009年8月20日木曜日

アジャイルかウォーターフォールか

知ったかぶりであることを前提としてください。

私が見聞きする限り、、、

  • プロジェクト計画はガッチガチのウォーターフォールが再び幅をきかせはじめ、それに伴い契約条件もガッチガチに縛られるケースが増えているらしい。成果物請負で〆切りまでに完成しなかったら死ね、みたいなヤツ。
  • しかし案件情報の多くは技術者に求めるスキルがどんどん幅広くなっている。歌って踊れるのは当たり前~、みたいな。プロジェクト計画を立てても後々変わるだろうから、何でも出来る人アサインしちゃえ、ってヤツ。

もうね、その盾と矛はどっちが強いんですかと問いたい。
問い詰めたい。
小一時間ほどry)

どう考えても変更はある!
だったら「ある」前提で計画と契約をするべきだろうと!

目的を達成するための変更を受け入れられる契約形態を模索しちゃいかんのかと。

個人的には以下のアプローチでやってみたい。
  1. やはりアジャイルなプロセスを採用することが望ましい。
  2. CPIFなどの変更に強い契約形態を模索すること。
  3. 発注者、受注者はお互い誠意を持って仕事をすることを合意すること。
  4. あわせて信頼関係を構築すること。

これなら上手くいくはず。






多分ね。

2009年4月22日水曜日

Agile Japan 2009 に行ってきたでござるの巻

(※ mixiの日記と同じ内容です)

// 「Blog/Mixiに書いたらコメント(できれば)する」と平鍋さんがおっしゃっていたので(笑)。

イベントの趣旨と反して、会社に黙って自腹で行ってきました。

なんか不思議な日だった。
「自腹で来たから少しでも身につけて帰るぞ!」の決意の元、めいっぱい前の席に行ったら目の前がポッペンディーク夫妻の席だったとか(笑)。
そのポッペンディーク夫妻が書かれた本にサインをもらおうとして便乗したら平鍋さんのサインまでもらうとか(笑)
とどめに午前中のスピーカーの黒岩さんが隣に座ってるとか。(恐れ多くて何も話せなかった。。。)

そういうミーハーな話はおいといて。

セッション中はひたすらメモとりまくり。テキスト化しんどかった。。。

印象に残ったところとしては、、、
・本質をとらえろ!
・上っ面の改善や部分改善は悪だ!
とかは「リーン開発の本質」を最近読み始めたこともあって、ふむふむという感じ。
あとうっすら自分の中で疑念が生じていた「スペシャリスト化を推奨する組織」に対して、アンチテーゼの「多能工の必要性」が言及されていて嬉しかった♪
なんでもやればいいってもんじゃないけど、これしかやらないって宣言しちゃうのもいかがなものかと。

そういう自分としてはここしばらく「コーディングは死んでもやらん。覚える気ナッシング!」というのを撤回しようかと。
とりあえず"Hello world"からはじめようかな……?

でもやっぱ一番印象残ったのは
"Defend Vision"
だな。平鍋さんも通訳をされながらおっしゃっていたけど、"Keep"じゃないところに重要さを感じた。
ヴィジョンを守れ! ていうか「ヴィジョン防衛」。さらに言うとヴィジョンの防衛のためなら先制攻撃もやむを得ず。そういうイメージ(笑)
(※ そんなこと誰も言ってません)

感想としては、参加して良かった!
なんかやる気がでた気がする(明日には元に戻る?)

2009年3月10日火曜日

私的な格言(ムダに関して)

コミュニケーションは仕事をする上でもっとも大切な事の一つだが、仕事を進める上で最もムダな事の一つでもある。

──takelog3000

私の数少ない経験上、コミュニケーション・マネジメントはどこ行っても軽んじられているにもかかわらず、軽んじてしまったがためにプロジェクトに重大なオーバーヘッドを発生させる原因にもなっていると思います。
クライアントが何気なく納品を求めたドキュメントはそのわかりやすい例ですが、日常においても「なんでそんなこと知らないの?」みたいな事は思いの外、時間をムダにするものです。

シナジーがどうたら言う前に、コミュニケーションに無理、ムダ、抜け、漏れ、冗長さがないか、根本に立ち返って考えてみるのも悪くないはずです。






多分ね。

ユニクロすごい

いつからこうなってたのか知りませんが、、、 
まずTOPページから店舗検索に入ります。 


「GoogleMAPすか、そうすか」 

くらいの感想です。そういうサイトいっぱいあるしね。 
で、その後に「地域検索」で好きな都道府県を選びます。東京を選べば、東京都の地図にユニクロのアイコンがぶわーっとでてきます。 

「ま、どこでもやってるよね。」 

でも実はGAP、無印、しまむらはやってない(はず)。 

でもあんまり驚かない。 
それからどこか適当な店舗を選んで「詳しくはこちら」をクリックします。 
そうすると「店舗情報」がでますよね。その下の方に表示されている折り込みチラシのサムネをクリックします。 


「へぇー、やるじゃん。でもスーパーとかもやってるよね」 

そう、やってますよ、どっか忘れたけどスーパーとかも。 
でもこのチラシの「値段」をクリックしたらびっくりしました。 


「ちょwwwwwwwおまwwwwwwwwwwwwww」 

通販ページにとぶんですよ! 
しかも気づきましたか? ここにいたるまでちっとも重くなかったことを!! 
このページもすごいんだけど、こういうサービスを展開できるってことは、業務も含めて効率化が図られているんだと思う(当たり前だけど。。。) 

ヤバイ。。。 

ていうかヤバイ通り越してキモイ。 

この本、買うべきだろうか……? 
http://www.amazon.co.jp/dp/447837483X/ 
(ファーストリテイリングの事例が載ってる) 


なんか己の不勉強さとかいろいろ考えてしまった。。。 


うちの会社のSEもさぞかし驚くかと思い、メッセンジャーでURLを送ったら↓のような返信が。。。 


「佐々木希ちゃんだーーーーーっ♪」 


そこかよっ!

2009年2月19日木曜日

最近ていうか昨日買った本。

「アート・オブ・アジャイル デベロップメント ―組織を成功に導くエクストリームプログラミング 」 
http://www.amazon.co.jp/dp/4873113954/

  受託の開発案件でアジャイルを採用するには、、、?
  そんなことを考える今日この頃。これから読みます。


「Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本」
http://www.amazon.co.jp/dp/487311392X/

ノリだね。思わず買ってしまった。そのうち読みます。


「JUDEで学ぶシステムデザイン (oop Foundations)」
http://www.amazon.co.jp/dp/4798114766/

会社の昼休みにちょっとずつやってみることにしました。


私が所属している会社は「RIA」の開発をやっています。
昨日、勉強会にいったこともあるので思うのですが、今後は「クラウド」を使う頻度は高くなるはずです。
開発会社としてはノウハウは必須。
さらにお客さまにとって価値あるシステムをとどけるには「アジャイル」が必要なんだと思います。
受託の開発でアジャイルを採用するにはかなーり閾が高い(お客さまが嫌がるケースが多い)のですが、なんとかしないとならんだろうと。

プロジェクトで利益がでても、お客様にとって無価値なシステムを納めたら、イコール、私たちはお客様にとって無価値だと思うんですよ。





多分ね~。

2009年2月18日水曜日

2009年2月10日火曜日

開発プロセスにおける妄想

特に使い道のない妄想を書いたのでblogにはっておく。

【目標】正しいアジャイル型のプロセスをもつ組織になる
【補足】アジャイルの肝は規律である!

【目標】顧客にとって本当に価値のあるシステムを構築しやすいプロセスをもつ組織になる
【補足】単純な人月の論理を顧客に押しつけないこと。顧客の満足をめざし、そこから得られるチームの喜びに執着すること。

実現するためには。。。

1.開発プロセスの標準化について

「プロセス」という上段から入ると収集がつかなくなるか本当に大切なことを見落とすことになる。なぜならプロセスは「概念」レベルだから。まずはプロジェクトを遂行する上で計画や作業の抜け漏れを防ぐために「アクティビティ」の洗い出しを優先する。

(参考までに)
 プロセス     概念。作業手順を抽象化したもの。
 └アクティビティ 論理。動きや振る舞い、活動を表す。
  └タスク    現実、物理的なもの。人やモノに結びつく。対象物が存在する。
 
 プロセスの標準化において、現時点で洗い出すものを「アクティビティ」のレベルとしたのには理由がある。
 プロセスのレベルではあまりにも抽象的すぎて営業レベルで話す分には問題がないかもしれないが、プロジェクトに適用するのは無理。そもそも抽象の度合いが強すぎて解釈が大幅にぶれる。タスクのレベルは実際のプロジェクトでないと決めることが難しく、現実のプロジェクトにおいても日々増減をするものなので、事前に決めるのには無理がある。
 
 
2.アクティビティの洗い出しについて(マッピング)

プロジェクトにおけるアクティビティは多い。そこでPMBOKの5つのプロセスと9つの知識エリアを利用してマッピングをして整理する。

<PMBOK>
http://www.netlaputa.ne.jp/~hijk/study/docs/pmbok_overview.html#AContents
 プロジェクトのプロセス
1.立ち上げのプロセス プロジェクトの次のフェーズの着手を組織としてコミットする。
2.計画のプロセス
3.遂行(実行)のプロセス
4.コントロールのプロセス 計画からの乖離を識別するために、 プロジェクトの進捗は定期的に測定する必要がある。
5.終結のプロセス
 知識エリア
統合マネジメント
スコープマネジメント
タイムマネジメント
コストマネジメント
品質マネジメント
組織マネジメント(リソース)
コミュニケーションマネジメント
リスクマネジメント
調達マネジメント

 なぜPMBOKなのか? それはPMBOKがプロジェクトの「順序」よりも扱わなければならない「事象」に重きおいているからだ。
 順序が間違っていても、扱う事象が正しければプロジェクトはいつかは終わる。逆に順序が正しくても、扱う事象が間違っていればプロジェクトは終わらない。


3.アクティビティの洗い出し(なにから手をつけるか?)

 最初にコミュニケーション、次に品質から洗い出すことをオススメしたい。もちろん理由はある。ちょっと遠回りだが説明をする。
 プロジェクトにおいて「早い、安い、旨い」の3つを実現するのは難しい。何か1つを犠牲にすれば2つは実現できる。しかし3つ全部はそれなりに考える必要があるが優先順位をつけることで打開できはずだ。
 
 「早い」
 逆の視点。遅いはどうだろうか? システム開発において遅いはあらゆる観点で罪だ。遅いは「高い」にもつながる。

 「旨い」
 品質は早いを実現する必須条件である。プロジェクトの進捗を滞らせる原因はあらゆるフェーズに潜むバグである。プログラムのバグもそうだが、プログラムのバグの元になる設計のバグ、設計のバグの元になるコミュニケーションのバグ。これらは手直しに工数を要するため結果として早さと安さを犠牲にしてしまう。
 つまり「旨い」は「早い」につながり、結果として「安い」を導き出す。3要素を高レベルで達成することを目指さないと、これから先の開発ベンダーは生き残っていくことが厳しくなってくる。
 ならば品質から着手するべきではないかと思ってしまうが、結局、品質を下げる原因になるのはコミュニケーションのエラー(バグ)だ。認識の違い、情報共有の拙さがエラーを生み出し貴重な時間を浪費することになる。また顧客が本当に必要とする価値のあるシステムにたいする要求を拾い上げる妨げにもなる。だから洗い出すべき最初のアクティビティはコミュニケーションを中心に行う必要がある。
現実のプロジェクトにおいても、品質要件や非機能要求は顧客とのコミュニケーションから生み出される。目標もはっきりしなければどの程度の品質を確保すればいいのかすらわからないはずだ。



4.モデルプロジェクトの構築

PMBOKへのマッピングが終わったらモデルプロジェクトを構築しレビューを行う。まず手始めに10~20人月程度のプロジェクトを想定してみると良い。10人月未満のプロジェクトではプロセスはそれほど大切ではなく個々人のスキルに依存する割合が高い。20人月を超えるプロジェクトはより厳格なプロセスが必要になり扱いが困難になる。10~20人月のプロジェクトをしっかり運営できるようにすることから始めるのは決して悪い話ではない。
そしてしっかり洗い出されたアクティビティがベースになっていれば、抜けや漏れがあることは考えづらい。今度は「冗長」なアクティビティを省略する作業を行う。これも「早い、安い、旨い」を高レベルで達成するために必要な手段である。


5.注意点

これらの作業を進めていく上で気をつけること。おそらくいろいろな要素が関連し合い、まとめたり洗い出したりする作業が困難になってくる時期がある。そういうときは下記の原則を思い出すこと。

・インプットとアウトプットに着目し、シンプルに考える
・正しい行動は「考える、実行する、確認する」の3つの要素でなりたっていること。迷ったらこれを思いだしシンプルに考える。

アクティビティの洗い出しを進めるとき、序盤でどれくらいの時間がかかったのか記録をしておこう。こうすることであとどれくらいで作業が完了するのか、より正確性の高い見積もりができるはずだ。





多分ね~。

2009年2月8日日曜日

最近買った本

(※ mixiの日記と同じ内容です)

「システムはなぜダウンするのか 知っておきたいシステム障害、信頼性の基礎知識」 
http://www.amazon.co.jp/dp/482228381X 
→まだ読み途中。ダウンの原因、、、やっぱり行き着くところは「人」だよなぁ、、、と思う。エラーやバグを作り込まないために「コミュニケーション」の品質を上げるっていうことにもうちょっと気を遣いたい、っていうか遣おうよ、ってボソっといってみたんだけど「…?」な感じ。 


「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」 
http://www.amazon.co.jp/dp/4839924023 
→まだ読み途中。開発対象を「作業量」でなく「価値」で見積もり、実際にどれくらいかかるかは組織の「生産性」をもって計画をたてなさい、とかね。これは「初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方(http://www.amazon.co.jp/dp/4822282422/)」における、1.機能量、2.工数、3.期間、4.生産性、5.品質は分離して考えなさい、というのに近いなと。当たり前に思えるかもしれないけど、現場(ウチの会社)はこの辺がごっちゃ。 
あと仮説ベースで機能がどれくらいの経済的な価値をもっているのか算出しましょう、とかもね良い! 読み応えあります。あと装丁が格式高い感じがするのも良い。 


「与信管理の本」※ タイトルぼかしました。 
→まだ読み途中。こういう本を買って読まなきゃならんあたり、つくづくIT雑用係の名に嘘偽りはないな、と。(自称ですけど) 
中身はね、ひどい。こんなに抽象的な表現で、冗長な構成で、日本語そのものの品質がひくく、読んでいてイラっとする本はないね。仕事中にくるヘンなメール並みの腹立たしさ(笑)。 


「Google Gearsスタートガイド」 
http://www.amazon.co.jp/dp/477413287X 
→途中、途中読んだ(しゅんぺいさんごめんなさい) 
すごく、細かいです。 
そのくらいの内容は読み手に調べさせればいーじゃん、ていうところまでしっかり解説。全然、手抜きなし。あと説明が簡潔で具体的。だからGoogle Gearsやらない人が読んでも良いし役に立つ内容。Adobe AIRとかをやっている会社で働いていて、気まぐれなお客さんに「AIRって何?」って聞かれたときに、「そんなもんググレカスとか」とか言い返したい気持ちをぐっとおさえて説明するときに、この本を読んでおくとその説明の裏付けや説明そのものをわかりやすくすることにも役に立ちます。こう書くと理論や概要を説明している本かと思いますが、ちゃんとサンプルプログラムやリファレンスも載ってるから資料的価値も高い。 
お買い得感満載な本です。 


「ネットワークはなぜつながるのか 第2版 知っておきたいTCP/IP、LAN、光ファイバの基礎知識」 
http://www.amazon.co.jp/dp/4822283119 
→訳あってあとまわし 


「T業界のための『工事進行基準』完全ガイド 基礎と事例と18の特効薬」 
http://www.amazon.co.jp/dp/4822215792/ 
→あとまわし。訳はない。




多分ね~。