手離れの良い設計とは

個人的に何らかのシステム開発を請けたとき,数年前までは本職のときとほぼ同じような設計を行ってきた。依頼主の業務を把握し,システムの管理下におかれる情報の洗い出しと整理を行う。そしてデータベースの構築と画面の設計を行って,依頼主と合意し,プログラミングに入るという流れだ。しかし,実際には「個人的に」請けたときには,同じような設計をしてしまってはうまく行かないということがわかってきた。

「システムの僕からの手離れを第一に考えること」が重要だということだ。

本職の立場で,つまり企業として仕事を請ければ,作りっぱなしはあり得ないし,運用や保守は当然付きものとなる。つまり,依頼主からの修正依頼や,機能追加などの要望を,普通はリアルタイムに対応することが可能である。

しかし,個人で「ほぼ趣味の範囲で」請けてしまっては,そう簡単に対応の時間を取ることができない。本職が優先だし,遊びも優先してしまう。他にやりたいことが見つかれば,ついそちらをやってしまうのが人間だ。もちろん,依頼を受ける時点で,「簡単に要望には答えられないよ」と断りを入れてから開発を請けている。でも,使う側からしたら,いくら断りを承諾していたとしても,不満な結果になってしまうだろう。

では,どうしたらよいか?

一般的にデータベースの設計は,必要な情報の項目を表の列として静的に定義し,それらを固定的に扱うプログラムや画面を作るのが普通である。この場合,追加したい情報の項目が出てきたときは,表に列を足して,プログラムを変更しなければ対応できない。つまり,作った僕が対応しなければいけなくなってしまう。

そこで,システムが扱う情報の項目自体をマスタ化しておいて,項目の増減や変更を行う画面を作っておく。そして情報の表示自体も,項目マスタを見ながら情報を検索して取得するようにする。更に,項目の表示順序や一覧画面への表示/非表示もできるようにしておく。もちろん検索機能に関しても,追加した項目について条件指定が動的にできるようにしておけば,大抵のシステムでは事足りる。

システムの使用者自身が,情報の項目を作っていけるようになることで,システムを「育てる」ことができるようになるのだ。そうなれば,自分でできることをわざわざ僕に相談しなくても良くなる。結果として,手離れが進むというわけだ。

当然,帳票出力や社外の人間に対する機能の公開などについては,上記のような汎用的な仕組みではなく,しっかり作りこむ必要があるだろう。しかし,僕一人で作れてしまうような規模のものであれば,上記のような仕組みは非常に有効だ。

では,具体的にどんな設計を行えば良いか。それはまた,別の話。。。

このエントリーをはてなブックマークに追加

関連記事

40%キーボードに慣れるためにやったこと

Lunakey PicoでQMK Firmwareを動かしてみました

Googleアシスタント向け会話型アクションが1年後にシャットダウンされます

Google I/O 2022でのGoogleアシスタント関連のセッション

Remap Organizations feature has been released