アジャイルソフトウェア開発について前回書きました。
2009年Ver1でスタートしたSpring Rooは本格的なRAD（Rapid Application Development）ツールです。
現在Javaでの開発手法として一番有望な技術だといえます。
2003年頃日本ではSpringフレームワークがJavaのDIコンテナやAOP注目され始めました。初期はXMLでの設定が複雑になりすぎて、この欠点からもう一つのDIコンテナとしてSeaserという技術が沖縄から発信されていました。
私も勉強しようとして両方に関する書籍を購入しましたが、現実的にユーザの実装で使うにはまだ時期尚早で、自己流のフルスタックのフレームワークをStrutsと組み合わせて使っていました。
現在、Springも１０年を超えました。APIも体系も膨大な資料になりました。
今ではJavaのサーバフレームワークの代名詞がSpringになりました。
Java言語も確かチューニング完全宣言がアナウンスされました。
このような良い意味で枯れた技術を基盤として現れたのが、Spring Rooと考えています。
元々フルスタックのサーバサイド技術がない為にSpringが登場したわけですが、Sunの技術があまり浸透しないで、RADツールとしてRooが生まれました。
どうやらこの技術が成功したら、PHPの開発も同じツールでカーバしてくれるようです。
このツールの本質は、「設定よりも規約」です。XMLやJavaで実装パラメータを設定したことに限界を感じて、次世代技術として規約が注目されたわけです。
設定もマクロ化して考えれば、単に規約に集約されると言えるので、非常にリーズナブルな概念であると思います。
私はかねてからオブジェクト指向技術は基盤であって、上位設計での技術ではあまり活用できないと信じてきました。決して基盤でのオブジェクト指向技術を否定しているわけではありません。
上位設計では理論よりも効率と正確性を強く求めています。又最も要件としてあるのはコミュニケーションでしょう。
Rooはこの要求に一歩近づいた考え方であり期待できる技術であると考えています。
欠点は、一度動作に問題があるとほとんどが自動化されていて、技術的基盤自体が巨大なAPI体系で構成されている為、解決することが難しいと思います。
開発の容易性では、他の言語でも検討しなければいけませんが、RubyとPHPが日本では主流です。Pythonも同じカテゴリですが、海外ほど利用者が少ないのが現状です。ここで正確には以下説明のRubyとPHPは、MVCの体系を指しています。
Ruby on Railsは、「同じことを繰り返さない」コンセプトです。ネットでの評判はかなりの支持者がいます。RubyDocサイトを訪問してみましたが解り易く、利用しやすいドキュメントでした。利用者側の意図を組み入れている内容でした。
CakePHPは、やはり海外のサイトですので、英語のドキュメントで７５０ページ程度のものがありました。やはり日本語がいいのですが、元々解り易い言語なのであまり問題視しなくても良いかもしれません。
3つを同じ目線で比較すると、RooはバックグラウンドのJavaが体系が膨大で、色々考慮する内容が多すぎて、Java+Spring＋SpringRooの３層になっています。
RubyとPHPは元々開発のし易さが売りなので、２層になっていると考えられます。
以上、今後の動向を注目するべき内容と思います。
2013年6月30日日曜日
2013年6月26日水曜日
アジャイルソフトウェア開発手法について
アジャイルソフトウェア開発手法の調査をしたので、少し検討してみます。
２００１年の発案者はその道を極めたすごい人々なのでしょう、私はマーティン・ファウラー氏 しか知りませんが。
手法の概要を確認すると、「開発での文書化よりも直接の会話重視」、「実際に動くシステムを作ることが一番大事」、「開発の反復を重視し最適化する」の3つでしょうか、どれも問題がない実に本質的で合理的な考え方であると思われます。
それではこの技術が生まれた背景を推察してみることにします。
一つ目の要素：
私はかねがねシステム開発の洋書の翻訳の内容から、米国の技術者はシステム開発 の自動化が得意で且つ普通のことと考えます。
特に感心したのは、本の著者自らが書いている書籍に掲載されるソースコードを自動検証 可能なツールを構築して、検証をしてから本の推敲をしていたことです。
もう一つの要素：
通信系のシステムではごく普通の自動検証でしょうが、作業自体ではなく考え方が進んでいると 思いました。 この他にポイントとなっているのは、WEBが現れるまでは通信系技術で標準化が進んでいました。 OSI参照モデルのプロトコルの７層を技術者同志でよく議論していました。今ではHTTPプロトコル １つで大体話題は済んでしまうので、非常にシンプルです。
WEB関連では色々な標準化が進みました。
HTML５、XML、DI、JavaScript、C#等々今までベンダーが抱えていた分野までも標準化されています。システム開発を実施している技術者は覚えることが増えましたが、標準化が進めば技術が当然管理する分野へと変化します。MOTとかPMBOKをよく目にすることは世の中全体が標準化していけば自然の流れであると考えられます。
従ってウォータフォール型開発が主流な時期から確実に環境や技術基盤がステップアップしたところで、 アジャイルソフトウェア開発手法は時代的な背景が生んだ考え方だと思います。
特にリーマンショック以降は経済的にも時間的にも、アジャイルソフトウェア開発手法を育てた時期であると思います。
「アジャイルソフトウェア開発手法は自動化が進んだ状況で実施するべきである。」
と考えています。
自動化すれば、開発での文書化が少なくても自動でドキュメントをいつでも参照できるので問題がなくなります。少し違うことは美術的に綺麗な図を観れなくなることぐらいでしょうか。
反復でも自動化することによりデメリットはなさそうです。
最後に私が開発手法でもう一つ付け加えたいのは、
「オントロジーとタクソノミーの意識的適用です。」
これがこのブログのテーマです。
２００１年の発案者はその道を極めたすごい人々なのでしょう、私はマーティン・ファウラー氏 しか知りませんが。
手法の概要を確認すると、「開発での文書化よりも直接の会話重視」、「実際に動くシステムを作ることが一番大事」、「開発の反復を重視し最適化する」の3つでしょうか、どれも問題がない実に本質的で合理的な考え方であると思われます。
それではこの技術が生まれた背景を推察してみることにします。
一つ目の要素：
私はかねがねシステム開発の洋書の翻訳の内容から、米国の技術者はシステム開発 の自動化が得意で且つ普通のことと考えます。
特に感心したのは、本の著者自らが書いている書籍に掲載されるソースコードを自動検証 可能なツールを構築して、検証をしてから本の推敲をしていたことです。
もう一つの要素：
通信系のシステムではごく普通の自動検証でしょうが、作業自体ではなく考え方が進んでいると 思いました。 この他にポイントとなっているのは、WEBが現れるまでは通信系技術で標準化が進んでいました。 OSI参照モデルのプロトコルの７層を技術者同志でよく議論していました。今ではHTTPプロトコル １つで大体話題は済んでしまうので、非常にシンプルです。
WEB関連では色々な標準化が進みました。
HTML５、XML、DI、JavaScript、C#等々今までベンダーが抱えていた分野までも標準化されています。システム開発を実施している技術者は覚えることが増えましたが、標準化が進めば技術が当然管理する分野へと変化します。MOTとかPMBOKをよく目にすることは世の中全体が標準化していけば自然の流れであると考えられます。
従ってウォータフォール型開発が主流な時期から確実に環境や技術基盤がステップアップしたところで、 アジャイルソフトウェア開発手法は時代的な背景が生んだ考え方だと思います。
特にリーマンショック以降は経済的にも時間的にも、アジャイルソフトウェア開発手法を育てた時期であると思います。
「アジャイルソフトウェア開発手法は自動化が進んだ状況で実施するべきである。」
と考えています。
自動化すれば、開発での文書化が少なくても自動でドキュメントをいつでも参照できるので問題がなくなります。少し違うことは美術的に綺麗な図を観れなくなることぐらいでしょうか。
反復でも自動化することによりデメリットはなさそうです。
最後に私が開発手法でもう一つ付け加えたいのは、
「オントロジーとタクソノミーの意識的適用です。」
これがこのブログのテーマです。
2013年6月22日土曜日
実装技術については別ブログで
少し寄り道をします。今回からSpringについて入門を書いてみます。
SpringはJavaのフレームワークの一つですが、これをまとめて 「実装技術へのタクソノミーの適用」を実践で確かめるためにも具体的なことで 説明をしないといけないと考えました。 仕様としても簡単ではないようですし、まとめる量も大きいので単なるお勉強に は終わらないと考えました。
ただし、このブログはコンセプトを書くことなので主旨が違います。そこで別ブログで書いて行きます。
「TakioQ Method」「TakioQ TOOL」というブログに書いて行きます。
TakioQ Methodの定義
参考にする人が補完知を使って「補完法を意識して記述したドキュメント」を理解し二次利用する方法。 勝手に私がブログで定義した方法です。
より詳細は６月の「Aha体験よりもBEHの方が大切かも」をお読みください。
ヒントはこれまで書いてきた内容とプラスCheatsheetの考え方です。 Cheatsheetには「アンチョコ」や「巻物、お宝的情報」という意味が込められています。
どうなることやら解りませんが、やってみないと解らないので、一定の目途を着けるまで は別ブログで作業をします。こちらでは書く機会が少なくなります。
情報洪水のなかで救命ボートがみつかることやら
では、溺れないことを願って
～～～～～～～～～～～～
～～～～～～～～～～～～
～～～～～～～～～～～～＝＞ [TakioQ Method]
～～～～～～～～～～～～＝＞ [TakioQ TOOL]
～～～～～～～～～～～～
SpringはJavaのフレームワークの一つですが、これをまとめて 「実装技術へのタクソノミーの適用」を実践で確かめるためにも具体的なことで 説明をしないといけないと考えました。 仕様としても簡単ではないようですし、まとめる量も大きいので単なるお勉強に は終わらないと考えました。
ただし、このブログはコンセプトを書くことなので主旨が違います。そこで別ブログで書いて行きます。
「TakioQ Method」「TakioQ TOOL」というブログに書いて行きます。
TakioQ Methodの定義
参考にする人が補完知を使って「補完法を意識して記述したドキュメント」を理解し二次利用する方法。 勝手に私がブログで定義した方法です。
より詳細は６月の「Aha体験よりもBEHの方が大切かも」をお読みください。
ヒントはこれまで書いてきた内容とプラスCheatsheetの考え方です。 Cheatsheetには「アンチョコ」や「巻物、お宝的情報」という意味が込められています。
どうなることやら解りませんが、やってみないと解らないので、一定の目途を着けるまで は別ブログで作業をします。こちらでは書く機会が少なくなります。
情報洪水のなかで救命ボートがみつかることやら
では、溺れないことを願って
～～～～～～～～～～～～
～～～～～～～～～～～～
～～～～～～～～～～～～＝＞ [TakioQ Method]
～～～～～～～～～～～～＝＞ [TakioQ TOOL]
～～～～～～～～～～～～
2013年6月19日水曜日
FDDはアジャイル開発の手法
FDD(Feature Driven Development)は、ユーザ機能駆動開発になります。
どうやらアジャイル開発の手法としても考えられているようです。
FDDは、「オブジェクト、結果、アクション」の３つの 組み合わせでフィーチャーを表現しているようだ。
全体工程では、反復工程を強く意識する。以下にまとめると
全部で５工程に分けられる。
最後の２つは（４と５）繰り返し工程。
１．全体モデルの開発
２．フィーチャーのリスト作成する
３．フィーチャー毎に計画を立てる
４．フィーチャー毎に設計する
５．フィーチャー毎に構築する
本情報はややタイムリーではない、少し古い情報です。 ここでは、フィーチャーの使い方を参考にしたくて取り上げています。
アジャイル開発は、ドキュメントよりも成果物やコミュニケーション重視のようですが、 全体モデルが変更された場合はどうするのであろうか。
現場では死にそうに大変な人が数パーセントいるのではないだろうか。
開発工程の話であり、工程については普通の話しなので問題がないと考えました。
ポイントは、ユースケースではなしにフィーチャーの概念を中心にして、 開発を進めていることでしょうか。
どうやらアジャイル開発の手法としても考えられているようです。
FDDは、「オブジェクト、結果、アクション」の３つの 組み合わせでフィーチャーを表現しているようだ。
全体工程では、反復工程を強く意識する。以下にまとめると
全部で５工程に分けられる。
最後の２つは（４と５）繰り返し工程。
１．全体モデルの開発
２．フィーチャーのリスト作成する
３．フィーチャー毎に計画を立てる
４．フィーチャー毎に設計する
５．フィーチャー毎に構築する
本情報はややタイムリーではない、少し古い情報です。 ここでは、フィーチャーの使い方を参考にしたくて取り上げています。
アジャイル開発は、ドキュメントよりも成果物やコミュニケーション重視のようですが、 全体モデルが変更された場合はどうするのであろうか。
現場では死にそうに大変な人が数パーセントいるのではないだろうか。
開発工程の話であり、工程については普通の話しなので問題がないと考えました。
ポイントは、ユースケースではなしにフィーチャーの概念を中心にして、 開発を進めていることでしょうか。
2013年6月18日火曜日
FODAを調べてみる
FODA(Feature-Oriented Domain Analysis)は、形式仕様記述の一つらしい。
「ユーザ機能を捉えその機能をドメイン分析する手法？」なのでしょうか、名前からはこう理解しました。
フィーチャー分析でさしているフィーチャーは、ユースケースと対比した言葉
のようです。フィーチャーは、ユースケースのメタの概念で、長期的視点で
区別しているようです。
あまり明確な資料が見つからなかったので、ネットでサーチした結果で まとめてみます。
1.フィーチャー図を利用して分析する手法のようです。
（フィーチャー図とは、必須、オプション、排他の関係で表す図）
2.ソフトウェアでは再利用性を検討する上で役立つようです。
3.1980年代からすでに考え方はあったようです。
4.欧米ではアーキテクトの手法では普通の手法と受け止めました。
5.日本でも生産技術の分野では使われているようです。
6.論文等をみると何故かJSD法に表現方法が似ていた。
よく考えると「実装技術をオントロジーで考えないでやると 意味のところはどう考えるのか」疑問が出てきます。
タクソノミーでは自己流の分類になってしまい、意味を捉える基準が明確になりません。
そこでFODAはまさしく実装技術をまとめる手法として役立ちそうです。
実績も十分あるようです。
ポイントはドメイン分析と考えます。
物事の特徴となる言葉はドメインの要素（単複）を持ちそこから違いや 関係を把握できます。関係をフィーチャー図で検討すれば把握しやすいですね。
特にJavaのフレームワーク群をまとめるのに一番向いていると感じました。
あまり明確な資料が見つからなかったので、ネットでサーチした結果で まとめてみます。
1.フィーチャー図を利用して分析する手法のようです。
（フィーチャー図とは、必須、オプション、排他の関係で表す図）
2.ソフトウェアでは再利用性を検討する上で役立つようです。
3.1980年代からすでに考え方はあったようです。
4.欧米ではアーキテクトの手法では普通の手法と受け止めました。
5.日本でも生産技術の分野では使われているようです。
6.論文等をみると何故かJSD法に表現方法が似ていた。
よく考えると「実装技術をオントロジーで考えないでやると 意味のところはどう考えるのか」疑問が出てきます。
タクソノミーでは自己流の分類になってしまい、意味を捉える基準が明確になりません。
そこでFODAはまさしく実装技術をまとめる手法として役立ちそうです。
実績も十分あるようです。
ポイントはドメイン分析と考えます。
物事の特徴となる言葉はドメインの要素（単複）を持ちそこから違いや 関係を把握できます。関係をフィーチャー図で検討すれば把握しやすいですね。
特にJavaのフレームワーク群をまとめるのに一番向いていると感じました。
2013年6月16日日曜日
11.実装技術をタクソノミーとして考える
実装技術を俯瞰すると、直近15年でインターネットのインフラの変化で前と後では大きく変わりました。
この間ドックイヤーで始まり、リーマンショックで価値観が変わり、東日本大震災で絶望を感じた 時期でしたが、まだまだ過去形ではないことを大事に生活していきます。
実装技術は何があるのか検討してみます。大きく分けると
T1．サーバ、クライアントやネットワーク等のOSを含む基盤
T2．プログラム言語
T3．プログラム言語のAPIとフレームワーク
T4．その他ツール類
ここで扱う情報の構造を考えてみます。２つの視点があります。
１．ベンダーと利用者側の対峙
ベンダー側では非常に重要な意味(オントロジー的意味)があることでも、利用者側すなわち使う側からは 意味つけは薄くなることがあります。
ベンダー側でも当然解り易いモデルを供給しようと最善の努力をするのですが、 何しろ今までに存在しない技術をベンダー同志の競争の中で提供していきます。 しかも市場との対話が必要な作業でもあります。 事実、歴史的なバックグラウンドが多分に関係してきます。
２．ベンダーと利用者の人口比率的な違い
もう一つ構造で把握しておく必要があることは、 ベンダー側で働いている人数とこれを利用している側の人数の違いです、 この視点は非常に重要だと思います。当然利用者はベンダーの何倍も比率的には多いでしょう。
オブジェクト指向を例にして説明します。 オブジェクト指向が始まった当初とにかくバラ色の技術革命として流行ったわけですが、 確かにベンダー側ではGUI、基盤やツール技術では非常に重要な技術で実際に大きな 発展をもたらしたことは間違いありません。しかし利用者側は違いました、オブジェクト 指向で実装されたフレームワークを理解し使いこなす時間に非常に体力を使いました。 本来は業務でフレームワークやAPIを使う場合でも、技術力が高い実装設計者がパイロットと して、よく使うテンプレートを作成しておきます。
このテンプレートを元にコーディング規約に従って実装が進むわけです。 こうしておかないと品質が保てません。
ここでのウェイトは業務仕様の方が当然高いため、オブジェクト指向を 少し使うだけで開発ができてしまうわけです。もちろんUMLで設計する必要が発生する データモデルの部分はあるわけですが、これはERDやデータ中心の設計でも可能なのです。
従って利用者側のオブジェクト指向の恩恵は理論的には少なくなるのではないでしょうか。
この考え方は間違いだったのでしょうか。
面白いことに、ベンダー側でも全てのインフラ設計をDSLで再度定義し直した話しを聞きました。
この場合オブジェクト指向の技術の要素がどれだけ関係しているかは非常に興味があります。
検討する上での主題は、「実装技術をタクソノミーとして捉える」ということです。
上流設計ではオントロジー的に設計をしてきたのですが、 下流設計をタクソノミーでだけで把握することが不可能かもしれません。 また情報空間が膨大過ぎてイメージできていません。
この間ドックイヤーで始まり、リーマンショックで価値観が変わり、東日本大震災で絶望を感じた 時期でしたが、まだまだ過去形ではないことを大事に生活していきます。
実装技術は何があるのか検討してみます。大きく分けると
T1．サーバ、クライアントやネットワーク等のOSを含む基盤
T2．プログラム言語
T3．プログラム言語のAPIとフレームワーク
T4．その他ツール類
ここで扱う情報の構造を考えてみます。２つの視点があります。
１．ベンダーと利用者側の対峙
ベンダー側では非常に重要な意味(オントロジー的意味)があることでも、利用者側すなわち使う側からは 意味つけは薄くなることがあります。
ベンダー側でも当然解り易いモデルを供給しようと最善の努力をするのですが、 何しろ今までに存在しない技術をベンダー同志の競争の中で提供していきます。 しかも市場との対話が必要な作業でもあります。 事実、歴史的なバックグラウンドが多分に関係してきます。
２．ベンダーと利用者の人口比率的な違い
もう一つ構造で把握しておく必要があることは、 ベンダー側で働いている人数とこれを利用している側の人数の違いです、 この視点は非常に重要だと思います。当然利用者はベンダーの何倍も比率的には多いでしょう。
オブジェクト指向を例にして説明します。 オブジェクト指向が始まった当初とにかくバラ色の技術革命として流行ったわけですが、 確かにベンダー側ではGUI、基盤やツール技術では非常に重要な技術で実際に大きな 発展をもたらしたことは間違いありません。しかし利用者側は違いました、オブジェクト 指向で実装されたフレームワークを理解し使いこなす時間に非常に体力を使いました。 本来は業務でフレームワークやAPIを使う場合でも、技術力が高い実装設計者がパイロットと して、よく使うテンプレートを作成しておきます。
このテンプレートを元にコーディング規約に従って実装が進むわけです。 こうしておかないと品質が保てません。
ここでのウェイトは業務仕様の方が当然高いため、オブジェクト指向を 少し使うだけで開発ができてしまうわけです。もちろんUMLで設計する必要が発生する データモデルの部分はあるわけですが、これはERDやデータ中心の設計でも可能なのです。
従って利用者側のオブジェクト指向の恩恵は理論的には少なくなるのではないでしょうか。
この考え方は間違いだったのでしょうか。
面白いことに、ベンダー側でも全てのインフラ設計をDSLで再度定義し直した話しを聞きました。
この場合オブジェクト指向の技術の要素がどれだけ関係しているかは非常に興味があります。
検討する上での主題は、「実装技術をタクソノミーとして捉える」ということです。
上流設計ではオントロジー的に設計をしてきたのですが、 下流設計をタクソノミーでだけで把握することが不可能かもしれません。 また情報空間が膨大過ぎてイメージできていません。
2013年6月14日金曜日
10.ここまでのまとめ
前回(連載番号：1-9)まで解ったことをまとめてみます。
１．設計書のパラメータは、スキーマを決めることにより明確に設計が可能になる。
２．スキーマも表で定義すると、網羅性のチェックや関連性が検査できる。
３．完全なオントロジーではないが、業務用語を定義しブレークダウンしていくと設計が完成する。
４．作業工程はスプレッドシートで設計できる。(規模が大きくなるとツールが必要)
５．設計書はツール等を作成すれば、検証が可能になる。
６．伝統的な構造化設計手法とも類似しているので、手法としては理解しやすい。
７．設計書をそのままテンプレート化しやすい。
８．Graphviz等のツールを使い、ダイヤグラムを自動で作成しやすい。
９．全て行列で定義しているので、公理的設計と相性が良い？
１０．作業はマトリックス指向なので、人により手法の好き嫌いがある。
１１．スキーマの定義でのカスタマイズが自由に行える。
１２．XMLとの違いは、ベースのインスタンスは用意しておく必要があることです。
最後に９については以前から気になっていた手法なので、少し掘り下げて検討してみます。
公理的設計の出典は、
Axiomatic Design 2001.Oxford University Press, Nam Pyo Suh
翻訳本：「公理的設計」森北出版
からです。
次の設計公理を満たすことが条件のようです。
公理１：独立公理(Independence Axiom)
公理２：情報公理(Information Axiom)
独立公理とは、要求機能は最小個の独立性を必要条件として定義すること。
情報公理とは、独立公理を前提条件に、設計の情報量を最適化すること。
Q.今回の方法では、機能を定義しているが最小個になっているか？
A.小さいシステムでしか検討していないので判断はできない。
Q.独立性は保たれているか？
A.オントロジー的に設計していけば、条件は満たせるのではないか。
Q.設計の情報量を最適化できているか？
A.説明を必要最小限な文で記述するので、最適化は比較的満たせる。
かなり荒い分析ですが、本来ならば大規模システムで検討しないとこのような評価 が意味をなさないので、これぐらいにしておきます。
ここまでの開発手法の名前を付けます。
「TakioQ Method」日本語名「タキオク手法」と言います。「頑固で早く、品質まで確保」するイメージで命名しました。
私が勝手につけた名前です。
このブログを読んだ人しか知りません。
多分今回のこれを読んでくれている人は少ないので、このままで終わってしまう開発手法 なのかも知れません。ただし、旧バージョンですがローカルなシステムで実績はあります。
もし、興味を持たれましたらメールで連絡ください。
１．設計書のパラメータは、スキーマを決めることにより明確に設計が可能になる。
２．スキーマも表で定義すると、網羅性のチェックや関連性が検査できる。
３．完全なオントロジーではないが、業務用語を定義しブレークダウンしていくと設計が完成する。
４．作業工程はスプレッドシートで設計できる。(規模が大きくなるとツールが必要)
５．設計書はツール等を作成すれば、検証が可能になる。
６．伝統的な構造化設計手法とも類似しているので、手法としては理解しやすい。
７．設計書をそのままテンプレート化しやすい。
８．Graphviz等のツールを使い、ダイヤグラムを自動で作成しやすい。
９．全て行列で定義しているので、公理的設計と相性が良い？
１０．作業はマトリックス指向なので、人により手法の好き嫌いがある。
１１．スキーマの定義でのカスタマイズが自由に行える。
１２．XMLとの違いは、ベースのインスタンスは用意しておく必要があることです。
最後に９については以前から気になっていた手法なので、少し掘り下げて検討してみます。
公理的設計の出典は、
Axiomatic Design 2001.Oxford University Press, Nam Pyo Suh
翻訳本：「公理的設計」森北出版
からです。
次の設計公理を満たすことが条件のようです。
公理１：独立公理(Independence Axiom)
公理２：情報公理(Information Axiom)
独立公理とは、要求機能は最小個の独立性を必要条件として定義すること。
情報公理とは、独立公理を前提条件に、設計の情報量を最適化すること。
Q.今回の方法では、機能を定義しているが最小個になっているか？
A.小さいシステムでしか検討していないので判断はできない。
Q.独立性は保たれているか？
A.オントロジー的に設計していけば、条件は満たせるのではないか。
Q.設計の情報量を最適化できているか？
A.説明を必要最小限な文で記述するので、最適化は比較的満たせる。
かなり荒い分析ですが、本来ならば大規模システムで検討しないとこのような評価 が意味をなさないので、これぐらいにしておきます。
ここまでの開発手法の名前を付けます。
「TakioQ Method」日本語名「タキオク手法」と言います。「頑固で早く、品質まで確保」するイメージで命名しました。
私が勝手につけた名前です。
このブログを読んだ人しか知りません。
多分今回のこれを読んでくれている人は少ないので、このままで終わってしまう開発手法 なのかも知れません。ただし、旧バージョンですがローカルなシステムで実績はあります。
もし、興味を持たれましたらメールで連絡ください。
9.業務サンプル（２）
前回の続きになります。
２．各インスタンスデータをノードとしてリンク付けをする。
link(ロール,link(link(サブシステム,機能),アクティビティ))
link(link(link(サブシステム,機能),アクティビティ),画面)
link(link(link(サブシステム,機能),アクティビティ),帳票)
link(link(link(サブシステム,機能),アクティビティ),エンティティ)
後は、画面、エンティティ、項目等も設定しないといけないのですが省略します。
ここまで設計を進めると、何故か構造化設計の手法とかなり類似している感じを受けます。
２．各インスタンスデータをノードとしてリンク付けをする。
link(ロール,link(link(サブシステム,機能),アクティビティ))
| A03.R001- | 顧客 | 見積を依頼する | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| A03.R002- | 訪問客 | 見積を依頼する | |||||||||
| A03.R003- | 営業担当 | 見積を依頼を受け、見積を提供する | |||||||||
| A01.S001- | 受注管理 | ||||||||||
| A02.F001- | 見積機能 | ||||||||||
| A001 | 見積入力 | ||||||||||
| A002 | 見積照会 | ||||||||||
| A003 | 見積変更 | ||||||||||
| A004 | 見積取消 | ||||||||||
| A005 | 見積検索 | ||||||||||
| A006 | 見積一覧 | ||||||||||
link(link(link(サブシステム,機能),アクティビティ),画面)
| A01.S001- | 受注管理 | ||||
|---|---|---|---|---|---|
| A02.F001- | 見積機能 | ||||
| A04.A001- | 見積入力 | ||||
| G001 | 見積情報 | 入力 | |||
| A04.A002- | 見積照会 | ||||
| G001 | 見積情報 | 照会 | |||
| A04.A003- | 見積変更 | ||||
| G001 | 見積情報 | 変更 | |||
| A04.A004- | 見積取消 | ||||
| G001 | 見積情報 | 変更 | |||
| A04.A005- | 見積検索 | ||||
| G002 | 見積検索 | 検索 | |||
| A04.A006- | 見積一覧 | ||||
| G002 | 見積検索 | 表示 |
link(link(link(サブシステム,機能),アクティビティ),帳票)
| A01.S001- | 受注管理 | ||||
|---|---|---|---|---|---|
| A02.F001- | 見積機能 | ||||
| A001 | 見積入力 | ||||
| A002 | 見積照会 | ||||
| A003 | 見積変更 | ||||
| A004 | 見積取消 | ||||
| A06.A005- | 見積検索 | ||||
| G002 | 見積書 | 印刷 | |||
| A06.A006- | 見積一覧 | ||||
| G002 | 見積一覧 | 印刷 |
link(link(link(サブシステム,機能),アクティビティ),エンティティ)
| A01.S001- | 受注管理 | ||||
|---|---|---|---|---|---|
| A02.F001- | 見積機能 | ||||
| A05.A001- | 見積入力 | ||||
| E007 | 見積ヘッダ | C | |||
| E008 | 見積明細 | C | |||
| E003 | 商品マスタ | R | |||
| E004 | 商品価格マスタ | R | |||
| E001 | 顧客情報 | R | |||
| E005 | 部署マスタ | R | |||
| E006 | 社員マスタ | R | |||
| A05.A002- | 見積照会 | ||||
| E007 | 見積ヘッダ | R | |||
| E008 | 見積明細 | R | |||
| E003 | 商品マスタ | R | |||
| E001 | 顧客情報 | R | |||
| E005 | 部署マスタ | R | |||
| E006 | 社員マスタ | R | |||
| A05.A003- | 見積変更 | ||||
| E007 | 見積ヘッダ | U | |||
| E008 | 見積明細 | U | |||
| E003 | 商品マスタ | R | |||
| A05.A004- | 見積取消 | ||||
| E007 | 見積ヘッダ | D | |||
| A05.A005- | 見積検索 | ||||
| E007 | 見積ヘッダ | R | |||
| E008 | 見積明細 | R | |||
| E001 | 顧客情報 | R | |||
| A05.A006- | 見積一覧 | ||||
| E007 | 見積ヘッダ | R | |||
| E008 | 見積明細 | R | |||
| E003 | 商品マスタ | R | |||
| E001 | 顧客情報 | R | |||
| E005 | 部署マスタ | R | |||
| E006 | 社員マスタ | R |
ここまで設計を進めると、何故か構造化設計の手法とかなり類似している感じを受けます。
2013年6月13日木曜日
8.業務設計サンプル
販売管理サブシステムをサンプルに設計を進めていきます。
設計手順は、次の工程になります。
１．各スキームに基づくインスタンスデータを用意する。
２．各インスタンスデータをノードとしてリンク付けをする。
３．１と２のデータの確認を行い、修正をする。
４．業務担当者とSEがレビューを行い仕様を確認する。
５．１から４までを、完成するまで繰り返す。
具体的な設計を進めて行きます。全部詳細まで説明するとかなりのデータ量になるので、一部の内容で説明します。
説明も一般的な内容は記述していません。
１．各スキームに基づくインスタンスデータを用意する。
サブシステム
機能
アクティビティ
ロール
画面
帳票
外部データ源
エンティティ
１．各スキームに基づくインスタンスデータを用意する。
２．各インスタンスデータをノードとしてリンク付けをする。
３．１と２のデータの確認を行い、修正をする。
４．業務担当者とSEがレビューを行い仕様を確認する。
５．１から４までを、完成するまで繰り返す。
具体的な設計を進めて行きます。全部詳細まで説明するとかなりのデータ量になるので、一部の内容で説明します。
説明も一般的な内容は記述していません。
１．各スキームに基づくインスタンスデータを用意する。
サブシステム
| O-ID | サブシステム | 説明 |
|---|---|---|
| S001 | 受注管理 | 商品の見積や受注までの管理を行う |
| S002 | 売上管理 | 商品の売上、請求、入金までの管理を行う |
| S003 | 出荷管理 | 商品を受注納期までに出荷する |
| S004 | 発注管理 | 受注を受けた商品を発注する |
| S005 | 仕入管理 | 商品の仕入、支払、出金管理を行う |
| S006 | 入荷管理 | 商品を入荷しその情報を管理する |
| S007 | 顧客管理 | 新規顧客の情報や変更の情報を管理する |
| S008 | 販売情報管理 | 販売実績表を作成し表示する |
| S009 | マスタ管理 | 商品マスタ、社員マスタ等をメンテナンスする |
| O-ID | 機能 | 説明 |
|---|---|---|
| F001 | 見積機能 | 商品の見積を行うこと |
| F002 | 受注機能 | 商品の受注を行うこと |
| F003 | 売上機能 | 商品の売上を行うこと |
| F004 | 請求機能 | 代金の請求を行うこと |
| F005 | 入金確認機能 | 入金の確認を行い、入力すること |
| (以下省略） |
| O-ID | アクティビティ | 説明 |
|---|---|---|
| A001 | 見積入力 | 顧客からの依頼により見積条件を入力する |
| A002 | 見積照会 | |
| A003 | 見積変更 | |
| A004 | 見積取消 | |
| A005 | 見積検索 | |
| A006 | 見積一覧 | |
| (以下省略） |
| O-ID | ロール | 説明 |
|---|---|---|
| R001 | 顧客 | |
| R002 | 訪問客 | 顧客マスタに未登録なお客様 |
| R003 | 営業担当 | |
| R004 | WEBシステム担当 | |
| R005 | 受注担当 | |
| R006 | 出荷担当 | |
| R007 | 仕入取引先 | |
| R008 | 金融機関 | |
| R009 | バッチ | バックエンド処理 |
| O-ID | 画面 | 説明 |
|---|---|---|
| G001 | 見積情報 | |
| G002 | 見積検索 | |
| G003 | 顧客登録 | |
| G004 | 受注登録 | |
| G005 | 受注検索 | |
| G006 | 出荷情報 | |
| G007 | 出荷検索 | |
| G008 | 売上情報 | |
| G009 | 売上検索 |
| O-ID | 帳票 | 説明 |
|---|---|---|
| L001 | 見積書 | |
| L002 | 見積一覧 | |
| L003 | 受注伝票 | |
| L004 | 受注日報 | |
| L005 | 売上伝票 | |
| L006 | 請求書 |
| O-ID | 外部データ源 | 説明 |
|---|---|---|
| O001 | 電話 | |
| O002 | FAX | |
| O003 |
| O-ID | エンティティ | 説明 |
|---|---|---|
| E001 | 顧客情報 | |
| E002 | 顧客決済情報 | |
| E003 | 商品マスタ | |
| E004 | 商品価格マスタ | |
| E005 | 部署マスタ | |
| E006 | 社員マスタ | |
| E007 | 見積ヘッダ | |
| E008 | 見積明細 | |
| E009 | 受注ヘッダ | |
| E010 | 受注明細 |
2013年6月12日水曜日
7.スキーマ定義(業務設計)
業務設計で使うここでの全体のスキーマを定義すると以下のようになります。
ただし、全部を前回のような記法で表現すると、それだけで煩雑になってしまうので
表形式でまとめました。
二項関係は"/2"、それ以上は"/N"で一緒には存在しえないセルに書いてあります。 少しパズル的な表現になっていますがお許しください。
行と列が逆転しているところは、"@"が付いていますので、行と列を交換して理解してください。
なにやら数独みたいな表に結果なりましたが、非常にシンプルに１８個もの設計パラメータの関係を
把握でき且つコントロールできてしました。
オントロジー的な思考アプローチで可能になってしまうことが示せたと思いますがいかがでしょうか。
これは、一つのケースであり、それぞれシステム開発の現場で変更することにより、より設計が正確に なることでしょう。ただし、あまり理想的に関連を規定すると設計が細かすぎたり、矛盾等が 発生する場合が出てきます。
むしろ検証用のツールを作成して使い、その情報を二次的に利用するか、設計書修正で役に立てる ことをお勧めします。
「これはスキーマなのでまだわかりやすいのでは？」と疑問に思うかもしれません。次回は 簡単な業務サンプルを書きます。
二項関係は"/2"、それ以上は"/N"で一緒には存在しえないセルに書いてあります。 少しパズル的な表現になっていますがお許しください。
行と列が逆転しているところは、"@"が付いていますので、行と列を交換して理解してください。
| M01 | A01 M02 |
A02 M03 |
M04 | M05 | M06 | M07 | M08 | M09 | M10 | A22 M11 |
M12 | M13 | M14 | M15 | M16 | M17 | M18 | ||
| サブシステム | M01 |
||||||||||||||||||
| 機能 | M02 | A01 /2 |
|||||||||||||||||
| アクティビティ | M03 | A02 /3 |
|||||||||||||||||
| ロール | M04 | A03 /4@ |
|||||||||||||||||
| 画面 | M05 | A04 /4 |
|||||||||||||||||
| エンティティ | M06 | A05 /4 |
A10 /2 |
||||||||||||||||
| 帳票 | M07 | A06 /4 |
A11 /2 |
||||||||||||||||
| ファイル | M08 | A07 /4 |
A12 /2 |
||||||||||||||||
| 外部データ源 | M09 | A08 /4 |
A13 /2 |
||||||||||||||||
| バッチ | M10 | A09 /2 |
|||||||||||||||||
| イベント | M11 | A22 /2 |
|||||||||||||||||
| 状態 | M12 | A23 /3 |
|||||||||||||||||
| アクション | M13 | A24 /3 |
|||||||||||||||||
| メッセージ | M14 | A21 /2 |
|||||||||||||||||
| ルール | M15 | ||||||||||||||||||
| 権限 | M16 | A20 /2 |
|||||||||||||||||
| 項目 | M17 | A14 /2 |
A15 /2 |
A16 /2 |
A17 /2 |
A18 /2 |
A25 /2 |
||||||||||||
| 部品ファイル | M18 | A19 /2 |
これは、一つのケースであり、それぞれシステム開発の現場で変更することにより、より設計が正確に なることでしょう。ただし、あまり理想的に関連を規定すると設計が細かすぎたり、矛盾等が 発生する場合が出てきます。
むしろ検証用のツールを作成して使い、その情報を二次的に利用するか、設計書修正で役に立てる ことをお勧めします。
「これはスキーマなのでまだわかりやすいのでは？」と疑問に思うかもしれません。次回は 簡単な業務サンプルを書きます。
2013年6月11日火曜日
6.スキーマ定義(リンク)
次は、リンクにあたる部分の定義です。
RDFのトリプルと同じ形式の定義が基本形になっています。
RDFではXMLのタグを使わないで表していいので、ここではXMLを使いません。
リンクは、ノードとノードの二項関係でのみ結合できること
二項式で表現すると
link(node,node)
になります。
三項関係は、二項式で生成されたものとのリンク関係となります。
link(link(node, node), node)
link(node, link(node, node))
のいずれかで表現できます。
例：業務の言葉で関係をインスタンスデータの例で表現すると
「販売管理サブシステムは、見積機能を持つ」
「販売管理サブシステムは、受注機能を持つ」
になります。
言葉で関係をメタデータで表現すると
「サブシステムは、機能を持つ」
になります。 これを、リンクで表すと、記述方法で表現すると以下になります。
凡例：
"[]"は、ノードやリンクデータの１レコード
"_"は、何のデータでも自由
"/N"は、次元数、二項式では２
スキーマ定義（リンク）
この規則を使い、ノードのリンクを定義すると以下のようになります。
RDFのトリプルと同じ形式の定義が基本形になっています。
RDFではXMLのタグを使わないで表していいので、ここではXMLを使いません。
リンクは、ノードとノードの二項関係でのみ結合できること
二項式で表現すると
link(node,node)
になります。
三項関係は、二項式で生成されたものとのリンク関係となります。
link(link(node, node), node)
link(node, link(node, node))
のいずれかで表現できます。
例：業務の言葉で関係をインスタンスデータの例で表現すると
「販売管理サブシステムは、見積機能を持つ」
「販売管理サブシステムは、受注機能を持つ」
になります。
言葉で関係をメタデータで表現すると
「サブシステムは、機能を持つ」
になります。 これを、リンクで表すと、記述方法で表現すると以下になります。
| リンク | ノード又はリンク | ノード又はリンク |
|---|---|---|
| link[A01,hsA,/2] | node[M01,サブシステム,_] | node[M02,機能,_] |
| link[A02,hsA,/3] | link[A01,hsA,/2] | node[M03,アクティビティ,_] |
"_"は、何のデータでも自由
"/N"は、次元数、二項式では２
スキーマ定義（リンク）
この規則を使い、ノードのリンクを定義すると以下のようになります。
| リンク(リソース) | ノード又はリンク | ノード又はリンク |
|---|---|---|
| link[A01,hsA,/2] | node[M01,サブシステム,_] | node[M02,機能,_] |
| link[A02,hsA,/3] | link[A01,hsA,/2] | node[M03,アクティビティ,_] |
| link[A03,hsA,/4] | node[M04,ロール,_] | link[A02,hsA,/3] |
| link[A04,hsA,/4] | link[A02,hsA,/3] | node[M05,画面,_] |
| link[A05,hsA,/4] | link[A02,hsA,/3] | node[M06,エンティティ,_] |
| link[A06,hsA,/4] | link[A02,hsA,/3] | node[M07,ファイル,_] |
| link[A07,hsA,/4] | link[A02,hsA,/3] | node[M08,外部データ源,_] |
5.属性について検討
ここではリンクについて説明をしていくつもりでしたが、
リンクで使う属性(Property)を検討しておく必要があるようです。
そこで属性について検討します。RDFとRDFS(スキーマ）について検討すると
コアの部分が再帰的な構造になっていること。
プロパティは独立して定義してよい。
主なプロパティは、コアの単なる属性と考えればいいようです。
次は実際にオントロジーを作成していく場合の高いハードルは、概念間の 関係です。 定義しておくことにします。
それぞれの用語はオントロジーでは厳密につかわれるようですが、ここではあまりこれを追及しないことにします。
| コア | rdfs: Resource |
rdfs: Class |
rdfs: Literal |
rdf: Property |
|
|---|---|---|---|---|---|
| rdfs:Resource | ←rdfs:subClassOf | ←rdfs:subClassOf | ←rdfs:subClassOf | ||
| rdfs:Class | ←rdf:type | ←rdf:type | ←rdf:type | ←rdf:type | |
| rdfs:Literal | |||||
| rdf:Property |
| rdf:Property | ←rdf | Type | |
|---|---|---|---|
| ←rdfs | subClassOf | ||
| ←rdfs | subPropertyOf | ||
| ←rdfs | comment | ||
| ←rdfs | label | ||
| ←rdfs | seeAlso | ||
| ←rdfs | isDefinedBy | ||
| rdfs:ConstraintProperty | ←rdfs | range | |
| ←rdfs | domain |
プロパティは独立して定義してよい。
主なプロパティは、コアの単なる属性と考えればいいようです。
次は実際にオントロジーを作成していく場合の高いハードルは、概念間の 関係です。 定義しておくことにします。
| 概念関係 | ここでの略記号 | 意味 |
|---|---|---|
| is-a | isA | 上位と下位の関係 |
| has-a | hsA | 全体と部分の関係 |
| part-of | ptO | 概念を分割する関係 |
| instance-of | inO | クラスに対する実際のデータ |
| attribute-of | atO | 属性関係 |
2013年6月9日日曜日
4.スキーマを定義する
ここでは、業務担当者とSEがシステム開発設計で使える言葉で、スキーマを
定義します。厳密な定義は始めから考えないで、実践で使える
フレームワークに徹します。何度でも再考して修正していきます。
WordNetの助けを借りて、スキーマを定義していきます。 始めにノードの部分を検討します。
いったいこれのどこがオントロジーなんだともいえるかもしれませんが、
本当にオントロジーの恩恵を受けるには、ここからさらに語彙の厳密性や
自動化へつながる方法をバックエンドで実行することが必要と考えています。
こうしないと、厳密性や記述ばかりに気をとられて、結局使われないツールに
なってしまいます。
「ドライバーを使うとき、ねじの穴が合わなくて困った。」てなことは誰にだってありますよね。
WordNetの助けを借りて、スキーマを定義していきます。 始めにノードの部分を検討します。
| 業務用語 | システムID | M-ID | 説明 |
|---|---|---|---|
| サブシステム | sub-system | M01 | 行動を司る方法または規則の複合体、メタ機能 |
| 機能 | function | M02 | 目的、役割または機能を提供する |
| アクティビティ | activity | M03 | 特定の行動、目的が機能を実現すること |
| ロール | role | M04 | 何かがそのために使われる、役割 |
| 画面 | GUI | M05 | GUIまたはWEBインターフェイスを指す |
| エンティティ | table | M06 | DBのテーブルをさすが、ストレージに蓄積したデータを指す |
| 帳票 | list | M07 | 会社で使われている、伝票、帳票やレシートを指す |
| ファイル | file | M08 | 業務で使われている物理的なファイルを指す |
| 外部データ源 | IF | M09 | WEB受付、コールセンタ、FAX、E-メール等 |
| バッチ | batch | M10 | システムのバックエンドっで実行される処理 |
| イベント | events | M11 | 所定の場所・時刻で起こる事 |
| 状態 | state | M12 | その主要な特性に注目したときのある物のあり方 |
| アクション | action | M13 | 何かをすることを決める行為 |
| メッセージ | message | M14 | コミュニケーションが伝えるもの |
| ルール | rule | M15 | システムの機能に関する決まりまたは法則 |
| 権限 | authority | M16 | 命令をするか、決定をする力または権利 |
| 項目 | item | M17 | エンティティやファイルの属性、項目名 |
| 部品ファイル | item-file | M18 | システムの設計で使うファイル、例えば、会社のロゴ画像ファイル |
「ドライバーを使うとき、ねじの穴が合わなくて困った。」てなことは誰にだってありますよね。
3.フレームワークを定義する
前々回「ビッグスペックをイメージする」では、システム開発の
具体例を上げました。この条件を対象に分析および設計を進めていきます。
目的は、オントロジーとタクソノミーをツールとして使いこなすことです。
ツールと言っても概念なので、フレームワークとして定義しなければいけません。
具体的な作業はWBS（Work Breakdown Structure)形式で詳細化してきます。
メタデータとインスタンスデータからなります。
メタデータはインスタンスデータのスキーマとなり、再帰的階層を持ちます。
メタデータがシステム開発での具体性を持った実装フレームワークになります。
これまでを検討すると、RDFのサブセット版になっていると考えられますが、 何が違うのかまた後で検討します。
次はメタデータを定義します。
| ツール | オントロジー | タクソノミー |
|---|---|---|
| 目的 | 語彙の定義、構造化 | 語彙の分類、階層化 |
| 型 | 構造 | 木 |
| ノードの粒度 | WBSなので段階的に詳細化 | 同左 |
| メタデータ | ||
| ノードの定義 | [M-ID,項目名,説明,コメント] | [M-ID,項目名,説明,コメント] |
| リンク：属性 | [A-ID,属性名,説明,リンク/2] | [A-ID,属性名,説明,リンク/2] |
| リンク:分類 | [C-ID,分類名,説明,リンク/2] | [C-ID,分類名,説明,リンク/2] |
| インスタンス | ||
| ノードの定義 | [O-ID,項目名,説明,コメント] | [T-ID,項目名,説明,コメント] |
| リンク：属性 | [A-ID,属性名,説明,リンク/2] | [A-ID,属性名,説明,リンク/2] |
| リンク:分類 | [C-ID,分類名,説明,リンク/2] | [C-ID,分類名,説明,リンク/2] |
| リンク | ノード対ノードを属性で関係づけ、再帰的 | ノード対ノードを関係づけ、階層化のみ |
| 検証 | 上位と下位、網羅性 | 階層表で確認 |
メタデータはインスタンスデータのスキーマとなり、再帰的階層を持ちます。
メタデータがシステム開発での具体性を持った実装フレームワークになります。
これまでを検討すると、RDFのサブセット版になっていると考えられますが、 何が違うのかまた後で検討します。
次はメタデータを定義します。
2013年6月8日土曜日
2.ビッグスペックのイメージ：実装編
前回は業務編を検討しましたが、今回は実装編（WEB、オープン系）で検討してみます。
やはり、５０項目を超えてしまいました。
実装での特徴は、特にベンダーや機器類が、数年おきに契約更新になり、又バージョンアップ する為、外部要因で強制的に保守が発生します。従って保守に対応するためのかなり大量の 作業が発生します。
| 全体管理 | 目次、全体概要図、管理対象、バージョン管理、全体計画、組織図、用語辞書 |
|---|---|
| 基盤管理 |
基盤概要図、基盤詳細、ベンダー関係（ライセンス契約書、費用資料、更新管理） ネットワーク、データベース、サーバ、端末 データセンタ管理 |
| ネットワーク管理 |
サイト契約 基本設計書、機器一覧、機器設定情報、設定手順書、バージョン管理 |
| データベース管理 |
ベンダー情報 基本設計書、機器一覧、機器設定情報、設定手順書、バージョン管理 |
| サーバ管理 |
ベンダー情報 基本設計書、機器一覧、機器設定情報、設定手順書、バージョン管理 |
| 端末管理 |
ベンダー情報（ブラウザ、携帯端末等） 基本設計書、機器一覧、機器設定情報、設定手順書、バージョン管理 |
| 運用管理 | 運用タスク管理、運用日報、障害管理、定期点検、セキュリティ管理 |
| 保守管理 | 保守タスク管理、メンテナンス手順書、保守報告、設計書改変作業 |
| 新規開発 |
業務分析 要件定義、基盤検討、方式検討、アーキテクチャ検討 セキュリティ設計 基本設計書、テーブル設計 詳細設計書、 単体試験、結合試験、システム試験、及び報告書 ソースコード、コード履歴管理、リリースバージョン管理、 ベンダー決定、機器類手配、インストール、受入検査、 マニュアル作成、リリース教育、研修、連絡票 ＊再帰的に上記全部を含む工程 |
実装での特徴は、特にベンダーや機器類が、数年おきに契約更新になり、又バージョンアップ する為、外部要因で強制的に保守が発生します。従って保守に対応するためのかなり大量の 作業が発生します。
1.ビッグスペックのイメージ：業務編
今や本屋は本のデーパートみたいなところで売られている。
国立国会図書館なんて本が置かれている巨大な要塞だ。
そしてサイバースペースには、この何倍の本や論文が存在しているのであろう。
Googleのストレージだけが知っているのでしょうか？
「もうだめです。全部想像することなんてできませ～ん。」
いったい今私が１０歳ならば、本屋で本の壁に挟まれて、どう立ちすくんでいるのだろう。
三浦つとむ氏、武谷三男氏、吉本隆明氏、遠山啓氏、立花隆氏、養老孟司氏、PF.ドラッガー氏 の本に無事出会えていたのだろうか。
今の子供たちはいつ自分にとって一生忘れられない、本当に大事な言葉に出会えるのだろうか？
さて、ビッグスペック（big specification)ですが、量を把握する為に業務管理の一部を上げると
販売管理は一番身近な業務で且つ、顧客に近い会社の生命線なので特別掘り下げたいので、
詳しくしました。これだけで５０以上の業務プロセスが存在しています。
店舗管理は、特に会社の中の一部門である場合と独立した事業主で大きく違ってきます。 また、WEBのバーチャルな店舗の場合でも特性が違ってきます。
「もうだめです。全部想像することなんてできませ～ん。」
いったい今私が１０歳ならば、本屋で本の壁に挟まれて、どう立ちすくんでいるのだろう。
三浦つとむ氏、武谷三男氏、吉本隆明氏、遠山啓氏、立花隆氏、養老孟司氏、PF.ドラッガー氏 の本に無事出会えていたのだろうか。
今の子供たちはいつ自分にとって一生忘れられない、本当に大事な言葉に出会えるのだろうか？
さて、ビッグスペック（big specification)ですが、量を把握する為に業務管理の一部を上げると
| 販売管理 |
見積管理、需要予測、 受注管理、注文請書、出荷指示、納品、商品受取、受注伝票、検収、 売上管理、請求管理、請求書、代金支払、代金回収 クーポン管理、 |
|---|---|
| 購買管理 | 購入依頼、受発注、納品検収、物品受領、仕入計上、代金請求、代金支払 |
| 生産管理 | 需給予測、生産計画、計画手配、製造指示、製造報告、原価計算、品質管理、製番管理 |
| 在庫管理 | 資材管理、棚卸管理、処分品管理、 |
| 物流管理 | 倉庫管理、輸送管理、輸出入管理 |
| 店舗管理 | 売上管理、日月報処理、マスタ管理、棚割管理、売上目標管理 |
| 会計管理 | 予算管理、原価管理、売掛管理、買掛管理、マスタ管理 |
| 財務会計 | 取引先管理、資金管理、経費管理、資産管理、決算管理、部門管理 与信管理、為替管理 |
| 人事管理 | 勤怠管理、給与計算、労務管理、人事考課 |
店舗管理は、特に会社の中の一部門である場合と独立した事業主で大きく違ってきます。 また、WEBのバーチャルな店舗の場合でも特性が違ってきます。
2013年6月7日金曜日
身近なXBRLは実は解りやすかった
XBRLは実は解りやすくなっているようです。
一般社団法人XBRLのホームページを訪問して、動画ビデオを観るだけでXBRLのコンセプトがだれでも理解できてしまいます。
ただし、現在も金融庁がルールの更新を予定しているので、まだ課題はあるようです。
ここでは、視点を変えてタクソノミーを概念のツールとしてどう使うかを目的に検討します。
XBRLは情報系で一番末端の業務処理にあたることから、 旧来のローカルな情報系からXBRLへの移行がし易かったことがあるようです。 それでも現場担当者の方の日々の苦労は大変なものがあります。
XBRLを一つのタクソノミーのモデルケースとして考えてみます。
これだけの内容に要約できるようです。
勘定科目をXMLのタグ付き言語を扱い、勘定科目同志をリンク付けることで構成されています。
仕組みやデータ作成することは、現場担当者がデータを用意するところは大変です。
考察：
業務内容からはオントロジー的な思考がウエイトを大きく締めていると思われます。
技術的には非常に先進的な方法であり、タクソノミーの良いお手本となっています。 スキーマを定義してやることが非常に重要であり、XBRLが活用されています。
タクソノミーが役立つ事や手法が、既知の事実になっていることが解りました。
ただし、現在も金融庁がルールの更新を予定しているので、まだ課題はあるようです。
ここでは、視点を変えてタクソノミーを概念のツールとしてどう使うかを目的に検討します。
XBRLは情報系で一番末端の業務処理にあたることから、 旧来のローカルな情報系からXBRLへの移行がし易かったことがあるようです。 それでも現場担当者の方の日々の苦労は大変なものがあります。
XBRLを一つのタクソノミーのモデルケースとして考えてみます。
| XBRL | eXtensible Business Reporting Language |
|---|---|
| コンセプト | 財務会計のXML化、全世界共通スキーマ、情報の二次利用 |
| 構成 | インスタンス文書＋タクソノミ文書 |
| インスタンス文書 | ビジネス報告情報を記述したXML文書 実績値データ（報告数値、テキスト、期、年度、単位） |
| タクソノミ文書 |
いわゆる共通のインスタンスが入る辞書枠 タクソノミスキーマ（リンクベースを含む） |
| タクソノミスキーマ |
要素名：勘定科目名 属性：ID、リンクベース、注記事項の項目 |
| リンクベース |
１．項目間の表示順 ２．項目数値データの重付き加算式 ３．項目間の様々な関係(項目の出現規則等) ４．項目表示名称（多国語対応） ５．参考文献（根拠になる文献） |
| その他 | 勘定科目のカスタマイズが可能だが、日本は比較的規格が明確で問題があまりない |
勘定科目をXMLのタグ付き言語を扱い、勘定科目同志をリンク付けることで構成されています。
仕組みやデータ作成することは、現場担当者がデータを用意するところは大変です。
考察：
業務内容からはオントロジー的な思考がウエイトを大きく締めていると思われます。
技術的には非常に先進的な方法であり、タクソノミーの良いお手本となっています。 スキーマを定義してやることが非常に重要であり、XBRLが活用されています。
タクソノミーが役立つ事や手法が、既知の事実になっていることが解りました。
2013年6月6日木曜日
身近なオントロジー
WEB上では、OWLがウェブオントロジー言語としてすでにあります。
また、WEB上の意味を取り扱った、OWLの基礎になっているRDFがあります。
我々の身近に存在しているオントロジーツールが、OWLと言えます。
それではRDFとOWLを簡単に比較してみます。
OWLを編集するには、XMLなので専用のエディタを使うようです。
OWLの検索では、SPARQL（RDF（XML）に対する問い合わせ言語のような）を使うようです。
出力フォーマットのレポートも専用のSWを使うようです。
簡単ですが、もう少し気合をいれて平たく説明ができないか考えましたが、力不足に終わってしまいました。
目的はあくまでも、概念として役に立つツールか評価しておきたいので、業務で使うにしては、 構造化する過程が粒度的に細かすぎる気がしました。
結論としてやはりオントロジーを使うには、業務担当者ではなく、SEが担当する必要があります。 この場合、業務を深く知らない訳で専用エディタで開発を進めるには難しいと思いました。
| 名称 | RDF：Resource Description Framework | OWL:Web Ontology Language |
|---|---|---|
| 年 | 1999年誕生 | 2004年勧告 |
| 目的 | Web上の情報資源の構造を論理的に記述すること | オントロジーを使いデータ交換すること、推論計算も可能 |
| 概要 | 基本単位（トリプル）は、主語、述語、目的語。
トリプルに基づく構成で定義 主語（楕円）や目的語（長方形）を述語（矢）で結ぶ記法 |
３つのサブ言語からなる。 厳密（DL)：推論が可能、範囲狭い 簡易（Lite)：限定的 RDF拡張（Full)：範囲が広い |
| 用途 | 語彙の提供、情報検索、図書情報管理、 業務設計で利用しているケース | |
簡単ですが、もう少し気合をいれて平たく説明ができないか考えましたが、力不足に終わってしまいました。
目的はあくまでも、概念として役に立つツールか評価しておきたいので、業務で使うにしては、 構造化する過程が粒度的に細かすぎる気がしました。
結論としてやはりオントロジーを使うには、業務担当者ではなく、SEが担当する必要があります。 この場合、業務を深く知らない訳で専用エディタで開発を進めるには難しいと思いました。
2013年6月5日水曜日
図と表について
システム開発でよく使われる図や表を上げると、（文書も中に含まれていることはとりあえず無視して考えています）
図：システム全体図(俯瞰）、フローチャート、ERD、クラス図、状態遷移図、シーケンス図、画面モック、ネットワーク図
表：目次、WBS、進捗表、障害票、ユースケース、テーブル定義、連絡票、テスト結果票、状態遷移表
やや適当な分類と内容になりましたが。後日修正していくつもりです。 又本来ならば、表を単なるパラメータとして考えた場合、図へ変換が可能なのでそもそも 捉え方が問題かもしれません。
話が変わってしまいますが、システム開発では、 対象の情報量が多くなると扱いが難しくなるので、図や表の次の概念としてDSLやXML等の パラメータをルールにした考え方を考慮していく必要性が出て来ると思います。
これは自動検証へとつながります。あまりにビッグスペックな対象をコントロールする にはこの方法しかないような気がします。
オントロジーやタクソノミーが、設計作業を形式化するツールとなることのヒントとなれば いいのですが。
図：システム全体図(俯瞰）、フローチャート、ERD、クラス図、状態遷移図、シーケンス図、画面モック、ネットワーク図
表：目次、WBS、進捗表、障害票、ユースケース、テーブル定義、連絡票、テスト結果票、状態遷移表
| 図 | 表 | |
|---|---|---|
| 例えると | オントロジー的 | タクソノミー的 |
| 関係 | 構造的 | 階層的 |
| 制約 | ２次元 | 行列 |
| 線 | フリー | 直線 |
| 網羅性 | △ | ◎ |
| 再帰性 | ◎ | △ |
| 自動化 | △ | ◎ |
| 整理 | △ | ◎ |
| 入力効率 | △ | ◎ |
| ノード/頁 | 小 | 中 |
| 関係表現 | ノード＋リンク | タイトル＋項目＋インスタンス |
| 認識 | イメージが直接的 | 間接的、言葉の場合直接的 |
| 種類 | ダイヤグラム、記号 | 行列表、 |
| 記号化 | よく使う | あまり使わない |
| 再利用性 | △ | ◎ |
| 文書率 | 少ない | 多い場合もある |
| 知識 | 形式知的 | 暗黙知的 |
| SW | 専用ソフト等 | スプレッドシート |
| スキル | 学習が必要 | 基本的な知識 |
| 指向 | イメージ指向 | パラメータ指向 |
やや適当な分類と内容になりましたが。後日修正していくつもりです。 又本来ならば、表を単なるパラメータとして考えた場合、図へ変換が可能なのでそもそも 捉え方が問題かもしれません。
話が変わってしまいますが、システム開発では、 対象の情報量が多くなると扱いが難しくなるので、図や表の次の概念としてDSLやXML等の パラメータをルールにした考え方を考慮していく必要性が出て来ると思います。
これは自動検証へとつながります。あまりにビッグスペックな対象をコントロールする にはこの方法しかないような気がします。
オントロジーやタクソノミーが、設計作業を形式化するツールとなることのヒントとなれば いいのですが。
2013年6月2日日曜日
システム開発の現場で使える言葉とツール
SE:「今からこの販売管理をオントロジーを使って設計します。」
業務担当者：「オントロジーてなんじゃそれは？、そんな言葉は使えないよ」
SE:「ええ、オントロジーは存在論で、。。。。」
こんな言葉はシステム開発の現場ではとても使えません。
それこそ1日で両者は不仲になってしまいます。
オブジェクト指向がシステム開発で登場した時を思い出してしまいます。
ここでは、システム開発の現場を想定してツールが使えるか検討してみます。
オントロジーやタクソノミーをツールとして使う場合、現場で使われる言葉はそのまま使えないので、
オントロジーは「意味」、「辞書」、「業務用語」、「構造化」、「定義」
タクソノミーは「分類」、「仕分け」、「階層化」、「木の構築」
みたいな言葉で使うことが妥当なのでしょうか。
開発の現場でツールが利用されるであろう要件や注意点を以下にまとめてみます。
１．フレームワークとして定義し、具体的に利用可能になるまで詳細化していること。
２．コミュニケーションを手助けできるものであること。
３．利用者全体で共通の言葉が使えること。
４．専用のSWを使う場合は単なる道具と考え、手段と考えること。
５．１０年後でも有効なツールであること。
６．正確性の向上や効率化に貢献できること。
７．実業務とフレームワークが合っていること。
８．トップダウン、ボトムアップ両方からアプローチ可能が望ましい。
９．概念を対象にすると、スコープが広がり過ぎ無駄が多くなるので注意する。
Googleでググると、
"ontology taxonomy framework"をキーで280万件
"ontology taxonomy framework XBRL"をキーで28700件
ヒットします。
ほとんどがWEB検索系の体系から始められた関係のものだと考えられますが、
それにしてもすさまじい数です。
そろそろシステム開発でも使えるフレームワークが出てきてもおかしくありません。
XBRL(拡張可能な事業報告言語)のような世界的に始まっている取り組みもあるので、
もう少し調査をしてみます。
業務担当者：「オントロジーてなんじゃそれは？、そんな言葉は使えないよ」
SE:「ええ、オントロジーは存在論で、。。。。」
こんな言葉はシステム開発の現場ではとても使えません。
それこそ1日で両者は不仲になってしまいます。
オブジェクト指向がシステム開発で登場した時を思い出してしまいます。
ここでは、システム開発の現場を想定してツールが使えるか検討してみます。
オントロジーやタクソノミーをツールとして使う場合、現場で使われる言葉はそのまま使えないので、
オントロジーは「意味」、「辞書」、「業務用語」、「構造化」、「定義」
タクソノミーは「分類」、「仕分け」、「階層化」、「木の構築」
みたいな言葉で使うことが妥当なのでしょうか。
開発の現場でツールが利用されるであろう要件や注意点を以下にまとめてみます。
１．フレームワークとして定義し、具体的に利用可能になるまで詳細化していること。
２．コミュニケーションを手助けできるものであること。
３．利用者全体で共通の言葉が使えること。
４．専用のSWを使う場合は単なる道具と考え、手段と考えること。
５．１０年後でも有効なツールであること。
６．正確性の向上や効率化に貢献できること。
７．実業務とフレームワークが合っていること。
８．トップダウン、ボトムアップ両方からアプローチ可能が望ましい。
９．概念を対象にすると、スコープが広がり過ぎ無駄が多くなるので注意する。
Googleでググると、
"ontology taxonomy framework"をキーで280万件
"ontology taxonomy framework XBRL"をキーで28700件
ヒットします。
ほとんどがWEB検索系の体系から始められた関係のものだと考えられますが、
それにしてもすさまじい数です。
そろそろシステム開発でも使えるフレームワークが出てきてもおかしくありません。
XBRL(拡張可能な事業報告言語)のような世界的に始まっている取り組みもあるので、
もう少し調査をしてみます。
Aha体験よりもBEHの方が大切かも
始めに謝っておきますが、BEHは補完知のことで、ここでの造語です。
別におちゃらけているわけではないのですが、あまり良い言葉が見つからなくて、
BEH（behind)を使わせていただきます。
私が「Aha！体験」の言葉を知ったのは1979年の日経サイエンス社の雑誌を購入して
でした。当時職場の同僚にAhaの言葉を説明しようとしたら目を丸くされたので
話すのをやめてしまったことを覚えています。
今では茂木さんがTVでAha体験の話をしてくれていて、認知されているので説明は
必要がないので、普通に脳の話を日常会話でも使えるようになりました。感謝しています。
BEH(補完知)は何を指しているかを定義すると、時間制約を前提に、リアルタイムで人が
そこに明確にはないものを補完して認識している知のことを指しています。
例えば、TVで紹介されたアルファベット文字の上半分を目隠しされてもその文字を読める
ことや、実際に録音をしてある音を消してしまってもそこにない音を補完してくれます。
特に日本人は英語の発音を聞き取れていないので、訓練しないと補完がきかないので苦労
します。（私はアイルランド技術者との会議で話し言葉が全く聞き取れなくて、他の人は問題
がなく聞こえていたことには、自分の能力のなさに驚きました。逆Aha体験でしょうか？）
システム開発なんかでは、このBEH(補完知)が特に重要であると考えています。
システム開発のマニュアル、仕様書や設計書でもぶ厚い辞書のようなものに仕事では
よく遭遇します。
仕事はすぐスタートさせなければならないので、短時間で書類を理解するの
は少し技術が要ります。まずやるのは、とにかく高速で全頁をぱらぱら
目を通します。これで構成やボリュームは認識できます。特にローカルな
仕様書や設計書は、著者が読者に対し読んでもらうために書いた書籍と違い、
殆ど体系化されていないことや、同じような繰り返しパターンなので、補完知
を使い量を理解することが重要です。
次は、目次、タイトル、図を対象に目を通します。これである程度のインデックス
やイメージは頭の中に出来上がります。ここまでは形式的に作業します。
次は、内容へ移るのですが要件仕様にはよく目を通しておきます。
この後は、地道に仕事をこなしていくだけです。特に役立つことは
当たり前のことですが、普段からのひたすら技術を事前に習得しておくこと
です。特にタクソノミー的な技術は実際でも体験しておかないと、意味のネットワーク
を作ることが難しいので、なかなか使いこなすことはできません。
例えばフレームワーク（Javaのフレームワーク群,.Net等）などのビッグスペック
を覚えるには非常に苦労します。
失敗例は、最近体験したことでWindows８を購入した時のことです。
今まで、DOS時代から全てのOSのバージョンアップされたものを使い始めるのに、
苦労した覚えがなく使えたのですが、もちろん最初のPCの操作方法を覚えるのは
勉強が必要でしたが、MS-Windowsシリーズが始まってからはあまり苦労した
覚えがなかった記憶があります。Win8は少し違いました。始めは使いこなせなくて、
購入してから1ヶ月間はインストールを済ませてから何もしないでいました。
そのままWindows７を使っていました。
使う必要が出てきたので、OSの紹介ビデオ説明を見たり、ネットで操作キー方法
のポイントが書いてあったサイトを見つけて、操作方法のポイントがつかめたら
少し設定を変えるだけで、無事仕事でも使えるようになりました。今では快適に
使えています。
ここで私の間違いは、従来の体験と知識が逆に邪魔をして、マニュアルを読む
必要なんかないと判断したことです。７から８への差分を確認してから使う
必要がありました。補完知をあてにして逆に邪魔している例でしょうか。
（単にプライドが高いバカではないのかという意見もあるかもしれませんが）
BEH(補完知)は案外、速読なんかと脳の中で同じことが起こっているのかもしれませんが、
全く想像にしかすぎません。
仕事で人から話を聞く時、話の主旨を外れてエビデンスばかり永遠に話を聞いている場合、
折角BEH(補完知)を使って仕事をしているのに、話の主旨に早く戻ってくれればいい
のにと思うことがありますよね。
また、「結論から話をする」ことも、「一を聞いて十を知る」BEH(補完知)そのものですね。
書籍で「差分」佐藤雅彦著を見ると差分によるイメージがダイレクトに伝わってくるのですが、
この感覚が関係していることも何か関係性のヒントになりそうですが、全然論理的には
説明ができません。
BEH(補完知)は、対象の情報量が大量でも、一瞬で対象を理解できることが特徴です。
単なる知恵と区別していることは、時間制約のもとに意識的に作業をおこなっている
ことが特徴です。「火事場の馬鹿力」みたいなことも脳に作用しているかもしれません。
他に誰にも体験があるかもしれませんが、難しい内容の本を買って読むのですが、
少しも頭に入らず投げ出した本でも、実際に仕事で使うことが決まったら急に理解
ができるようになることを体験したことがあります。（これは集中力というのですが）
哲学書を読んでいる時のことですがゆっくりマイペースで読むよりも、できるだけ速読した
方が理解できることを体験したことがありました。
もしかしたら頭が良い人で哲学書がスラスラ読める 人は読むスピードが超高速なのかもしれません。
補完法（BEHM)の定義：参考にする人が補完知を使って 「補完法を意識して作成した形式知的ドキュメント」を理解し、二次利用できようにする方法。
勝手に私がブログで定義した方法です。いつの日かこんな方法ができないか模索していきます。
これが可能になれば、情報の二次利用の流通が可能になると夢見ています。
ヒントとなったことは、CheatSheetを参考にしていてからです。 CheatSheetとは、「カンニングペーパ」とも解釈されまたは、「ノウハウの塊、魔法の巻物」とも解釈されるわけです。
もしこれが本当に可能であるならば、BEHMも論理的に可能ではないかと考えたわけです。
別におちゃらけているわけではないのですが、あまり良い言葉が見つからなくて、
BEH（behind)を使わせていただきます。
私が「Aha！体験」の言葉を知ったのは1979年の日経サイエンス社の雑誌を購入して
でした。当時職場の同僚にAhaの言葉を説明しようとしたら目を丸くされたので
話すのをやめてしまったことを覚えています。
今では茂木さんがTVでAha体験の話をしてくれていて、認知されているので説明は
必要がないので、普通に脳の話を日常会話でも使えるようになりました。感謝しています。
BEH(補完知)は何を指しているかを定義すると、時間制約を前提に、リアルタイムで人が
そこに明確にはないものを補完して認識している知のことを指しています。
例えば、TVで紹介されたアルファベット文字の上半分を目隠しされてもその文字を読める
ことや、実際に録音をしてある音を消してしまってもそこにない音を補完してくれます。
特に日本人は英語の発音を聞き取れていないので、訓練しないと補完がきかないので苦労
します。（私はアイルランド技術者との会議で話し言葉が全く聞き取れなくて、他の人は問題
がなく聞こえていたことには、自分の能力のなさに驚きました。逆Aha体験でしょうか？）
システム開発なんかでは、このBEH(補完知)が特に重要であると考えています。
システム開発のマニュアル、仕様書や設計書でもぶ厚い辞書のようなものに仕事では
よく遭遇します。
仕事はすぐスタートさせなければならないので、短時間で書類を理解するの
は少し技術が要ります。まずやるのは、とにかく高速で全頁をぱらぱら
目を通します。これで構成やボリュームは認識できます。特にローカルな
仕様書や設計書は、著者が読者に対し読んでもらうために書いた書籍と違い、
殆ど体系化されていないことや、同じような繰り返しパターンなので、補完知
を使い量を理解することが重要です。
次は、目次、タイトル、図を対象に目を通します。これである程度のインデックス
やイメージは頭の中に出来上がります。ここまでは形式的に作業します。
次は、内容へ移るのですが要件仕様にはよく目を通しておきます。
この後は、地道に仕事をこなしていくだけです。特に役立つことは
当たり前のことですが、普段からのひたすら技術を事前に習得しておくこと
です。特にタクソノミー的な技術は実際でも体験しておかないと、意味のネットワーク
を作ることが難しいので、なかなか使いこなすことはできません。
例えばフレームワーク（Javaのフレームワーク群,.Net等）などのビッグスペック
を覚えるには非常に苦労します。
失敗例は、最近体験したことでWindows８を購入した時のことです。
今まで、DOS時代から全てのOSのバージョンアップされたものを使い始めるのに、
苦労した覚えがなく使えたのですが、もちろん最初のPCの操作方法を覚えるのは
勉強が必要でしたが、MS-Windowsシリーズが始まってからはあまり苦労した
覚えがなかった記憶があります。Win8は少し違いました。始めは使いこなせなくて、
購入してから1ヶ月間はインストールを済ませてから何もしないでいました。
そのままWindows７を使っていました。
使う必要が出てきたので、OSの紹介ビデオ説明を見たり、ネットで操作キー方法
のポイントが書いてあったサイトを見つけて、操作方法のポイントがつかめたら
少し設定を変えるだけで、無事仕事でも使えるようになりました。今では快適に
使えています。
ここで私の間違いは、従来の体験と知識が逆に邪魔をして、マニュアルを読む
必要なんかないと判断したことです。７から８への差分を確認してから使う
必要がありました。補完知をあてにして逆に邪魔している例でしょうか。
（単にプライドが高いバカではないのかという意見もあるかもしれませんが）
BEH(補完知)は案外、速読なんかと脳の中で同じことが起こっているのかもしれませんが、
全く想像にしかすぎません。
仕事で人から話を聞く時、話の主旨を外れてエビデンスばかり永遠に話を聞いている場合、
折角BEH(補完知)を使って仕事をしているのに、話の主旨に早く戻ってくれればいい
のにと思うことがありますよね。
また、「結論から話をする」ことも、「一を聞いて十を知る」BEH(補完知)そのものですね。
書籍で「差分」佐藤雅彦著を見ると差分によるイメージがダイレクトに伝わってくるのですが、
この感覚が関係していることも何か関係性のヒントになりそうですが、全然論理的には
説明ができません。
BEH(補完知)は、対象の情報量が大量でも、一瞬で対象を理解できることが特徴です。
単なる知恵と区別していることは、時間制約のもとに意識的に作業をおこなっている
ことが特徴です。「火事場の馬鹿力」みたいなことも脳に作用しているかもしれません。
他に誰にも体験があるかもしれませんが、難しい内容の本を買って読むのですが、
少しも頭に入らず投げ出した本でも、実際に仕事で使うことが決まったら急に理解
ができるようになることを体験したことがあります。（これは集中力というのですが）
哲学書を読んでいる時のことですがゆっくりマイペースで読むよりも、できるだけ速読した
方が理解できることを体験したことがありました。
もしかしたら頭が良い人で哲学書がスラスラ読める 人は読むスピードが超高速なのかもしれません。
補完法（BEHM)の定義：参考にする人が補完知を使って 「補完法を意識して作成した形式知的ドキュメント」を理解し、二次利用できようにする方法。
勝手に私がブログで定義した方法です。いつの日かこんな方法ができないか模索していきます。
これが可能になれば、情報の二次利用の流通が可能になると夢見ています。
ヒントとなったことは、CheatSheetを参考にしていてからです。 CheatSheetとは、「カンニングペーパ」とも解釈されまたは、「ノウハウの塊、魔法の巻物」とも解釈されるわけです。
もしこれが本当に可能であるならば、BEHMも論理的に可能ではないかと考えたわけです。
2013年6月1日土曜日
勝手に10年後の開発手法予報
プログラム言語の１０年後を予想することはイメージできますが、
1０年後の開発手法は予想することは難しそうです。
何故ならば、システム開発手法が現状でもあまり現場まで浸透した
スタンダードなものがないことからも想像できます。
まずは過去を振り返り開発手法を検討してみます。
まとめてみると以下になります。順番は大体話題に上った順に並べてあります。
傾向を分析すると、制御や処理->データ->オブジェクト->フレームワーク、基盤、管理、概念
具体的な記法は、図、表、タグ
段々新しくなるにつれ手法の適用範囲も段々大きくなっていると考えられます。
UMLの様に、それまでのいいとこどりで用意した記法でしたが、結局業務担当者と
実装担当者の間では効率の良いツールにならないで、使えるものだけを利用して
使っている状態のものもあります。
又世の中に出てきた時点では、非常に期待されてセミナーが開かれて注目されるの
ですが、現場や会社全体で効率が上がらなかったり、主体となる部署で理解が得られ
ない場合があり、なかなか開発手法が定着しません。
結局どの会社でも採用されているツール（開発手法ではありませんが）は、現実は
MS-Word,MS-Excel,MS-PowerPointでインフォーマルな手法で開発は進められている
ことが事実です。
ここからは、単なる予想になります。
現在、システムは、ビッグデータ、ハイスピード、ビックスペックの時代に突入しています。
傾向をみると次に注目されることは、基盤のフォーマットは構築されつつあるので
これからは、より概念やセマンティクな開発手法が予想されます。
いわゆるボトムアップ型思考とトップダウン型思考を両方で利用できる開発手法です。
「オントロジー＋タクソノミーをツールにフレームワークを構築した開発手法」が、
私の勝手な１０年後の開発手法予報とさせていただきます。
（動的概念を忘れていました、コレオグラフィーまでも考慮に入れる必要があるのかもしれません。)
あまり具体的ではないので、ピント来ないかもしれませんが。これ以上述べると占い師
になりかねないので。
まずは過去を振り返り開発手法を検討してみます。
まとめてみると以下になります。順番は大体話題に上った順に並べてあります。
| 手法 | 年 | 説明 | フローチャート | 1921 | 制御の流れ図、特許等でも前説なしで使っている記法、 業界を問わず世界的に採用されている図 |
|---|---|---|
| 構造化手法、ＤＦＤ | 1978 |
データフロー図で、プロセスとデータストアの関係をＩ/Ｏの矢で結んだ図 設計というよりもレビューで説明用に使われている |
| CASE TOOL | 198? |
専用のエディタを使い設計書を作成し、ソースコードも自動で生成するツール 何故か今では日本ではほとんど言葉でさえ使われていない状態 |
| 状態遷移図、状態遷移表 | 198? |
現在の状態、イベント、アクション、次の状態を図や表 制御、組込み系では定番の手法 |
| ＪＳＤ法 | 1983 | 主に制御等を階層と記号で表し、オブジェクト指向の元になった手法 |
| ＤＤ、ＩＲＭ | 1982 | データディクショナリ、情報資源管理でシステムの何でもＤＢに登録して管理利用 |
| ＤＯＡデータ中心 | 198? |
プロセスや制御よりも、データが安定していることを利用 ER図は本当は独立した手法ですが、手法的には同類とみなしています |
| ＥＡ | 1992 |
フレームワーク、モデル、構築ツール等で体系化、会社や社会全体までもモデル化 奥が深そうです。 |
| ＵＭＬ | 199? |
オブジェクト指向での設計手法のスタンダード ユースケース、クラス図、シーケンス図、アクティビティ図が主 |
| ＸＭＬ | 199? |
開発手法ではないが、データの規格化の基盤、XMLはただの共通フォーマットなので
将来までも活用されていると思います XBRL(2008)はタクソノミとインスタンスで構成 |
| ＰＭＢＯＫ | 1987 | プロジェクトマネジメント知識体系ガイド、PMの基盤を提供 |
| SOA | 2004 |
サービス指向アーキテクチャ、大規模なコンピュータ・システムを構築する際の概念あるいは手法 |
| MOT | 198？ |
Management Of Technology 技術経営、 生産技術、品質機能展開等製造業のすべてのノウハウが盛り込まれている |
具体的な記法は、図、表、タグ
段々新しくなるにつれ手法の適用範囲も段々大きくなっていると考えられます。
UMLの様に、それまでのいいとこどりで用意した記法でしたが、結局業務担当者と
実装担当者の間では効率の良いツールにならないで、使えるものだけを利用して
使っている状態のものもあります。
又世の中に出てきた時点では、非常に期待されてセミナーが開かれて注目されるの
ですが、現場や会社全体で効率が上がらなかったり、主体となる部署で理解が得られ
ない場合があり、なかなか開発手法が定着しません。
結局どの会社でも採用されているツール（開発手法ではありませんが）は、現実は
MS-Word,MS-Excel,MS-PowerPointでインフォーマルな手法で開発は進められている
ことが事実です。
ここからは、単なる予想になります。
現在、システムは、ビッグデータ、ハイスピード、ビックスペックの時代に突入しています。
傾向をみると次に注目されることは、基盤のフォーマットは構築されつつあるので
これからは、より概念やセマンティクな開発手法が予想されます。
いわゆるボトムアップ型思考とトップダウン型思考を両方で利用できる開発手法です。
「オントロジー＋タクソノミーをツールにフレームワークを構築した開発手法」が、
私の勝手な１０年後の開発手法予報とさせていただきます。
（動的概念を忘れていました、コレオグラフィーまでも考慮に入れる必要があるのかもしれません。)
あまり具体的ではないので、ピント来ないかもしれませんが。これ以上述べると占い師
になりかねないので。
登録:
投稿 (Atom)