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

 

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

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

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

・不要な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句使い回しダメ、絶対。

 

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

 

 

【お知らせ】
ティネクト(Books&Apps運営会社)提供オンラインラジオ第6回目のお知らせ。


<本音オンラインラジオ MASSYS’S BAR>

第6回 地方創生×事業再生

再生現場のリアルから見えた、“経営企画”の本質とは

【日時】 2025年7月30日(水曜日)19:00–21:00
【ご視聴方法】
ティネクト本音オンラインラジオ会員登録ページよりご登録ください。ご登録後に視聴リンクをお送りいたします。
当日はzoomによる動画視聴もしくは音声のみでも楽しめる内容となっております。

【今回のトーク概要】
  • 0. オープニング(5分)
    自己紹介とテーマ提示:「地方創生 × 事業再生」=「実行できる経営企画」
  • 1. 事業再生の現場から(20分)
    保育事業再生のリアル/行政交渉/人材難/資金繰り/制度整備の具体例
  • 2. 地方創生と事業再生(10分)
    再生支援は地方創生の基礎。経営の“仕組み”の欠如が疲弊を生む
  • 3. 一般論としての「経営企画」とは(5分)
    経営戦略・KPI設計・IRなど中小企業とのギャップを解説
  • 4. 中小企業における経営企画の翻訳(10分)
    「当たり前を実行可能な形に翻訳する」方法論
  • 5. 経営企画の三原則(5分)
    数字を見える化/仕組みで回す/翻訳して実行する
  • 6. まとめ(5分)
    経営企画は中小企業の“未来をつくる技術”

【ゲスト】
鍵政 達也(かぎまさ たつや)氏
ExePro Partner代表 経営コンサルタント
兵庫県神戸市出身。慶應義塾大学経済学部卒業。3児の父。
高校三年生まで「理系」として過ごすも、自身の理系としての将来に魅力を感じなくなり、好きだった数学で受験が可能な経済学部に進学。大学生活では飲食業のアルバイトで「商売」の面白さに気付き調理師免許を取得するまでのめり込む。
卒業後、株式会社船井総合研究所にて中小企業の経営コンサルティング業務(メインクライアントは飲食業、保育サービス業など)に従事。日本全国への出張や上海子会社でのプロジェクトマネジメントなど1年で休みが数日という日々を過ごす。
株式会社日本総合研究所(三井住友FG)に転職し、スタートアップ支援、新規事業開発支援、業務改革支援、ビジネスデューデリジェンスなどの中堅~大企業向けコンサルティング業務に従事。
その後、事業承継・再生案件において保育所運営会社の代表取締役に就任し、事業再生を行う。賞与未払いの倒産寸前の状況から4年で売上2倍・黒字化を達成。
現在は、再建企業の取締役として経営企画業務を担当する傍ら、経営コンサルタント×経営者の経験を活かして、経営の「見える化」と「やるべきごとの言語化」と実行の伴走支援を行うコンサルタントとして活動している。

【パーソナリティ】
倉増 京平(くらまし きょうへい)
ティネクト株式会社 取締役 / 株式会社ライフ&ワーク 代表取締役 / 一般社団法人インディペンデント・プロデューサーズ・ギルド 代表理事
顧客企業のデジタル領域におけるマーケティングサポートを長く手掛ける。新たなビジネスモデルの創出と事業展開に注力し、コンテンツマーケティングの分野で深い知見と経験を積む。
コロナ以降、地方企業のマーケティング支援を数多く手掛け、デジタル・トランスフォーメーションを促進する役割を果たす。2023年以降、生成AIをマーケティングの現場で実践的に活用する機会を増やし、AIとマーケティングの融合による新たな価値創造に挑戦している。
ご視聴登録は こちらのリンク からお願いします。

(2025/7/14更新)

 

 

 

【著者プロフィール】

著者名:しんざき

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

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

ブログ:不倒城

Photo by Dwayne Madden