無料ブログはココログ

« 2015年1月 | トップページ | 2015年3月 »

リスクベース私論 - リーンソフトウェア開発とプロダクトラインから考える -

アジャイルと規律によれば、アジャイル開発には優先度ベースとリスクベースの二つがある。

リスクベースとはなにか?

リスクベースのひとつであるリーンソフトウェア開発では、引き取りかんばんの様にpullで無駄のないプロセスを実現する。しかし、全てがオンデマンドな開発だけでは後手後手になるので、ある程度は計画的に進める必要がある。

そこで、ニーズが確定していないものは

  リスク=発生時の影響度×発生確率

と考えて、リスクが最小になるように割り当てる必要がある。

基本的には必要なもの、つまり遅くなるとリスクが大きくなるものから先行着手してリスクを低減するという戦略をとる。しかし、早く実施するよりは遅く実施したほうが良い場合は「決定を遅らせる」という戦略をとる。

プロダクトラインで考えてみよう

ソフトウェアプロダクトラインのコア資産をいつ作るかを考えてみる。プロダクトラインでは製品群を開発していく上で、その共通部分をコア資産として整備する。単に優先順位を考えるなら、コア資産は製品群の最も重要なものであり、先に作ると効率が良いだろう。

しかし、製品の全貌が見えていない段階でコア資産を作り出すと仕様のバリエーションに対応できない可能性があり、もし、うまく作れたとしてもその開発の負担で製品出荷が遅れてしまうリスクがある。

つまり、最初から仕様が固まっていて並行に開発できるなら別だが、
・他の仕様が明確になってからでないとリスクが大きい
・早期に実施すると機会喪失やキャッシュフロー不足のリスクが大きい
ので、(将来リファクタリングの必要はあるが)リスクベースに考えると決定を遅らせる方が良いだろう。

かつて、XPのブームの頃は単に優先度順に開発すると言われたが、最近ではロードマップを重視されるたり、リーンスタートアップのように価値を生み出すことが重視される。表現は異なるが、リスクベースの考え方が広がっているのだと思う。

このエントリーをはてなブックマークに追加


[#benkyoenkai] WHATとHOWの溝をモデルでつなぐ - 三要素分析法を考える -

第39回IT勉強宴会in大阪に参加しました。今回はT字形ER手法と三要素分析法での花束問題をモデリングをネタに議論するという内容でした。このうち、三要素分析法の感想を書きます。

三要素分析法

三要素分析法とは、業務のあり方を示す「業務モデル」、帳簿組織のあり方を示す「データモデル」、機能のあり方を示す「機能モデル」を分析し、それぞれ訓練済みの要員、DB、プログラムを実現してで業務システムを構築します。

この3つで分析する仕組みは機能、データ、状態、で分析する構造化分析と似ていると思っていましたが、その感覚が理解を阻害していた事に気付きました。

構造化分析/構造化設計

構造化分析(SA)は機能、データ、状態をそれぞれDFD(データフロー図)、ER図、状態遷移図(または表)で分析し、その結果はWHAT(何を作るか)を示します。そして 構造化設計(SD)では、トランザクションの単位で分割する、データフローの最大抽象点でSTS分割する、といった方法やモジュール間結合とモジュール強度の指標でHOWを設計していました。

SA/SDで問題になったのは、WHATとHOWの断絶(溝)です。 構造化分析から設計に移行する際は、DFDの中心から引っ張り上げるようにして構造を決めるという手法がありました。しかし、それだけでは良い構造ができず、実装寄りに考え直す事が必要で、溝ができていたのでした。

その後、分析から設計まで同じモデリング記法を使い、WHATとHOWの溝を埋めるとの触れ込みでオブジェクト指向分析/設計が入ってきました。しかし溝は埋まったものの難易度が高く、オブジェクト指向が普及したのはデザインパターンが広く知られるようになってからでした。

ライブモデリングの流れ

渡辺幸三さんのライブモデリングで気付いたのは、SAのように3つの側面で分析をとことんするのではなく、業務モデル、データモデル、機能モデルとモデリングを進めていく事です。まず、DFDをわかり易くした業務モデルを書いて、流れがわかってからER図を書きます。そして、顧客への説明や実際のイメージを考える時など、必要に応じて画面を考えます。

この流れはWHATに始まり、段階的にHOWの世界に進んでいます。実際には行きつ戻りつするのでしょうが、モデリングの様子を見ているととてもスムーズに見えました。しかし、慣れてない人間にはデータモデルが急展開したように見える場面があり、そこが三要素分析法のポイントだと思いました。

急展開の秘密

ここで渡辺幸三さんの著者ページを眺めてみると、入門書が1冊に練習帳が1冊、残り3冊が業務別の書籍になっています。方法論よりも業務別の本が多く、それが三要素分析法の秘密なのだと思いました。

オブジェクト指向がパターンで難易度を下げたように、業務のパターンが三要素分析法の難易度を下げてWHATとHOWの溝を埋めることで、モデリングをスムーズにするのだと思いました。

おわりに

業務システムのための上流工程入門―要件定義から分析・設計まで」の目次を見ると、まさにパターンが説明されている様です。この本はまだ読んでいないので、じっくり読んでみたいと思います。

このエントリーをはてなブックマークに追加


要件構造の見える化 #RDRAセミナー

これから作るモヤモヤしているシステム。どうやってすっきりしていくか?
RDRAセミナーでそのヒントをいただきました。

要件定義

「要件」とはやらないといけないことと、やってはいけないことを示したものだと考えています。その幅が設計の自由度になります。

妙に詳細に書かれた要件は後工程の自由度を下げますし、大切な内容が抜けている要件は動かないシステムを生みます。コンパクトに必要な情報だけを示すことができれば、内容の確認も容易になりますので仕様の抜けも少なくなるでしょう。

RDRAとシステム地図

今回のセミナーの技法であるリレーション駆動要件定義(RDRA)ではUML記法の各種モデルを用いて要件を表現します。その全体像を示すのがシステム地図です。システム地図はこれらの要件を一覧可能な抽象度の高いモデルです。

RDRAでは、要求、利用シーン、ユースケース、機能、画面、データ、イベント、イベントデータ、外部システム、入出力、などでシステム地図を書いていきます。新規開発の場合は上に書いた順に要件を固めていきますが、既存システムのリプレスではデータモデルなどやり易いところから始めます。いずれの場合でも一度に深いところまでモデル化せず、色々なモデルで行ったり来たりしながら段階的に要件を定義していきます。

ワークショップ

ワークショップでは貸会議室を題材に、RDRAツール(ベータ版)を使ってシステム地図を作製しました。ある程度モデル化されていたので、比較的スムーズにシステム地図を書く事ができましたが、ある程度書き進めると補助的な画面を作るかどうか議論になりました。要件の構造が見える化される事で、決めておかないと行けない事がわかったのだと思います。

RDRAツールは軽くて使い易いものでした。作成済みのアイコンのオブジェクトを選択しておいて新しいオブジェクトを作成すると、自動的に線が引かれるところなど、使い易いと思いました。初心者なので、オブジェクトの種類を変える事が多かったので、これが簡単にできると良かったと思いました。

要件定義のポイント

要件定義が日本語で書かれていると、整理されていても見通しが悪く、全体を追いにくくなってしまいます。ワークショップではシステム地図で議論できたことからも、 RDRAのように要件を構造化して抽象度の高いレベルでの俯瞰や詳細な検討ができれば、全体が追い易く、要件の抜けや、一貫性、対称性なども容易に確認できるでしょう。

RDRAでシステム地図を書く際は実現可能性を検討しません。実現可能性は要件チームとは別にいるアーキテクチャチームが考えるそうです。最近は要件に合わせて色々な選択肢があるからとのこと。業務に近いレイヤだからでしょう。しかし、より低いレイヤのソフトウェアや特殊な非機能要件がある場合は実現できるかどうかが大きな問題なので、HOWの突き上げよろしく、アーキテクチャチームとの連携を密接にする必要があると思います。

要件がなかなか決まらないパターンの一つに実装イメージが浮かばないことがあります。イメージがないままに詳しく書こうとすれば、やらないといけない事や、やってはいけない事ではなく、イメージの一例を書いてしまい、設計の自由度をなくすことになりかねません。RDRAでは要件定義チームがアーキテクチャの基礎知識を持っていることが、前提になっているのだと思いました。

おわりに

システムのモヤモヤはステークホルダーが協力しなければ解決しないと思います。その時点でわかっている事をモデル化する事で、問題点や不明点が見える化されてモヤモヤは徐々に解決すると思います。

そこで大切なのは、人が見渡せる範囲で表現できる事です。今回学んだシステム地図は、要件の構造を適切な抽象度で示すことでコミュニケーションが可能です。要件定義を進める手がかりを少しずつあぶり出しながら、作業を進める事ができるでしょう。

このエントリーをはてなブックマークに追加


« 2015年1月 | トップページ | 2015年3月 »