要求考古学 Part.2

前回に引続き、6月末の要求開発アライアンス 勉強会合宿で見つけたキーワード「要求考古学」に関する考察です。いくぶん妄想(暴走)気味ですのでご注意を。記載内容は私の考えであって、内容は誤っているかもしれません。

■近代的要求考古学

現行システムを「観察する」ことによって得られる情報は、限られています。というわけで、より深く調査をするのであれば、「分解する」する必要があります。というわけで、仮にこれを(前回評した古典的要求考古学に対するものとして)近代的要求考古学アプローチとでも呼ぶことにします。

「分解する」とひとことで言っても、実際のところは設計作業をもういちど行う、つまり「再設計する」事に等しく、ひょっとしたら「分析」「解析」というキーワードが適切かもしれません。

言うまでもなく、現行システムを完全に解体し設計書を全て再作成することは困難なだけではなく、その労力を考えると現実的ではありません。また、次のプログラミングの基本法則により、実際の作業は見かけよりも難しいと言えます。引用元は書籍化もされている、システム開発に関する有名BlogのJoel on Softwareからです。

プログラマがいつでも既存のコードを捨てて最初からやり直したいと思うのには、ちょっとした理由がある。その理由というのは、古いコードがクズだと思っているからだ。そしてここに興味深い観察事実がある。 彼らはたぶん間違っている。 彼らが古いコードがクズだと思うのは、プログラミングの基本法則のためだ。

プログラムというのは書くのより読むほうが難しい。

これがコード再利用がかくも難しい理由だ。あなたのチームのプログラマが、文字列を分割して配列にするための関数に、みんな違うものを使っているのはこのためなのだ。彼らが自分で関数を書いている理由は、古い関数をどうやって使うのか調べるよりも、そのほうが簡単だし、楽しいからだ。

Joel On Software/Joel Spolsky

■分解する方法について

さて、分解の方法としては、いくつかの戦略を取る事ができます。それぞれのメリットやデメリットを整理してみます。

• データ中心アプローチ
• 入力(人間系や外部システムから)から出力(画面や帳票、外部システムまで)まで、データの流れを中心に分解する方法です。一般的にはデータフローダイアグラム(DFD)を作成していく形になります。(要求開発アライアンスの提唱する開発方法論 Openthologyでは、UMLクラス図をカスタマイズしたTFP分割手法を提言していますが、これも一種のデータフローダイアグラムと言えます)
• メリット
• システムの堅牢性、確かさの側面で深く分析がされます。
• 機械的な作業であるため、人海戦術を用いて実行することができます。
• 誤解の入る余地があまりありません
• システム対象業務固有の知識を、あまり意識する必要がありません。
• デメリット
• 対象の規模にもよりますが、コストと期間を要します。
• システムの使いやすさや、特徴は表現されません。
• 分析結果は利用者には分かりにくいものになります。よって、レビューなどによる確認が難しくなります。
• 機能中心アプローチ
• システムの有する機能(メニューや機能名)中心にシステムの構成要素を分解する方法です。結果として、システムユースケース図に近い成果物を作成する事になります。
• メリット
• システムの使いやすさや、特徴が現れます。
• 利用者にもわかりやすい分析アプローチのため、分析作業やレビューに参加してもらうことが容易です。
• デメリット
• データ中心アプローチと異なり、分析に漏れが発生する可能性が高くなります。これは、データと異なり機能は隠されたり、分散されている事があるからです。
• システム対象業務固有の知識が必要です。用語集などを作成しなければ、誤解を生じる可能性があります。
• 構造中心アプローチ
• システムを構成するプログラムの構造を中心にした分析です。一種のリバースエンジニアリングに近く、コードを元に分析を行います。データライフサイクルの観点でプログラムとデータの関係を整理する(CRUD図)、プログラムの構造を図式化する(UMLクラス図等)ことになります。
• メリット
• 作業の機械化が可能です(実際に、このような分析を行うツールは様々なものがあります)
• デメリット
• 既存システムの品質(保守性やコードの可読性、充分な共通化)によっては、結果が使い物にならない可能性があります。スパゲティプログラムを分析しても、わかる事は限られています。
• 分析結果は利用者には分かりにくいものになります。よって、レビューなどによる確認が難しくなります。

ここまで書いて息が切れました。というわけで、次回に戦略面での考察を続けます。

要求考古学

この間の要求開発アライアンス 合宿勉強会のワークショップの中で出てきたキーワード「要求考古学」について考えています。

■要求考古学の定義

考古学は人類が残した痕跡(例えば、遺物、遺構など)の研究を通し、人類の活動とその変化を研究する学問である。

Wikipedia:考古学より

を参考とするならば、要求考古学の定義は次のようになるかと思います。

要求考古学は設計者が残した痕跡(例えば、現行システム、設計書、マニュアルなど)の分析を通し、本来のシステム要求とその変化を研究する学問である。

要求考古学が必要とされるシチュエーションは、次のようなケースをぼんやりと考えています。

• 現行のITシステムに新たな機能(要件)を追加する必要がある。
• 現行のITシステムが何らかの理由で維持困難となり、現行システムの要件を充足した新システムを構築しなければならない。
• ITシステムのデータを再利用する目的で取得し、何らかの処理を行なう必要がある。

こういった作業の際に、システムの当初の要求(要件)が不明である場合(当初の関係者がいない場合を含む)には、作業者は要求考古学を用いて要求発掘を行う必要があります。

■古典的要求考古学

さて、最も簡単なアプローチは何でしょうか。それは「観察する」です。つまり、

• 現存するドキュメントを読む
• 動かしてみる
• プログラムを追いかけてみる

ことにより、なぜそうなっているのかを類推するアプローチです。

実際にITシステムの保守フェーズでは、こういったアプローチは一般的に行われていると思います。ちょっとした機能の追加を小規模に行う場合には、適用可能な方法です。

しかし、このアプローチには、2つの問題があります。

■効率の問題

ITシステム開発では、「仕様の爆発」という現象が発生します。

真実26.仕様定義フェーズから設計フェーズに移るとき、膨大な数の「派生仕様(derived requirements:仕様を具体的な設計方式にブレイクダウンする場合、設計方式に対する要求仕様)」が生じる。これは、問題解決プロセスが複雑なために発生するもので、この設計設計の量は元の仕様の50倍になることもある。

ロバート・L・グラス ソフトウェア開発55の真実と10のウソ より

これはつまり、当初の要件が、最大で50倍の文書等に分散してしまうということを言っています。実際にはここまでの爆発はあまりないと思いますが、それでも、爆発した仕様の破片から、当初の要件を導き出すのは効率的ではないと言えます。

■正しさの問題

もう一つの問題は、現行システムを観察しても「正しい要求」を導き出せない事があるという点です。これには二つの理由があります。一つはソフトウェア開発特有の原因です。

真実27.ソフトウェアの開発において、ベストの解法が１つしかないことは、まずありえない。
真実28.ソフトウェアの設計は、複雑で反復が必要なプロセスである。従って、最初に考えついた設計方式が間違っている可能性は高く、最適解ではない。
ロバート・L・グラス ソフトウェア開発55の真実と10のウソ より

つまり、今見えている仕様が最適解であるとは限らないのです。その仕様を元に当初の要求を考察したとして、本当に正しい要求に立ち戻れるかは大きく疑問があります。

また、もう一つの問題点としては、現行システムが「当初の要求ではなく、要求の代替策を表象している」可能性があることです。現行システムを最初に開発した時には、何らかの理由で要件を満たすことができず(例えば、パフォーマンス等の問題により)、より望ましくない要件(例えば計算を簡略化するなど)が採用されている場合、観察によって当初の要件が得られることはまずありません。

というわけで、改めて書き下してみると、古典的要求考古学は問題点が山積みです。長くなってきたので、次回は別のアプローチを考察してみようと考えています。

ソフトウエア開発 55の真実と10のウソ

posted with amazlet on 07.07.09

ロバート・L・グラス 山浦 恒央
日経BP出版センター (2004/04/08)
売り上げランキング: 113029

Amazon.co.jp で詳細を見る

要求開発アライアンス合宿レポート その２

というわけで、前回に引続き先日行った、要求開発アライアンスの勉強会合宿「要求開発 実践からのフィードバック」のレポートです。個人的なメモも兼ねているので、一部わけわかんなかったらごめんなさい。2日間の合宿の1日目のレポートはこちらです。

さて、前日の講演と宴会(反省会・猛省会)が終わった後ホテルに帰ったのは午前3時orz...。ギリギリまで寝て、翌朝バイキング形式の朝食を済ませた後、さっそくのワークショップです。

■ワークショップ１『要求不在自慢 ～「失敗に学ぶ、要求開発実践のためのポイント」』
要求開発アライアンス理事の細川さんによるプレゼンテーションとラウンドテーブルです。

失敗学のすすめ

posted with amazlet on 07.07.06

畑村 洋太郎
講談社 (2000/11)
売り上げランキング: 34241

Amazon.co.jp で詳細を見る

私はまだ味読なのですが、「失敗学」を参考に、特に上流工程における失敗についての対策を考察するという筋立てで、参加者によるディスカッションをしました。細かい内容は非常にナマナマしいのでご紹介できないのですが、いろいろと興味深いキーワードも沢山出ました。以下メモです。

• 日本のITにおけるユーザ「没」主体と業界構造
• 米国では、ユーザ企業の役割として「CIO」「アーキテクト」「PM」「専門技術者」がいて、これを支援する形で外部のベンダーや専門家・海外技術者が参加するというプロジェクト形態となっている。
• 日本では、ユーザ企業の役割は未分化で、「CIO」もいない場合が多く、また情報システム部門が曖昧に「アーキテクト」「PM」「専門技術者」の役割を担っている。そして、外部のベンダーが対応して二次請けとしてソフトウェアハウスや海外技術者を利用するという、多段構造になっている。
• 日本の「総合的なIT投資意欲」の低さ
• ITへの投資額などは大きいが、CIO設置比率や経営陣のIT重要性理解、攻めのIT投資など総合的に比較すると、海外に比べて非常にランキングが低い。(ガートナー 2007/5)
• 日本人は「失敗を受け入れ難い」(?)
• 本来はデジタルに「成功」「失敗」が決まるわけではない。「失敗」ではなく「10%成功」「30%成功」という状況を受け入れて、より成功するための戦略を。
• うまくいかないパターン
• 要求不在
• ビジネス目的と関係の無いゴールがあらかじめ設定されている
• ステークホルダー不在(肝心な利害関係者がプロジェクトにいない)
• フォーマルな開発方法論の適用やコタツモデルの導入で失敗を防止
• 要求発掘(要求考古学)
• 最近増えて来ているシステム更改では、要求を定義したり開発をするのではなく、考古学的に発掘しなければならない事がある。
• 仕様書がない、とか
• 仕様変更の繰り返しの結果、当初の目的が失われている、とか
• 面倒になって、全てを移植しても、実際には使われない、とか
  
• 非常に困難そして非効率。
• 別のアプローチの検討が必要

約90分のセッションはあっというまに時間切れ。参加者は10名くらいだったのですが、かなり熱いディスカッションとなりました。個人的には「要求発掘」について響く事が多く、もうすこし考察してみたいと考えています。

なお、同じ時間には別の部屋でもセッションが行われています。『布教の時間：～ビジネスモデリングの有効性：価値のある見える化に向けて～』『おまかせ隊長！よだばなし』全部に参加できないのが残念です。

■ワークショップ２『実演ライブ！　要求分析ツリーがみるみるできる』
続いてのセッションは、要求開発アライアンス理事長の山岸さんの実演ライブ。要求分析ツリーの作成を、コンサルタントとユーザ企業担当者の掛け合いロールプレイで実際にやってみるというものです。個人的にはトークの流れや質問の仕方について非常に刺激になりました。また、要求分析ツリーは適当なツールが無いのが悩みで、ExcelやPowerPointを活用していたのですが、ここではJUDEのアクティビティ図を使って作成していました。なるほど！

このセッションもあっという間に時間が尽きてしまいました。別の部屋では『ハッピー！ホッピー！TFP！』『体験！君がオブジェクトだ！』というセッションが行われていましたが、これも超気になります。

ここでだいたい12時です。最後にクロージングミーティングを全員で行って合宿は終了。睡眠不足気味ですが、非常に充実した2日間となりました。

要求開発アライアンスで合宿を行いました

またもや更新間隔が空いてしまいましたが、先日金曜日の夜から翌日の昼まで、都内某所のホテルのカンファレンスルームを利用した合宿形式の勉強会に参加(?)してきました。要求開発アライアンス「要求開発　実践からのフィードバック」というタイトルです。というわけで、記憶が薄れる前にレポートします。

■基調講演「開発上流工程の歩き方」
春から新たに要求開発アライアンスの理事として参加いただいた中山さんの発表です。ユーザ企業のシステム部門の目からみた上流工程に関するお話です。ベンダ企業に勤める私としても、とても参考となるお話がたくさんありました。
なお、着色している部分は私の個人的な感想ですのでご注意ください。

• ほとんどウォーターフォール(WF)は採用していない。
• 開発はRUP風(?)に、「準備」「方向付け」「推敲」「作成」「移行」の5つのフェーズに分けられているとのこと(反復型開発)。
• 確かに、開発ベンダから見ればWFは御しやすく、いろいろと都合の良い(契約や、コスト・仕様変更などの取扱い)のですが、ユーザ企業の観点からすると当然だと思います。その割には世の中的にはWF型のプロジェクトが多いのはなぜなんだろう･･･
• ポリシーとして「プロジェクトサイズ」をコントロールする。
• プロジェクト期間は12ヶ月以内と制限しているそうです。これは、大規模プロジェクト化した場合のリスク対策に加えて、技術進歩や世の中のスピードへの対策としてとのこと。
• 超えてしまう場合は次フェーズに見送るということです。
• 情報システム部門の役割
• ユーザ部門と、ベンダの間のメッセンジャーではない。
• 企画・設計を行う。
• 手段は「モデリング」である。
• 新システムの前提
• 単純コンバージョンのシステム更改を除き、ポリシーを決めている。
• 業務のBPRや組織改革を伴わなければいけない。
• 新たなITを取り入れたものでなければいけない。
• このビジョンは、わかりやすさと明確さでちょっと感動した。
• テスト駆動
• 情報システム部門としては、コードや設計レビューの実施は現実的では無い。その代わりにプロジェクト初期からテストデータ作成に参加し、実業務に近いINデータとOUTデータによってシステム検証に参加する。
• スケジュール管理
• 遅れが2週間を超えた時点で再スケジューリングを実施。
• 再スケジュールは科学的根拠に基づく次工程移行の短縮による。
• あたりまえなのですが、それをやっているということ、およびユーザ企業の方から聞けるということにクラッとしてしまった･･･。

他にもいろいろな気づきやヒントをいただける講演でした。内容そのものもそうですが、全体的にはシステム部門としてのポリシーやビジョンがハッキリとしている事に感動を覚えました。あたりまえですが、ユーザ企業は「システムを導入すること」が目的ではなく、「システムを使ってビジネスで成功すること」が目的です。しかし、プロジェクトが開始されると参加者の目標が「システムを導入すること」に摩り替わってしまい、結果として使えないシステムや使いにくいシステムが生まれる原因になりがちです。これに対する対策として、まずポリシーとビジョンをしっかりと定めるというのが、とても効果的だというのが感想です。

■その後
1日目は基調講演後、ホテルのパーティルームでの反省会、居酒屋に移動しての猛省会、そして……という感じでした。私は普段は自宅が遠い為に途中で失礼することが多いのですが、この日はホテル泊なので時間を気にする必要が無い！ というわけで、とてもリラックスして参加できたのが良かった……

長くなりそうなので、合宿2日目のレポートは次回にまわします。翌日は9時からワークショップを2セッションです。