今月から書き始めたシリーズは「続・開発プロセス」というカテゴリにします。以前のシリーズでは、INTER-MediatorあるいはWebアプリケーションということで検討しました。要素を検討することで粒度を下げることをがんばってみましたが、粒度が小さすぎると、設計として成り立つ抽象度が下がってしまい、実装しているのと同じことになります。そこは反省点として、改めて考えてみるのがこのシリーズです。
検討しているうちに、INTER-Mediatorだけの問題ではないことに気付きました。Webアプリケーションでは様々なフレームワークを使います。それぞれのフレームワークを使う上での問題という見方もできます。また、FileMakerに代表される開発ツール系、あるいはSalesforceやServer Nowなどのクラウド系サービス、いずれも共通する問題を持っていると考えます。その問題とは、「制約された状況で実装可能な設計を行うこと」に集約されます。制約というとネガティブな感じがあるかもしれませんが、制約されているということは、言い換えれば既に出来上がっている仕組みがあり、より広い範囲でソフトウェアの再利用ができているとも言えるわけです。もちろん、適切な設計がなされている必要がありますが、多数のインストールベースがあるアプリケーションやサービスではそうした利用実績があることから、「一定以上の完成度を確保できる」という点が満たされると考えるのが自然でしょう。すなわち、ある特定の開発環境を利用することは事前に決まっていることも多いとも言えます。そうした特定の開発環境の世界を俯瞰する意味で「制約のある開発環境」と言えるでしょう。なお、マイクロサービスアーキテクチャーも状況によっては制約として適用されると思われますが、しばらくは、Webフレームワーク＋FileMaker＋クラウドサービスを中心に考えたいと思います。
そして、もう１つの方針は「ドキュメンテーションの方針」を示すことです。まず、ドキュメンテーションは軽く、最小限の時間で管理できるようにするということを目標に掲げます。いろいろな手法が提唱されていますが、時間がない、つまりは予算がないという理由でアクションのみのを採用してドキュメントが何も残っていないことはよくあります。メモでもいいのですが、埋もれがちです。もちろん、議事録はひたすら書くべきですが、それはナレッジにはなりづらいです。できればコアになる情報がなるべくコンパクトにまとめておける必要があります。その点も意識したいと考えます。