Category: INTER-Mediator

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

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

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

UIの設計はどうするか？　設計の成果物は何にするのか？　これは難しい問題であり、そう簡単には結論できません。特定の形式に決めてしまうと、それだけで「自分はできない」「自分は関係ない」という気持ちに強くさせると思います。ですが、設計と実装はどこかで線引きは必要です。その線引きも、会社、チーム、案件、顧客、まずはステークホルダーの集団ごとに違ってくると思われます。そして、設計中も、実装中も、要求との適合を判断するための基準は、UIから得られることは多いでしょう。UIだけということではないものの、システム全体像を形作るものがUIでもあることから、UI設計は独立して進めることになります。

ここで、UIの設計を、制約された状況（フレームワークやツールを使う前提での開発）において適用する場合、まずは、プロトタイプの構築を目指すべきと考えます。なぜなら、それらのツールは一般にUI構築が容易であり、変更も容易であることを謳っているからです。その仕組みを設計においても使わない手はありません。また、Webフレームワークであるなら、Webページのモックアップを作ることを行います。どの手法で、どこまで作り込むのかということは、ツールによっても違ってくるとは思います。ですが、ここでは「実環境である程度作る」ということが重要と考えます。

よく、ホワイトボードや紙を使って設計することがあります。ホワイトボードや紙を使うのは悪いことではありませんが、それらを設計の成果物とすることには、以下のような問題があると考えます。まず、ペンで記述するという自由さから、実装不可能なデザインをやってしまう可能性があります。プロトタイプやモックアップを作るのなら、少なくとも見かけの上では、実現不可能なことは実現できない時点で判別します。そして、やはり手書きの問題点は、書き漏れが多いということです。ホワイトボードや紙を使って、特にグループワークをしていると、話しながら書くので、話を聞いていれば意味がわかる線の塊も、単にその「線の塊」を見ただけではなんのことかわかりません。また、場所が足りないので、「…」となっていたり、書き損じがあるなど、最終的な成果物としては不完全です。つまり、ディスカッション等に費やした時間が後々に無駄になる可能性が高いのです。

では、Excelで清書しようということになるのですが、ずばり言ってそれは無駄です。Excelでグラフィクスを駆使する時間があるのなら、プロトタイプを作ってしまいましょう。また、HTMLでモックを組めば良いことです。わざわざExcelで作ることで、時間をかけるのは無駄です。証拠を残すだけのExcelワークほど無駄なものはありません。ホワイトボードや紙でのディスカッション結果や検討結果は、記憶が新しいうちに、プロトタイプやモックアップに展開し、そこで表現しきれないことは、要求として記述を残しておくのが良いでしょう。

プロトタイプやモックアップをUI設計の成果とする場合、大きなポイントは、それによって何を明確にするのかを、予め目星をつけるあるいはチームとして合意をしておくということがポイントになります。プロトタイプはうまく作りすぎると、クライアントは「もう出来上がったのですか！」と期待に胸を膨らませることになり、ボタンを押しても何も起きないことにかえって幻滅します。おそらく、ここで機能の実装をガッツリやることは、避けたいと思うところです。なぜなら、UI設計をしている段階ではまだまだ多くのことが決まっていないので、実装結果が無駄になる可能性があるからです。よって、プロトタイプもモックアップもともかく、労力がかからない範囲にしないと、かえって無駄な作業をしたことになります。

プロトタイプやモックアップにって明確にすべきことのまず一番重要なことは、「項目」となるべき要素の抽出です。UI画面に入力枠があって、そこに入力するということは、「項目」の1つです。また、一覧表を考えたとき、その列に表示すべき情報も「項目」です。これらは、明らかにデータベースのスキーマや、あるいは内部動作でのプロパティに直結するものであり、UIの上で必要なものを可能な限り余すところなく、UI設計上に記述できていれば、設計のレベルとしては成功だとみなせるでしょう。また、可能であれば、クライアントに協力してもらって、実際に入りそうなデータを入れてみます。もちろん、プロトタイプでは制約も多いですし、HTMLのモックだと自由度は少ないでしょう。それでも、例えば、それらをホワイトボードに写して、そこに手書きでもいいかと思います。具体的にデータをいれる場面にならないと実業務との関連性を判断できない人は多い、というか、ほとんどの人はそうです。抽象的なデザインのモックを見て判断できる人は、一般ユーザーではなくその道の人です。プロトタイプやモックアップでは、項目の抽出が目的であることを常に示しながら、クライアントに的確な判断ができる素地を整えるのが、UI設計のセッションには必要ということになります。

次に明確にすべきこと、あるいはできることとしては、その場面で必要な作業です。狭い意味では、どんなボタンをつけておくと良いのかということになりますが、言い換えればページやパネルなどに実装すべき機能を特定するということです。ここでは、いろいろなワークフローを想定してもらい、そのワークフローがスムーズに進むように、仕組みを追加すると言えばいいでしょうか？　そうなると、開発側がプロトタイプやモックアップを紙芝居的に見せながら、不足する機能をピックアップするというセッションが可能になります。ただ、現実位はワークフローの抽出はなかなか大変です。当然、ドキュメントになっていて手順になっていれば、作業はスムーズですが、多くのクライアントは「時間がない」とか、「自分は全部知らない」などの言い訳をして、そうしたドキュメントは作ってくれません。開発側で要求抽出の結果から、不完全なワークフローの記述を作るなどの方策も考えられます。結果的にその場に来てもらって確認ということになることが多いとは思います。このセッションは恐らく達成率はあまり高くならないでしょうけど、要求を実現するための仕組みをUI設計に落とし込むためには、どうしてもワークフローとの関係を早い段階から明白にする必要があります。プロトタイプやモックアップを使えば、一定の範囲内では可能と考えられます。

プロトタイプやモックアップを作った後は、潔く捨てるのか、それとも、それを元に開発を進めるのか？　これは非常に悩ましいところです。理想的には1からやり直すべきでしょうけど、結果的にはプロトタイプやモックアップをベースに開発は進むことになります。ここで注意したいのは、プロトタイプやモックアップに入れたけど、結果的に不要だった要素を確実に排除しておくことです。また、データベースを含むプロトタイプもFileMakerを使うような場合はあるかと思いますが、操作が簡単なら、データベース設計はやり直すのが良いと思われます。数回後に説明しますが、別途データベーススキーマの設計はすることになるので、結果的に1から作り直すことになるでしょう。ただ、プロトタイプやモックアップの完成後の扱いは、慎重に検討しましょう。また、作りかけの素材を元にする場合も、プロトタイプベースの開発と同様に、既存の開発物をどのように使うのかという問題は付き纏います。

制約された状況での開発プロセスとして、どこにフォーカスするかをまずは示しておきます。開発において、「要求」が最初にあり、それに応じて「設計」「実装」と進む点はもちろん外せません。ここで、重点をおきたい「設計」については、(1)ユーザーインタフェース設計と、(2)内部動作設計の2つに分離して考えます。古くからの言い方だと、外部設計、内部設計に相当し、呼び方としてはそれでいいとは思いますが、ポイントはUIとそれ以外に分離します。(2)は何かいい言葉が見つかったら変えます。

ここで、全体的なデザインやUXはどうなるということが気になるところですが、もちろん、UXはUIとは切っても切れない間柄ではあるものの、本来はUXの検討事項は要求に還元されるのではないかとも言えます。ユーザーの体験は「実現したいこと」であり、どう実現するかと言うことではないのです。

一方、ドメイン知識などはどうでしょう？　これは、要求を明確化するための素地と考えます。ビジネスモデルは、要求を明確化したものとも言えます。このように、初期段階の難しいプロセスは、実は要求の定義に帰着します。そうなると、やはり要求は無視できないということになりますが、ここでは現在の様々な開発現場の状況をそのまま取り込むことを考えます。要求分析はしないわけではないですし、軽視するつもりもありません。しかしながら、現実に要求が固まった状況で開発に取り掛かれることは皆無であり、開発途中で要求は変化し、追加され、また物によってはなくなります。開発プロセスの中で、要求までフィードバックして、再検討することは多々あるという状況です。また、派生開発では、謎の実装があってもそれら全部に要求をマッピングすることはせずに進める場合もあるでしょう。時間がないというより、本当に分からないこともあり、影響がないなら無視と判断するのは効率を基準にすれば正しいと言えます。

制約された開発環境の多くは、そうした仕様変更への対処に強いことが特徴として言えます。変更後の実装変更作業が、相対的に軽いと言えるでしょう。そのために制約があるものの、その制約を理解した上で最短のタスクを動かせば、短時間で巻き返しが可能です。そこが大きな特徴であることは明白なのですが、スクラッチな開発の話ばかりが強調されている気もします。

要求自体をどのように扱うかと言う点については、ここで検討する開発プロセスでは、結果的に「通常通り」と言う結論になり、そこから先のプロセスを考えることにします。ただ、制約された開発環境で発生する要求上の問題もある程度は見通しがあるのですが、まずは、その後の工程についての検討から進めたいと考えます。いずれにしても、何らかの方法で、要求を集めてドキュメントにしなければなりません。インタビューの記録や議事録でもいいのですが、それは一次情報なのでそこから整理した要求定義を作文しておくのは、後々のための知識蓄積には必要な作業だと言えます。

ただし、要求定義の段階で、要求抽出をしながらも、設計の検討を始めることで、設計そのものに要求を明確に反映させることも可能です。ただ、設計したらそこに全ての要求が記述されたも同然とはいえません。しかしながら、ある程度の明白な要求は、UI設計をすることでそこに込めることも可能です。UI設計を進めながら要求を検討することで、要求として書き残すことが少なくなるとは言えますが、一方で「書かなくても良い」「書くべき」という判断が難しいところです。

要求が絡むと問題が難しくなりがちですし、そのドキュメンテーションの基準も曖昧な物になりがちではありませんが、最初に要求を追求することは必須であることを指摘しておきます。

システム開発と言えば、プログラミングが作業の主体で、プログラマがたくさん関わるというイメージが世間的には強いかもしれません。しかしながら、スクラッチから作るような開発タスクでさえ、プログラマよりもデザインや調整等で動く人の方が数多く関わる状況かと思います。まず、全体の傾向として、プログラミングもしくはコーディングは年々縮小していると言って良いでしょう。その１つの大きな要因は、開発環境としてソフトウェアの再利用が年々洗練化され、高まっているということがあります。

つまり、フレームワークの利用は当たり前の時代からさらに進んで、ERPによる開発や、あるいはSalesforceやService Nowに見られるような、開発ツールの提供というよりも、開発が既に行われていて、むしろ容易にカスタマイズできる点が、今現在の顧客の求めるものであるという段階にきていると言うことです。もちろん、スクラッチからの開発というのも今でもありますが、世間で言われるようにメンテナンス開発の方が案件が多いといった事情もあります。

もちろん、それは今に限ったわけではなく、私が昔から関わっているFileMakerは容易に開発作業ができる点を売りにしています。しかしながら、パッケージ化されたソリューションは他のサービスに比べてかなり弱い状態になっています。サンプルプログラムとパッケージ化されたソリューションの間には大きな溝があり、FileMakerと言う製品はまだそこのジャンプができていないと考えます。

先日、Service Nowのイベントがありました。導入事例を見る限りは、Serivce Nowだからと言うよりも、用意されている人事管理ソリューションなどが概ねそのままビジネス現場に持ち込めるから導入している企業が多いという気がしました。導入企業は開発する気がない、と言うか、開発しているつもりはないと言う感じです。要するに、開発環境というよりも自社向けに色々改良できるクラウドのSaaSみたいな見方をしていると強く感じました。

今時のIT導入では、『もはや開発をしている場合ではない』という状況ではないかと考えられます。スクラッチから開発すると、費用も時間もかかり、さらに思った結果が得られないリスクと戦いながら、顧客側にとっては強いコミットが必要になります。しかしながら、パッケージ化されたソリューションを導入しようとしている企業は、自社業務の独自性へのこだわりを少しだけ捨てて、パッケージの仕組みに適合することで、コストも時間も節約できることに気づいているのでしょう。

そうなると、開発環境の競争においては、パッケージの品揃えで勝負するか、一方、開発作業にフォーカスするとしたら、とにかく短時間で開発ができると言うことが最低限必要です。つまり、超高速開発ツール改め「ローコード」と業界団体の名前が最近変わりましたが、まさに、ローコードであるのが1つの重要なスペックになるでしょう。開発ツールそのものは需要はなくならないですが、既に業界の人は気づいているように一般的な業務はほとんどの企業でSaaSやクラウドを使うようになり、案件が発生するのはそうしたソリューションがない特殊な業務、あるいはその企業に特有の業務が中心になっています。もちろん、スクラッチから書くのがエンジニアリングなんだと言うことで従来型の仕事の方法をメインにする、つまり従来型のSIer業務で押し通すと言うこともあるかもしれませんが、そうした市場が年々縮小しているのは皆が知るところです。IT業界への期待はパッケージ化されたソリューションにあるわけです。

既存のソリューションがある上でのメンテナンス開発は、既に作られている部分があると言う意味では、パッケージ化されたソリューションとそのカスタマイズをするのに似ていると言えるでしょう。ただ、パッケージに比べて秘伝のタレがかかっているとか、謎のファイルなども出てきますが、ある形態の切り口ではよく似ていると言えます。

また、マイクロサービスについても、「既存のマイクロサービスを利用する前提」と言う開発であれば、やはり同様に、パッケージ化された部分があり、そこに適合すると言う側面があります。正し、マイクロサービスの携帯によってはバックエンド的に使われることもあり、そうなると、マイクロサービスそのものの影響は少なくなるかもしれません。一方、マイクロサービスの機能をメインに使うと、まさにERPの開発に近くなるかもしれません。

結果的に、フレームワークを利用した開発、クラウドサービスをベースにした開発、FileMakerやAccessなどのデータベース系開発ツール、ある種のマイクロサービスの利用形態、これらは全部、なるべく多くのソフトウェアの再利用をすることが根底にあり、さらにカスタマイズがやりやすいという共通の特徴を持っています。一方で、既存のソフトウェアはほとんどの場合改変はできません。カスタマイズができるとは言え、その既存ソフトウェアの動作を理解し、要求に合うように手を加えるというのが開発の作業となります。手続き型言語でスクラッチから作るソフトウェアと違い、既存のソフトウェアが存在することで、便利になる反面、そのこと自体が制約であると考えられます。こうした意味で「制約のある環境での開発」として抽象化して扱えるのではないかというのが前の記事に書いたことの詳細な説明です。

ここから、INTER-Mediatorの話になります。INTER-Mediatorには、パッケージ化されたソリューションはありません。雑なサンプル程度しかないということで、まさにトレンドに乗れていないフレームワークです。もちろん、ソリューションを作りたい気持ちはありますが、フレームワーク自体の開発にも時間が足りない状態なのに、今はソリューションに注力する余裕は全くありません。ただ、将来的に時期が来ればとは考えています。INTER-Mediatorは、スローガンとおり、少ない作業でデータベース連動Webアプリケーションが開発できるという点を追求するのが、取り残されないようにする最善策と考えます。