一般的に、「良いシステム」・「悪いシステム」というものは存在します。
これは「悪いシステム」です。
これは「良いシステム」です。
このように、開発者のさじ加減一つで、システムは良くも悪くもなります。
開発する以上、クライアントには「良いシステム」を届けたいものです。
この記事では、「良いシステム」を提供して、クライアントの満足度を高めるためにはどうすればいいのかを解説します。
開発者は環境を提供する
言うまでもなく、クライアントは、開発者に提供されたシステムを使って業務を遂行します。あるいは、クライアントがそのシステムを公開し、不特定多数の消費者がそのシステムを使います。
このとき、クライアントもしくはユーザーにとって、システムとは環境そのものです。
環境という言葉は、日常会話では、自分を取り巻く事象に対して用います。
開発者が提供するシステムは、クライアントあるいはユーザーを取り巻く事象そのものなのです。
業務を遂行するためのツールであり、消費行動を起こすためのツールです。
人間の満足度は、環境に大きく左右されます。
だから、開発者は、最適な環境を常に用意しなければなりません。
インフラエンジニアという言葉がありますが、全ての開発者は環境というインフラを提供するエンジニアだとも言えるのです。
開発者は仕事を生活を左右する重大な職務を担っています。
「スマホ・パソコンが分からなくて怖い」という人
「スマホ・パソコンが分からなくて怖い」という人は、何を怖がっているのでしょう？
たいていの場合、
- 「ここを押すとどうなるか分からない」
- 「変なところにアクセスしたら怖い」
- 「知らず知らずのうちに料金がかかったら怖い」
- 「変な操作をしてしまって元の画面に戻れない」
このようなことが、「怖い」原因です。
それらすべてに共通していることはなんでしょうか。
それは、「システムの作りの悪さ」なのです。
押すとどうなるか分からないシステムは、案内が不親切です。
変なところにアクセスするかどうかをきちんと示していないシステムは、そもそもそれを示すべきです。
知らず知らずのうちに料金がかかるのは、下手をすれば詐欺行為になります。
元の画面に戻れないシステムは一般的には作るべきではありません。戻ることを可能にするべきです。
悪意を持ち、このようなシステムを開発する人はいます。
しかし、単なる検討不足でこのようなシステムになっているなら、システムを早急に改善するべきです。
システムはリリースしたら終わりではありません。物理的な機械と違い、通常は、半永久に保守作業が発生します。保守作業とは、運用だけでなく、システムを改善していく作業そのものです。
開発者はシステムを改善していく義務も負っています。
機能要件と非機能要件
要件には機能要件と非機能要件があります。
機能要件とは、
「その機能がないとシステムが成立しない要件」
です。
メール送信システムでメールを送信するのは機能要件です。
非機能要件とは、
「満たしていればシステムがより顧客満足度を高めることになる要件」
です。
メール送信システムで大量のメールを高速に送信出来たり、
メールを作成する画面が操作しやすかったり、
エラーが分かりやすい言葉できちんと表示されたりすることは、
非機能要件です。
システムは機能要件だけを満足すればいいのではありません。
非機能要件もきちんとヒアリングし、または提案して、顧客満足度の高いシステムを作らなければなりません。
それが開発者の評価につながります。
ユーザーフレンドリーなシステムの例
スマホで、写真を見たいな、と思ったときに、2回のタップで見られるスマホと、3回タップしないとみられないスマホがあります。
これは、言うまでもなく、前者がユーザーフレンドリーです。ユーザーの求めるものになるべく短い手順で行き着くのが良いシステムです。
RPAシステムで、業務システムへのログイン／ログアウトも自動化していたら、それはユーザーフレンドリーなシステムです。自動化するなら完全自動化を目指したいものです。
Excelのシステムを作る際、入力する数字が「1」「2」「3」しかないなら、フリーで入力させてエラーメッセージを出すより、「1」「2」「3」のリストから選ぶ方式を採用したほうがユーザーフレンドリーです。ユーザーに余計な迷いを与えてはいけません。
ユーザーフレンドリーでないシステムの例
スマホのメーラーで、宛先を入力する際、メールアドレスの先頭の文字を入れて宛先候補を表示するだけのメーラーは、表示名の先頭を入れても宛先候補が表示されるメーラーよりユーザーフレンドリーではありません。メールアドレスの先頭の文字を記憶している人がどれだけいるでしょうか。ユーザーにとってより親しみやすい情報から全体の情報が得られるようにしましょう。
階層に分かれた項目を入力する際、例えば
a → a
a → b
b → 1
b → 2
となっている場合、初めにaかbかを選び、次に2階層目を1階層目に応じて選択させるシステムが良いシステムです。
初めからこの4つの一覧を出して選択させるのは、ユーザーフレンドリーではないシステムです。
今の例はたった2×2なので実感がわかないかもしれませんが、全体の項目が1000にも及び、階層も5つあったら、その差は歴然とします。
まとめ・「システムが悪い」はどうして出てくるのか
今までの話は、全て、「良いシステムとは何か」でした。
視点を変えてみれば、これらの非機能要件を満たしていないとき、クライアントは「システムが悪い」と言います。
実際、「システムが悪い」ことは多々あります。筆者は悪いシステムをいくつも改修してきました。そのたびに、なぜこのような作りにしたのか、非常に疑問に思いました。スキル不足なのでしょうが、開発者にはそういうスキルは必須です。また、悪いシステムは常にコードもぐじゃぐじゃでした。
もしかしたら、「整理するスキル」なのかもしれません。
常に顧客の満足度を考え、現状のシステムに満足しないでください。
それがあなたができる開発者になる秘訣です。
もちろん実際には予算や工数との兼ね合いになります。
だから、常に最高のシステムを提供できるわけではありません。泣く泣く品質を落とす場合もあります。
けれどもできる範囲での最高のシステムを。
それは開発者の開発者たる義務なのです。
