今年度から義務教育化された「プログラミング的思考」について、私流の角度でプログラミングに入る前の思考の方向性（準備運動みたいなもの）について書いてみたい。
これからの現場に（本当は20年前からだが（笑））必要とされる思考とは。
例えば職場がECを始め、注文番号を数字8桁に定めたとする。00000001、00000002という具合に0から始まる数字にすると、例えば「00105385」ならエクセルに入力した際「105385」に変換されてしまう。
データには「型」があり（プログラミングでもデータベース[SQL]でも同じ）、数値の場合は明示的なゼロ埋め（桁数揃え）をする特別な取り決めがない限り「00105385」は「105385」として見なされる。エクセルでは「数値」でも「標準」でも同様に扱われる。
/*
明示的ゼロ埋めとはクレジットカードの有効期限入力欄などに「月/年を入力してください。例：05/20」と書いてあるような場合。型が数値の場合、202005ならそのままでも崩れないが、0520と格納すると520に変換されてしまう。
*/
入力者が正しく8桁入力したと後から確認できる場合は「00105385」と入れたものが「105385」になったのねと解釈できるが（解釈に委ねるべきではないが）、必ずしも正しく8桁入力されたかどうか不明な場合は「105385NN」だったのか、「1053NN85」と入力したものが編集を繰り返しているうちに欠落したのか断定できない。
「8桁の注文番号（とか会員番号）をお願いします」と言われて「8桁の数字はどこにも書いてないんですけど」「注文確認メールの上部に注文番号（とか会員番号）があるはずですが」「えっと、6桁の数字はあるんですけど」「ではそれを教えてください」みたいなケースは大凡コレが原因。
初期段階での知識や理解の乏しさや計画性のなさが尾を引く。加えて担当者に対する配慮の欠如。
そこで短絡的に「だったら文字列として扱えばいいじゃない」と考える人がいる。確かに「8桁」は維持されるが見た目が数字なだけで「数値」としては扱われないため、SUMなどの計算ができなくなる。
※エクセルではフォーマット／セル／表示形式で変更できる（Macの場合）。
IF関数はエクセルに留まらず、あらゆるプログラミング言語でも使われているもの。図で「黄色いセル」と書いたところは実際のセル（A4など）を指定する。
IF(論理式,値が真の場合[A],値が偽の場合[B]) という式で（カンマ「,」で区切る）、意味はIF（もし）論理式が正しければ[A]の値を、正しくなければ[B]の値を表示する。
この図の例では、もし黄色いセルに入っている数字が 200000 よりも小さければ 1 を、そうでなければ 0 を表示するという式。当然 00105385（105385） は 200000 よりも小さいので 1 が表示されるはずだが、文字列ではそうはいかない。
仮に、文字列にして（見た目上）解決したつもりになった場合、後にどんな問題が起きるだろう。
「注文番号200000以下かつ入荷連絡[必要]ステータスを抽出する」という場合。
かつ（and）は =IF(AND(条件式1,条件式2),真の場合,偽の場合）とする。
この例では =IF(AND(注文番号のセル<200000,入荷連絡のセル="必要"),1,0）と書く。両方の条件式を満たせば真、片方だけ満たした場合または両方とも満たさない場合は偽。前述の通り、文字列では「200000以下」という判定さえ正常に機能しない。
※私がとりあえず返値を 1 か 0 かにするのは、その列のSUMを採れば件数がわかるから。1か2かにするとそれができない。直感的に見やすくするため「"必要"」「"不要"」としても良い。文字列の場合は""で囲む。
/*
この条件式はあらゆるところで使われているので、A以上、A以下、A未満という場合「A」を含むのかとか、AかつB（and）、AまたはB（or）とはどういう意味なのかを親子コミュニケーションレベルで小さい頃から正しく教えた方がいい。
エクセルの場合「数値」「標準」として数字を入力すると右寄りに表示される。一・十・百・千・万と小さい位から数えていくし、桁の違う数字が列ぶ売上票などではその方が大小が解りやすいから。一方数字の羅列を「文字列」として入力すると左寄りに表示される。横書きは左から右に読むのが基本だから。ヘブライ語でもない限り。
ということから人為的に中央揃え、右揃えなどをしていない限り、パッと見で数値なのか文字列なのか解るようになっている。その辺も豆知識として教えておくと子供達の理解が深まる。
*/
「じゃぁどうしろって言うの！」じゃなくて、それを自分で考えなさいというのがこの20年のデジタル社会であり、もういい加減ちゃんと解ってないとダメよというのが今年以降の義務教育時代。
イチバン間違いないのは、10000000、10000001、10000002 ... 10105385だろう。
新会社や新しい事業・部署を立ち上げた際、何かと管理用のエクセルファイルを作ることになる。そこで後先考えない人が作ったもので運用が始まると、いずれ担当者や後任が困る（生産性が下がる）ことになる。
「○○が必要なら○○すればいい」は単細胞（笑）で、「今後○○が必要だが、○○を継続するためには何が必要か、どうすべきか」を考えて行動するというのがプログラミング的思考の基礎。
例えば商品リストを作る場合、本体価格×税率を電卓で計算して税込価格を商品数分入力した場合、税率が変わった時に全ての値を再計算して書き換える必要がある。全セル手作業。
次の段階として、本体価格セル[A]と税率セル[B]を分けて、税込価格セルを =An*Bn とすれば、税率が変わった時に税率列をオートフィルで一気に書き換えたら良いと考える。しかし軽減税率などのように税率列に8%と10％が混在していると「オートフィルで一気に」とは行かない。
次の段階では、税率は定数なんだから（多くても2種類、観光客の免税を入れたら3種）、上の一箇所に税率セルを設け、税込価格セルを =An*$B$1 （$は絶対参照）とすれば税率変更時も1セルを書き換えるだけで済む。税率が2つあるなら通常税率の商品の税込価格セルを =An*$B$1 とし、軽減税率の商品は =An*$C$1 としておけば、B1とC1セルを書き換えるだけで済む。
※これらの考え方がプログラミングの変数と代入式につながっていく。
※データベースでは重複や従属性を省いていくことを正規化と呼ぶ。
※「ヘブライ語でない限り」「観光客の免税」といった想定は社会人偏差値が低かったり生活水準の多様性に乏しいと導かれない。
会員ランクの名称なども同じ。「プラチナ会員」「ゴールド会員」と全行に入力してしまうと、「プラチナってゴールドより安いんだから、名称変更しない？」という話になったときに一箇所を書き換えたら済むのか全行書き換えとなるのか。
会員ランクが過去半年分の購入金額で決まるであれば、現在の年月日−購入年月日が180日以内なら購入金額を合計し、その合計額が○○万円を超えているならゴールド会員というIF関数の組み合わせで自動表示できる。そうすればイチイチ合計金額を電卓で弾いて会員ランクを決定するなどしなくて良い。SQLならWHERE文で複数の条件をAND指定する。
※1月と7月に1回など期間を区切ってランクが切り替わるようなところは手作業かもしれない（笑）。「180日以内」と移動合計で自動計算されていれば、締めて区切る必要がなく毎日ランクを自動決定できるから。例えば「1-6月の購入額が20万円を超えていたら次の期間はゴールド会員」という設定の場合、6月に会員になって19万円使った人はランクが上がらないどころか7月の集計からゼロスタートしてしまうので、自動化されていればこんな消費者をバカにしたような（笑）仕組みにはならない。ということは締め日に集計しているということ。これらを静的（static）、動的（dynamic）と言う。
という具合に、その値（数字や文字列）をタダの字として捉えるのではなく、いずれ変更されるかもしれない値か、いつか計算が必要になる値か、継続的・累積的な値に意味を持つのか（購入額とか）など、そのデータが将来的に膨大になったとしても柔軟に対応できるよう思考することが求められている。
この段階とは思考の成熟度そのものであり、成熟した人なら後半ステップからスタートするが、未成熟な人はゼロスタートし成長に合わせて作り替えが生じ、周囲の人はソレに付き合わされることになる（全体の生産性が下がる）。
すなわち自動化時代の賢さとは先を見越した思考ができること。が基本と言える。
まず全体（ゴール）を捉え構造化して考える。各部位をモジュール化し汎用性を持たせ、再利用できるようにすることで今後の効率を高め生産性を上げることを前提に先に考えること。
それがプログラミング的思考の導入部分と言っていいだろう。
対義語は行き当たりばったり（笑）。
0コメント