軽減税率で「えきねっと」が障害を起こしましたな。えきねっとは紛うことなきクソ使いづらげシステムなんだけど、例えば、システム開発を知らない君らよ。使いづらいWebサービスを見た時とか、システム障害が発生したときに何を感じるだろうか。

「技術力が無いんだな」と思うかもしれないな。あるいは個人情報の流出があったときに「ITは危ない」とか。それはそれで正しいんだけど、そこまで単純ではない。その辺を紐解くための参考情報を提示させていただく。

一般の人が使うシステムと、会社で働く人が使うシステムがあるな。どちらもそりゃシステム障害が発生する。困るね。使いづらいシステムも困る。どうしてイレギュラーは発生するんだろう？

◆開発者に技術力が無い

これが一番わかりやすいのかもしれない。

完璧な、非の打ちどころのない料理のレシピがあったとして、料理人にスキルが無ければダメでしょう。

レシピ「ニンジンを厚さ五ミリでいちょう切りしろ」

料理人「胃腸切り…？」

そして、そもそもシステム開発に決まったレシピなんてないです。レシピを書く係の人もいたりするけど。

技術力が無いと、本来必要となる手順をしなかったりする。例えばセキュリティについての知識。XSSとかCSRFとかSQLインジェクションとか辞書攻撃とか総当たり攻撃とかDDoSとか、ごくごく基本となるセキュリティ知識を持たない人間が開発をしていたりする。

アクセス可能なIPアドレスの制限がされていないとか、入力される文字がエスケープ（サニタイジング）されていないとか、ログイン試行回数が無限とか多要素認証が無いとかパスワードがハッシュされてないとか。

それを料理で例えるなら、ジャガイモの芽を取らないとか、フグのキモを抜かないとか。その辺においといた魚を生で食うとか、適当に捌かれた牛からレバ刺し作るとか。

いやそれ死ぬよね？っていう感じのシステム開発をしている会社もいますわね。

あとは道具を知らないとか使えないとか。Git使えないって何？webpack使わないって何？サクラエディタで開発ってなに？手斧で恐竜と戦うようなもんだぞ。いや手斧使ってもいいけど、手斧なりの用途があるだろ。

◆ヤバい会社に発注してる

世の会社は、システムを導入する。でも、なんでむざむざ技術力の無い会社に仕事を発注するんだろうか？だってJRとか金持ちでしょう。Suicaとか構築実装出来てる時点で技術力すごいじゃん。JASRACも沢山お金稼いでるじゃない。なんでゴミシステムしか作れない会社とつるんでんの？そんなん競争力失くしちゃって、外資に飲み込まれて終わっちゃうよ？

っちゅう疑問は当然ながら発生するわけだが、ちょっと待っていただきたい。システムを知らない人間が、どうして「善いシステムを作る会社」を見つけることができるだろうか（いやできない）。

例えば、一国一城あって、そこに殿様がいる。殿は言う。「フグという、美味なる魚がおるらしい。是非食べてみたいものじゃ。」

家臣はフグを調理できる料理人を公募する。2人の料理人が名乗り出る。

ひとりは「1両と新鮮なトラフグを用意していただければ、薄造りを賄いましょう。フグには色々な食べ方がありますが、初めて召し上がるのであれば薄造りが一番かと存じます。」と言う。

ふむ。

もう一人はこうきた。

「ウチは腕利きの料理人を大勢召し抱えております。1両頂ければこちらでフグも用意いたしますし、てっさ、てっちり、ヒレ酒、子糠漬けまで用意いたしましょう。ウチのてっさはそこらの貧乏くさい薄いてっさとはワケが違います。贅沢に厚切りにしたフグこそ最高の味わいです。」

うん。

どっちに発注する？

なんとなく「後者はなんかキナ臭いし、発注するなら前者じゃねぇかな」と思ったかもしれんが、それは文脈から読み取れただけにすぎない。

現実では当然、良いことしか言わない会社に発注される。安い方に発注される。だって発注する側がそもそもフグについて詳しくないんだもん。だから厚いふぐ刺しが出てくる。「フグって硬いな。あんましうまくねぇな。」ってな感じになる。家臣は子糠漬けを毒見する。毒に中ってぶっ倒れる。

町人は思う。「ふぐってこえー！」「もっと大規模な、大量の料理人がいれば大丈夫だったんじゃないか。」「子糠漬けっていうのがヤバいんでしょ？」「てっさもそんなに美味くないらしい。」

いやぁ、違うよね？なんでフグを捌けないやつがフグ料理作ってんの。そんなん許されないだろ。まずフグに失礼だし、こんなんがまかり通っていたら、マトモな仕事をする料理人も調理代金を値下げしなければならなくなる。必要な金を貰えないからマトモな仕事が出来なくなっていく。

そして、こんなやり取りがなされる。

「小糠漬けに不具合がありました。こちらのミスです。修正して再納品します。さらに新しい創作フグ料理もサービスで提供させていただきます。」

「うーん…そうなの？しょうがないか。ミスは誰にでもあるし、幸いにも殿は無事だ。」

ちがうんですね。フグの子糠漬けって、作るのに2年3年かかるらしいんです。それが何で半年で出てくるんですかって。おかしいと思わないの？

あぇ？家臣が半年で用意しろっていったの？うーん…いやでもできないものはできないだろ。何を受注しちゃってんのよ。

何か根本的に間違っている気がするが、システム開発ではこれが発生するんですね。そりゃあ意味の解らんシステム障害もおきますわ。

◆そもそも何を作ればいいのか分かっていない

システムを導入しようとしている会社は、そもそも自分たちにどんなシステムが必要なのかを理解していない場合が多い。

例えば、以下のような業務フローがあったとする。

  • ある営業が契約を取ったとき
  • 本社に戻ってまず上半身裸になり
  • 「エ゛イ ゛ ！ エ゛イ ゛ ！ 」という掛け声とともに150回スクワットをした後
  • 40分間サウナに籠ったのち
  • 下半身裸になり
  • 14キロの砂糖水を飲み干したら
  • 課長に「契約取れましたー」と報告する
  • 契約書を（以下略

この会社が業務効率化の為にシステムを導入しようとしている。

いや、どうしろって言うんだよ。

「150回のスクワットをサボる社員がいるので、センサーと顔認証機能で社員のスクワット状況をモニタリングしたい。」

いや…いや、どうしろって言うんだよ。

なんでスクワットするの？

「社員の士気、体力を向上させるためです。」

えぇ…

…スクワットするのって削れないの？

「業務フローを変更することは社員への負担になる。」

何言ってんだコイツ。

でもお金払ってくれるもんだから、この仕事を受注する会社がある。そして社員は「業務改善されてねぇな？」と感じ、デキル営業からその会社を辞めていく。

「システム導入しても業務が改善されなかった」って言われる。「いや、オメーがアホだったんですよ。実は。」と言ってあげてもいいけど面倒だし。

システムの事はシステム屋さんに任せる方がいい。でも業務知識はないわけだから、発注する側も発注される側も、「いいものを作ろう」と協力してやっていかなければならない。それなりの大きな時間を割いて取り組まなければならない。

◆い・な・り

だから、お客さんの言いなりになってシステム開発している会社は終わってる。

「ちょっなんでフグのキモ捨てるの？」

毒だからです。

「えーもったいない。美味しいらしいし、ちょっとなら大丈夫でしょ。いれちゃおうよ。」

いや…死んじゃいますけど。

「大丈夫だって！」

じゃあ入れますけど…知らないですからね？

「うんうん！」

◆古い

古いシステムを後生大事に抱えている会社が、システム刷新とか言いながら既存のシステムに引きずられまくったものを作ろうとするやつ。

あるいは刷新まで行かず、例えば20年前に作られたシステムに「令和」を導入しようとする。バグる。

システムっつーのは、保守する人も代替わりです。いかに優れた思想で作られようが、長い時の中でシステムの担当者は移り行くものであるから、どっかでクソアホに当たる。客も代替わりだ。無茶で短期間な要求をはした金で飲ませると、システムに毒が混入することになったりする。

それにしたって20年物のシステムのコードなんて読みたくない。

大きいシステムであればあるほど、刷新のコストは高い。だから小さいシステムが相互に連携する仕組みが賢い。

◆開発会社に設計力がない

昔の仕組みしか知らないとか、頭がわるいとか。

設計がイカれていると、イカれた処理をするプログラムを書かねばならなくなります。イカれた処理をするプログラムは、難解、読めなくなります。読めないコードと読めるコードがあったとき、バグが埋まりやすいのはどっちだろうか。

じゃあ、イカれた自動販売機を考える。

  • 1円と5円しか入らない。
  • おつりが処理できないので、ぴったりの金額じゃないと購入できない。
  • 欲しい商品の下にあるボタンを押すと、2つ右の飲み物が40本購入される。
  • 飲み物が一本だけ欲しい時はクラッチを踏み込んでからギアを1速に入れ、アクセルを少しだけ踏み込み、クラッチを半分ほど緩めてからボタンを押す。
  • 購入した飲み物を取り出すには右手と左手の小指を自販機の取り出し穴に挿入し、「ピリカピリララポポリナペペルト」とマイクに唱え続けながら缶を秒速2cmの速さでゆっくり持ち上げ、最上部に付いたら小指で缶を奥の穴に投げ込む。自販機の上部から缶が射出されるので、そばにあるタモでキャッチする。

この自販機が組み込まれたシステムを作るのは辛いだろう。例えば永続化層の設計がクソアホだとデータを取り出すのも大変な手間だ。

この例は流石にイキスギだが、もっとﾇﾁｬっとした感じに設計が狂ってるシステムがあったりしますね。それは不具合を引き起こし、システム障害が発生しますね。

◆SE

「システムエンジニア」をSEと呼ぶ。そして、開発経験のないSEがいる。

技術力ない人がシステムエンジニアリングできるのかって？

できるわけないんですね。本人も気づかないままクソを生み出しています。本人はベストの仕事をしています。「ある程度やれてるな」と思っています。でも今もどこかの会社でクソを生み出し続けています。

技術力ってのでプログラミングを思い浮かべる人も多いかもしれんが、そんなものは氷山の一角でしかない。ネットワーク、ハードウェア、コンピュータアーキテクト、ソフトウェア、ミドルウェア、セキュリティ、認証、まだまだある。プログラミングの勉強なんかしたってしょうがないんだ。

技術を知らない人が要件定義しても、精度が出ない。当たり前だ。「えっ毒のある魚もいるの？」みたいな話をしているのだもの。

結果、クソな要件からクソな設計が出来てクソなコードが起こされクソな品質管理でシステム障害が発生する。

◆開発会社がシステムの作り方をしらない

「技術力ない」よりも多いのがこれだ。

アジャイル開発を知らないとか今更ないだろうけど、その意図、理由、思想を考えたことが無い人は多い。「アジャイル開発で進めましょう」とか言いながら宣言すら、原則すら読んだことないとか。

なんでシステム開発が苦しかったのかを考えないまま、苦しいことをやりつづけている。そして自覚がない。根本的に間違っているプロマネ、開発を大勢の人間が続けている。アジャイル開発になっていないアジャイル開発を導入し、「開発楽にならねぇな。ウォーターフォールでいいか！」みたいな辛すぎることを未だにやっている。

はい。解説する。

超ザックリ説明すると「開発をどれくらい蓄積させるか」という話だ。アジャイルは以下の感じ。

※リリース…システムを公開し、お客さんが使えるようになること。

小さく開発して小さくリリースし、なるべく早くお客さんに使ってもらう。随時修正しながら新機能を追加していく。毎週リリースをかけることもある。

かたやウォータフォール。

業務フロー全体を把握して、最終的に使いたいものを想像する。その仕様を全て仕様書、設計書に起こす。そして数か月～数年の間開発を続け、その開発したものを全てテストし、開発したことを全て手順書に起こす。作ったものを全て数日でリリースする。

上手くいくわけないじゃん。

ワイシャツ着る時に、掛け違えてないかなって一つ一つ確認しながらボタン付けるじゃん。なんで全部のボタン付けてから掛け違えの確認しようとするかね。理解できないわ。

あと、その作った資料さ。ずっとメンテするわけ？今のシステムとの整合性をとるためのコストってどっから出てくるの？例えば改修が入って整合性とれなくなった時点でそれ嘘情報、つまりゴミデータになるんだよ？

そうでしょ？

アジャイルは小さくて素早い。間違えたらすぐに引き返すことが出来る。お客が「これなんか使い勝手悪いな」と思ったときに、それを受け付けることが出来る仕組みだ。

お客からの要望も、毎週確認できる。やりたいことに優先度をつけて「これやろうとすると、時間的にこっちはできませんね」っていう話を常にできる。ウォーターフォールじゃ無理ゲーだ。だってスケジュールの引きが長すぎるんですもの。無理なスケジュールかどうか判断がつくわけがない。余ったり足りなくなったりが絶対に発生する。

アジャイルは短くて小さいタスクの締め切りがたくさん来るから、俺みたいなクソ開発者もサボりにくい。

バグのインパクトはどう考えてもウォーターフォールのほうが大きいし、不要な機能が実装されるケースも多い。実証実験とかもしないもんだからシステム障害が発生するんですね。

◆以上

なんか、ちょっと分かった？なかなか一筋縄じゃいかないんですよ。利害関係のある人全員が、スクラムを組むように進むことが出来ればそれが一番だ。でももう、くんずほぐれつの団子状になってビチャビチャアって終わることもある。

多分まだいろいろあるけど。取り敢えずこんな感じ。また思いついたら追記するわ。