文字の大きさを変更できます
ProjectID:60382
公開日時:2015-04-25 14:10
D-ADD技術を用いたKnowledgeLineの紹介
[md]

株式会社Symphony 代表取締役 永山 辰巳 様

第2回『 DEOS 協会技術部会(D-ADD)』での発表補助資料
発表持ち時間25分

本Web資料は、主にシンポジウム参加者への講演補助資料として一般公開されました。

本資料の短縮URLは、

#http://u111u.info/kdIA
材料探索研究ノートシステム(KnowledgeLineの祖先)
 KnowledgeLineの着想は古い。1985年から始めた材料の組成探索シミュレーションソフト開発の時代に遡る。
1985年、アモルファスの組成物性計算を行うのに関数電卓を駆使しても1週間ぐらいかかった。それをPCで行えるようにして、かつ試作した材料の物性データをデータベース化して、統計解析、多変量解析を用いた各材料元素の物性寄与率、アモルファス構造に与える影響度(例えば屈折率)をシミュレーションできるようにした。

 このデータベースと計算システム、そして何度も組成を繰り返し設計してシミュレーション能力とし予想物性値と実験データを照合することで、私の「考える力」は、それ以前とは比較できないほど強化された。
三角3元法
Webの時代
 いとも簡単に情報を配布、共有することが可能になったインターネットは、情報ハイウエイとして世界中に広まった。
もし、研究者がノートシステムを共有して、様々な議論やアイディアを時空間で共有したら?学術情報とはどんな変貌を遂げるのだろうか?

研究ノートシステムを作ることにした。

 日産自動車中央研究所は1989年当時所員2,000名いて、一つの製品である「クルマ」を研究していた。その特殊性において、ノートシステムは、クルマの構造をしている構造化文書システムとして捉え、コンピュータ上のノートシステムとして研究を始めた(当時の日産は、MacからクレイまでFDDIリングでネットワーク化しており、コンピュータの万国博覧会と言われた)。

 この研究ノートシステムは、最初はX11(SUN、Solaris)次にNeXTSTEP、そしてJavaアプリケーションサーバと時代を経て受け継がれたが、中心的な課題は、文書を構造化すること、部品のように組み合わせるインターフェースがあり、抽象化された情報(メタ情報)をどのように利用するかであった。そして、構造化文書システムの実態としては、次第にXML文書データベースに修練されていった。
この実験システムは、後の2002年に私が東芝の情報系子会社時代に一度製品化されたが、製品コンセプトが時代より早すぎてしまった。
【ファイルダウンロード】
  1. [ 知識のインフラを目指して99.pdf ]
    構造化文書の最初の構想書
  2. [ WebOS5.pdf ]
    WebのOSを目指した時代
  3. [ Inspiration Technical Presentation (Tom).pdf ]
    WebOSを目指したプレゼンテーション(英文)
生涯の知識記憶を蓄積できるノートシステムの設計
 放送局のお客様、情報通信会社、医療サービスの会社のお客様からのシステム開発を経験する中で、たくさんの人々の知識が影響し合い、一人の人間としても生涯の記憶としての情報空間を構築できるノートシステムを作りたいと思うようになった。

 生涯の知識記憶を蓄積できるノートシステムの設計、つまりこれがKnowledgeLineのアーキテクチャの要求源である。そのような要求から、KnowledgeLineと命名されている。無限に広がり、無限に繋がる知識の様相、時間軸を含んだ知識の媒体をKnowledgeLineと命名した。

これが現在のKnowledgeLineの始まりである。

2004年にスタートしたKnowledgeLineプロジェクトは、1985年にまで遡る、私が設計した幾つもの研究システムを手本に構想作り始めた。

前提条件として

・Javaのアプリケーションサーバーとしての性能を持つこと
・Webアプリケーション開発フレームワークであること
・情報モデルとしてノードリンク型として、UIと永続化層の一致を行うこと
・構造モデルとしてWBS、プロセスとしてPDCAをデザインできること、そして時間属性を制御できること
・情報へのアクセスコントロール技術を有し、組織的な運用のために、組織の運用を設計できること

 幸いなことに、先進アーキテクチャ、アプリケーション開発環境を求められていたお客様と出会うことで最初のバージョンが動き出した。
アプリケーション開発環境としてのKnowledgeLine
 お客様とシステムデザインを行うにあたり、システム概要の視覚化を行うことにした。双方にとって未知の部分が多いときは、言葉、文章よりも、図解による相互理解は大きな利点がある。
また開発方式はアジャイル形式を取りたかったので、アジャイルに経験の無いお客様と合意形成がスムーズに行くように、紙でシステムデザインを検討出来る仕組みを考案した。

 この紙で動くデザインシステムが、KnowledgeLineに大きな影響を与えた。特に考案されたのが、WBS/PDCA型を実現するための、階層的PMT-Cなのである。

 この時デザインされたお客様の業務システムは、10年経って今でも稼働中であるが、設計当初の要求とは少々違っている。それでも、長く稼働している要因は、業務モデルをPMT-Cでデザインしたことである。
初期のニーズ
二つほど初期の事例を紹介する。

・情報通信会社様の2,000名の部員全員に、自分の持つ業務の棚卸しとして、PMT構造記述で各人の業務を洗い出すという実験があった。
・耳鼻咽喉科のクリニック経営者が、10人ほどクリニックドクターで、医療情報を共有したいというニーズがあり、ドクターノートシステムを運用した。目指したの新世代のクリニック経営手法。

他には、

・システム運用の記録簿
・マニュアル文書
・汎用的業務記録「業務日誌」
・プロジェクトマネージメント「意思決定」

などがあった。

DEOS/D-ADD:合意記述データベースとの出会い
KnowledgeLineに大きな転機が訪れた。

DEOS(Dependability Engineering for Open Systems)プロジェクトとの出会いである。
私の周りの人たちとの繋がり、研究の繋がり、そして時代のニーズなどにより、私たち(KnowledgeLineの開発チーム)は、DEOSプロジェクトの研究メンバーとなった。

KnowledgeLineにとって、合意形成は、基本的な導線である。ごく自然にそれを実行してきた。KnowledgeLineには、合意形成のプロセスが生まれ、確定のためのエビデンスとしてコメントラインが作られた。
KnowledgeLineによる業務はリアルタイム、即時的な繋がり、共有で行われるため、そもそも、「合意する、しない」、「主張と反論」といった議論の構図により、開発業務が行われていた。
【参照 URL(外部サイトへリンクします)】
  1. https://d-add.deos.or.jp
    DEOS協会:技術部会の紹介
D-ADD(合意記述データベース)
 DEOSは、ソフトウエアや企業活動を安全、安心に推進するためのガイドラインを策定するプロジェクトであった。その中で重要なのが、合意形成と説明責任である。図中のDEOSプロセスを業務の流れとしてみれば、固い合意形成としては稟議、議決、承認として理解すれば良い。
 長期にわたる意思決定、仕様の変化、新たな課題など時間的変化を遂げる合意は、徐々に矛盾や不整合をはらんでいく。あるとき、その矛盾や不整合が重なり大きな原因となって、障害や事故が起こる。
 D-ADDは、プロセス全体に起こる時系列としての合意形成を記録し続けることによる、合意の齟齬や矛盾点を探り当てる役割として定義された。当初はその要求に対してKnowledgeLineは十分ではなかったが、プロジェクトにおいて、研究システムを構築するためには十分な経験と親和性を持っていた。
 そして、二年間のDEOSプロセスの研究を終了し、KnowledgeLineに新たなDEOS的視点を与えることで、高信頼性アプリケーション開発環境としての製品化へ準備が整ったのである。
DEOSプロセス図
D-ADD版KnowledgeLineを用いたシステム開発、応用展開
[tt]
 KnowledgeLineを用いたシステム開発や、開発環境の構築、さらに運用環境としての手法を紹介する。
 企業において、特に複雑な業務システム、長期間、多数の関係者で進められるプロジェクト、大規模システム開発などを想定したKnowledgeLineの特徴をアピールしたい。

 第2回『 DEOS 協会技術部会(D-ADD)の永山の発表では、

*D-ADD技術による上流と下流を結び、高信頼性システム開発へ向かうKnowledgeLine*

として説明を行う(添付資料参照)。
【ファイルダウンロード】
  1. [ KLカタログコンセプト.pdf ]
    上流と下流を繋ぐKnowledgeLine
  2. [ D-ADD_WhiePaper_Rev100 20131218更新.pdf ]
    Revision 1.0
1.高信頼システム開発環境としてのKnowledgeLine
[md]
 KnowledgeLineをソフトウエア開発ツールのポジショニングとして考えると、MSプロジェクトとRedmineの中間に位置している。中間とは、プロジェクトマネージメントとしての色合いを備え、品質保証機構を備えた開発ツールとして提供されることを意図する。

 DEOSプロセスを品質保証機構として設計書データベース(XML)を実現した。

要件定義、仕様書、設計書、議事録等のドキュメントデータベース実現した
マークアップによる変更管理、注意点監視、履歴管理を実現した

また、監視技術とソースコード管理技術との連動は、お客様による要求にて機能、サービスの接続開発をオプション(要望開発)にて行う。


合意形成によるアシュアランスケース、DEOSプロセスによる品質保証のためのロギング(監視、記録、変化対応)
ソースコードの管理としてリポジトリ(SVN、Git等)とCIサーバを連動して、ソースに対応する文書とのリンク機構


 KnowledgeLineが挑戦しているのは、**上流と下流の接続**である(添付資料、KLカタログコンセプト.pdfを参照のこと)。上流とは、要件定義書、仕様書、設計書であり、下流とは、実装、テスト、さらには運用である。
KnowledgeLineは、様々なドキュメント(書)の格納と展開に力を入れており、XMLドキュメントシステムとして成長させている。今回、PCIソリューションズからの依頼で、設計書(Excel文書)の格納と管理技術をKnowledgeLine上に拡張した。100名近い人員でのソフトウエア開発時に利用する設計書の管理技術は、その後実装とテスト、品質検査と連続していなければならないが、現実は、どちらかのアップデートに対して、追従できなくなる傾向がある。しかし、この結果起こりえることに重大な齟齬、障害が待っている。
【ファイルダウンロード】
  1. [ KL概要2014withDEOS2.pptx ]
    参考
  2. [ KL=D-ADDwithDEOS.pptx ]
    DEOSプロセスとD-ADD
2.システム統合、移行、運用環境としてのKnowledgeLine
 KnowledgeLine(KLと略す)によるアプリケーション開発技術として、Apache/Camelプロジェクトの仕様を取り込んだ試験開発を行った。この結果、KnowledgeLineの新たな適応分野が広がってきた。例えば、企業内にAシステムとBシステムがあり、それらを統合、あるいはサービスを相互に乗り入れたいなどの要求があったとする。

その場合に、A<>KL<>Bとしての構成を検討して、AとBの接続要件、ならびに動作監視をKLを利用して行う。A<Camel>Bという具合に開発を進めることになる。実行の可否やメリットは、Camelに依存する部分も多いが、複数のシステムが複雑に繋がるケースでは、KLを利用したCamelによるシステム統合、移行は、開発の省力化、仕様と運用監視、品質保証などにメリットがある。
Camel
【参照 URL(外部サイトへリンクします)】
  1. http://sourceforge.jp/projects/cameluserjp/wiki/FrontPage
    日本Apache Camelユーザ会
3.モバイルアプリの母核システムとしてのKnowledgeLine
 あるお客様の業務ニーズで、多数のiPhoneと多数のiPadをクライアントに持つ業務改革が計画された。そこで、KnowledgeLineにXMLインターフェース(API)を作り、KnowledgeLineと連動するモバイルクライアントアプリを開発、運営できるようにした。
 さらに現在は、XML_API+Camelを用いた拡張開発を行えるようになり、モバイルクライアントアプリの開発能力は飛躍的に向上している。

 琉球大学の山田先生、河野先生とのプロジェクト(仮名:ポートフォリオノートシステム)でも、同型式の開発を行ってプロトタイプの開発が進められている(シンポジウム当日デモの予定)。
センバルβ
4.ソフトウエア工学における反復開発
 アジャイルという手法は、計画と結果の因果関係はっきりさせることで、課題や問題を明確化し、目指すソフトウエアの開発を動的に成功させようというアプローチである。
 アジャイルには幾つかの手段があるが、どのような手段をとっても、アジャイルであるからにはフィードバックが良好で、修正が容易に行われるようマネージメントされる必要がある。アジャイルは、管理技術の一体系である。

 KnowledgeLineを用いてのソフトウエア開発は、管理技術を与える。KnowledgeLineがプロジェクトマネージメントツールである理由は、「管理技術(MOT)のための設計・実施」ができる運用環境であるからである。
 KnowledgeLine上にこれから行うべきソフトウエア開発の設計を行うことからスタートする。設計とは体制や方式、手段、そして日程や実績の管理などを定義していくことになる。

 この点においてMSプロジェクトと似ているが、何が違うかと言えば、MSプロジェクトは入力された管理情報しか扱えないが、KnowledgeLineは、成果物であるドキュメント、ソースコード、それらの関係までも管理し運用する。
 最大の挑戦は上流(ドキュメント、意思決定)と下流(実装、テスト、運用)の接続であり、その相互的な追従、アップデートを容易にするというのが、KnowledgeLineの特徴である。
5.経営工学、あるいは組織論
KnowledgeLineで業務を書き下ろすと組織が見えてくる。
組織に対して、WBSとして業務定義を与えると組織の構成、妥当性を評価できる。

そのようなお客様のニーズを紹介する。
ある巨大な企業の一部門、なんと2,000名近い部門。
その統括部長に任命された方が、「ところで、なぜ2,000名必要なのか、解っているのか?」と直下の上位管理職に訪ねた。この質問に即座に答えられないことが、大きな課題となった。
ちょうどKnowledgeLineの導入を検討していたので、試験的に部員一人一人の受け持っている業務を棚卸ししてみたらどうか?という話になった。
もし、2,000名が自分の業務をすべて記述できて、それらを繋いで見て、リソースとして2,000名必要であることが証明されれば良い。記述できることで業務改革も可能になると期待が膨らんだ。

実際にこの取り組みがスタートしたが、20名ぐらいで始めたところで、業務の繋がり、前後がよく解っていないことが散見されてしまった。

KnowledgeLineを経営工学として使ってみたいという感想は、それから何度かチャンスとしてあったが、大きな成果を期待できる反面、実行する勇気は相当に必要である。

※琉球大学情報工学科の山田先生のプロジェクトは、対象が、学生、大学であるが、教育学習の変革として検討されている点では、非常に良く似たケースである。
WBS/PDCAとガントチャート
KnowledgeLineの文書構造のマスタープランは、WBS/PDCAである。
プロジェクト型の業務では、WBS/PDCAがよく利用される。しかし、これがたいへんに難しい作業であることは経験したことがある人ならば、何度やってもうまくいかないと感じているであろう。

NASAは、アポロ計画を推進するにあたり、WBS/PDCAを生み出したと後年語られている。NASAの資料によれば、人間を月に運ぶというプロジェクト業務のWBSは、ロケットの構造を元に作られている。つまり、対象となるものが製造であり、物体であり、そして三次元的な構造体であるときには、WBS/PDCAは管理技術(MOT)としてはとても解りやすく対象となる構造物の設計図と密接に関係する良い手段だある。

しかし、形のないソフトウエアを設計し、製造し、テストすることをWBS/PDCAで行おうとするととても難しい。それでも、全体における部分の関係や、構成管理、さらには、影響の範囲などを織り込むことで、ソフトウエア開発時にWBS/PDCAを機能させることは可能だと考えてきた。

なにより、ガントチャートを上手に使うことである。一般的なガントチャートは、その日の実態を反映することが作業的に厳しい。大抵は計画時に作られて、定められたマイルストーンでアップデートするのだが、致命的な出来事がマイルストーンで解るようでは後の祭りなのである。

 KnowledgeLineが目指したのは、デイリーで更新されるガントチャート。あるお客様との開発で、WBS(PMT)からTODOを作りだし、その実績を記録することで、ガント形式のマスタープランの実績をデイリーで生成、更新することを試してみた。
この結果は、皮肉な結果を突きつけられた。たいていの場合、計画(ガント形式のマスタープラン)に妥当性がないことがすぐに解ってしまう。多くの場合は、希望的計画、あるいはお尻が決まっていることから逆算で描かれている。数億円もの予算を投入して開発される基幹システムのような巨大ITシステムでは、神のような計画を作り出すことはまず不可能である。だが、何か描かれていないとよりどころがないから、全員、妥当性がないことを承知で、計画を握り合う。

経験的に知り得ていることがある。なぜ妥当性がないか、その理由を早期に知れば、対応策を幾つか注入することが出来る。そしてその効果、結果も早く知ることでさらなら対応策を打つことができる。KnowledgeLineが目指しているのは、計画段階の静的なWBSから、実績の元日々更新される動的なWBSへ、そして更新差分をデイリーで分析し、最終的に行程、品質、性能をガントチャートとして集計しえるようになれば、プロジェクトの成功が近い。

KnowledgeLineのビジネス:その1
参考:

KnowledgeLineのビジネスとして、お客様からの要求により、管理要件をアプリケーション化する部分として最も付加価値の高いのが、WBS/PDCAの設計とリアルタイムガントチャートの生成である。
大学ノート、研究ノート
 冒頭に述べたように、KnowledgeLineの生まれ、原型は、自身のための材料探索研究ノートであった。

 化学者は、最初にノートテイキングを学ぶ。実験を行う場合には、参加者、場所、日付、天気、温度、湿度などの天候情報も重要であった。実験では、どんな試薬を使ったのか(メーカ名、純度、購入日)、試薬の調合はどの方法で行ったのか、装置、精度、ことのほか詳しく記載することになる。
 実験計画法は、時にはもっとも重要である。世の中を騒がしたあの事件も、化学者としての作法を守っていれば、もう少し違った展開だったかもしれない。
 (コクヨが、素晴らしい紙の研究ノートを発売されているので参考にされたい)

 私が目指した研究ノートは、形式だった研究ノートよりも、研究としてのブレークスルーのための発想支援、あるいは自己との対話、記録を付ける技術を重視している。このことにより新たな発見へのステップなどに着目したノートシステムを考えてきた。1985年から開発を始めた材料探索研究ノートも、その目的が強かった。

 化学の歴史を紐解く訳ではないが、アモルファスという材料はこの数十年の間に飛躍的に進化した材料物性科学である。結晶構造を持たない不連続体としてのアモルファスは、大昔から存在するガラスとしては良く知られていた。
 最新科学としてのアモルファス材料を研究することになった時に、これまでの伝統的な手法で、コツコツとやるのでは先人達と勝負にならないと考え、自分の考え、実験結果、ベテラン研究者からのアドバイス、書物の知識、手に入れたすべて情報をコンピュータに入力してノートシステムとして記述できることを目指した。さらに結果を統計的に分析できるようにもした。当時は、ノートシステムの中にもう一人の自分が出来ないかと想像もした。
 折しも、1980年後半はAIが流行の兆しを見せ、エキスパートシステムがあれこれ取り上げられていた。私のノートシステムがAI、エキスパートシステムと大きく違った点は、あくまで自分の脳内情報とノートの記述から導かれる、まさに人間の発想能力の向上だった点である。

 今回、琉球大学のお二人の先生方との議論で、新たに山田先生の授業である「プロジェクトデザイン」のノートシステムとして実験が始まることは、私にとっては感慨深い。
 現代の学生は、生まれたときからコンピュータを利用しているのであるから、私の世代とは全く違った発想をするであろうし、ツールとしての発展、アイディアもまた違った世界観で広がるのではないかと期待している。
1992年頃の資料
【参照 URL(外部サイトへリンクします)】
  1. https://www.kokuyo-st.co.jp/stationery/labnote/
    コクヨのリサーチラボノート
【ファイルダウンロード】
  1. [ 青学との大学ノート研究概要.pdf ]
    青学との大学ノートの研究
KnowledgeLineによる大学の研究ノート管理の構想
琉球大学工学部情報工学科

山田先生のプレゼン資料へ
【参照 URL(外部サイトへリンクします)】
  1. http://u111u.info/kdQu
    山田先生の講演資料へ
日産自動車総合研究所時代のノートシステム、THInKS
 私が所属したのは、1989年〜1996年。日産自動車中央研究所、材料研究所であった。総合研究所になり研究プロジェクトセンターに移動した。
 当時、約2,000名が所属して、自動車技術、関連技術など総合技術の集大成である研究機関であった。
 最初に企画したのは、2,000名が日常的にEWSを用いて、研究記録、報告を行うノートシステムであった。ゼロックスのJ-Star、そのソフトであったカードシステムをお手本にした。独自の構造化文書技術を設計して、ノートシステムの骨格を作った。コンセプトは、2,001人目の研究者が存在する!だった。この研究は、日産、富士ゼロックス、ソニー、IBMとの協同プロジェクトになった。基幹ソフトである研究ノートは、日産の永山と富士ゼロックスの黒川氏が担当し、EWSはソニーのNEWS(近藤氏)、IBMはサーバー、ネットワークを担当した(菊間氏)。
初期の構造化文書の設計図
THInKSのロゴ、コンセプトを時間軸を持ったリサーチワークとした
【ファイルダウンロード】
  1. [ 知識のインフラを目指して99.pdf ]
    THInKSの研究がきっかけでソニーCSLに招待された
最新機能
新たに追加された機能を紹介する。
Evernote連携
Evernoteコンテンツとの相互のアップデート
Evernoteを利用する人からの強い要望
LaTexによる数式表現
[mathjax]

\[ \left( \sum_{k=1}^{n} k \right)^2 = \left\{ \frac{n(n+1)}{2} \right\}^2 \]
格納ファイルの全文テキスト検索機能
Apache Tikaを利用したファイル内全文テキスト検索機能

KnowledgeLineにApache Tikaが対応しているファイルを保存すると、テキストが抽出されて、検索用インデックスが生成される。
最新のPostgreSQLの全文検索機能、N-gramなどの要素技術を応用している。
【参照 URL(外部サイトへリンクします)】
  1. http://tika.apache.org/1.6/formats.html
Markdown表記法
汎用的なMarkdownとRedmineのtextileに対応した。
【参照 URL(外部サイトへリンクします)】
  1. http://ja.wikipedia.org/wiki/Markdown#.E8.A6.8B.E5.87.BA.E3.81.97
    Markdown
  2. http://redmine.jp/tech_note/textile/
    2.Redmineのtextile記法への対応
ソースコード表記
[md]

## Cのソースコードの表示例

```c

#include <stdio.h>

int main(void)
{
printf("hello, world\n");
return 0;
}

```

## Markdownでのソースコードの記法 例:C

> (空行)
> \`\`\`c
> int main(void)
>{
> printf("hello, world\n");
> return 0;
>}
> \`\`\`
> (空行)
NoSQL技術の採用
Neo4j、MongoDBの接続、利用
Apache/Camel技術の導入
Googleカレンダーとの連係
とあるプロジェクトからの要望で試験実装した。
プロジェクトのイベントは、公的、私的にかかわらずGoogleカレンダーで共有しているとのこと。
KnowledgeLineを使うに辺り、利用しているGoogleカレンダーの情報をKnowledgeLine内にダウンロードして、展開保持する。
自分の作業、TODOをカレンダーの空き時間にマッピングできないかというもの。
参照資料
レオナルド・ダ・ヴィンチ:マドリッド手稿、岩波書店 1975年
【参照 URL(外部サイトへリンクします)】
  1. http://ja.wikipedia.org/wiki/レオナルド・ダ・ヴィンチ手稿
知力工学:大須賀節雄監修、オーム社 1992年
情報科学辞典:岩波書店
コンピュータ文書管理によって初めて編纂された書
ハイパーテキスト情報整理学:ロバート・E・ホーン著、日経BP
会議力:奥出 直人著、平凡社新書 2003年
【参照 URL(外部サイトへリンクします)】
  1. http://www.amazon.co.jp/会議力-平凡社新書-奥出-直人/dp/4582852009
    会議力
問い合わせ先
株式会社Symphony
代表 永山辰巳
tatsumi@symphonies.co.jp

158-0095
東京都世田谷区瀬田4-14-3
03-5491-8523
【参照 URL(外部サイトへリンクします)】
  1. http://www.symphonies.jp/
    株式会社Symphony