[IM] INTER-MediatorでFileMakerを使うときの注意

FileMakerは、テーブル、TO、レイアウトといったオブジェクトを利用する。Web共有からテーブルを直接指定はできない。また、TOも指定できない。指定できるのはレイアウトのみである。レイアウトが事実上のテーブルに相当するエンティティとなる。したがって、定義ファイルのnameキー、viewキー、tableキーには、レイアウト名を指定する。たまたま、同じ名前のテーブルやTOがあっても、FileMakerのWebアクセス時に実際に利用するのはその名前のレイアウトである。

フィールドのタイプで、日時の記録用に「日付」「時刻」「タイムスタンプ」の3つがある。Web経由では、「月/日/年 時:分:秒」のフォーマットにしなければならない。また、日付フィールドに時刻を含む文字列を入力したり、時刻フィールドに日付を含む文字列を入力すると、エラーになり処理は何もなされない。その「日付等の書式エラー」の番号が500なので、余計なことを考えてしまいそうだが、この500はFileMakerが規定したエラー番号である。

[続開発プロセス#10] UIの大枠から機能を検討する

少し間が空きましたが、開発プロセスの中で、まずはUIのモックアップを中心に要求を固めて、そこから設計に入る場合に、まず、データベースのスキーマから入る方法があるというのを説明しました。レイヤー構造で構築する場合、データは低い位置にあるので先に決めるという点に意義はないとは思いますが、一方で、あらゆる状況を加味したデータベース設計ができるのかという問題もあります。ですが、ここでは先に決めるという流れでプロセスを追っています。

データベース設計ができれば、そこに対してどんな仕組みをかぶせることで動くアプリケーションができるのかということを考えます。UIの設計から、まずは目に見える機能を取り出し、それをどのように構成するのが良いのかを考えます。ここで、「機能の一覧」を書き出すことが1つの方針としてはあり得るのですが、その機能をある程度分類しないと、構成が定まりません。そこで、メモのページ全体をMemoPoageとして、それらが、メモ一覧を示すMemoListと、左側のカテゴリ一覧を示すPickingUpの2つのクラスのコンポジションであるという見方をします。まず、目に見える範囲を狭めて、開発単位となるブロックを見つけるということです。ここで、一覧だと、1行のコンポーネントが複数あるようなことを示さないといけないのかと言えば、これは経験則的には不要だと考えます。ここで「リスト」と言ってしまうことで自明だからです。言い換えれば、1行の要素が繰り返されるということ自体は、そのクラスが持っているという見方をして、過剰に細かくは書かない方が設計は素直で読みやすくなるということです。データベースのテーブルを記述する場合に、クラス図では1つのボックスしか書かないのと同じ理由です。しかしながら、何らかの定義はどこかにあるわけですので、その点も書きたい場合はメモを追加するか、あるいはクラス名の意味をどこかに記載すればいいでしょう。なお、このようなクラス図からオブジェクトを図を想像できるかどうかということは、ダイアグラムの理解には重要なポイントであることは間違いないのですが、設計上どうすればいいかを詳細に決めると多分面倒なだけになりますし、大雑把にするとチーム内でコミュニケーションが中途半端になる可能性があります。機会があればこれは検討したいテーマです。こうして作成したのが以下のクラス図です。

緑色の3つのボックスがUIのブロックを1つのクラスとして記述したものです。中身は、ボタンや編集など、ほぼ、ページ上でのイベントに対応するもの、そしてそのリスト自体を生成するためのものが記載されているだけなので、細かくは説明しません。それぞれ、どのテーブルを利用するかで2つのテーブルに線を引きました。また、MemoListは、ページネーションと日付時刻のピッカーを、別に用意されているUIのコンポーネントを使うことにします。ここでは、MemoList上にある要素とは別のもの(ここでのページネーション)や、要素の動作を補助する必要があるものを(ここでの日付時刻ピッカー)抽出します。ただ、このUI Componentsは、実装先によって実態は異なると思われます。ここではまだ実装を加味しないということで進めてきましたが、実際にはこのように実装先の状況が徐々に現れることになります。プロセス的にはまず設計をして、実装に関わることを検討しようということを書いていますが、線引きは明確にはできないと思います。ここで重要なことは要素として抽出しながらも、一定の範囲で実装を意識したという点をメモにするか、きちんと意識しておくことです。

ここまでの設計の図を見る限りは、明白にレイヤー構造です。このような簡単なアプリケーションなら、もう実装は簡単にできると言っても良いでしょう。手慣れた方ならここまで図にしなくても、頭の中で設計ができてしまっており、自身の知識を持ってすればすぐに実装の作業ができるはずです。こういう状態を「スキルがある」ということになるかと思います。そのような状態の効率良さは当然ながらあるわけで、その結果「設計は不要」という考えにもつながるでしょう。設計不要論については今回は扱わないつもりですが、設計の行為を体系的に記述するため、ここで終わらずにさらに設計の検討を進めるのが一連の記事の目的です。よって、まだ続きます。次は、実装環境の制約を加味した設計を作っていきます。

SELinuxを避けずにINTER-Mediatorの稼働ができた

CentOSはSELinuxが既定値で機能しており、ちょっとしたことでも阻止されます。例えば、Apacheのドキュメントルートを/var/www/htmlとは異なる場所に設定したい場合、Apacheの設定以外にSELinuxでの許可を得る必要があります。セキュリティは重要とわかっていても、「ちょっと試す程度だしいいか」ということで、SELinuxの機能をオフにしてのその場しのぎはきっと世界的に普通に行われていると思います。SELinuxでググって見れば、オフにする方法のサイトばっかり出てきます。

実は最近、ある場所で、LinuxをセットアップしてWebアプリを納品することがあったのでした。INTER-Mediatorではなく、スクラッチから作っているWebアプリですが、コマンド呼び出しなどを多用するもので、SELinuxでの運用をまずは目指したものの、ちょっと行き詰まったのでした。そこでどうするか? 恐る恐る、SELinuxはなしでいいかを聞いたら、あっさりOKだったのです。セットアップ時に忘れないように切らないとと思っていたら、最初からオフだったし、Firewallは完全オフだったりと、清々しいVMだったりして、もしかして、世間的にはそんな感じなのか?とも思いつつ、ちょっと安心したりしました。

しかしながら、『INTER-MediatorはSELinuxでは動かない』となってしまうのも良くないので、サンプルの多くが稼働できる状態まで可能なポリシーファイルを作成して、レポジトリに掲載するところまでができました。その記録を書きますが、私自身はSELinuxの全貌を理解しているわけではなく、むしろほんの一部しか理解していません。実際のアプリケーションを動かすためのプラクティス的な情報しかありませんが、SELinuxで悩んでいる人や、将来のINTER-Mediatorのメンテナンスのためにブログを書いておきます。ちなみに、以下の作業は「 sudo yum install policycoreutils-python」でパッケージを1つ追加しないとコマンドが使えません。

SELinuxは、非常に大量の設定があるというのはまずは知るべき事実でしょう。最初に書いたように、ドキュメントルールが/var/www/htmlであるという定義があり、別の場所をルートにしようとしたら、この制約をオフにするか、別の場所に許可を与えるなどの処置が必要になります。OSやサーバー等の至る所に設定がなされており、全体像を把握するのはまず無理と思われます。設定ポイントというか、1つ1つの制約機能には、階層的に名前がつけられていて、場合によってはそれを読み解く必要もあるかもしれませんが、その方法は別のブログ等に委ねます。まずは、大量の設定があって多くは「禁止」状態になっており、必要なものを「許可」するというファイアウォール的な作業が必要であるということを理解しておく必要があります。

そこで、SELinuxの世界では、Boolean値と呼ばれれる定義定数があり、個別の設定よりも、もう少し粒度が荒いレベルでの許可を、論理値なので簡単に設定できるようにすることを意図した仕組みがあります。PHPのクラス等でメールを送りたいのなら、「sudo setsebool -P httpd_can_sendmail 1」コマンドを入れます。httpd_can_sendmailというのが既定値の論理値変数で、この値が1なら「許可」となります。通常はこの値は0になっていてメール送信は禁止されていますが、このコマンドを入れればメールを送信できるようになるという具合です。なるほど、それじゃあ、変数を探せば…と最初に考えるわけですが、変数が多すぎて訳がわかりません。変数名から「Webサーバーの」などと言った情報はあるので、頑張って読めばいいかと思いましたが、あまりに多過ぎて諦めました。ググっても「この変数です」というのが全ての場合では分かるまでには至りません。この方法は、簡易的に対応可能な場合だけに限るようです。

次に目をつけたのは、SELinuxでのログ(/var/log/audit/audit.log)を元に、禁止していることを許可するような設定を自動的に取り出してくれるという方法です。方法はいろいろ取れると思いますが、アプリケーションをインストールして、いろいろな作業を行い、そこで禁止されたことを拾い出すという仕組みが用意されているのです。「sudo audit2allow -a」のようにすれば、ログから得られた禁止情報を元に、許可すべき項目などを画面で見えるのですが、「sudo audit2allow -a -M ファイル」とすれば、カレントディレクトリに「ファイル.te」と「ファイル.pp」の2つのファイルを作ります。これらのファイルには、禁止された項目を許可するための設定記述が入っています。そして、「sudo semodule -i ファイル.pp」により、収集した許可設定をシステムに与えることができます。.teファイルが人間が読めるもので、それをコンパイルしたものが.ppファイルです。ちなみに、.teはテキストの略ではなく「Types Enforcement」の略だそうです。.ppは「Policy Package」です。つまり、audit2allowにより、禁止されたポリシーを許可する設定を作るということになります。自分で.teを編集して.ppを生成することもできるのですが、ほぼ、操作をした結果で必要な許可のための記述は得られるようで、操作、audit2allow、semoduleをひたすら繰り返し、エラーが出ないような状態になるまで地道に繰り返しました。また、アプリケーションをいくつか変えるなどして、なるべく多くの機能をカバーできるようにしました。本当はこれもきちんとプランをした方が良いのでしょうけど、まずは完全なものではなく実用になるものと思って手作業を進めました。なお、audit2allowでファイルは更新されますが、元のログファイルが同じであれば、以前に生成された定義は常に入ることになるので、同じファイルに気にしないで何度も定義の生成をしても構いません。

audit2allowでは、論理値変数についての情報も得られるのですが、生成された.ppファイルをsemoduleコマンドで取り込むことで、論理値変数の設定は特にはしなくても良いようです。いくつかのサイトを見ながら作業を進めたのですが、「setenforce 0」でSELinuxをPermissiveモードにして、監査とログ投入は行うのだけども、エラーとしないで実施可能な状態にして、ログに溜め込み一気に.te/.ppファイルを作るという方法が紹介されていました。なるほど。ただ、今回は、どんな風に「動かない状態」が発生するかを確認することもあって、1つ1つやっていきました。

ただ、SELinuxの設定の中にはログを残さないというタイプのものもあるようで、実際、いろいろやっているとそういうのに引っかかったようです。そこで「sudo semodule -DB」と入力することで、全ての監査結果がログに残るようになります。このコマンドを入れないと、収集漏れが発生していたということです。INTER-Mediatorのレポジトリで、dist-docs/selinuxディレクトリに生成したファイルを入れてあります。

もちろん、単に許可するとだけだと、セキュリティ的に甘くなるのではないかということも十分に考えられます。ポートを開くと言っても、決められたポートだけにしたいというセキュリティ上の要求はあるでしょう。それをSELinuxで賄うことで、INTER-Mediatorで作るWebアプリ以外での制限はしやすくなるものの、自動生成したポリシー設定からさらに難易度は上がりそうです。SELinuxを無効化するよりも遥かにましだということで納得しようと思います。

参考にしたサイトは以下の通りです。ありがとうございます。こちらの方が、本稿よりも詳細な情報が得られます。

[続開発プロセス#9] データベースの設計から入る

前回までに、サンプルとして作るメモアプリケーションと、その要求項目をまとめました。本来は、そこから「要件定義」をするところかもしれませんが、要求+UIデザインがあれば、基本的には要件と呼ばれる項目もピックアップされていると考えて、今回はシンプルなアプリケーションでもあるので、割愛します。ここから分担して作業するような場合には確かに要件定義も必要かもしれませんが、ここで紹介しているアプリケーションだと表現の違い程度のものしかありませんので、文書化する手間を省きます。

実際に作成するものが決まって来れば、全体の機能からだんだんと詳細化する様な方法がまず1つあります。これに対して、まずはデータベースのスキーマを確定させ、ドメインをデータベースの中に実現することを優先する方法もあります。複雑なアプリケーションの場合は前者のように、機能を分析して、どういう構成をするのかということを先に考え、並行してデータベースの設計をするのが良いと思われます。一方、シンプルなものは、データベースをまずは設計して、UIとDBの間をどのように埋めるのかということを考える方が効率が良いと思われます。ということで、今回は、まずはER図レベルのものを作ることにします。要求項目等から、以下のようなER図あるいはクラス図を作成しました。

前者はER図、後者クラス図です。ここでは、どんなテーブルがあって、どんなフィールドがあって、関連付けをどう行うかということが記載されていればいいので、どちらの図でも大きな違いはないと思います。見ての通りAstah*を使っているので、どちらかと言えば、クラス図の方が自由度が高いこともあって、私は通常はクラス図で記述します。クラス図では付加的な情報はステレオタイプを活用することで、ちょっと見慣れるのに時間がかかるかもしれませんが、記述は可能なので、そうした仕組みを用意しています。

要するに、メモとカテゴリの2つのテーブルがあるということです。メモに日付時刻のdtフィールド、メモのmemoフィールドがあるのはいいとして、2レベルのカテゴリ設定のために、2つの外部キーフィールドtop_category_id、sub_category_idを用意して、カテゴリつまりcategoryテーブルのcategory_idフィールドに関連づけています。カテゴリは、目に見えるデータはcategory_nameだけですが、階層化の管理をここではテーブル内に持たせることにします。本来は、カテゴリとカテゴリ間の関連を別々のテーブルで表現するのが役割を分離した設計になるかもしれません。ですが、2レベルということで、主キーとなるcategory_idと、自分の上位のカテゴリを示すparent_category_idのフィールドを用いるだけで概ね問題ないと判断して、このようにしました。parent_category_idがNULLであれば大分類、category_idに存在する値があれば小分類とすることができ簡便です。もちろん、1つの小分類項目は、1つの大分類項目にだけ所属できるので、完全にツリー状の構造になるでしょう。前回のUIサンプルのカテゴリ一覧(ページ左側)にあるような大分類、小分類の構成にするには、例えばテーブルのデータは次のようになります。

category_idparent_category_idcategory_name
1仕事
2ホーム
3趣味
41毎日
51レポート
61進行中
71気付き
82レジャー
92学校行事

本来、こうした状態をキープするためには、カテゴリの修正ページはそこそこ複雑になります。もちろん、名前を書き直すのは容易ではありますが、大分類を消した時、小分類も一緒に消すのかどうか、あるいは残すのか。また、それぞれの分類を消した場合、その分離を設定しているメモの方はどのような扱いにするかなど、検討事項はいろいろありますが、今回の設計例ではこれも省略します。ちょっと省略しすぎかもしれませんが、お許しください。

メモを一覧表示する部分はあまり難しさはないと考えますが、結果的に残るのは、分類のリストからの検索と、新規入力時に大分類と小分類のポップアップメニューがあることです。後者は、大分類と選択すると、それに所属する小分類のポップアップメニューに更新しなければなりません。しかし、この段階では、まず、そうした具体的に実装されるべき機能を把握することに進みます。

Chart.jsのチャートのサイズ増加が止まらん!

Chart.js v2.5使ってます。久しぶりに開いたページの中にChart.jsによるレーダーチャートがあるのですが、描画後、チャートがビヨーン、ビヨーンとサイズがデカくなるのでした。以前はそんなことはなかったはず、なんでやねん! 変なプログラムを書いてしまったか?と思ったけど、そうではない。デバッガを見ていると、canvasのwidthとheight属性が、すごいスピードで+1ずつインクリメントしているのです。durationの値は0にしている。そこに100とか数字を入れても同じだったので、これの問題ではないということですね。かなりあれこれ探したら、なんと、公式ドキュメントに書いてあるじゃないですか。「canvasのコンテナはposition: relativeにしなさい」ということで、なんとか、ビヨーンはなくなりました。しかし、もう、画面に何も表示されないくらい、チャートがデカくなっていくのは悲しい画面でしかないですね。ということで、Chart.jsのcanvasは、divなどで囲ってください。

[続開発プロセス#8] 設計作業の実例(ドメイン分析とUI設計)

ここからは開発プロセスに従って、実際にどのように設計を進められるかを検証しながら、問題点やポイントを把握して行くことにします。サンプル開発のテーマですが、あまり難しすぎると把握が大変で、プロセスそのものとは関係ない情報を大量に捌くことになりかねないので、なるべくシンプルなものにしました。テーマは「1行メモ」です。もちろん、ものすごく簡単なので、すぐに作れるという方は多いとは思います。とはいえ、小さな開発でも突き詰めればきりがありません。要求をしっかり掘り下げるといくらでも細かな点は抽出できます。過剰に複雑にならないように、とは言え、ステークホルダーの要求に答えるというプロセスを考えるためには、一見するとすごく簡単なテーマがいいのではないかと思います。

以下、まずはINTER-Mediatorで構築することを中心に考えます。モックアップも、INTER-Mediatorを使って作りますが、データベース定義などしないで、モックは単に見栄えのチェックのためのものだけを作ります。

まずは、最初の要求が発生するとして、次のように要求が出てきたとします。

  • [R1] 1行メモを複数記録でき、一覧で見ることができる
  • [R2] メモ作成あるいは変更時の日時を記録することができる
  • [R3] 1つ1つのメモは、大分類と小分類を設定することができる
  • [R4] それぞれの分類は、予め定義されたものから選択するようにできる
  • [R5] 小分類の項目は1つの大分類項目に所属する形式にする(大分類と小分類は階層的な関係になっている)
  • [RX-1] 利用者、1人1人の1行メモを管理でき、他人のメモを見たり修正できたりはしない
  • [RX-2] 大分類、小分類の項目を編集する機能が必要

項目にコードを割り振っています。RはRequirementのつもりですが、RXの番号があるものは、要求としてはあるけども、設計作業を単純にするために、以後は無視するものとします。思いつく全ての要求を入れてしまうと、プロセスよりも状況の把握の方が膨大な情報量になるので、その点はご容赦ください。もちろん、無視した要求が重要なこともあるかと思いますが、ここでは、プロセスを通すことをまずは説明したいと思います。

上記のような要求がある場合、ざっくりとモックアップを作ってみるとこんな感じでしょうか? INTER-Mediatorを読み込んでいるので、テーマが適用されていますが、あとは単にinputやselectタグを適当に並べているだけで、特にデータベース処理などはしていません。要するに、tableタグにtrタグが3つ含まれていて、「複数のメモがある」感じを出しているだけです。

こういうのを作ると、もう、ここでいろんな要求が増えてきます。ちなみに、「メモ」あるいは「リマインダー」って、多くの人は「いいアプリがない」とお悩みなようで、どうやら、一人一人が要求するスペックが多岐に渡っていて、落とし所が見つかりにくいテーマなようです。ということで、以下、要求が出てくるとは言っても私の好みという色彩は強いので、メモアプリケーションとして評価はしないでください。あくまで、プロセスとしてこういう流れがありうるのかどうかということです。以下のような要求が追加されました。

  • [R6] 一覧に表示するメモは、分類に応じて絞り込みができるようにする。
  • [R7] 分類に関係なく全部のメモを表示したい。
  • [R8] メモがたくさん出てくる可能性がある。だとしたら、10ずつ表示するなど、ページネーションが必要になる。
  • [R9] 日付の入力はキータイプだけではなく、JavaScriptのコンポーネントを利用したい。

これらを含めたモックアップとして、次のように発展させたとします。絞り込みのため、左側に分類名のボタンを用意します。ページネーションは「とりあえず配置する」ということを示す赤い文字列を示すに留めています。一定以上の労力がかかる作り込みは、モックアップでは避けた方が良いでしょう。その代わり、例えば、このように赤字でコメントを書くということを行うことで、コミュニケーションを図ります。

この辺りまで進んでくると、おそらくディテールについて、いろいろな意見が飛び交うでしょう。まず、前の図だと、分類やメモそのものはテキストフィールドにありますが、最初に書き込んだ文言から変更しないことが多いのだから、テキストフィールドである必要はないと言えます。また、文字数が長くなると、欠ける可能性もあるので、メモの一覧には編集機能を付けないのがいいのではないかということになります。

であれば、入力や編集はどうするか? 1つの方法としては、以下の図にあるように、メモの一覧の下などに、メモの入力用エリアを設けて、ここで最初の入力ができるようにすることになるでしょう。他にも方法がありそうですが、ここでは別領域を設けることで合意したとします。

  • [R10] メモの一覧は、表示のみにする
  • [R11] 新しいメモを入力するためのUIを、一覧とは別に用意するタイプにする

左側の絞り込みを見てみると、小分類での絞り込みはできそうですが、指定した大分類だけの絞り込みもしたいのではないかということになりました。要求についてはR6が詳細化されたとみることができるでしょう。

  • [R6-m1] 一覧に表示するメモは、分類に応じて絞り込みができるようにする。この時、小分類だけでなく、大分類を指定しての絞り込みができるようにする

入力と表示を分けましたが、このままでは、メモの編集ができません。書き損じた場合はどうするのということもありますし、分類を変えたい場合も手段がありません。要するに、CRUDの考慮が必要になるということになりました。項目の削除は、一覧に「削除」ボタンを作る。そして、項目の内容を変更することは、どちらかと言えば主要な操作ではないので、リストをクリックするか、あるいはボタンを押すなどの方法で、別のページに遷移して修正ができるようにしようということになりました。ただし、この別ページ部分は今回の流れでは追わないことにしましょう。

  • [R12] 一覧にあるメモを「削除」ボタンで削除できるようにする
  • [RX-3] 既存のメモの内容を変更するための編集ページを用意し、遷移して修正できるようにする

他にはどうでしょうか? リストや分類項目の並べ方が確定していません。これについてもやはりいろいろな意見があるでしょうが、次のようにしましょう。

  • [R-13] メモの一覧では、作成修正日時の逆順で表示する。
  • [RX-4] 絞り込みの部分での項目の順序は、分類項目の編集時に指定できるようにする。

ちょっとしたアプリケーションのつもりでも、結構、項目は出てくるものです。ここまでのところでは、要求に関して、UI設計を進めることで、要求に不足する情報を補うことを意図した作業を進めてみました。メモについてはドメインと呼べるほどの知識はないのかもしれませんが、アプリケーションによってはそのドメイン部分の理解を何かの方法で進めながら、要求とUIの部分を進めました。次回は続いて、要件定義からモデル化を進める部分に進みましょう。

設計作業のサンプルで用いたファイルは、こちらで共有します。

今現在のINTER-Mediatorのポジション

INTER-Mediatorは「少ない作業でデータベース連動Webアプリケーションを開発できるフレームワーク」と説明してきました。しかし、この文章の中にある言葉の意味も、10年も経過するとかなり違ってきているということに気付き、現状をどう説明すれば良いかを考えてみました。

まず、システム開発をする時に、どんな手段あるいは手法を取るかということについて、いろいろな軸はありますが、コアとなる素材の選択は重要な作業です。スクラッチからの開発、あるいはサービスを使って事実上は開発しないという両極端の間にいくつか段階があると言えます。

軸に並べているのは、隣同士は近い関係にあり、中間的なものもありうるだろうということが考えられるからです。ただ、距離については正確ではないでしょう。この軸は、順序尺度と比例尺度の中間的なものを想定しています。それぞれのポイントは次のように定義してみました。

名称説明
スクラッチ開発多くの部分を独自にプログラムを記述するなどして開発される形態。今時は、純粋にスクラッチなものは少ないかもしれない。
フレームワークフレームワークを利用して、その上でシステムを拘置する形態。ネイティブ系であればOSに用意されたフレームワークを使うことが多いが、Webだと多数のフレームワークがあり、何を使うかを最初に検討することになる。
カスタマイズ基本的な機能が揃っている環境をベースに開発を行う。ページ要素などは用意されていて部品のように使ってページを作るなどの仕組みを持つもので、主として汎用的な用途の機能が提供されている。具体的にはFileMakerやKintoneなどがこれに相当する。
ソリューション(利用)一般的によく行われる業務のシステムが概ね構築されており、カスタマイズ等の手法で利用者の要求にマッチさせるようなシステム開発の形態。カスタマイズの仕組みは容易にできる点が特徴ものから、開発言語によるものまで様々ある。salesforce、ServcieNowなどがこれに相当する。
サービス利用すでにサービスが起動しており、開発作業なしに簡単な設定だけで業務が進められるようになる形態。業務が法令に則っているような場合などは、十分に実用的なサービス設計ができる。freeeなどがこれに相当する。

この軸上で、INTER-Mediatorは、フレームワークが中心になりますが、カスタマイズという側面と、スクラッチ開発の側面に広がるものと考えています。よく、INTER-MediatorとKintoneの違いはどこなんだと聞かれることがありますが、INTER-Mediatorは中心はフレームワークであるということであり、Kintoneはカスタマイズ開発向けであるということになります。

なお、これらの分類は新規開発という状況での検討事項ではありますが、図中に示したように、開発後にメンテナンス開発をかける時には、開発物そのものが仮にスクラッチであっても「カスタマイズ」で対応可能という状況や、フレームワーク的に使ってかなり作り替えるとか、ソリューションとしてプロダクトライン的に使うなどの側面でも評価できると思いますが、この記事ではメンテナナス開発については詳しくは取りあげません。最後に少し記述があります。

この軸に沿った分類をした時、現実にどの程度のソリューションが作られたかを想定してみました。もちろん、きちんととした統計を取ったわけではありません。想定していない分類の統計は取れないので、情報もないですが、ここではイメージで図を作成してみました。線の曲がり具合などは異論はあるかもしれませんが、言いたいことは、スクラッチ開発は相対的に減り、フレームワークを使ったような開発も減ってないとしても相対的には減り気味、一方でカスタマイズやソリューション、サービス利用は年々増えているという傾向があると考えられます。

サービス利用やソリューションの比率が上がるということは、一般的な業務や、法令で決められたような業務については、その領域での開発で済んでしまうということに他なりません。そうなると、INTER-Mediatorやその他のフレームワークは居場所がなくなるのでしょうか? これはそうではありません。むしろ、サービスやソリューションで解決できない領域の業務システムを中心に据えるべきでしょう。その会社、あるいはその部署で独自に行うような業務をシステム化して効率を高めることは、競争力の原動力になるのは古くから言われている話です。開発対象の特性を考えて、向き不向きを考える必要があり、軸の右の方は、そうした一般的でない業務や、あるいはサービスやソリューションそのものの開発素材という方向性を意識すべきです。

では、カスタマイズはどうなるかと言うと、これは相対的には広がっていると思われますが、ほとんどの製品がベンダーロックインがかかってしまう点があって、「減らない」だけなのではないかとも考えられます。しかしながら、ソリューションが進展すると、ベンダーロックインはもう関係ないことになりそうですし、より標準的に業務を進める方向へと流れるとしたら、カスタマイズから左に向かう流れはなかなか止められません。結果的にカスタマイズ各社も「すぐに使えるアプリケーションがあります」的なプロモーションを展開することになります。

INTER-Mediatorは、フレームワークを軸足にしたカスタマイズ性を持つ開発素材であると言うことになりますが、そこからは広がらないのでしょうか? そんなことはないと思います。例えば、クラウドで簡単に使えるサービスや、あるいは開発ツール的なものを組み合わせれば、カスタマイズ領域に展開できると考えられます。また、ソリューションを作ってしまって、それを素材としたビジネスも考えられます。そう言う意味では、すでに存在するINTER-Mediatorは、軸の左方向へは展開可能です。ただ、現状、数人のコミッターの状況ではそこまでできないので、コア機能の充実にフォーカスしているわけです。

いずれにしても、ソリューション、カスタマイズ、フレームワークの領域の製品は、いろいろなメリットがありますが、開発が楽になる的な表現がよくされますけど、本質は「改変が楽」と言う点にあります。つまり、メンテナンスしやすいと言う方向性を持ちます。その特性を行かせるのは、やはり「過去に作ったことがない」ようなシステムでしょう。作って検証し、そしてさらに開発を続けると言う枠組みにうまく入れる製品が望まれると言えます。もちろん、これは、既存ソリューションの改造でも同じことは言えます。そのような点でのコミュニケーションが重要であると言うことも、以上の考察から得られる結論です。

INTER-Mediatorは「少ない作業でデータベース連動Webアプリケーションを開発・改変できるフレームワーク」と説明するのは変わりないとして(最初からちょっと変わっていますが)、ここでの考察を組み込んだスローガンを考えないといけません。これは宿題ということで、お許しください。

[続開発プロセス#7] ここまでのビッグピクチャー

ここまでに説明したことを図解してみます。以下の通りです。要するに「通常の開発」とさほどの違いはありません。UI設計を独立させていることと、実装設計モデルという考え方が入っているだけです。

ちなみに、「こんなにたくさんのドキュメントを作れというのか?」という気になるかもしれませんが、メリハリは付けるべきであるし、開発のイテレーションでは更新しないというドキュメントも出てくるかもしれません。むしろ、どの成果物に力を入れるべきかを考えながら、さらにこれから深掘りしようと思います。

そういうわけで、皆さん、良いお年を!

[続開発プロセス#6] 実装部分の設計の大まかな方針

開発においては要求が最初に何らかの方法で記述される前提で話を進めます。前回のポストでは、要求から具体的な機能や必要なデータベース設計を検討するために、UIの設計を進めることを説明しました。制約された状況(フレームワークや開発ツールを適用した開発)では、UI開発がいろいろな意味で容易にできる状況が用意されているので、UIの設計はプロトタイプを開発したり、あるいはモックアップを作ることで、エンドユーザーによる確認ができることを示しました。そのUI設計や元になっている要求定義をもとにして、どのような仕組みが必要かをさらに検討できます。もちろん、機能や非機能という言い方もできるでしょうし、要件定義という言い方もできますが、UI設計によるビジュアルな側面の具体化とは別方向に、実装すべき機能を抽出するための設計のプロセスが必要です。もちろん、ここでも制約された状況において適用可能な方法を考えて行きます。なお、具体的なモデリング例などは追々紹介するので、まずは全体像を示します。

まず、一般には、要求定義などの初期段階で得られる情報を元にして、ビジネスモデルやあるいはドメインモデルと呼ばれるモデルが作られます。最初に作成できるモデルは、システム境界は曖昧か決まっていない状態のもので、システムを取り巻く業務全体がどのような要素とそれらの関連性を持つのかということを記述するものです。一般にはクラス図で書かれるものが多いと思われます。この段階では、対象とするビジネスドメインを整理し、理解するためのモデルとなります。また、その業務領域における概念を整理し、特定し、名前を確認する(あるいは名前を付ける)ということを行います。なお、用語としてのビジネスモデルは、別の意味にも捉えられるているので、この最初のモデルを「ドメインモデル」と呼ぶことにします。

ドメインモデルにおいては、「どうやって実装するか」ということをなるべく排除する方が良いでしょう。一番の目的は、業務全体をモデルとしてどのように今現在捉えられているかということを理解するためのモデルであるからです。開発者がどうしたいのかということはなく、あくまで、現状のスケッチであり、顧客が考えるシステムを取り巻くビジネス環境を表現したものです。用語については、極力、顧客が使っている用語を使うべきで、ここで用語の整理はまずしない方が良いでしょう。顧客が使っている帳票などから読み取る作業を通じて、1つのまとまった対象が何か、それらがどのような順序で登場し消えていくのか、そして、何を手がかりにその対象が結びついているのかなどをモデル化します。ここで、若干の矛盾点があってもモデルとし、その疑問点はメモ等で残し、どこかで解決を図ることにします。矛盾点は整理せず、現状やプランに矛盾と思われる箇所がある点をモデルとして表現することが肝心です。

この作業は、要求を抽出した段階でもできますが、UI設計の結果を反映させることまでは考えなくても良いでしょう。要求やそのための調査の結果を整理するという目的のためであって、このドメインモデルは最終的な着地点ではありません。UI設計に基づく結果は、実装のための設計にステップは進んでいるので、初期段階での理解をするためのドメインモデルは、要求を元にして作成することにします。

ドメインモデルやUI設計、そして要求を元にした要件定義、あるいは機能や非機能の整理をした結果が得られます。これを元に、具体的な設計を進めます。UI設計を行った結果、まず、システム境界はかなりはっきりするはずです。要求としていろいろ出ているとしても、対象とするシステム外部のことは、設計には含める必要はありません。ただ、別のシステムとして将来実現するというようなことがあれば、要求の記述を改めてそれを設計に含めるということになります。

具体的な設計とは、例えば、データベースのスキーマ(ER図)や、実装につなげるためのクラス図、シーケンス図、コミュニケーション図などで作成することになります。この段階のモデルは一般には「設計モデル」と呼ばれます。ここで、設計モデルは、開発環境の制約を考慮しないものをまずは作成します。最初から制約を考慮するのは手間もかかるし、また、様々な考慮すべきことや解決のための発想を阻害する可能性があります。つまり、まずは一般的な設計を目指すということです。データベース主体の設計では、ER図に相当する設計だけで済ませるかもしれませんが、プログラムを記述するような場合はコントローラに相当する部分の機能の抽出とモデリングもきちんと行うべきです。この段階では、デザインパターンやアーキテクチャパターンなどの様々なテクニックを駆使することも必要になります。

こうして設計モデルが確定が近くなると、実際に開発で利用する状況に合わせた設計モデルへと変化させます。このモデルを「実装設計モデル」と呼ぶことにします。設計モデルに対して、制約を適用したモデルへと発展させて作ります。例えば、モデルやコントロールのクラスを継承するような場合、詳細な設計が必要なのはコントロールそのものではなく、継承して追加する部分だけになります。設計モデルでは「必要な機能を持ったコントロール」が、実装設計モデルではフレームワークが提供する部分はむしろ割愛し「実装作業が必要な部分の記述に絞ったコントロール」として定義し、既存のクラスから単に継承等で記載するだけにします。もちろん、そうすることで、実装の作業をスムーズにすることを意図しています。FileMakerの場合は、ER図を記載した上で、リレーションシップに記述するオカレンスの図に発展させるのが、設計モデルと実装設計モデルの違いになります。いずれの場合でも、開発環境に合わせたパターンなどの設計ノウハウの適用が必要になります。この領域でのノウハウは、ともすると長年のノウハウといった俗人的な対応がよく見られますが、汎用的な開発と同様、パターン集の充実など、環境に合わせた開発ノウハウの標準化をしておくことで、スムーズに実装設計モデルを構築できるでしょう。

このように、設計においては、ドメインモデル→設計モデル→実装設計モデルといった段階を踏むことで、設計を進め、制約された状況でのモデルを構築することを提唱します。特に、設計段階で、どこで制約を適用するかということについては、設計の後の段階で行うがポイントになります。言い換えれば、ツールや環境を考えずに、まずは汎用的な設計をした上で、その設計を実際の環境に適合させることにより、ツールや環境ありきの限定された実装を避けることを意図しています。どの段階でも、モデルに落とし込むテクニックとしてはパターンがまずは挙げられますが、実装設計モデルへのパターンについてはなかなか用意されていないのが実情であり、そのパターン化を意識しながら作業することにもなるかもしれません。そして、ここで本当に欲しいのは最後の実装設計モデルであるとも言えるので、そうなれば設計モデル自体は時間をかけて仕上げるのではなく、不足がないようにすることを心がけてあまり詳細化しすぎない程度で終わらせておき、実装設計モデルに必要な部分だけの詳細化を進めると言った効率的な作業の段取りも考えられます。