Category: 続・開発プロセス

制約された状況での開発プロセスとして、どこにフォーカスするかをまずは示しておきます。開発において、「要求」が最初にあり、それに応じて「設計」「実装」と進む点はもちろん外せません。ここで、重点をおきたい「設計」については、(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アプリケーションが開発できるという点を追求するのが、取り残されないようにする最善策と考えます。

今月から書き始めたシリーズは「続・開発プロセス」というカテゴリにします。以前のシリーズでは、INTER-MediatorあるいはWebアプリケーションということで検討しました。要素を検討することで粒度を下げることをがんばってみましたが、粒度が小さすぎると、設計として成り立つ抽象度が下がってしまい、実装しているのと同じことになります。そこは反省点として、改めて考えてみるのがこのシリーズです。

検討しているうちに、INTER-Mediatorだけの問題ではないことに気付きました。Webアプリケーションでは様々なフレームワークを使います。それぞれのフレームワークを使う上での問題という見方もできます。また、FileMakerに代表される開発ツール系、あるいはSalesforceやServer Nowなどのクラウド系サービス、いずれも共通する問題を持っていると考えます。その問題とは、「制約された状況で実装可能な設計を行うこと」に集約されます。制約というとネガティブな感じがあるかもしれませんが、制約されているということは、言い換えれば既に出来上がっている仕組みがあり、より広い範囲でソフトウェアの再利用ができているとも言えるわけです。もちろん、適切な設計がなされている必要がありますが、多数のインストールベースがあるアプリケーションやサービスではそうした利用実績があることから、「一定以上の完成度を確保できる」という点が満たされると考えるのが自然でしょう。すなわち、ある特定の開発環境を利用することは事前に決まっていることも多いとも言えます。そうした特定の開発環境の世界を俯瞰する意味で「制約のある開発環境」と言えるでしょう。なお、マイクロサービスアーキテクチャーも状況によっては制約として適用されると思われますが、しばらくは、Webフレームワーク＋FileMaker＋クラウドサービスを中心に考えたいと思います。

そして、もう１つの方針は「ドキュメンテーションの方針」を示すことです。まず、ドキュメンテーションは軽く、最小限の時間で管理できるようにするということを目標に掲げます。いろいろな手法が提唱されていますが、時間がない、つまりは予算がないという理由でアクションのみのを採用してドキュメントが何も残っていないことはよくあります。メモでもいいのですが、埋もれがちです。もちろん、議事録はひたすら書くべきですが、それはナレッジにはなりづらいです。できればコアになる情報がなるべくコンパクトにまとめておける必要があります。その点も意識したいと考えます。