Talk about computer, network and how we should work.
Chart.js v2.5使ってます。久しぶりに開いたページの中にChart.jsによるレーダーチャートがあるのですが、描画後、チャートがビヨーン、ビヨーンとサイズがデカくなるのでした。以前はそんなことはなかったはず、なんでやねん！ 変なプログラムを書いてしまったか？と思ったけど、そうではない。デバッガを見ていると、canvasのwidthとheight属性が、すごいスピードで+1ずつインクリメントしているのです。durationの値は0にしている。そこに100とか数字を入れても同じだったので、これの問題ではないということですね。かなりあれこれ探したら、なんと、公式ドキュメントに書いてあるじゃないですか。「canvasのコンテナはposition: relativeにしなさい」ということで、なんとか、ビヨーンはなくなりました。しかし、もう、画面に何も表示されないくらい、チャートがデカくなっていくのは悲しい画面でしかないですね。ということで、Chart.jsのcanvasは、divなどで囲ってください。
ここからは開発プロセスに従って、実際にどのように設計を進められるかを検証しながら、問題点やポイントを把握して行くことにします。サンプル開発のテーマですが、あまり難しすぎると把握が大変で、プロセスそのものとは関係ない情報を大量に捌くことになりかねないので、なるべくシンプルなものにしました。テーマは「1行メモ」です。もちろん、ものすごく簡単なので、すぐに作れるという方は多いとは思います。とはいえ、小さな開発でも突き詰めればきりがありません。要求をしっかり掘り下げるといくらでも細かな点は抽出できます。過剰に複雑にならないように、とは言え、ステークホルダーの要求に答えるというプロセスを考えるためには、一見するとすごく簡単なテーマがいいのではないかと思います。
以下、まずはINTER-Mediatorで構築することを中心に考えます。モックアップも、INTER-Mediatorを使って作りますが、データベース定義などしないで、モックは単に見栄えのチェックのためのものだけを作ります。
まずは、最初の要求が発生するとして、次のように要求が出てきたとします。
項目にコードを割り振っています。RはRequirementのつもりですが、RXの番号があるものは、要求としてはあるけども、設計作業を単純にするために、以後は無視するものとします。思いつく全ての要求を入れてしまうと、プロセスよりも状況の把握の方が膨大な情報量になるので、その点はご容赦ください。もちろん、無視した要求が重要なこともあるかと思いますが、ここでは、プロセスを通すことをまずは説明したいと思います。
上記のような要求がある場合、ざっくりとモックアップを作ってみるとこんな感じでしょうか？ INTER-Mediatorを読み込んでいるので、テーマが適用されていますが、あとは単にinputやselectタグを適当に並べているだけで、特にデータベース処理などはしていません。要するに、tableタグにtrタグが3つ含まれていて、「複数のメモがある」感じを出しているだけです。
こういうのを作ると、もう、ここでいろんな要求が増えてきます。ちなみに、「メモ」あるいは「リマインダー」って、多くの人は「いいアプリがない」とお悩みなようで、どうやら、一人一人が要求するスペックが多岐に渡っていて、落とし所が見つかりにくいテーマなようです。ということで、以下、要求が出てくるとは言っても私の好みという色彩は強いので、メモアプリケーションとして評価はしないでください。あくまで、プロセスとしてこういう流れがありうるのかどうかということです。以下のような要求が追加されました。
これらを含めたモックアップとして、次のように発展させたとします。絞り込みのため、左側に分類名のボタンを用意します。ページネーションは「とりあえず配置する」ということを示す赤い文字列を示すに留めています。一定以上の労力がかかる作り込みは、モックアップでは避けた方が良いでしょう。その代わり、例えば、このように赤字でコメントを書くということを行うことで、コミュニケーションを図ります。
この辺りまで進んでくると、おそらくディテールについて、いろいろな意見が飛び交うでしょう。まず、前の図だと、分類やメモそのものはテキストフィールドにありますが、最初に書き込んだ文言から変更しないことが多いのだから、テキストフィールドである必要はないと言えます。また、文字数が長くなると、欠ける可能性もあるので、メモの一覧には編集機能を付けないのがいいのではないかということになります。
であれば、入力や編集はどうするか？ 1つの方法としては、以下の図にあるように、メモの一覧の下などに、メモの入力用エリアを設けて、ここで最初の入力ができるようにすることになるでしょう。他にも方法がありそうですが、ここでは別領域を設けることで合意したとします。
左側の絞り込みを見てみると、小分類での絞り込みはできそうですが、指定した大分類だけの絞り込みもしたいのではないかということになりました。要求についてはR6が詳細化されたとみることができるでしょう。
入力と表示を分けましたが、このままでは、メモの編集ができません。書き損じた場合はどうするのということもありますし、分類を変えたい場合も手段がありません。要するに、CRUDの考慮が必要になるということになりました。項目の削除は、一覧に「削除」ボタンを作る。そして、項目の内容を変更することは、どちらかと言えば主要な操作ではないので、リストをクリックするか、あるいはボタンを押すなどの方法で、別のページに遷移して修正ができるようにしようということになりました。ただし、この別ページ部分は今回の流れでは追わないことにしましょう。
他にはどうでしょうか？ リストや分類項目の並べ方が確定していません。これについてもやはりいろいろな意見があるでしょうが、次のようにしましょう。
ちょっとしたアプリケーションのつもりでも、結構、項目は出てくるものです。ここまでのところでは、要求に関して、UI設計を進めることで、要求に不足する情報を補うことを意図した作業を進めてみました。メモについてはドメインと呼べるほどの知識はないのかもしれませんが、アプリケーションによってはそのドメイン部分の理解を何かの方法で進めながら、要求とUIの部分を進めました。次回は続いて、要件定義からモデル化を進める部分に進みましょう。
設計作業のサンプルで用いたファイルは、こちらで共有します。
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アプリケーションを開発・改変できるフレームワーク」と説明するのは変わりないとして（最初からちょっと変わっていますが）、ここでの考察を組み込んだスローガンを考えないといけません。これは宿題ということで、お許しください。