前に書いたＫＢＳＥの話は、実は、「要求の自動抽出がどれだけ現実化しているか」を語っているのだが、それ、わかりにくいので、コメントしておく。
■システム開発は、３つの自動抽出ができると、ほぼ完成する
その前に、「要件の自動抽出技術」が完成すると、どういうことが起こるのかについてすこし。
システム開発は、以下の３つの自動抽出ができると、ほぼ完成する
・（要求～設計）「要件の自動抽出」により、
顧客から対話型ないしは自然文で要求っぽいことを入力してもらうと、
要求から機能要件、非機能要件を抽出し、
あらかじめ登録してあるサービスを検索し、利用すべきサービスと手順を設計書として出力し
結合テスト、総合テストを自動生成する
・（設計～実装）「設計書からプログラムを自動生成」
上述の設計書をもとに、プログラムとドキュメント、単体テストを自動生成する
・（テスト）「テスト自動実行」
上述の単体テスト、結合テスト、総合テストを自動実行する。
この３つの自動抽出が完成すると、デジタル土方さんは必要なくなる。
偽装請負の問題や、ブラック企業の問題、メンタルの問題は一切なくなる。
なんたって、その対象である、デジタル土方さんがいなくなるのだから・・・
そして、「テスト自動実行」は、なんとかＵＮＩＴとか、いろんなテスト自動実行ツールで
実用化の段階に入っている。
「設計書からプログラムを自動生成」は、いわゆる超高速開発であり、GeneXusや、
富士通のInterdevelop Designer
などがそれに当たる。つまり、実用化の段階に入っている。
しかし、現状、「要件の自動抽出」ができていない。そこで、ユーザーから要求を聞いて、それを設計書に起こすまでが、人間の仕事として存在する。
このうち、ユーザーからのヒアリングは上流の会社が、設計書の記入と、超高速開発、自動テストの運用と設定が、デジタル土方さんの仕事となっている。
つまり、現在、「要件の自動抽出」ができていないので、デジタル土方さんは、必要である。逆に言うと、「要件の自動抽出」ができれば、デジタル土方さんは必要なくなる。
■要件の自動抽出の３つの要素技術
さらに、要求の自動抽出は、以下の３つの要素技術でできる。
１．顧客から対話型ないしは自然文で要求っぽいことを入力してもらうと、
要求から機能要件、非機能要件を抽出する
２．機能要件から業務ワークフローを割り出し、
既存のサービスから、ワークフローにあったサービスが存在するかどうかを検索し、
存在した場合は、順番にそのサービスをならべ、設計書を出し、
存在しない場合、どのようなサービスを作成すればよいかサービス仕様書を出力する
３．業務ワークフローが存在し、
それを満たす既存のサービスが複数存在する（＝機能要件は満たす）ときに、
非機能要件から、最適なサービスを抽出する
このうち、前回のＫＢＳＥ
論文とかが通るかどうか、判断＆アドバイスしてくれるかもしれないソフト？
http://blog.goo.ne.jp/xmldtp/e/bf2dcaa49c0b76fab8972186c0d7fa7c
の石川先生「機能・品質の多様性を扱う適応的サービス合成」の発表は
上記３を説明している
つまり、非機能要件を評価関数にして、
ジェネリックアルゴリズムを使って、サービスの組み合わせを決めていく
ことにより実現する
また、コグニティの河野さんの「BrainPlots/CogStructureのご紹介」は、
上記１を説明している
このツールは、文章をチェックし、足りない部分などをアドバイスし、
要約して抽出する。
で、質問として出てきた、D-CASEの回答にあるように、
いま、ゴール指向とのマッピングをおこなっている。
ゴール指向とのマッピングが行えれば、このソフトで、
ゴールを挙げてもらえるような、アドバイスをする
ゴールをまとめて出力する
ことはできそうということになる。
非機能ゴールに関しては、すでに、Lamsweerdeのゴールカテゴリ、
NFR、（ゴールじゃないけど）非機能要求グレードなどで、
なにを挙げればよいかが分かっている。
機能ゴールは、最終的に必要な出力内容の定義（＝トップゴール）となる。
（業務内容によって異なる）
よって、あと、必要なのは、上記の２になる。
■ゴールから要件の割り出し
のこりの２については、萌芽的な研究しかないが、方向性はわかりかけている。
（ここの論文の
「刺激―反応ゴール」あたりをロリポおじさんなみのテキトーさで解釈すると）
つまり、以下の手順で行う
（あ）まず、トップゴールをゴールとします
（い）ゴールに対応するプロセスが１つ以上あると仮定して、
（う）そのプロセスが必要とする入力を指定してください
入力から出力が作れれば、仮定したプロセスは実現できることになります。
（え）上記（う）の入力値が、他システムから与えられるか、誰かが手入力する
というのでなければ、その入力値をゴールとして（い）に戻ってください
（お）最終的に、他システムまたは手入力をもとに、最終的に必要な出力内容
が得られるプロセスがわかります＝業務要件とサービスがでてきます。
例：酒屋倉庫問題
・手元にお酒が届いている→入力値：注文したお酒＆送付先情報（プロセス：配送）
・注文したお酒→入力値：注文したお酒のの種類と数＆倉庫のお酒（プロセス：出庫）
・注文したお酒の種類と数→入力値：顧客からの手入力（プロセス：受注）
・送付先情報→入力値：顧客からの手入力（プロセス：受注）
・倉庫のお酒→入力値：発注したお酒の種類と数＆発注先のお酒（プロセス：入庫）
・発注したお酒の種類と数→入力値：発注者の手入力（プロセス：発注）
・発注先のお酒→他システム（発注先にある）
よって業務プロセスは
発注→入庫→受注→出庫→配送
■全部できると・・・
そうすると、以下の手順で、要求抽出は自動化できそうである
・ゴールを挙げてもらいます（サポートするツールで）
最終的な出力内容と
非機能要件を
・最終的な出力内容をもとに、既存のサービスを検索して、上記手法によって
業務プロセスを導き出し、該当サービスがあればそれを抽出、なければ、
どのようなサービスを出せばよいか出力する
・業務プロセスが決まれば、非機能要件を満たす、最適なプロセスを
遺伝的ありごリズムを使って抽出する
で、これができると、ユーザーが要求を入れさえすれば、設計、プログラム、テストが
自動的に行われ、システムができることになる。デジタル土方はいらない。
■開発で残れる人
このような状況になっても、要求を出すために、上流の会社はのこる
まだないサービスをつくるため＆自動生成を起動するため、
富士通系だとFSA
のメンバーは残れるかもしれない。都筑さんはのこるだろう。
（両毛さんは、ＦＣＡに入ってる）
でも、それ以外はいらなくなってくるかもしれない。
富士通以外でも、似たようなもんになるだろうから、多くのデジタル土方は
いらなくなる・・・転職したほうがいいかも。
会社は別事業を考えたほうがいい？
たとえば、
秋葉原にあるなら、
女子社員を４８人集めて、ＡＢＣ４８とか作って、
バブルのころは良かったけど、最近ぱっとしないテレビ局に
「うちの名前の会社名の前に、”オールナイト”とつけた冠番組を深夜に行う」等と提案し
コンテンツビジネスで儲ける・・
とか・・・（冗談ですよ ＾＾；）
アクセス
トータル
ランキング
