システムは「ビジネスにおける目的」がないと作れない
本日は、「システム」と「ビジネス」の関係性について考えていきます。また、それに関連して「コンサル」と呼ばれる職種の、種類と役割についても解説します。
ビジネス課題の解決に”システム”を使う
システム開発における最大の問題は「ついつい、システムをどう作るかを主題として議論しがち」というところにあると思っています。
システムというものは、所詮はツールです。システムを作るというのは、所詮は手段です。目的が先になければ、手段は意味を成しません。
というわけで、具体的な例に沿って「システムを開発する」とはどういうことなのかを考えていきましょう。
システムを作るために”何を考えていく”のか
そもそも、システムを作る前に「ビジネス上の目的」を考えていくことになります。多くの場合「何らかの課題解決」を目的として据えることが多いでしょう。というわけで、今回は「売上向上！」を目的とおいて”考えること”の流れを追ってみます。
尚、本稿が「システムを作る」ということを説明するため記事ですので、課題解決の結論が「システムを作る」ところに落ち着きますが、本来的には「そのビジネス課題の解決方法は、システム開発ではない」ということも十分起こりえます。”システムを作ることを前提としたビジネス課題の議論”は本末転倒ですので、どうぞお気を付けください。
売上向上の実現に向けて”考える”流れ
売上向上、すなわち、売上を伸ばす余地があるはずだ、という課題認識を解決しようとすると、現状をしっかりと理解する必要があります。今回の例では、営業人員に余力はないが、生産能力には余力がある、ということが分かったとします。そして、その結果「営業人員を割かなくても、勝手に売れる仕組みを作りたい」というアイデアが出てきました。（尚、繰り返しますが、別に自動販売システムを作らなくても、”代理店販売を始める”という選択肢もあります。）
その「自動販売システム」を行う上で、商習慣上必須の「取引毎の割引」が”自動”的に処理されないと、「自動販売」にならない、などの事情を考慮して、システムとしてどういうものを作るべきかを考えていく必要があります。ここで重要なのは「業務上、どういうことが必要か」ということと「それをシステム的にどう実現するか」は全く別の話ということです。ここを混ぜちゃう人が多いんですよね。ちなみに、前者が業務要件で、後者がシステム要件というやつです。”要件定義”というときにも、この2つが混じってしまっているケースが散見されますので、本当に気を付けましょう。（特に、「じゃぁ、8月までに要件定義をして・・・」というときの”要件”が、ビジネス要件なのかシステム要件なのかがズレてたりするとデスマーチへようこそ！って感じです。）
ここまで決まれば、（システム要件に沿って）「仕様」を決めていくステップに入れます。（※下図では「システムでどう実現するか仕様検討」が「システム要件定義と、それに基づく仕様の検討」を示しています）
その後、仕様書に基づいて、具体的な機能を定義・設計し、実際のコードを書く＝プログラミング・テストのフェーズを経て、無事、システムとしてリリースされることになります。おめでとうございます！
どこまでが「ビジネス」でどこから「システム」なの？
さて、この一連の流れの中で、どこに「ビジネス領域」と「システム領域」の境界線があるのでしょう。
先ほど述べた「ビジネス要件定義」「システム要件定義」の間が、まさに”境界線”です。「ビジネスの観点で何を実現するのか」と「それをシステムでいうとどうなるのか」に大きな川が流れているわけです。
ビジネス領域は、誰が考えるの？
一般的なケースにおいて、クライアント（事業会社）が関与するのは「ビジネス領域」です。そうすると、システム開発においては社内の様々な部門が関わることになります。
今回の場合、最初の経営課題の部分は「経営層および経営企画」が担当するでしょう。その課題設定や方針を受けて、「事業企画（会社によっては営業企画）」が具体的な打ち手に落とし込んでいくことになります。
その上で、システム領域に”翻訳”するために、「情報システム部」が主導して「ユーザー部門」を巻き込みつつ、業務を設計していくわけですね。もちろん、予算や期間の制約もありますが、可能な限り”本来の目的に沿った業務の姿”を描き切ることが情報システム部には求められます。
外部は何を手伝ってくれるの？
自社の各部門が上記のような役割分担で業務を整理していく中で、外部（外注）は「何を」手伝ってくれるのでしょうか。
まずは、下図をご覧いただきましょう。
- いわゆる「企画」の領域は、戦略コンサルが担当します。彼らは「何をすべきで、何をすべきでないか」を一緒に考えてくれます。
- 続いて、「業務の設計」は、業務コンサルが担当します。業務の効率向上や既存業務との不整合を起こさないために「どんな業務にすべきか」を整理することが得意です。
- 「システムにつなぐための準備」になると、ITコンサルが登場します。この段階では、ビジネス的にどういうことをしたいのかは大括りでは決まっていますので、それを「システムで実現するために過不足がない情報の集合」としてまとめることを手伝います。
この後は、ITコンサルと上流SEがタッグを組んで、具体的なシステム要件・仕様・機能へと落とし込んでいきます。それをシステムとして動くものとして実装するためにプロジェクト管理・運営なども含めて担当するSEや、プログラムを書くいわゆるプログラマが登場してくるわけです。（このあたりは「連載：本気で読み解く”人間の神話”」で詳細に解説していきます。）
尚、このように見ていただくと「戦略コンサル」と「業務コンサル」が「システムを作るのがゴール」と無条件で言っているのはあまりに畑違い、ということにお気づき頂けると思います。本来的に、戦略コンサルや業務コンサルは、冒頭申し上げた通り「システム以外の解決策の方が妥当なら、システムを作る必要はない」というスタンスにいるべきなのです。
余談ですが・・・
以上、システム開発とビジネス課題の解決の関係性について解説してきました。今回の記事作成にあたって、僕の社会人経験が非常に役立ったなと思いますので、余談ながら、少し僕の昔語りにおつきあいください。
僕は、新卒でSI企業に入社しました。300人程度の小規模ながら、大手商社の子会社ということで大手通信業者の情報系システムのヘッドコントラクターとしてのプロジェクトがあったりしましたので、新人として「PG（プログラマ）ロール」をやりながら、協力会社さんのチームを含むPM（プロマネ）を行いつつ上流工程の仕様検討もこなすという「SE（システムエンジニア）ロール」も経験できました。アクセンチュア戦略グループに転職してからは、BPRプロジェクトなどで「業務コンサルロール」を、新商品・新サービス開発プロジェクトなどで「戦略コンサルロール」を経験し、現在は、ギックスで自社の「経営企画・事業企画（というか、まぁ、役員なので経営そのものも含めて）」を担当しています。
僕自身の得意不得意・向き不向きや、スキル・知識の濃淡があるのは否めませんが、これらのロールを一通り経験してきたのは非常に良かったなと思います。結局のところ、世の中にはいろいろなポジション・トークが存在するわけですが、その多くのポジションを経験したことで、統合的に全体を俯瞰し、メッセージを出していくことができるのは、僕の強みの一つだなと感じています。コネクティング・ザ・ドットという名言がありますが、「すべてのロールをこなしたからこそ思うこと」を今後も継続的に記事としてまとめていきたいと思います。また、お付き合いください。
