この記事で言いたいことは、まとめると以下のような内容になります。

・「面倒くさくて複雑」といフローは、例外もあるものの、基本的には不適切であるか、そのフローが必要とされる前提の方がおかしい

・けれど世の中には、「面倒で複雑なフロー程正しいし価値がある」と考える人が案外多い

・「面倒くさい」と言える人は貴重なんだけど冷遇されがち

・不要なJOIN句は敵だし、JOIN句の使い回しなど絶対してはならない

よろしくお願いします。

さて、言いたいことは最初に全部言ってしまいましたので、後はざっくばらんにいきましょう。

先日、Twitterでこんなことを呟きました。

結構色んな人に刺さったようで、たくさん引用リツイートをして頂いたんですが、私自身そこまで深く考えて書いたツイートではなく、ちょっと一人歩きをしている嫌いもあったので、軽く補足してみたくなりました。

実を言うと、私がこのツイートをした時、私の念頭にはとあるシステム開発プロジェクトの記憶がありました。

十数年くらい前、私が所属していた会社での話です。

SI7割SES3割って感じの、まあ昔ながらのSI企業でした。

その時私が配属されたのは、とある企業の社内業務システムのリプレースのプロジェクトでした。

社内の勘定系と顧客管理系を統合したようなそこそこ大きな規模のシステムだったのですが、以前他社さんで開発した時に要件定義からこけちゃって、色々とよくわからないことになっているのでまとめて再開発したい、というようなプロジェクト設立経緯だったと思います。

そのシステムについては調査段階から様々な面白エピソードがありまして、すいませんもしかするとシステム屋さんでないと分かんない話も混じってるかも知れないんですが、軽く紹介してみます。

・本来なら日次で動かさないといけないバッチ処理が24時間で終わらず、常に複数のバッチが並行稼働していた

・一部の処理が並行で走っている間はシステムに触れないので、その間発生したデータをExcelで入力しておいて、後から手動で再入力するフローになっていた

・複数の人が別々のExcelを作って後からそれを統合しているのでしょっちゅう統合ミスが発生する。その為のチェック体制もある(当然人力の目検)

・DBを調べてみたらストアドプロシージャで色んなロジックが実装されてるんだけど、何故かJOIN句以下が全部同じで、どう見ても不要なテーブルがJOINされまくっていた

・どうも「JOIN句とWHERE句以下を全てのプロシージャでコピペ共通化して、ロジックに応じて条件ととってくる列だけ変更する」というもの凄い設計になっているらしい

・そこ共通化していい場所じゃないです

・何故か全てのテーブルに、「全ての列をキーにした複合INDEX」という意味不明なものが設定されている(当然全く選択されておらず、更新のコストだけが無意味にかかっている)

・上記のINDEX以外にINDEXが設定されておらず、TABLE ACCESS FULLが発生しまくっている

・あまりに処理が重くて勘定系が使い物にならない為、市販の勘定系ソフトが別に稼働していて、週末に手動でデータを同期させるという二重管理状態になっていた

まあ、上記はほんの一例なんですが、なかなかエキセントリックな状態にあったことは察して頂けるのではないかと思います。

私の担当分野がDBだったんでまずDBから見始めたんですが、最初に「JOIN句以下が全部同じ」ということの意味に気付いた時には軽く眩暈がしましたよ。

そこ共通化するのあまりにも漢らし過ぎるだろ。超兄貴か。

で、業務システムがそんな状態なのに、そこそこお金をかけたシステムを除却するという判断がなかなか出来なかったらしくって、その状態でなんとか回す為に考えられた複雑怪奇なフローがたくさんあったんですよ。

「Excelで手入力したデータを後から手動で再入力」という時点で既に大概ですけど、まあ他にもあるわあるわ、手入力の内容をチェックする為のダブルチェックフローとか、データを転記するだけの為に造られた保守性の低いVBAとか、ドキュメントを紙で出力した後に何故かわざわざスキャンして画像データで取っておくとか。

もちろん、そういったフローは、システムがまともに稼働しない状態でもなんとか業務を回す為に工夫されたフローでして、その時々では必要だったものだろうと思います。それは分かります。

そんなところに新たにシステム開発が入るんだから、さぞかし皆喜んで、不要な業務を全部効率化出来たのだろう、と思うじゃないですか？

ところが、当初要件を聞き始めた時、驚くべきことに「基本的には今のフローを全てそのままの形で踏襲する」という形での要件しか出てこなかったんですよ。

複雑怪奇で面倒なフローは今のまま全部保持して、システムだけ速くしてください、って内容だったんです。なんだそれ。

いや、「お金がないんでほんのちょっとだけの修正に留める」って話じゃないんですよ？

ちゃんと予算もとって、フルスクラッチで一から作り直すっていうプロジェクトでそれです。

ちゃんと動かないシステムで無理やり業務を回す為にこねくり回されたフローを、ちゃんと動くシステムでもそのまま適用したい、というのが当初のお客さんの要望だったんです。

当時はまだ私下っ端だったんですが、プロジェクトの内部でも色々相談しました。

我々が色んな人に個別にヒアリングした感じ、こういった要望しか出てこない原因は、多分下記のようなものでした。

・そもそも、「現状のフローはまともに動かないシステム用の間に合わせのもの」という認識が現場の誰にもなく、「誤りを防ぐための丁寧で価値のあるチェック体制」だと認識されていた

・今のフローを考案した人がリスペクトされていて、そのフローが神聖視されていた

・現状のシステムで複雑な仕事を丁寧に回せる人が評価されてリーダーになっていて、その人が今のフローを変えることを望まなかった

・経営層は「システムがまともに動かない」という問題は把握していたものの、具体的にどんなフローが走っているかは理解していなかった

・現状のフローに「これおかしいだろ」と思ってそう指摘する人もいたが、そういう人たちは「面倒なタスクを嫌う怠惰な人たち」とみなされて冷遇されるか、あるいは既に退職していた

で、我々がヒアリングしたのがまさにその、「今のフローを丁寧に回すことで評価されたリーダー」だったので、フローを変えられること自体を拒絶されてしまった、という話なんですよ。

そのリーダーさんにしてみれば、今のタスクをきちんと回すだけで自分は十分評価されるし、フローが変わったらその後どう成果を出せばいいか分からない、ということで、一種の抵抗勢力になっていたみたいなんです。

この時、「言われた通りに実装してお茶を濁す」という選択肢もあるにはあったものの、プロジェクトリーダーの人の決断で経営層も交えて何度も話し合いを行って、システムの新規開発でどんな効率化が出来るかを繰り返し説明しました。

で、最終的には「不効率なフローをまとめて刷新してシステムリプレース」ということになりました。

まあ当初は使いにくい使いにくいって現場の人たちに散々文句を言われたものの、最終的には新しいフローでちゃんと仕事が回り始め、経営層含め満足頂いた、という話なのです。

リーダーさんは最後まで文句言ってて、そのうちその会社辞めちゃったんですけど。

そんなに珍しい例というわけではないと思います。

後から考えると、「システムリプレース」という案件の一つの典型例だったのではないかなーと。

まあ、あのDBのJOIN句使い回しだけはかなりの特殊例だと私は思ってるんですけど。

***

もちろん上記は極端な例でして、世の中には「ケースバイケース」という言葉がありますので、中には「きちんとした理由があって必要とされている面倒なやり方」というものもあります。

上のケースでも、旧システムが現役の時代にはそうだったのでしょう。

とはいえ、何か面倒なやり方が稼働していた時、

「この面倒さは本当に必要な面倒さなのか？」

「もし必要な面倒さだとしたら、そもそもその面倒さを必要とする前提がおかしいんじゃないか？」

という思考は絶対に必要です。

人間の処理能力や注意力には限界というものがあって、フローが複雑であればある程効率も下がりますし、ミスの可能性も上がります。

フローはシンプルであればシンプルである程正しく、価値がある。

これは一般に言ってしまっていいと思います。

ただ、それに対して、「面倒で複雑なやり方であればある程、正しいし、価値があるし、ミスが防げている」と考える人も、そんなに少なくない数存在するんですよね。

というより実際にはすごーく多い。

鍵をなくして業者さんに開けてもらう時、さくっと開けてもらうより手間取ってみせた方が納得する人が多い、みたいな話、ありますよね。

一つ一般に言えることとして、「この仕事面倒ですね」と言える人は案外貴重、という話があります。

面倒な仕事を嫌う人は「単なる怠け者」と見られがちですが、その人が「なにか前提がおかしい」ということに気付ける貴重な批判能力と、それを口に出来るだけの発信能力を持っている人でもある可能性は割と高いです。

そういう人たちを、「こいつ怠け者で不平屋だから」ということで冷遇していると、貴重な改善機会を見逃す可能性がある。

これについては注意を払うべきだ、と私は考えるわけなんです。

面倒くさがり、大事です。

その為、現在私の部署は「面倒くさがり」ばかりが集まっていて、ちょっとでも面倒なフローを見つけると寄ってたかって殲滅しにかかるという、なかなか楽しいことになっています。

まあ、実際に「この仕事面倒」というと何故か怒る人が多いので、「このタスク、ちょっと工数が多過ぎるので工数を削減しませんか？」とかそういう言い方にした方がいいのかも知れませんが。世渡りって大変ですね。

あとJOIN句使い回しダメ、絶対。

今日書きたいことはそれくらいです。

【お知らせ】
大好評ティネクト主催ウェビナー5月実施のご案内です。

＜2024年5月13日実施予定　ティネクト90分ウェビナー＞

マーケティングの人手不足は「生成AI」を活用した仕組みづくりから

-生成AIで人手不足を解消しようセミナー


＜セミナー内容＞
1.あらゆる業界で起こっている人手不足
2.「動ける人材がいない状態」から脱却しつつある事例紹介
3.マーケティングの省力化事例
4.生成AI用いた業務省力化、その他の取り組み

【講師紹介】
倉増京平（ティネクト取締役）
楢原一雅（同取締役
安達裕哉（同代表取締役）

---

日時：
2024年5月 13日 (月曜日)⋅18:00～19:30
参加費：無料　　
Zoomビデオ会議（ログイン不要）を介してストリーミング配信となります。

---

お申込み・詳細 こちらティネクウェビナーお申込みページをご覧ください

(2024/4/21更新）

【著者プロフィール】

著者名：しんざき

SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。

レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。

ブログ：不倒城

Photo by Dwayne Madden