今回は、葬儀屋さんがシステム開発に失敗する理由について語ります。
目次
お仏壇のはせがわの悲劇
2021年3月こんなニュースが発信されました。
お仏壇のはせがわが基幹システム開発中止、コロナ禍で構築体制の整備困難に
要約すると、東証スタンダードに上場している墓石仏具販売の株式会社はせがわが、基幹システムの開発に失敗し、4億3000万円の損失を出したという話です。
仏壇や墓石を販売するはせがわは2021年3月11日、受発注情報や在庫情報、顧客情報などを管理する次期基幹システムの開発を中止すると発表した。これに伴い、2021年3月期の第4四半期（2021年1～3月）決算で4億300万円の特別損失を計上する。
同社が基幹システム構築に着手したのは2019年。ERP（統合基幹業務システム）パッケージの導入や周辺システムの開発を含めたプロジェクトで、当初は2021年4月に稼働させる計画だった。
だが2020年に入り、国内で新型コロナウイルスの感染が広がったために開発作業を中断していた。今後も「新型コロナウイルス感染拡大の防止を行ないながら、開発環境を整えることが困難」（はせがわ）と判断し、作業再開を断念して開発費用の一部を特別損失として計上することにした。
いや、それにしてもコロナのせいで、開発できないってなに？
墓石や仏具の対面販売が困難なら分かるけど、システム開発ならオンラインでできるはず。
コロナうんぬんというのはウソでしょう。私が株主なら総会で詰めるな。
断念した時期が、稼働直前だったことから、プロトタイプ（試作品）が上がってきてから「こりゃ、使えねぇ」ってことになった可能性があります。使えねぇっていうのは、システム自体のクオリティが低いというだけでなく、ウチの従業員のITスキルが低いせいで使えねぇという可能性もあります。
別にはせがわさんをdisっているのではなく、葬儀業界全体がITスキル低いのです。
そもそも今回の開発も、時代はDXなんで新しいEPR（※）を！という話ではなく、単にシステムの老朽化のために仕方なく、のような気がします。（あくまで私の推測です）
システム開発に失敗は、たまに裁判沙汰にもなっていて、どの企業でも構造的にあり得る話なのですが、これからは「葬儀社のシステム開発が失敗する理由」について語ります。
（※）EPRとは「Enterprise Resource Planning」の略称。 企業の経営資源である「ヒト・モノ・カネ・情報」に関する情報を一元管理することで、企業全体の状態をリアルタイムでスムーズに経営判断ができるシステム
システム開発の流れ
システム開発にあまりくわしくない方のために、新たに社内プロジェクト立ち上げてシステムを稼働させるまでの流れを説明します。ざっくり下記の通りです。
1. ベンダー選定
- リサーチ: 複数のベンダーをリサーチし、実績や評判を確認します。
- RFP（提案依頼書）作成: ベンダーに対して提案依頼書（RFP）を作成し、要件や期待する成果を明示します。
- 提案の評価: 各ベンダーからの提案を評価し、比較検討します。
2. 予算とスケジュールの設定
- 予算設定: 外注費用の予算を設定します。
- スケジュール設定: プロジェクトのスケジュールを策定し、納期を決定します。
3. 要件定義
- 目的の明確化: 業務システムを外注する目的を明確にします。
- 要件の洗い出し: システムに必要な機能や要件を詳細にリストアップします。
4. 契約締結
- 契約書作成: 選定したベンダーと契約書を作成します。契約内容には納期、費用、支払い条件、著作権、秘密保持などを含めます。
- 法務確認: 契約書を法務部門に確認してもらい、問題がないかチェックします。
5. プロジェクト管理
- プロジェクトチーム編成: 社内でプロジェクトチームを編成し、担当者を決定します。
- コミュニケーションプラン策定: ベンダーとの定期的な打ち合わせや報告体制を策定します。
- 進捗管理: プロジェクトの進捗を定期的に管理し、問題が発生した場合は迅速に対応します。
6. システム開発とテスト
- 要件定義書の確認: ベンダーが作成した要件定義書を確認し、必要に応じて修正を依頼します。
- 開発: ベンダーがシステム開発を行います。
- テスト: システムのテストを実施し、バグや問題点を洗い出して修正します。
7. システム導入と運用
- 導入準備: システム導入のための準備を行い、必要なデータ移行や設定を実施します。
- ユーザートレーニング: システムのユーザーに対してトレーニングを行い、使い方を習得してもらいます。
- 運用開始: システムの運用を開始し、運用中に発生する問題に対応します。
8. 保守とサポート
- 保守契約: システムの保守契約を締結し、定期的なメンテナンスを実施します。
- サポート対応: システムの利用中に発生する問題に対してサポートを提供します。
発生する問題
では個々のフェーズで発生する問題について述べていきます。
1. ベンダー選定
さてシステムを外注するためにはベンダー（ソフトウェアの設計、開発、テストを行い、クライアントの要件に基づいてシステムを構築する企業）を決めねばなりません。
通常は「葬儀社のシステム開発実績のある企業」が理想ですが、とても少ないためなかなか見つかりません。
そもそも、最近葬儀業界は寡占化が進んではいるものの、企業数でいうとほとんどが中小企業です。一からシステムを開発する財力を持ち、開発のリターンが得られる企業規模の葬儀社はとても少ないのです。おそらく4,000社ある葬儀社のうち、TOP30 くらいまでじゃないでしょうか。
後述しますがシステム開発がうまくいかない素地がある業界なので、そこそこ企業規模が大きくても、ある程度ブラッシュアップされているであろうパッケージにしておいたほうが無難が気がします。
2. 予算とスケジュールの設定
ざっくりとバリューチェーンを描くと
顧客情報管理→受託→初動→打ち合わせ→発注→納品→施行→請求書作成→顧客情報管理（アフター部門）
こんな感じだと思うのですが、これをシステムで全部網羅しようとすると当然億単位の話になります。
本来はざっくりと３の要件定義を先にやって、どこまでやるかのざっくりした広さと深さを見極めた後、予算を決めて、１のベンダー選定が理想的なのです。
しかし葬儀社にとってベンダーの協力なくして要件定義を先にやるのは難しいですし、トータルでいくらかかるのかすら回目見当がつかない葬儀社も多いですから、今回この順番にしました。
葬儀屋の情報システム部門なんてシステム開発外注をしたこともなく、ベンダー側も葬儀屋の業務内容など見当もつかず開発実績もないので、コンペを開いたはいいが、選定基準がなく、中身は精査されず、結局使える予算の多寡でベンダーが決まることが多いです。
そしてスタートしてから、業績悪化で予算縮小みたいな話が、いきなりトップダウンで降りてきて、本来葬儀打ち合わせ業務の時は、ファミレスのようにタブレットで商品の画像を使用したUIを使うはずだったのに、いつのまにか商品のコード番号を手打ちにするなどという地獄のような変更が行われたりします。
当初プロジェクトの開発メンバーから、とてもスタイリッシュで効率的なレボリューション（笑）が行われるはずと漏れ聞いていた現場スタッフは、プロトタイプを見て愕然とします。士気だだ下がりです。
3. 要件定義
要件定義とは、システム開発プロジェクトにおいて、システムが満たすべき機能や性能、仕様などを明確にするプロセスを指します。ここが各フェーズの中で一番重要です。
先ほど述べたように、葬儀屋自身で要件定義を行うのはむずかしいので、実務的には４の契約締結後に、３と５のプロジェクト管理は同じフェーズで行われる事が多いです。このあたりはどうかと思いますが、おそらく社内にシステム開発を仕切れる人がいないのなら、この手順はやむを得ないと考えています。
そのためこのパラグラフ内の以下の記述は、５のプロジェクト管理も含んでいるとお考えください。
さて葬儀屋の業務のバリューチェーンの一例を挙げておきます。
- 顧客情報管理
- 事前相談の問い合わせや見積もり依頼時に顧客情報を収集・管理。
- 受託
- 葬儀の依頼を正式に受けるプロセス。
- 初動
- 葬儀の手配や準備の初期段階。例：ご遺体の搬送、関係者への連絡など。
- 打ち合わせ
- 家族との詳細な打ち合わせ。葬儀の形式や内容、日程などを決定。
- 発注
- 必要な物品やサービスの発注。例：花、棺、霊柩車、会場の手配など。
- 納品
- 発注した物品やサービスの受け取り・確認。
- 施行
- 実際の葬儀の施行。通夜、告別式、火葬などの儀式を行う。
- 請求書作成
- サービスや物品に対する請求書を作成し、顧客に送付。
- 顧客情報管理（アフター部門）
- 葬儀後のアフターケア。例：四十九日法要の案内、仏壇・仏具の販売サポートなど。
ベンダーの人に、一般的になじみのない業務内容を正確に伝えるというのは、なかなか難しいです。
さらに難しいのは、現状の業務フローを正確に伝えるだけではなく、業務改善を織り込んだフローをどこまでシステムに織り込むか、です。
個人的には、システムは、業務フローを強制的に変えることができる強力な武器だと思っています。
葬儀屋という人種は、マニュアル的作業をやりたがりません。
職人気質の文化なのと、一葬儀に一担当なので業務内容がブラックボックスになりがちなため、「生産性を上げるために業務内容を標準化しましょう。」と言ってもインセンティブが発生しない構造になっています。
しかしシステムに対しては、ごまかしや手抜きが効かないため、しぶしぶながらも従わせることができるのです。
現場あがりのマネージャークラスの開発プロジェクトメンバーは、システムに理想のフローを組み込む欲を出します。
一番分かりやすいのは「ペーパーレス化」です。
（時代は、ほら、SDGｓだし（笑）この記事書いているのは2021年なのですが、10年後、この言葉は残っているのでしょうか？）
葬儀現場の人種は良く知らないけどコールセンター経験のある人間がプロジェクトメンバーに混じっていると、「訃報の電話を受けたら、直接システムに入力できるシステムを」みたいなことを言い出します。
「でもタッチタイピングできるのは、現場の1割いないですけど」という話が出てきて、システムのためにタッチタイピングをマスターさせるのか、それとも人差し指入力を貫いてシステム導入以前のメモ書きより生産効率が悪化させるのか、楽観主義に基づいた賭けを強いられます。
大体、後者ですね。
ベンダーに向かって「葬儀屋のITスキルの低さを甘く見るんじゃねぇ」と言ってやりたいです。
ちなみに現時点で、ちなみに国ごとのキャシュレス度を比較すると、中国は85％で日本は40%くらいです。これは中国人の方がIT偏差値高いというより、「できなきゃ死ぬけどいい？」という国策を発動しているからです。
死ぬ必要はありませんが、このシステムに従わせる賭けに勝つには人事権を発動させないと、実際は無理です。ところがなにしろ役職が上にいけばいくほど、ITスキルが落ちるので、「まぁまぁそこはなんとか」ということで、順当に現実追従路線確定です。
取引業者の発注をオンライン化したくても、「半分はメアドすら持っていなくて、電話とFAXのみ」みたいな状況でどうすんだよ、という話もお約束ですね。
ベンダーもちゃんとしたところだと、JTC（伝統的な日本の大企業 Japanese Traditional Company ）を相手にした経験から業務改善コンサルティング的な発言もしてくれるのですが、大体役に立ちません。いや、それは私の経験の範囲だけの話だけであって、アクセンチュアレベルならなんとかしてくれるんでしょうか。
こちらは従業員にタッチタイピングとショートカットキーを使わせる段階でつまずいているのですが。
かくいう私もノートPCのキーボードは余裕でタッチタイピングですが、システムをiPadで使うという話になって、ディスプレイキーボードかペラペラパンタグラフの外付けキーボードなら、ストレスはたまると思います。
また「この処理を葬儀の現場担当者にしてもらうことで、経理部の事務処理負担が減ります」みたいな提案をされることもありますが
「いや、現場担当者は経理部門の3倍の時給なんだから、経理にやらせるべきでしょ」という発言が葬儀担当部門のマネージャーから出て、経理部門のスタッフがイヤな顔をする、みたいなことも起きます。
基本的に効率化ではなく、プロジェクトメンバーが背負っている社内組織の力学が反映されることが多いです。
4. 契約締結
省略します。
5. プロジェクト管理
くわしくは３の要件定義を御覧ください。
週数回、ベンダーを交えたミーティングが行われます。
ここで現場から選ばれているメンバーというのは、現場業務に精通していて、それを言語化できて、フローチャートが作れるような人です。つまり何でもできる有能な人ということです。
ということは、いろいろ頼みごとをされる忙しい人で、さらにお葬式といういきなり受注が発生する案件を同時に抱えるため、ミーティングの欠席が多くなります。
それを見越して多めのメンバーをアサインするのですが、そのためにいつのまにか「誰かがやってくれているだろう」的責任感になってしまい、月イチの役員報告会で「え、そんなフローになってんの？」という話を初めて聞き驚愕するも、役員の前で手戻り発生のちゃぶ台返しなどできるはずもなく、やっちまったなぁの後悔を引きずることになります。
6. システム開発とテスト
要件定義に付き合ってきたベンダーも、開発は下請けにまわすことが多いです。
システム開発で、一番重要なのは要件定義だと思いますが、2番目に大事なのは開発ベンダーの基礎能力ではないかと思います。
これがボンクラだと、要件定義で決まったことをただプログラムに落とし込んだだけ、というプロトタイプが仕上がってきます。
たとえるなら、クライアントはイラストレーターを使ったポスターを依頼しているのに、メモ帳にテキストだけ打ち込んで返される状況です。
ダメなところは、UX（ユーザーエクスペリエンス）の基本すらできていないのです。
「背景ライトグレーで文字が白」ってコントラスト考えろや、とかアンカーテキストが周りのテキスト全く同じ書式で見分けがつかないとか。
データベースの設定間違えて、棺と霊柩車を同じカテゴリーに入れて、こんなの見つけられるか！とか。
あとオンライン上で動かしているのに、すぐ止まるとか。
また、細かいですが、こういうケースがあります。
発注→納品→施行→請求書作成
という業務フェイズが存在するとします。そして各フェイズの下にいろんな作業がツリー状にぶら下がっています。
施行後に商品個数修正を行う場合、商品単位で、業務フェイズを移行したいのですが、
商品選択→変更→業務フェイスの階層に戻る→業務フェイズを移行→商品選択→処理→業務フェイズの階層に戻る
といういちいち手間のかかる動線付き合わされることも多いです。
使う人のことを全く考えていないのです。仕様書通りに作ったといえばその通りなのでしょうが、こっちは素人なので、仕様書見せられた段階くらいでは、システムの出来上がりが想像できないのです。
パッケージ購入なら事前にイメージをつかめますが、ゼロから開発だとこんな地獄が起こり得ます。
開発ベンダーには、「オメーら、MacOSのUX見たことないのか」と言ってやりたいです。
この状況の唯一良い点は、キックオフから参加している社内のプロジェクトメンバーが青ざめて、必死になりだすことですかね。
さて、なんだかんだでテスト期間に入ります。
選抜メンバーと言っても、メンバーの半分はあえて、「CPUって何？」という人たちを入れます。ボトムの人が使えないと意味がないからです。
そして改善要求が山のように積み上がります。
予算策定の段階で、最悪手戻りが発生することは織り込んでおいたほうがいいです。
コストが掛かる話なので、プロトタイプを見せられた段階で「こんなクソシステム作りやがって」とキレちらかしておいて、今後の交渉を有利にしておかねばなりません。
稼働し始めたらホールドアップで、保守を含めて相手のいいなりにならざるを得ないのですから。
本番稼働直前のこの段階における情報システム部署の仕事は「俺達は、悪くない」と言い張ることです（笑）
情報システム部署にとっては、新型クソシステムのせいで現場の作業量が増えることなどどうでも良く、セキュリティがガチガチであり、プロジェクト運営に問題がなかったと言い張れればそれでいいのです。開発の中身は、役員にとってはブラックボックスなので、プロジェクトメンバーがいないところであることないこと吹きこむのは容易いです。
現場の選抜メンバーにとっては、開発ベンダーも自社の情報システム部署も共犯関係であるということで「敵」認定が行われます。
情報システム部署は、自分たちの能力不足を認めることになるので、選抜メンバーの改善要求に難色を示します。
ここが現場の選抜メンバーのがんばりどころです。
「ここは譲れない」というポイントを把握しつつ「テキストのここが半角空いているのが気に入らない」というところまであげつらいます。交渉事はデッドラインを決めつつ、譲歩分も織り込んで、最大限要求することが必要です。
そして改善要求したら「いつ実装されるのか」「できない理由はなんなのか」を意地になって問い詰め続けなければなりません。開発期間が終わって、現場に戻るとその熱意も冷めそうですが、実際は「こんな使えないシステム作りやがって」という現場の声で針のむしろなので、続けざるを得ません。
7. システム導入と運用
そして本番稼働が始まると、プロジェクトメンバーの携帯電話が、そのままレスキュー電話窓口になります。
QOLの概念は葬儀屋にはなく24時間営業です。23時まわったからそろそろ寝るかというときに携帯が鳴って
「システムエラーで止まっちゃいました。あと30分で終電無くなります」という泣きながらの訴えにつきあうことになります。
8. 保守とサポート
この段階に至ると「みずほ銀行、馬鹿にしてごめん」と、遠くを見つめながらつぶやきます。
失敗しないためにはどうすればいいのか
ではこんな失敗をしないためにはどうすればいいのでしょうか。
葬儀社側に力量がない場合（ほとんどがそうですが）外注開発は、投資とリターンのバランスが悪いです。
私は開発のプロではないので分かりませんが、失敗のリスクを最小限にするなら、結局パッケージのシステムを導入することではないでしょうか。
パッケージがある程度バージョンアップされているなら、フィードバックを経て改善されているでしょうし、クライアント側も事前に仕上がりをイメージをしやすいでしょう。
葬儀屋用パッケージソフトで、頭角を現しているかのように見える企業はこちらでしょう。
自社プロモーションを前提にはしていますが、一読をおすすめします。
コメントを残す