プログラミングシンキング：05 ソフトウェア開発の目的
前回までのおさらい
これまでの４回のシリーズで、実現したい機能から、フローチャート、ユーザインタフェースを設計して、ノーコードやローコードでプロトタイプまで非プログラマーの方でもできるお話をしました。今回は、実現したい機能をどうやって整理すればよいかについてお話します。
デザインシンキングやロジカルシンキングでは、顧客などステークホルダーの価値やメリットを明文化することが多いと思います。これを起点として、機能に落とし込み、フローやインタフェースを設計していくことになります。デザイナーに頼めば、オーサリングツールやデモ映像で表現してくれることもあるでしょう。一見、立派なプロトタイプに見えるかもしれませんが、多くの場合、ひとつの流れでしか表現されていなくて、ソフトウェアとしての機能は完結していません。
今回は、より良いプログラムを開発するために、顧客への提供価値を完結した機能としてプログラマーに伝える方法についてお話しようと思います。
何かを変える
顧客の要望をソフトウェアなどの形にして提供する目的は、顧客の何かを変えるということです。ユーザインタフェースの回でお話したように、ソフトウェアを使ってもらうとき、ユーザには時間や認知的負荷をかけてしまいます。その代わりに、これまで◯◯だったことが、◇◇になる、といったことをお返ししなければいけません。この変化が機能として表現されているか？を考えるとよいと思います。ヒアリングなどを通じて、顧客の困りごとをお聞きして、整理・分解・再構築してみましょう。これらの困りごとをソフトウェアで解決できそうなら、その機能を考えてみましょう。
まず、これまでアナログな手段で手間がかかっていたことを効率化したい、という場合であれば、単純にデジタル化(Digitization)するだけでいいかもしれません。手書きの表をエクセルなどのスプレッドシートに変えるだけの話です。これだけでも、入力や修正が楽になったり、画面や印刷したものが見やすくなったりすることで、顧客の経験価値は変化するでしょう。デジタル化とは、アナログの情報をデジタルで表現された情報に変えるということです。
デジタル化された情報は、広く活用することができます。サーバーで共有すれば、場所や時間を越えてアクセスできますし、そのデータから業務の計画を立てたり、顧客との接点など業務そのものの改善点を見いだせたりできるようになるでしょう。このように、業務プロセス、ビジネスモデル、組織のあり方なども変えることができます。これをデジタライゼーション(Digitalization)と呼ぶこともあります。
さらに、最近ではデジタルトランスフォーメーション(DX: Digital Transformation)という言葉も多く使われるようになりました。DXとは、社会全体を変革するという意味です。デジタル化の主語は「情報」、デジタライゼーションの主語は「産業や組織」だったのに対して、DXの主語は「社会」です。公共サービスはもちろん、様々なソフトウェアが社会を変えつつあります。ただ、DXという言葉があちこちで使われるようになって、単なるデジタル化でもDXと呼ばれてしまっているケースもあります。後述しますが、この手の大風呂敷の言葉は往々にして意味が矮小化されていきます。
https://ja.m.wikipedia.org/wiki/%E3%83%87%E3%82%B8%E3%82%BF%E3%83%AB%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B9%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3
ソフトウェアがもたらす変化の５つのパターン
ではソフトウェアは、具体的にどんな変化を提供できるでしょうか。例えばこんなものがありそうです。
① 作業を効率化して、負担や誤操作を減らす
② 現象を模擬して、最適な条件を見つける
③ 経験を活用して、暗黙知を伝承する
④ 未来を予測して、事前に対処する
⑤ 状態を判断して、問題を発見する
さらに、物理・サイバー攻撃を防御する(Security)、商品やデータを流通させる(Distribution)、意思を伝達する(Communication)など、他にも変化をもたらすソフトウェアはたくさんあるでしょう。
ソフトウェアがもたらす５つの変化
① 作業を効率化して、負担や誤操作を減らす
作業を効率化する目的は、人間の作業の負荷を軽くしたり、ヒューマンエラーが起こる確率を減らしたりすることにあります。そのための取り組みとしては、次のようなものが考えられます。
たとえば、アナログ的な作業であれば、データ形式を統一してデジタル化すると、データの修正や再利用が容易になるでしょう。設計から製造、その後のメンテナンスまで部品を統一的に管理するBOM（Bill Of Material）技術も広まっています。また、膨大な計算や資料の作成を自動化することで、作業時間を減らし、ヒューマンエラーを低減することもできます。これはRPA (Robotic Process Automation)と呼ばれています。
さらに、たくさんのデータが表などにまとめられた数値は、人間の認識に多大な負荷をかけます。ビジュアリゼーション技術や３次元CG (Computer Graphics)、VR (Virtual Reality)、AR (Augmented Reality)などの可視化技術も役立ちます。
以前、世界銀行(World Bank)や国際通貨基金(IMF)などが公開している各種指標の時系列データを３次元空間上にビジュアライズ・分析するソフトウェアを作ったことがあります。人口や国内総生産(GDP)などの基本情報の他、水をどのくらい消費しているか、また、農業、工業、生活のどこにどれだけ水が使われているか、といった情報をインタラクティブに見ることができる、というものです。３次元空間をマウスでグリグリ動かしながらデータを見るのは楽しく、一見わかりやすいと感じますが、錯覚でした。３次元の情報は動かしながらでないと意味がなく、その画面を印刷してしまうと余計にわかりにくくなってしまいました。可視化技術を使えばなんでも解決する、というわけでもありません。
プログラムは人間をラクにしたり、ミスを減らしたりします
② 現象を模擬して、最適な条件を見つける
コンピュータで現実世界の現象を模擬すれば、実際にモノを作らなくても、設計の時に性能を予測できるようになります。また、装置などの稼働条件を変えたときの影響を計算して意思決定に役立てたり、最適な条件を探索したりすることもできます。
シミュレーションのためには、実際のモノがどう動いているか、条件を変えたときにどう変化するのか、といった物理・化学の知識が必要です。これは演繹的アプローチと呼ばれています。
この手法は、たとえば台風などの大雨が降った場合の洪水予測に役立ちます。ある分水嶺に囲まれたエリアにどれだけ雨が降るかといった気象予測データを入力すると、地形の３次元データや、水の染み込みやすさの土壌データを用いて、河川がいつ、どのくらいの水量になるかを計算することができます。分布型流出モデルと言います。さらに、河床や堤防の形状を用いて、いつ、どの程度水があふれるかも計算できます。最近のハザードマップは、このようなシミュレーション結果から作成されています。同様に、地震発生時の津波の到達予測、鉄道の事故発生後の混雑予想などにも使われます。演繹的アプローチと帰納的アプローチを組み合わせた手法も開発されています。
プログラムで自然現象を予測して災害などに備えます
③ 経験を活用して、暗黙知を伝承する
経験を活用する方法は、昔から広く使われています。現状と同じパターンを過去のデータから探して、このあとどうなるかを予測したり、どう対処すればよいかを検討したりすることができます。また、職人などの頭の中だけに入っている技術やノウハウなどの暗黙知を、データやツールとして形式知化することで、後世に伝承することもできます。
たとえば、夏の最高気温とアイスクリームとアイスキャンディーの売り上げの関係がよく知られています。暑ければどちらも売れるのですが、ものすごく暑くなると、アイスクリームは売れずに、アイスキャンディーがさらに売れるようになるそうです。
第二次人工知能ブームに流行ったエキスパートシステムは、これらの知識を十分に入力できれば、人間と同じような知能が可能になることを夢見ていました。そして、フレーム問題という壁にぶつかり、ブームは去ってしまいます。ですが、統計解析などの様々な技術が確立され、現在でも多く使われています。
過去の経験や暗黙知をプログラミングして知識を伝承します
④ 未来を予測して、事前に対処する
未来を予測するためのさまざまな技術が開発されています。消費動向や、装置の寿命、環境の変化、などを予測することで、事前に対策することができます。未来の予測には、帰納的アプローチと演繹的アプローチの両方があります。現象の理論から出発する演繹的アプローチでは、理論をプログラミングして、将来を予測します。帰納的アプローチでは、過去のデータの統計解析や機械学習で得られたパターンを使って予測します。ディープラーニングもこの一種です。
日本では、少子化が深刻な社会問題になっています。1970年代後半から出生率は急速に減少しています。ところが、国立社会保障・人口問題研究所が出している出生率推計では、いずれも発表時の出生率から少し回復して、その後一定に保たれるというカーブを描いています。このパターンは、1976年の推計から続いています。何らかの少子化対策の政策が実行されているので、出生率の減少に歯止めがかからないとは言えない、という事情が反映されているのかもしれません（個人的な憶測です）。何らかのアルゴリズムを使った予測だとしても、予測する人の希望的主観が入ることは多々あります。予測値を見るときは、誰が、どのような手法と根拠で算出したのかを見極めるリテラシーが重要になってくると思います。
要するに占いです。
https://www.boj.or.jp/announcements/press/koen_2012/data/ko120530a1.pdf
AIの未来予測は占いのようなものです
⑤ 状態を判断して、問題を発見する
状態を判断するとは、新しいデータが入ってきたときに、正常なのか異常なのかを見極めることです。データの組み合わせが、過去に経験していたかどうかを判断します。
クラスタリングと呼ばれる手法は、過去のデータの組み合わせをグループ（＝クラスタ）に分けるというものです。あるグループは正常な状態で、別のグループは異常な状態として区別することもできるでしょう。また、入ってきたデータがどのグループにも当てはまらなければ、経験したことのない状況だということが言えます。クラスタリング手法は、K-means法、サポートベクターマシン(SVM)、ART (Adaptive Resonance Theory)などが知られています。
たとえば、簡単な回路を考えてみます。電流と電圧を測る装置から、電流と電圧値のデータを蓄積できるとします。普段は、電圧Eが高いと電流Iも大きくなり、電圧が下がると電流も小さくなるような、正の相関が見られるでしょう。オームの法則のE = IRですね。抵抗Rが一定なら計測データは直線に乗ります。この電圧と電流の２次元のデータの塊をクラスタと言います。あるとき、電圧は高いのに電流が小さいデータが来たとします。これは、明らかにクラスタから外れており、これまでに経験したことのないパターンです。何らかの原因で物理的に回路が破損し、抵抗が異常に大きくなったためかもしれません。このように、原理は演繹的にわからないものの、データから帰納的に判断するために、クラスタリングが用いられます。
理屈から外れたデータこそ、物事の本質の理解に役立ちます
破綻のない完結したフロー
小説、音楽、映画、演劇などの純粋な時間芸術作品と、ゲームを含むソフトウェアの大きな違いは、時間や順番の流れが１種類かそうでないかです。時間芸術は観客や読者の意思とは関係なく、場面が推移していきます。一方、ソフトウェアの多くは、ユーザの操作によって場面が推移します。
もちろん、例外もあります。観客からお題をもらって、即興で話を作る落語家や演劇もありますし、ウィザードのように強制的に場面が推移するソフトウェアもあります。
それはともかく、一般的にはソフトウェアはユーザの操作に応じて、適切な場面（画面）に推移するように設計する必要があります。ユーザはこう操作するだろうと思い込んでしまうと、１種類の流れしか設計できなくなってしまいます。実はこのようなケースをよく見かけます。ユーザの操作は必ずしも１つとは限りません。
ユーザの操作と画面遷移を整理するために、下図のようなダイアグラムを作成することをお勧めします。すべての画面はアクションでつながっている必要があります。画面間の関係を矢印で結ぶ図を画面遷移図と呼ぶことがあります。画面間を繋ぐだけでなく、ユーザが操作するボタンなどのUI部品まで書き込んでおくのがよいと思います。
１本の流れだけでなく、すべての操作のパスを書ききる
個人ワーク
今回の個人ワークお題は、「あなたは、誰の何を変えたいですか？」にしましょう。顧客が何に困っていて、どうすればそれが解消されるかをイメージしながら、５分間考えてみてください。
プログラマーの生態
以前、プログラマーは定義にこだわるという話をしました。単なる「デジタル化」を「DX」と称しているのを見ると、もやもやしてしまいます。このような言葉の意味の陳腐化は、昔から繰り返されています。
「クラウド」という言葉が出始めたころは、複数のサーバーに置かれているAPIを活用してマッシュアップし、あたかもひとつのサーバーにみえるようなサービスまたはWebアプリ、という意味で使われていたと記憶しています。現在もWikipediaにはそのように定義されています。にもかかわらず、単なるサーバーとして使っている例を見かけることが増えてないでしょうか。「クラウドに置いといて」というと、Webサーバー上のストレージの意味で使われていますよね。
https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89%E3%82%B3%E3%83%B3%E3%83%94%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0
最近ではプラットフォームという言葉も乱立しています。人によって定義が異なるので、なるべくなら使いたくありません。
根本的で、古くて新しい例では、アナログとデジタルも難しい問題です。連続値か離散値か、物理的なモノか情報か、自然か人工か、という区別などもありえますが、私はどれもしっくりきていません。一般的には、アナログは滑らかで、デジタルは拡大していくと量子化されていてギザギザしている、という印象があります。ということは、アナログとデジタルの違いは、どうやって観測・測定するか、といった問題も絡んできそうです。また、「座標(10, 20)を中心とする半径30の円」というベクトル表現では、使われている10, 20, 30という数字はデジタルですが、どこまで拡大しても滑らかです。
めんどくさい言葉は使わない方が無難ですね。
まとめ
今回は、使う人の何を変えたいかを考えて機能を定義し、破綻のない完結したフローを設計して、プログラマーに伝えましょう、というお話をしました。
Programming Thinking Clubの第１回では、顧客の要望を「◯◯したい」という表現に落とし込むのは機能リストに繋げるひとつのテクニックというお話をしました。使う人の何を変えたいかを考えるというのは、この機能リストを作成する方法の補足になります。
また、第２回では処理の流れを表すフローチャート、第３回ではユーザインタフェースのお話をしましたが、破綻のない完結したフロー設計は、この２つの補足です。
これらを踏まえて、第４回でお話したローコードツールでワーキングモックアップを作ってみて、自分自身、同僚、まったく関係ない人に確認してもらうことで、よりコンシステントな仕様を策定できるようになると思います。
つまり私は、これまでの５回の話で、非プログラマーのみなさんが、プログラマーと上手くコミュニケーションできて、イケてるソフトウェアを開発できるように変化する、ということを期待しています。
この記事が気に入ったらサポートをしてみませんか？