プログラミング教育よりシステム教育

ディジタル庁創設とかで、改めてプログラミング教育の話題が取り沙汰されてる。

もう、かなり前から情報リテラシとかで、幼い頃からの「プログラミング教育」は話題になっていたと思うし、今更なんなんだという気もしなくもないけれど、現場のプログラマとして、「プログラミング教育より、先に、指導して欲しいこと」がある。それは、「システムのユーザ教育」とでもいうべきか。

しばらく前に、こちらも耐えきれずにお客様のところで「例」として話した話題がある。「家を建てているとします。かなり仕上がったところで、『洗面台は、ここだと使いにくいから、こちらに移して欲しい』などと言われたとすると、一旦仕上がった後なのに、壁を剥がしたり、それが2階の洗面台だとすると1階の天井だの、かなり激しく作り直しをすることになるので、普通はそういう『仕様変更』はお請けできません。それに近い感じの話題になっているので、これ以上の変更はできませんが、よろしいでしょうか?」と、伝えたことがある。後で営業さんにお話しして、「伝わっていますかね?」と確認したら、「伝わってないでしょう」と。

家とか車だとかなら、目に見えるから、例えば配管からやり直さなければならない、なんていう話をしても、ある程度は伝わるというか、通じるかも知れない。けれど、情報システムの場合には、「どんなデータを扱い、どう加工して、どう見せるか」というそれぞれの要素が、外からはかなり見えにくい。少しでもわかりやすくするために、「要件定義仕様書」だとか「基本設計書」のようなもので、文章化したり、Excelで画面イメージを作ったりして確認したりするんだけれども、いまだに記憶しているのは「こんなの見ても、わからないよ。まず作ってもらったものを見てから、要求を出したい」というやりとりが、初期段階にあったように思う。この「こんな書類を見ても、わからないよ」が曲者だったなと、今にして思う。

最初に「要件定義」でここまで作る、を明示して、その上での金額・工期を提示していたのに、その段階の「要件定義」はほぼスルーされて、かなり仕上がってから「実は、ここまで、こういう機能がなければ使えない」という話になった。この段階で、もともと「小さめの平屋建て」ていどの話だったのが「大きめの2階建」くらいの規模になり、(その平屋建てのつもりの金額・工期のまま)作り替えた後で、「ここは、こうでないと使えない、このデータも扱わないと使えない」という、後出しの話題がゾロゾロと出てきて、(こちらは、お客様のビジネスロジックを完全に把握している訳ではなく、確認を取りながら進めてきたつもりなんだけれども、その段階では「なぜ、そんなことを聞くの」くらいの感じだったのかもしれない)気がついてみたら、当初、「2LDK平屋建て」くらいのつもりが、「鉄筋3階建て」くらいに膨れ上がってしまって(基礎工事からして、一旦作ってから何度もやり直した感じで、)いまだに「要件定義」のきちんとした確認がとれていない(まだ、「みてから考える」感じが続いていて、)出口の見えない状況が続いている。赤字なんていうレベルじゃない。ほぼ無償奉仕に近い感じなのに、「いつになったら仕上がるの」的な「要求」だけは遠慮なく出てくる。物作りのプライドなんてのも、とっくに崩壊したかもしれない。元々平屋建てのつもりを、同じ価格のまま3階建てに作り替えて、ほぼ仕上がったと思っていたら、「トイレはここだと使いにくいから、こちらに動かして」ってな感じの話題が出たり、普通の「家作り」で、そういう要求を出せると思うかなぁ。配管や配線のやり直し、なんて、簡単にはできないと思うんだけれど、その「例え話」が伝わらない。

営業さんとも、話していて思った。「基本設計書」とか「要件定義仕様書」「画面レイアウト案」などなどの、「事前文書」を見て、どこまで「完成形」をイメージできるか。プロでないと無理なのかも知れない。説明不足?「ここまでは作れる」という説明はしたと思うけれど、後になってから「この情報も扱えないと、使い物にならない」っていうのが出てくる。「現場の紙ベースの業務を、システム化する」ならば、アウトプットから遡って考えることになるとも思うけれど、こちらも、出口側のチェックが不十分だったのかも知れない(と、思うから、追加請求せずに、ひたすら改修作業を続けたけれど、)この「要件定義の確認」という、最初の部分が、あまりにもおろそかだったかも知れないし、先方も「内容確認」をほとんどしないままで、「思い通りのものが手に入る」と勘違いするようなこちらのアプローチもあったのかも知れない。あまりにも痛すぎる経験だった(というか、過去形ではないのだけれど。)先方から持ち込まれた話ではなく、「営業」をかけて発注していただいた仕事だということも、大きいかも知れない。立場が弱すぎる。

思うに、プログラムを作る人間よりも、使う人間の方が、圧倒的に数が多い。

プログラミングは、蟻の目というか、細かいミクロの要素を組み合わせて、それを積み上げて、パーツ化したり、パーツを組み合わせて大きくしていく。その教育が無駄だとは言わない。ただ、使う側に押さえて欲しいことは、「システムのマクロ」であって、全体としてどんなことができるか、それを実現するのにどんな情報が必要か、マクロな全体を分解して、構成要素間の関係を描き出し、使う場合の「動線」というか流れを確認し、システム設計では、ユースケースだとか、状態遷移だとか、シーケンス図だの、なんだかんだと、マクロからのアプローチが不可欠になる。むしろ、「ユーザ教育」としては、こうした「システム」を理解したり、設計する能力の方がはるかに重要だと思えるのに、そちらの話題がほとんど出て来ていないような気がした。

思えば、政府の「コロナ対策」が「システマチックだ」と思える方は、どの程度いらっしゃるだろうか。場当たり的では「システム」は構築できない。目に見えるものが出て来てから、「洗面台は、ここじゃなくて、こっち」なんていう話題になったら、作る側は絶望的な気分になる。およそ「システム」という言葉が虚しい場面が、日常でも、それこそ政府のトップから、末端まで溢れている気がする。「システム」とは、およそ「日本的」なものと真逆な世界観なんかも知れない。

洗面台の位置が変わる、となると、ほぼ仕上げにかかっていた壁をかなり壊し、場合によっては柱の位置を変えて、(家の場合、作ってから柱の位置を変える、ってことは、要するに壊して作り直す感じになると思うけれど、)同じものを、2回も3回も作り直していて、それでも「画面」にはわずかな変更しかないから、「なんで、こんなに時間がかかるの」なんてことを言われてしまう。システム屋には通じると思うが、ほぼ仕上がったつもりが、思ったイメージと違うとのことで、「今度こそ最後」の、データベースのスキーマの大規模修正が入って、リレーション(要素の括り付き先)を見直し、作り替えた上での画面モック提案の確認が取れていないのに、納期は5月の連休明けだと、動かしてもらえそうにない。本来なら「作る前」に、「要件定義」の段階で確認して欲しかった。「こんなの見てもわからないよ」の一言に、リフレーンがかかっている。

以前、パプアニューギニアにいた頃、聞いた話。ある部族では、部族長は「声の大きさ」で決める、らしい。一番大きい声を出せるものが「リーダー」になり、リーダーが決まったら、その人に従う。(今はどうか知らないけど。)なんだか、日本でもそれに近い慣習があるかも知れない。

「お客様の声」は、確かに「天の声」かも知れないけれども、とにかく「作る前に、完成形についての緻密な議論を済ませる」ことが、できるような方が、お客様側にいてくれたら、こんなに助かることはない。いわゆる「プログラミング教育」では、そうした視点は育てられないと、私は思う。「システム教育」と「プログラミング教育」は、完全に別モノだと私は思う。


思えば、医療用のアプリを書いていた頃も、仕上げて請求書を出したら「タダにしろ」と医者に言われて、泣きを見た経験が一度じゃなかったのに・・・。薬屋は、そこでタダにしても別のところで利益を出せるから、平気でタダにしたり接待したりするけれど、システム屋がシステムをタダにされたら、生活できない。(といいつつ、税金を滞納しながら、リボ払いの高い利息を払いながら(早めに、取り返す手続きとらなきゃ・・・)とりあえず、生活はしてるけど・・・)

学習してねぇなぁ。反省材料が山積み。きっと、何かを学び取れば、今後はこういうことはなくなるに違いない、ってか、学習するまでは同じような経験を続けることになるのかも。頑張りましょ!?–>自分