システムを企画するときの覚え書き

ここでは、あまり大規模なシステムのことは扱っていない。局所的な使い道のシステムとか、ある大きなシステムの補助になるサブシステムとか、そんなのを想定。中小規模なシステムなだけに、わりと業者任せに「これこれこうしてよう」といいかげんに発注してしまい、あとでトラブって「こんなはずじゃなかった」と言いたくなることってある気がするので、そういうのを防ぎたいなあと思いながら書くメモです。

要求を見つける

こういうことがしたいんだ、という声がどこかから挙がってくるので、これが最初の要求かなあ、と考えるのが自然なんだけど、現場から上がる声と上司から降りてくる声には差があるので要注意。

現場の声からは、実際に困っている具体的なシーンを知ることができるが、システム全体としてのその業務の位置づけは別に考えてあげる必要がある。他の部署と共通点のある業務なのに、その人たち専用のシステムを作りこんでしまい、他の部署ではイマイチ使いまわせない…というのは時々ある罠。

上司から降りてくる声は、(あくまで一般論だけど)業務全体の効率化を願ってのことでも、業務上の個々の作業量への考慮は少ないことがある。あとは稀に、変なバズワードにかぶれてたり。そのネタ、どこの日経コンピュータから仕入れたんスか。

要求として声が聞こえてこなくても、システムが少し分かる立場から見てみると、なんだか変な苦労をわざわざしているなあ、と思えることがある。仕事している人は疑問をあまり持たずにそれを行ってても、その仕事って明らかに非効率なんじゃないかなあ、とか。これが潜在的な要求だとわかる。下のような感想を持つことって、割とあるじゃないですか。

  • なんか無意味なペーパーワークさせられてるなあ…
  • なんか無意味な人的チェックをしてるなあ…
  • なんか無意味な利用制約があるなあ…
  • なんか無意味な処理時間待ちをしてるなあ…
  • なんか無意味なデータ(レポート)整形に労力使ってるなあ…
  • なんか無意味に大きな添付ファイルをやりとりしてるなあ…

こういうのを見つけたら、現場の人とかに「これがこうだったら、もっと効率上がりませんかねえ」とか話を振ってみる。「そんなことができるなら(許されるなら)、やりたいな!」という返事が返ってきたら、ああ、要求はあったんだなあということ。

構想を練る

ここらへんで、誰にどのように役に立つ仕組みなのかを改めてよく考えてみる。この時点で、プログラミングなどの知識は不要。いるものは想像力。

最初はいい思い付きだと思っていても、完成したシステムの運用が始まってみると大して便利になっていないという失敗は、わりとありがち。そのシステムによって、誰が何を「できる」のか、誰が何を「できない」のか、誰が何を「してもしなくてもいい」のか。また、この際、「だれに面倒が生じるか」ということも想像してみるとよい。Aさんの手間を省くシステムのつもりで作ったら、Bさんの仕事が増えるとか。

ボタン配置がどうとか、ページ遷移がどうとか、そういうのを考えるにはまだ早い。

プログラミングの知識は不要というものの、システムが「データ」を扱うんだという認識はそれなりに必要。システムはデータのないところからそれを魔法のように生み出してくれるわけではないので、どんな「データ」を投入されて動くのかは意識したい。ただし、ここで賢しらにXMLだのKey-Valueだの変な用語をふりまわす必要はない。システムを「聞いたことを忘れない、(ある意味)超優秀な人間」くらいに想定して、そいつが何を知っていて管理してくれるとみんなの役に立つのか、という想像なんかをしてもいいかも。

やりたいことの「本道」のような部分により集中力を使ってみる。本質的でない部分を議論し始めてもあまり生産的ではない。「アイテムの表示ページには、ボスのコメントが点滅表示されるといいなあ」といった思いつきをねじ込まれたとしても、はいはい、くらいに生返事して、しばらく放っておくとか。

この時点で、利用の可能性がある人にできるだけ話を吹っかけて、大体同意、という意見を多く得ておくとよい。あとになっての基本的な機能の変更は、手戻りになってしまうので避けたい。開発業者にもとても嫌がられるものだし、場合によってはコスト割れさえしてしまうかも。

類似システムを予習する

やりたいことがよほど独創的なことでない限り、似たようなシステムはあるはず。それを探したり思い出したりし、それらと似ている点、違う点を考えてみると、最初の手掛かりになりやすい。

開発業者にあとで相談するときも、「○○という仕組みに似ていて…」という話から入ると、通じやすいかも。(業者側からは、「たしかに似ていますね」とか「それは実は似ていないですね」といった反応があるだろう。どちらにしても設計の助けになる)

こういう「似たシステム探し」を効果的に行うためには、よくあるシステム類型とその特徴は一通り知っていたほうがいいと思う。思いつくままに適当に挙げてみると…

  • Webアプリケーション…Webクライアントさえあればシステムが使える。不特定多数の利用を想定するなら普通これ。攻撃的アクセスを試されることが多い。
  • クライアントサーバー(クラサバ)型…VBとか、MS-Accessとかで、複数のクライアントがひとつのサーバー上のデータを共有・管理する。クライアント環境に注文が多くなる。一般に、開発は手早い。
  • スタンドアロン…入力ルートもひとつ、出力も、何か整形した成果物を取り出したいだけなんだ、といった感じのシステムだと、そもそもコンピュータ一台で完結してしまうようなときもある。

WebアプリならWebアプリでも、CMS(コンテンツ管理システム)みたいなもの、SNSソーシャルネットワーク)みたいなもの、Wikiみたいなもの、メールフォームみたいなもの、掲示板みたいなもの、ブログみたいなもの、アップローダ―みたいなもの…とかいろいろありますね。ふだんWebでいろいろ遊んでいると、自然と分かってくると思うけどなあ。

仕様のたたき台をつくってみる

利用中のイメージ(起こること、画面上の表示)をいろいろスケッチしてみよう。大き目の紙にガリガリ書いてみたり、紙を切り貼りしたりして組み立ててみてもいいだろう。思いつきをどしどし描くのに、パワポなんか使ってきれいな作図するヒマはないと思う。手描きが基本。

データはどこからどこに入って…といった感じの矢印記号を入れるのもいい。登場人物(操作者、管理者など)を棒人間でいいから横に書いてみよう。この人が画面を操作するんだな、というイメージが明らかになる。

こうしてメモ的な「プレ仕様」とでも呼べるものを作っているうちに、ふと「プロジェクト名」が浮かんでくることがある。プロジェクト名が決まると愛着がわいて、幸先がいい。

データを再利用したいときがあるかを考えてみる

システムからはどんなデータが発生するか。それらのデータはシステム内で使われることはもちろん、システムの外に出しても使い道があるかもしれない。どんな使い道が想像できるか。もしプログラムが書けたら、そのデータで何がしたいか。

プログラムなんて作れないよう!と思考停止しないで。Excelマクロとか、意外と書けてたりするじゃない。(ある意味、専用のプログラム言語より小難しいことさえしている。)でも、内輪でも特殊な人にしか書けないような複雑なプログラムが必要になりそうなら、その人がいなくなる時のことを考えて、プログラム作成はシステム開発の範囲に盛り込んだ方がいいだろうし、ここの見極めはちょっと難しいかもしれない。とはいえ、プログラム的なものは、自分たちでは一切管理できないと考える必要はないと思う。データの発生はシステム上で起こっても、その後、Excel等で生データが取り込めれば、グラフとかクロス集計で済ませられる部分がある。また、マスタ系のデータは、専用の編集インターフェースがなくたって、SQLやそれに類するツールである程度(危険度の考慮は必要だけど)整備できる。MS-Accessとか、phpMyAdminとか、データを自力でいじるための簡単な方法は以外といろいろあるものです。むしろ、これら相当の機能まで業者に作りこませたことで、高い上に却って融通のきかない(ときにはバグさえある)仕組みができてしまうことがある。

自前で足りる開発というのは、きっとある。プログラムの技術が少々と、あとは何より「ドキュメント作成の技術」があれば。意外と後者のほうが問題なんですよね。

業者に相談する

開発業者を呼んで相談するときには、相談に至ったストーリーに触れるのが重要。「何々がしたいと思って、こういう形のシステムになりそうだと考えた。」とはじめに伝えておくと、業者にとってはとても分かりやすい。業者は開発のプロであり、これこれの要求があるときは、お客自身のアイデアよりも、むしろこういう種類のソリューションが適している、という知識を持っているかも知れない。設計方針を間違えるとこういった落とし穴がある、という経験も持っているかもしれない。そこを引き出す役にも立つ。

業者相手にあまり技術上の知ったかぶりはしないほうがいい。どういう技術を選択するかは、普通は業者にある程度任せるのが正しい。背伸びして一知半解な用語を使ってしまい、それを真に受けられて変なシステムを作られたりしても嫌だし。

あとは、業務上の知識・概念を正確に伝えられるよう努力すべき。ふだん慣れた業務だと、変な用語が(それが一般常識とズレていても)当たり前のものとして認識されがちなので、つい共通の言葉だと思って使ってしまう。業務の内容や用語が正確に何を表しているのかについては、あらかじめ現場の人によくインタビューしておくくらいのことが必要。少なくともシステム企画をする自分には分かっていないと始まらない。あいまいに伝わりそうな言葉として思いつくものに、「支払」「締め」「営業日」「ユーザー」などがある。

システム的な考えになじまない人から、システムを作るための情報を聞くためにうまくインタビューするのはとても難しいよ。意外なほどに熟練が必要。

仕様を詳しくする

業者との打ち合わせで得た知識を援用して行う。どういうボタン、どういう入力欄があり、どういう操作のタイミングで何が起こるのかをできるだけ詳しく書いてみる。仕様のつくりかた全般については、このメモだけでは述べ尽くせないけど。

正しい値が入力されたときに何が起こるのかは想定しやすいが、間違った値が入力された(または空白のままだった)ときにどういう困った事態になりそうかも想像してみる。仕様上は、そういった入力、悪意のある入力を防ぐこと、といった記述が必要になる。これらが不完全なままシステムがリリースされると、入力ミスが即トラブルの原因になり、「おそるおそる」使わなくてはいけないシステムになる。「このボタンを押すと取り返しがつかないから押すな!」とか。システムが壊れたときに、なぜか通常権限しかないオペレータが怒られたり。傍から見ているとワケがわからない話だけど、時々起るのも確か。

システムに、どれほどの負荷がかかりそうかを現実的な値として考えてみる。データの容量が増えればストレージが不足したりバックアップ&リストアに時間がかかるようになるかもしれない。同時アクセス数が多ければメモリやCPUの使用を圧迫するかもしれない。これを検討したのちに、業者にシステム利用の想定規模を伝えて、スペックを見積もってもらうことになるだろう。

システムが「使えなくてもいい」日や時間帯はあるか。夜間は使わないシステムなら、その時間にすっかりシステムを止めて、フルバックアップバッチ処理にあてられる。止めることが許されないシステムなら、もうちょっとうまい方法が必要。それでも「止めていい」部分と「24時間稼働」な部分は切り分けられるといい。

発注する(契約内容を決める)

望むシステムについて、どのくらい環境依存が発生するのかは確かめておく。Windowsサーバーの特定バージョンでしか動きません、IEの特定バージョンでしか動きません、特定のプリンタでしか帳票が出せません、とか限定するほうが開発者にとってはリスクが少なくて楽なのだけど、使う立場は環境がいろいろ選べる方が有利なので、ここは妥協点を探して真剣に打ち合わせるべき部分。環境依存が減るのは、実は開発者にとっていい面もあるはずだよね。特殊なテスト環境をずっと抱えなくて済むとか。

要求する内容を変えることで、環境依存部分を減らせるかもしれない。希望する機能を達成するためにブラウザ上でActiveXを使うとか、一見うまいソリューションに思えても、後々になるとロクな保守ができずに困ることがある。要注意。

使う人がWindows以外の環境に自信がない(またはLinuxとか聞いたとたんに思考停止してしまう)ときは、ついサーバー環境にもクライアント環境にもそれらの慣れた環境を期待してしまい、結果として環境依存の強いシステムができてしまうことがある。

発注前には、当然見積もりを取ることになるのだけど、今まで挙げたような仕様上のポイントを押さえた上で見積もりを取ることで、業者にとっては余計なリスク感が減って、安くしやすい。また相見積もりをとって安い方を選んでも失敗が少ない。いいかげんな仕様にいいかげんな安値をつけてくる業者が、いい仕事すると思う?

開発の進捗をチェックする

作りかけのものを見せてもらえると、ちょっとした微修正もお願いしやすくてよいし、業者にとっても間違った道を進んでいないという安心感になる。変に「途中経過をなんとしても見せよ」とか言っていじめることはないけど。

「あれは思ったより難しいことが判明した。これをこうすれば代替案になる」なんていう提案が開発側から来るときがある。嬉しいことではないが、契約の範囲内で、なんとか柔軟に対応できるとよい。こちらの都合だけで書いた形式的なガントチャートみたいなのを押しつけて、ギリギリ締めるだけで困らせるのはよくないと思うんだよな…

納品物をチェックする

正常系のテスト(想定どおりのデータ・想定通りの操作手順を試すテスト)はもちろんだが、エラーを起こしてやろうという、ちょっと意地悪なくらいのテストをするのも必要。堂々と壊せるのは、ある意味今だけ。システムのシャットダウン・再起動もやってみる。本当にクリティカルなシステムのときは、電源を突然切断するとかそんな意地悪なテストもするときがあるが、それは程度次第。

バックアップ&リストアが正しくできるかどうか確認しておくべき。

ログがなぜか滅茶苦茶にたくさん出力されてるのに気づかず、ある日ストレージが枯渇する、なんていう話がときどきある。デバッグモードがONのままだったとか、内部的に山ほど起こっているWarningを無視していた、とか。サーバーの内容がある程度確認できるのなら、いろいろ探検してみると、こんな隠れ不具合も発見できるかも。

利用者へのトレーニングをする

利用者が多い時は、FAQが整備できるとよい。というか、問い合わせの殺到を防ぐためにぜひ作りたい。運用側の負荷を減らすために、よいFAQを目指すことは結構真剣な仕事。事例集やメールのやりとり記録なんかを無秩序にコピペしてもあまり役に立たない。FAQ作成担当が、事例をちゃんと消化して過不足のない内容にしなくてはいけない。また頻繁に更新もできるように。利用者目線の内容でないといけないので、あまり開発業者に任せられないところだと思う。

異常発生時を想定する

どんな問題が起こったときに誰に連絡し、その誰々が開発業者にどういう連絡をするのかを考えておく。必要ならば期間サポート契約を考慮する。

また、納品ドキュメントの品質がよければ、当該の開発業者にメンテナンスができなくなってしまったあとも対応が容易になるので、(品質の見分けをつけるのは簡単でないが)できるだけ注意する。

運用ドキュメントをつくる

運用担当者は入れかわるものだという前提を持つこと。何を把握しておき、どういう事態にどういう対応をすべきなのかを文書にしておく。どういった登場人物がいるのか、どういったルーチン作業があるのか、どこでパフォーマンスを監視できるのか、どこまでパラメータを調整していいのか。つまり属人的な運用体制にしない工夫をすること。これは、普通、開発業者にはできないこと。

メンテがままならないシステムのお守りを突然任せられる新人の悲しさったらないよ。

システムの寿命を想定する

家に帰るまでが遠足です! 捨てるまでがシステム企画です!

いつになったら(どういう条件が満たされたら)このシステムが不要になるか、または後継システムによって役割を引き継げるのかを想定しておけると望ましい。もちろん正確にこれを予想するのは難しいのだけれど。

時代遅れになってしまったシステムを後生大事に使い続けるときの弊害というものがある。遅い、高負荷に耐えられない、保守がままならない、セキュリティアップデートができない、後継システムへのデータ移行が難しい、とか。

とはいえ、ある程度時間がたつと、システムは「捨てていいのか分からない」という状態になってしまいがち。誰もシステムの全貌がわからなくなるからです。誰がこのシステムを使っているのか、必要なデータは誰が受け取っているのか、また、このシステムから出力されたデータはどう使われているのか、といったことが把握できなくなると、システムを捨てたときにどんな影響が現れるのかが判断できない。ドキュメントを残してあるのが重要な理由がここにあります。また、このシステムがそもそも何のために作られたんだっけ、ということをいつでも思い出せることが必要。これは運用ドキュメントの中に入っているべき内容です。