どっちも間違ってる。
ユーザ「システムのことがわかる情シス側がビジネス理解をして要求定義を定め、要件定義もやれば良いではないか。我々は通常業務で忙しく、そんな暇はない」
— 麹 (@oryzae1824) 2025年7月19日
この発言に反論してください
覚悟せぇや。
— レシート裏のがらすめん (@TNBTSS) 2025年7月19日
「暇がない」のではなく、「覚悟がない」んだ。
暇がない。一見もっともらしく聞こえる。しかしこれは、「社のビジネスの未来を他人任せにする」という責任放棄の宣言にほかならない。…
それより、ビジネス知っている人がシステム理解した方が確実ですばい。
— herofuwa (@herofuwa) 2025年7月19日
本来、情報システムの要求定義・要件定義をするのは、エンドユーザでもなく情報システム部門でもない。
情報システム以前に、組織内に従業員がいるとしてその人たちにどう動いて欲しい？部門や部署を作ったとして、そこにどう動いて欲しい？複数の部門や部署はどういう役割分担？その役割分担って誰が決める？
企業としてどのように組織を形成するかというのは企業によるとしか言えないわけだが、オレが上に微妙な書き方をしたのを再掲する。
- 本来、情報システムの要求定義・要件定義をするのは、エンドユーザでもなく情報システム部門でもない
そう、一方は情報システム部門なのに他方は「エンドユーザ」である。「部門」対「個」である。ここに不足しているのは、
- 組織内に従業員がいるとしてその人たちにどう動いて欲しい？部門や部署を作ったとして、そこにどう動いて欲しい？複数の部門や部署はどういう役割分担？その役割分担って誰が決める？
を記述した文書である。人にフォーカスすればジョブディスクリプション(職務記述書)だし、部門・部署にフォーカスすれば職務分掌規程などである。どう動いて欲しいって書いたものがあれば、それは人や組織に対する要求定義・要件定義そのものである。情報システムの要求定義・要件定義ということであれば、何を情報システムにやらせて何を人に任せるのかに分けて書くことになる。
何を読まされているんだって思う人もいるはず。そこでもう少し別視点で書く。
まずエンドユーザが要求定義・要件定義をするのがおかしい。これがエンドユーザ部門ということなら、それはおかしくない。企業活動としてどうあるべきかをボトムアップで作るというのがまず間違っている。そもそも企画・設計され文書化されているべきもので、指示命令系統を通じて示達されていなければならない。それを作るのがエンドユーザ部門の管理者なのか、別の企画・設計部門なのかという担当は企業それぞれであろう。企業規模にもよるだろうし、企業文化的なものによるだろうし。
一方で、情報システム部門が要求定義・要件定義をするのは明らかに間違いである。それぞれそのビジネスオーナーがどんな要求をするのかを勝手に情報システム部門が規定していいなら、それは情報システム部門ではなくビジネス企画・業務設計部門ということにもなる。いや、企業としてそこまで集約するんだという覚悟でやるなら、それはそれでありだけど。ただ、そこまで集約してしまうと各エンドユーザ部門はただのワーカーである。現時点維持なら問題は無いかもしれないが、ビジネス的な柔軟性(他社との新規協業とか新商品・新サービス企画とか)を考えるのであれば、ちょっと集約し過ぎで身動き取れない可能性は否めない。
まとめる。
そもそも日本の企業ではジョブディスクリプションや職務分掌規程などが文書化されていないという問題が多い。企業幹部などにはある意図があって組織体制を作っているはずで、誰・(部門・部署)に何をして欲しいというものもあるはずである。そこを文書化していないために今回のまとめのような誤解が生じる。
文書が無いなら無いでも仕方ないが、それをエンドユーザにお伺いするというのも間違いである。
ということで、情報システムにITアーキテクトが存在するように、ビジネスや業務にもアーキテクトという役割は必要である。ビル建てるのにそれぞれの作業者だけじゃ何もできないのと同じである。一級建築士などのチームが何をどう作るのかの全体を設計し、各専門家が細部に落とし、それをそれぞれの作業者が作り上げていく。
エンドユーザに要求定義・要件定義をさせるというのは、ビル建設に例えれば、土台屋に好き勝手に土台を打設させ、足場屋に適当に足場を組ませ(以下省略)。まともなビルになるはずがない。どう工程管理するのかさえ想像できない。
あと、アーキテクトを立てて全体を把握させ企画・設計させたとしても、それが最終案というわけじゃなく、レビューして叩いて漏れ・ダブリ・ミスを無くす必要はある。それはITアーキテクトであっても、建築や建設の設計であっても同じ。業務設計においてもそのフェーズは必要。
こんな不毛かつ間違った押し付け合いするくらいなら、もうそういう設計が実システムに落とし込まれたパッケージやSaaSを使って、パッケージやSaaSに合わせて業務を変えろとしか。
