lTサービス開発において、機能要望を仕分けするためのヒント
この文章について
例えば既存の業務システムやウェブサイトを作り変える際、通常、既存のユーザに改善要望を聞く、ということをします。
しかし、IT開発において、どのような機能を実装するかの議論は、実に、発散しやすいものです。
ある程度規模のあるシステムの場合、必ず「あれも欲しい」「これも欲しい」の大合唱が置きます。
要望リストが、あっという間に、何百行、何千行になっていく。
この文章は、そういう状況で、何をどのように考えるとドツボにはまるのか、どうすれば、脱出できるのかを解説します。
IT開発における機能検討のよくある姿
通常、上記のような検討の場では、優先度の吟味が始まるわけですが、よくあるのは、
絶対欲しい A
まぁ欲しい B
できれば欲しい C
みたいなものを作っていく、という流れです。
これらに、開発工数や難易度、コスト等を加味して、開発内容を絞っていこう、という発想です。
非常に合理的な流れです。
が、よくあるのは、Aだけでも、莫大な開発リソースを消費することが判明する、という状況です。
そこで、
ここだけは譲れない S
みたいな概念を捻出することになる。
しかし、それでも絞り込めない。SSが必要ではないか、いや、S+とかS--とすべきだ、といった議論に発展していく。
そして問題は、誰の意見が強いのか、誰が損を被るのか、という政治の舞台に移行します。
結果として、製品とユーザの存在は、忘れられていきます。
この先に待ち受けるのは、複雑怪奇で意味不明なUIができあがるという、誰も幸せにならない状況です。
エクセルシートで要望リストを確認すれば、確かにバツはつかない。
しかし、プロダクトとしての魅力が、感じられない。使いやすくない。
もちろん、ユーザの声を聞くのは大事なのですが、それに惑わされては、ユーザを見失うので、要注意です。
なぜ、こういうことが、起きるのか。
そもそも、検討過程自体が、誤りなのです。
開発機能を仕分けする、唯一無二の視点
どの機能を実装するか、しないかの基準は、実は、とてもシンプルなのです。
その事業のコンセプトや戦略、あるいはビジネスモデルやオペレーションの観点で、
本当に必要なものは、万難を排してでも、実現する。
あったらいいな、というレベルのものは、断固として、退ける。
それだけで、よいのです。
なぜ、そうなのか。
IT開発は、
作るのは簡単だったとしても、
期待通りに動くようにするのは、
果てしなく困難なのです。
多少乱暴な言い方をすれば、
前者のことを、機能要件を満たす（正常系で、設計者の意図通りに動作させるようにする）と、いいます。
後者を、非機能要件を満たす（異常系も含め、あらゆる利害関係者から文句が出ないようにする）と、いいます。
前者を満たすのは、極端な言い方をすれば、コードを書き加えるだけでよいのです。
いまどき、色んな部品がオープンソース化され、モジュール化され、ライブラリ化されています。
IT開発は、効率化のために、「ゼロから作る」よりも「組み合わせるだけ」が良しとされています。
ゆえに、確かに、加えることは、簡単なのです。
しかし、その裏腹に、前者を増やせば増やすほど、見えないところで、後者を満たすことの難易度が上昇するのです。
例えば、動作確認。
いまどき、デバイスも多様で、ブラウザも多様です。種類だけでなく、バージョンも様々です。
ユーザのマシンスペックや接続環境も様々です。
ひとつ機能を加えて、それらをすべて試験して回るのは、もはや不可能です。
ゆえに、ITサービスには必ず「前提とする動作環境」を定義します。
ちなみに、自治体や官公庁が提供するサービスは、この「前提」が恐ろしく長いことが、よくあります。
前提を超えて、もはや言い訳。
免責事項が多すぎて、「使ってくれるな」というメッセージすら、感じることもあります。
これは、彼らが「住民からのクレームに弱い」ということによります。
例えば、パフォーマンス。
機能が組み合わされば組み合わさるほどに、反応速度は下がっていきます。
UIUX以前に、パフォーマンスの悪いITサービスは、その時点で、嫌われます。
SEOでも、レスポンス速度が、極めて重視されています。
しかし、もし、本当にパフォーマンスを出したかったら、機能に最適な基盤から、作らなければならないのです。
例えば、セキュリティ。
機能を増やせば増やすほど、セキュリティの穴は、増えていきます。
機能を増やすにあたって、使い慣れていない部品を使えば使うほど、リスクは、増していきます。
ほとんどのIT開発では、要件定義工程において「機能を増やす」ことばかりに気が向きがちです。
また、ほとんどのIT開発では、試験をする頃になると、時間が枯渇します。
人間は、なぜか、機能を増やすことには希望を感じる生き物です。
試験を減らすことには、意外と、ためらいがありません。
世の中のITサービスの（特に業務システムの）多くが「使いにくい」と言われているのは、このような事情によります。
本当にあった、ログイン認証機能の怖い話①
一例として、実話を通して、こうした話を解説します。
ひとつは、筆者の、サービス提供者としての実体験から。
あるオリジナルなWebサービスを開発した際、会員登録にgoogleアカウントによるログイン機能を追加することにしました。
無事、実装することができ、自分も、その機能を使って、ログイン認証を行っていたのでした。
リリース後、半年してから、「会員登録できない」という連絡が入りました。
確認すると、googleアカウント認証機能の部品にアップデートがあり、その対応が漏れていたのでした。
調べてみると、半年間、その事象をほったらかしにしてしまっていたことが判明しました。
半年間、かなりの人が、会員登録に失敗していたのです。
が、誰もそれを、連絡してくれなかった。
まぁ、それはそうです。
無料サービスは、使いにくければ、使わない。
それが、ユーザの立場です。
新規ユーザ登録してくださる人は、事業にとって、宝よりも価値がある存在です。
こうしたことが、大いなる機会損失の垂れ流しであることは、自明です。
しかし、ITサービスは、不具合があっても、気付くことすら困難である、ということが、意外とあります。
本当にあった、ログイン認証機能の怖い話②
もうひとつは、筆者のユーザとしての、実体験です。
あるワインアプリを使っていたのでした。
飲んだワインの写真を登録し、コメントする。
SNS機能があって、他のユーザと繋がれる。
そんなアプリです。
3年ほど利用して、ワインリストが800本ぐらいになった頃でしょうか。
突然、ログインできなくなりました。
最初の2週間ぐらいは、なぜなのかもわからない。運営のアナウンスも、要領を得ない。
時間が経って、ようやく、facebookアカウントによる会員登録・認証が原因だったことが発表されました。
これも、ログイン認証のモジュールにアップデートがあって、それで生じた不具合だったようです。
問題は、その結果、どうなったのか。
まさかの「アカウントの再作成」をお願いされたのでした。
理由はわかりませんが、過去のデータを復旧するのは、どんなに頑張っても不可能だったそうです。
800本のワインリストは、諦めました。
まぁ、無料のサービスだったし、しょうがないといえばしょうがいないのですが・・・。
ただ、それは、いち利用者にとっては、単なるデータではなく、思い出なのです。
しかも、相当の時間とお金を投資した、貴重な記録でした。
自分にできることは、ただ、そのワインアプリは二度と使わないことだけ。それだけです。
そして、貴重な記録は、お金をかけてでも、ちゃんとした仕組みを利用すべきということを、学びました。
まぁ、ちょうど、ワインの記録を残すことに飽きたところだったので、まぁ、それきりですが。
ただ、そのアプリの提供者は、ワイン業界やアプリ業界に、相当悪い印象を残したことだけは、確かです。
まとめ
上記のログイン認証の件は、たったひとつの例です。
他のあらゆる機能（検索やデータ連携等）においても、事情は同様です。
発生した問題が、運用途中で対処できる問題なら、まだ、いいのです。
パフォーマンスなどは、一度動かしてしまうと、根本的な構造を、あとから修正するのは非常に難しいのです。
もちろん、チューニングできる部分もありますが。
（ほら、だって、Windowsって、いまだに、起動が遅くないですか？）
どんなにCPUやGPU、グラフィックボードその他の性能が向上し、AIが開発されても、Windowsの起動は早くならない。
開発内容は、本当に必要なものを、絞り込む。
たったこれだけのことが、IT開発においては、本当に、大事です。
「使いにくいサービス」は、この「絞り込む」ということができない結果、発生します。
あってもなくてもいいものは、ないほうがいいんだな （相田みつを）
ちなみに、この文章を書いている「cosense」(旧称：scrapbox)というサービスは、本当に本当に、素晴らしいですよ。
必要なものが、とことんまで、追求されている。
本当に称賛すべきなのは、AIではなく、こういうサービスなのです。