プログラミングシンキング：02 フローチャート

前回のおさらいとプログラミングシンキングの位置付け

　前回の「機能ブロック図」では、「（誰々が）〇〇したい」と書き出して、実現したい機能を明確にしてプログラマーに伝えましょう、というお話をしました。必ずしも機能ブロック図っぽく作図する必要はなく、大切なのは実現したい機能がリストアップされた文章です。今回は時間の概念を加えて、これらの機能の順番を考える「フローチャート」についてお話します。フローチャートも同じように、作図すること自体は重要でなく、どういう「順番」で機能を実行するかを明確にする、に尽きます。

　まずその前に、プログラミングシンキングと、ロジカルシンキングやデザインシンキングなどとの関係を整理してみましょう。ロジカルシンキングとは、複雑な現状を「分析・整理」するための方法論と言えるかもしれません。漏れやダブりなく考えるMECE（Mutually Exclusive and Collectively Exhaustive）や、ロジックツリーなどの手法をお聞きになったことがあるかと思います。また、ある状況が変化すると、このような影響が考えられるといった動的な複雑さを分析する方法をシステム思考（システムシンキング）と呼ぶことがあります。因果ループ図 (CLD: Causal Loop Diagram)などの整理方法が使われています。

　これに対してデザインシンキングは、私の解釈では「発見」のための方法論と言えると思います。ここで言うデザインとは、ファッションやグラフィックなどの意匠のことではなく、設計や合意形成といった問題の解決という意味で使われています。人間や社会を分析するエスノグラフィー、プロトタイピングなどを通じて仮説を検証するプロセスが用いられています。

　また、最近ではアートシンキングという言葉も使われています。個人的には上記の思考法と決定的な違いはないと感じていますが、あえていうなら、０から１を生み出す「発明」のための方法論でしょうか。

　では、プログラミングシンキングとはどのように位置づけたらよいでしょう。実現したいことを整理し、適切な製品・サービスがどうあるべきかを発見するという意味では、ロジカル／システム／デザインシンキングと同じ目的です。ただし、アイデア段階から、製品やサービスを具体化する一歩手前のプロトタイピングのフェーズに近い方法論だと考えています。往々にして、アイデア段階でいろんな方法論を試していると、パワーポイントのスライドは量産されるものの、泥沼にはまって抜け出せないことがあります。デザインシンキングでも強調されていることですが、ある程度のアイデア段階でプロトタイプを作って、いろんな人からの意見を聞いてみる方が、話が進むことが多いと思います。また、プロトタイプで十分に課題が検証されていれば、実際の製品・サービスも短期間で開発できるでしょう。

　ではどうやってプロトタイプを作ればよいのか。それがプロトタイプシンキングであり、ソフトウェア版がプログラミングシンキングと言えます。プログラミングなどのスキルを持つプログラマーと持たない非プログラマーの意思疎通を円滑にするための思考法です。後述するつもりですが、ソフトウェアに限らず、この考え方はあらゆるモノづくりに応用できると思います。

フローチャートってなに？

　さて、フローチャートの話に戻りましょう。フローチャートは、実現したいことの機能を順番に並べて、プログラムの骨格を表現する大切な図です。たくさんの図形が複雑に配置されていて、矢印があちらこちらに繋がっているのを見ると拒絶反応を示す方もいらっしゃるかもしれません。ですが、登場する図形は基本的に長方形とひし形と矢印だけです。最初と最後だけを角丸の長方形を使うこともありますが、大した意味はありません。長方形は前回お話した「機能」をあらわしています。ひし形は「条件文」です。フローチャートは、アルゴリズムを具体的に記述する一つの手法です。アルゴリズムは、この他にプログラミング言語でコードを書いたり、自然言語で書くこともできます。つまり、機能ブロック図を作図する代わりに、「〇〇したい」という平文で書いても同じだったように、フローチャートも文章で書き出すことができます。

　ふたたび、自動販売機の例でみてみましょう。簡単のため、現金決済で、炭酸水とお茶だけの自動販売機を考えてみます。処理の流れは、

1. 販売価格以上の金額が投入されるまで待機する
2. 商品ボタンを点灯する
3. ボタンが押されるまで待機する
4. 炭酸水のボタンが押された場合は炭酸水を、お茶の場合はお茶を取り出し口に搬出する
5. 投入金額が販売価格より多い場合はお釣りを払い出し、同額の場合は何もしない
6. 最初に戻る

となります。フローチャートで書くとこうなります。

　順番がきちんと言語化されていれば、自動的にフローチャートに変換できますし、実際のプログラムのコードにも実装できます。
とくに大切なのは「順番」です。プログラムという言葉は、特定の目的のために前もって(pro-)書かれたもの(-gram)です。テレビ番組、予定表、式次第などという意味で使われてきました。電子決済の場合の自動販売機のフローチャートも書いてみてください。順番が大きく変わります。

個人ワーク

　それでは、実際にやってみましょう。お題は「朝のタスク」です。朝起きてから出かけるまでにやるべきことを文章で書き出してみてください。順番を意識して、少なくともひとつ条件文を入れてください。例えば、天気や気温、外出の目的や会う人、その日の気分や体調で内容が変わるかもしれません。時間は５分です。

＊　＊　＊

　できましたでしょうか。下記は条件文を省いた私の例です。多少の違いはあるにせよ、みなさん似たような順番ではないでしょうか。

1. 朝食を食べる
2. 歯を磨く
3. 食器を洗う
4. 顔を洗う
5. 着替える
6. 戸締りをする

　順番を考えるとき、その機能を実行する準備ができているか？を考えるとよいと思います。朝食が済んではじめて、食器を洗うことができます。また、戸締りをして出かける前に、着替えも済ませておかなければいけません。一方で、順番を入れ替えても問題がない場合もあります。３の食器を洗うと４の顔を洗うは、入れ替えてもいいかもしれません。状況が複雑になってくると、状態遷移図や状態変数を使って機能が実行可能かどうかを判断することもあります。これはプログラマーに任せてよいと思いますが、大まかな流れを考えるとき、実行可能かどうかを意識しながら順番を決めてください。

　ところで、下記を見てください。違和感を覚えるでしょうか？

1. 顔を洗う
2. 着替える
3. 戸締りをする
4. 朝食を食べる
5. 歯を磨く
6. 戸締りをする

　たとえば、ホテルに滞在していて、朝食がビュッフェ形式の場合、こんな感じになるかもしれません。機能は同じでも、状況によってフローチャートは変化するのです。

プログラマーの生態　その２

　前回説明した機能ブロック図が階層的なのと同様に、フローチャートも階層的になります。このとき、下の階層で詳細を記述する機能の四角形の両側に線を入れることもあります。

　いいかげんに書いたプログラムは動きません。非プログラマーはそこまで考えなくていいのですが、プログラマーは一文字も間違わずに細部まで気にしています。階層が深くなると、さらに慎重になり、ロジックを追って階層をあちこち上下しています。そんなとき、私は息をしてないこともよくあります。話しかけても返事がない、反応が薄い、ということがあるかもしれませんが、大目に見てあげてください。数分後にはこちら側に戻ってきていると思います。

　こちらの漫画はプログラマーの気持ちをとても的確に表現してくれていると思います。

言迷水／日音黒通信団フ゛ロンス゛戦闘員【公式】
https://twitter.com/itm_nlab/status/1259800479267270656/photo/1

　もう一つ、ひし形で記述する条件文について、プログラマーは厳密に考える傾向があります。プログラミング言語も言葉ではありますが、形容詞はありません。特許の明細書や法律も同じだと思います。朝、着ていく服を選ぶとき、暑かったら半袖とか、偉い人と会うからスーツを着る、という条件文が考えられますが、暑いとは？偉い人とは？を決めなければプログラミングできないのです。この場合は、私が暑い、偉いと感じたら、といった主観でいいのですが、例えば最高気温の予報が３０度以上だったらとか、取締役以上の職位とか、客観的な定義やしきい値が必要になります。「明日は暑くなるのかなー？」と聞かれて、いくらプログラマーでも「暑さの定義は？」などとは聞かないとは思いますが、心の中では「平均気温かな、最高気温のことを言ってるのかな？ それとも湿度を含めた体感気温のことかな？」とか思っているに違いありません。メンドクサイですよね。慣れてください。

言迷水／日音黒通信団フ゛ロンス゛戦闘員【公式】
https://twitter.com/genmeisui/status/1257973602038591488/photo/1

まとめ、次回予告

　今回はフローチャート、すなわち実行する機能の順番についてお話しました。その機能は実行する準備が整っているかを意識して順番を決めてください。また条件文は、客観的に定義できる数値で表現してください。必ずしもきれいにフローチャートを作図する必要はありません。文章で十分です。

　次回は、いよいよ人間とソフトウェアが接する界面、インタフェースのお話です。使いやすいユーザインタフェース(UI)、ポジティブな体験を与えるユーザエクスペリエンス(UX)をどう設計すればよいのか、考えたいと思います。

　今回、さんざんフローチャートのお話をしましたが、最後にフローチャートをdisるおまけを追記しておきます。

おまけ　PADを使おう

　アルゴリズムをグラフィカルに表現する手法には、フローチャートの他にPAD （Problem Analysis Diagram）と呼ばれる記述方法もあります。1979年に日本の企業の研究者が考案しました。現在でもフローチャートを使う人の方が多いのですが、PADの方が格段に簡潔に書けます。

　フローチャートは、同じアルゴリズムでも、違う図が描けてしまいます。これは条件文のひし形の左右と下の３つの頂点のどこに条件の結果を割り当ててもよい、という自由度がひとつの理由でしょう。また、ループを表現するために下から上に矢印付きの線で結ぶなど、線の数が増えたり長くなったりしがちです。また、ひし形の内部に文字を書こうとすると、どうしてもスペースが狭くなります。さらに、条件文の結果は３つまでしか選べず、それ以上になると複数のひし形をつなげなければいけません。どうやらひし形が諸悪の根源のようです。

　これに対しPADは、ひし形の代わりに、長方形の右側をリボンのようにギザギザにカットした鯉のぼりのような形を使います。２択の場合は右側に２つの凸の角がある五角形になり、上がYes、下がNoと決められています。フローチャートのひし形の場合は、どこがYesなのか明示する必要がありましたが、このルールがあるのでPADでは不要です。３択以上の場合はギザギザを増やして、それぞれに条件を記載することになります。フローチャートではひし形をいくつも書く必要がありましたが、PADではひとつにまとめることができます。

　機能の書き方はフローチャートと同じ長方形ですが、長方形の左に沿って流れを示す線を書くのが流儀です。処理の流れは上から下、左から右と決められていますので、フローチャートで必要だった矢じりも不要です。
また、ループは長方形の左に１本の線を追加することになっています。下から上に戻る長い線を書く必要もなくなります。

　PADであれば、同じフローは、誰が描いてもほぼ同じ図になりますので、プログラムとの相性もよいと思います。なにより図がスッキリして理解しやすいですし、作図の時間も節約できます。幼稚園～小学生向けのビジュアルプログラミング言語のscratchも、考え方はPADにかなり近いと思います。
こんなにいいこと尽くしなのに、なぜフローチャートの方が広まっているのかわかりません。考案者の二村氏は、「アラビア数字が、それまで使われていたローマ数字に置き換わり、以降の数学の進歩に貢献したように、PADも国境を越えて後世に生き残ってほしい」とおっしゃっています。
https://www.hitachihyoron.com/jp/pdf/1986/05/1986_05_02.pdf