ひびき®Sm@rtDBの生い立ち


◇始まりは「不定形な箱」

Sm@rtDBの前身はCTOの前川が作ったプロトタイプ「INSUITE®ライブラリの強化版としてのWebDB」です。当時のコンセプトは、コンテンツの流通をサポートするために必要な、各種ドキュメント、Webページ、スレッドなどのコンテンツとタグ情報を格納する「不定形な箱」のイメージでした。


◇敢えて設けるべき「壁」

自身での利用以外に、サービスとして他社の構築支援を行われるほどのNotes の“超”ヘビー・ユーザーでいらしたコクヨグループでの移行案件に携わらせていただいたことが、製品としてのSm@rtDBの『誕生』の時でした。

GUIの強化のように、設計者やエンド・ユーザを支えるため『進化させるべき』機能。一方、スクリプトによるプログラミングのように『(メンテナンス性を考慮して、「設定」でできる範囲しか公開しないという)制約を設けておくべき』機能。特に後者はEUC(End User Computing)を極め、数多のDB資産の管理・移行に悩まれたコクヨ様ならではの発想で、私たちにとっては目から鱗が落ちる思いでした。


◇「大規模」情報管理に求められる強さ

エネルギー業界某社様のNotes移行案件では、『大規模』であることの難しさを教えていただきました。第1回ユーザ会のゲスト・スピーカーとしてもご登壇いただいた同社は、業界内でもシステムの積極活用で知られ、当然情報系システムを再構築される上でも、全職員にフル活用され、固有の知識やノウハウを流通・活用する仕組みとして『情報へのアクセスの迅速化』は欠かせない要素でした。大組織で機能するために必要な『筋肉』を一から鍛えていただいたと思っています。

◇アフター・プロジェクト―

“ビジネス・プロセスを成型するエンジンとしてのワークフロー”

実は、この頃Sm@rtDBはまだプロセス・エンジンの機能を備えておらず、時間的な制約もあってパートナー様によってアドオン開発をして対応いただきました。

(エンジニアにとっての悔しさと)反省、そして『組織を超えて文書を「回す」こと、その過程で「ステイタスを変化させる」』ニーズの汎用性を思い、Sm@rtDBは『エンジン』を取り込むことにしました。


◇『実際に動くもの』をベースに進めるメリット―プロジェクト推進の視点

新バージョンの一足早いお披露目の場となったパートナー会(2011年6月実施)において、以前から多くのプロジェクトを通じて協働をさせていただいているパートナー様から、Sm@rtDBを用いてお客様の声を全社の業務改善に還流させるCRMの仕組みの刷新をされたプロジェクトの発表をいただきました。

提案時には専用パッケージとのコンペであり『すでに一通りの機能が備わっている専用パッケージとの一騎打ちはかなり分が悪い』ように見えました。ですが、Sm@rtDBの長所も短所も熟知しておられるパートナー様の見方は異なりました。

一般に、業務システム構築の要件定義にはエンド・ユーザ部門の方が参画されます。しかし、業務知識・経験に比べて「システム的な見方」や「変更後の新たな業務の流れを想定しながら進める」ご経験をお持ちの方はまれです。

これらの方に対して、検討初期からプロトタイプの画面など『実際に動くもの』をお見せして進めることで、操作の違和感や仕様に対する認識の齟齬を早い段階で埋め、手戻りを防ぐことができます。また上流工程を終える頃にはシステムの大枠が出来上がるため、開発期間を圧縮し、仕様の確認に十分な時間を確保することができる。さらに、項目の変更に柔軟に対応することで、実利用の観点からエンド・ユーザのシステム満足度の向上につながる、というのがその評価です。

(スクラッチ開発と比較して)「自由さ・簡単さを手放し、制約への理解・工夫を要するけれど…」との指摘の後に続いたのは、「それでも…DB設計・方式設計などをパッケージに任せ、またプログラミング経験がないSEにも画面設計(フォーム定義)が可能であることから、体制作りの自由度が格段に高まる」。難易度の高いプロジェクトをいくつも成功させた『プロマネとしての経験』に裏打ちされた重い一言でした。


◇「リリース後の進化」という真骨頂

このお客様では、公開されたビュー(一覧画面)の数が、1年間の運用とご要望対応を通じて、次の観点で追加・変更され、運用開始時の1.5倍になったとのことでした。

  • 動的把握:業務の優先度・緊急度を表すステイタスの詳細管理の切り口
  • 傾向分析:データ蓄積されてはじめて見えてきた傾向分析の切り口
  • 操作性:利用する中で感じる操作系の改善

◇進化するベスト・プラクティスを支えるアプリケーション・プラットフォーム

単体で完結する業務への適用が多かったSm@rtDBが、より大きな業務プロセスの一部を担う機会を与えられるようになったのは、ベネッセ・コーポレーション様の「顧客対応業務のアプリケーション開発基盤」に採用が決まり、『基幹系データのリアルタイム連携』を行うための機能を志向してからです。

顧客対応支援などに代表される柔軟なバックオフィス業務の実現のためには、『多様性(動的な制御)』が鍵になります。多くのお客様では『工夫を盛り込んだ数百・数千の「帳票」+運用を熟知したベテランの判断』を駆使して対応されています。

その自由度を阻害せずに、構築後のメンテナンス時にも効率的な仕組み(のひな形)を提供する―その過程で固まってきたのが、v3.0のサブフォーム文書の親子関係クライアントAPIなどの機能です。(詳しくは、3.0の『新機能のご紹介』をご覧ください。)

高いハードルにくじけそうになる私たちを支えてくださったのは、お客様の『どう変わっていきたいか』という理想と『仕組みを継続的に成長させ、使い倒す』という意気込み、そしてSm@rtDBの可能性を見出し、真摯にお客様に向き合うパートナー様の姿勢でした。

業務は環境の変化と、担う方の習熟に応じて変わり、新たな気づきを生むもの。システムもそれに沿って成長するものでありたい―v3.0リリースに寄せて、改めてそう思っています。