連載

B2Bのコンテンツビジネス構造を考察してわかったこと

最初にB2Bのコンテンツビジネスとは、クラウドでの仕事斡旋、ビジネスマッチング、EC商材などのB2Bとした。
何故、このような考察したかといえば、EC販売の商品検討をしたとき、幾つか仕入れサイトに登録してみたが、コモディティ商品の販売となり、インターネットの世界では価格勝負になるので、大量仕入れをし、薄利多売となるのが基本的な考え方になる。当然、独自サービスを全面にして販売することは可能である。だが企業体力がある場合に限る。
ならばと、独自商品開発を検討したが、大量仕入をしない限り単価が割高となり、ブランドがないので、マーケティングコストも馬鹿にならない。在庫リスクを考え受注生産としても納期までの時間がかかり、販売戦略としては、好ましくない。
これでは八方塞がりなので、ビジネス構造を考察し、収益を圧迫する要素を除外できないか考えた。
 
B2Bのコンテンツビジネスの構造を考察してわかったことは、大きくビジネスモデルは2種類あった。

  • 情報掲載料
  • 手数料

情報掲載料は、広告と一緒で掲載しているコンテンツを見に来るユーザにリーチするためのものである。前提として、コンテンツの情報量が豊富で、精度が高いことが前提となるが、広告は継続して掲載する必要があるので、固定費がかかる。
手数料は、成功報酬であるものの数十%かかり安いわけではない。結局のところ、手数料分を契約金額に上乗せするので、割高になってしまう。
またまた、八方塞がりになってしまった。
よくよく考えると、ビジネス構造として買い手の方が強いと言われるが、小規模同士の売買は売り手の方が強いということがわかる。
ビジネス構造を改善するには直販に限る!
それだけでは不十分で、取引をする企業と信頼関係を築き、お互いに効率化を図りコストを下げることが出来なければならない。信頼関係はなかなか出来ないが、継続したビジネスをすることで、お互いを知り、実績が信頼を強める。
 
宣伝になるが、ZENEI(善栄)は直接取引の場を提供し、コミュニケーションが取れる仕組みを無料で提供するビジネスマッチング+B2Bソーシャルコンテンツである。
経済を支える、中小企業・家族経営・個人事業主・フリー・副業のひとたちに是非利用してほしい。
 
 
 

【連載】ヒアリングをまとめて全体像を描く

ヒアリング結果をまとめる

ヒアリング結果をもとに、全体像を描くことにした。
D社小林「まずは、S社の全体業務の流れを記載してみてください。最初は詳細は不要です。全体的な観点で大丈夫です。いきなり詳細をまとめると、嫌になってきてしまいますからね。ホワイトボードに記載してみてください。」
佐々木「わかりました。こんな感じです。」
D社小林「山田さん。ここにシステムを記載してみてください。」
山田「わかりました。受発注システム、店舗システム、EC、顧客管理システム・・・。こんな感じです。」
D社小林「ありがとうございます。このシステム構成で問題になりそうなことは、何でしょうか?」
山田「データが分散されてしまうことだと思いますが、いまは定期バッチで連携していますので、問題ではないと思っています。」
佐々木「バッチで更新されているのは知っているが、翌日にならないと集計されないので、リアルで数字を知りたい場合があるので、都度、情報システム部に連絡をして集計してもらっている。」
山田「すべてをリアルにするには結構大変です。特にシステム毎に同じマスタでも管理項目が違うので、一緒にすることができない。」
D社小林「そうですね。でも、このプロジェクトでは、既存の考えを取り払って、あるべき姿をイメージしてみましょう。でなければ、現状からの脱出はできません。」
山田「ネットワークの見直しもある前提として、こんな感じかな。」
D社小林「すばらしいですね。ここに業務を意識して機能を置いていきましょう。」
佐々木、山田「全部ではないですが、できました。」
D社小林「山田さん。想定で良いのでデータベースを配置できますか?」
山田「ざっくりですが、こんな感じです。(黒線)」
D社小林「ありがとうございます。バイヤーとのヒアリングでもありましたが、在庫問題は機会損失にもなりますし、足を運んでいただいたお客様に申し訳ない気持ちになります。ですので、在庫など出来る限りリアルで基幹システムにAPI連携しましょう。(赤線)
もう一つ、せっかくのデータが集まるのですから、システム間の連携だけではなく、ERPの要素を取り入れて、ダッシュボードを作りましょう。各工程に携わる人たちが、事実を知り改善ポイントの情報提供です。
もちろん経営陣には、いま以上に経営に活用していただきます。」

連載 全社システム構想


佐々木「ダッシュボードには何が表示されるのでしょうか?」
山田「分析ツールを配るのは大変です。」
D社小林「ダッシュボードでいろいろと表示させたいですよね。でも、基本は財務数字の見せ方です。利益は売上から経費を引いた数字です。売上は各店舗の売上の合計です。ようは、あれもこれも表示しても利用者は使いきれないと思います。だから、押さえるべき基本を表示すればと思います。何を表示するかはノウハウです。」
佐々木「そういえば、渡辺COOも、いつもの決まったフォーマットの経営数字だけで把握されているようですし、それだけでなく的を得た課題をぶつけてきます。いつも不思議に思っていたのです。」
D社小林「深掘りするには分析ツールは必要ですが、日々の業務については、ダッシュボードでできるようにしたいですね。」
後日
佐々木「小林さん。ダッシュボードで何を表示するか腕の見せどころとありましたが、売上は当然知りたいですが、それでは目標に対する進捗はわかりますが、遅れていたらどうすればよいかわかりません。わかるようにするということですか?」
D社小林「その通りです。店舗によって要因は違うとおと思いますが、商品別、時間別などは共通して確認すべき要因です。そういった要因を表示してはと考えています。」
佐々木「ありがとうございます。考えてみます。」

【連載】商品管理とバイヤー体制

バイヤーによる商品管理

S社は、セレクトショップである。S社で取り扱う商品は、S社コンセプトを基準に他社も扱う商品もあれば、S社しか扱っていない商品もある。このコンセプトが、S社のオリジナリティになっている。流行りものは、お客様を呼び、定番商品が安定した利益になっている。常に全体最適化をしながら、商機を最大にする品揃えにするよう心がけている。
バイヤーA「売り方は、商品説明はするが、店舗に任せている。店舗では、商品毎に利益率が違うので、セット販売やキャンペーンなどの工夫をしているようであることは聞いている。同じブランドでも、限定モデルや、海外限定モデルを輸入することも検討している。バイヤーは流行りに敏感でなければダメで、加えてお客様の声を聞き、さらに一歩上の求める商品を探すことをしたい。」
バイヤーB「在庫が減ったら発注するが、バイヤーが担当している。商品を探しながら、発注業務をしているので、つらい。また、移動も多いので、お取り引き様から連絡がつかないと言われることが多々ある。」
バイヤーC「在庫が減ってきたら、各店舗から連絡がある。その後、こちらから各店舗に連絡をして売れ行きを確認して発注数を決めている。定番商品は良いが季節性がるような商品は発注数を間違えると不動在庫になってしまう。」
佐々木「発注数はどのように決めていますか?」
バイヤーC「よくはないかもしれないが、経験と勘です。ですが、いままで、大きく外したことはない。計算してくれたら良いが、いろいろな状況から発注数を決めているので、難しいと思う。」
佐々木「店舗によっても違うし、キャンペーン内容でも違ってくる。都度都度、考えることが必要なんですよね。理論通りにいかないから、人の能力が必要なんですね。」
D社小林「内勤バイヤーチームを作ってはどうでしょう。ある会社で採用されています。実際に取り引きしていたのですが、とても助かった経験があります。内勤者は、在庫管理、発注業務を担当し、お取り引き様と接点を維持する。バイヤーは、新規開拓とお取り引き様の関係維持と強化に努める役割です。」
バイヤーA「いいですね。効率よく仕事ができそうです。」

【連載】SCM(サプライチェーンマネジメント)で仕入先との関係強化を図る

取引先との関係強化とSCM

S社に限ったことではないが、バイヤーが商品を探し仕入数を交渉しているが、在庫数は仕入先の都合にも左右される。仕入先もビジネスであるため、S社が独占しているわけではないので、必ずしも満足する回答が得られるわけではない。
仕入先も直販、S社以外の納入先への配慮、生産キャパシティ、利益と様々な要素で判断して、バイヤーとの交渉に応じている。S社はセレクトショップであり、仕入先があって成り立っているビジネスであるので、仕入先を手厚くもてなすのが社風にある。そこで、情報戦略プロジェクトの構想として仕入先とも連携する仕組みとすることにした。受発注だけでは、S社の効率化が目的で入れていることになってしまう懸念があるため、様々な情報交換ができる仕組みへと発展させる。仕入先が大手であれば、自社システムである程度のことは実現できているが、中小零細企業であっても素晴らしい商品が多数あり、取引をしているが、システム投資をする予算はない。そこで、S社のSCM構想に、取引先が利用できるようにする。機能としては、お客様の声や、基本属性による販売数分析結果などである。これにより、お互いの信頼関係の強化と、仕入先の意思決定の材料になればと思っている。
もうひとつの課題である在庫についても、KPIによる在庫管理をして需要予測をして仕入先との生産計画に役立てるようにした。この背景には、仕入れまでのリードタイムが変動することがあり、話をしてみると、原材料が余らないように少なめにして、受注生産に近いことをしていると聞いたからである。これでは製造ラインのこともあり、都度都度の調整が発生し、お互いに良い関係にはなっていないと感じていたからである。
山田「具体的なイメージがつきません。」
D社小林「S社独自のEDIといえば、イメージできるでしょうか? この機能を取引先に解放するのです。」
山田「わかったような、わからないような?」
D社小林「これから、全体をまとめるフェーズですので、そこで話をしましょう。」

【連載】自社のオムニチャネルを考える

S社のオムニチャネルを定義する

オムニチャネルをテーマに議論することになったが「店舗とECの融合だろ!」「ネットで検索したら店舗に誘導するとあったぞ。」オムニチャネルについて議論が発散してしまった。
そこで、S社のオムニチャネルの定義を考えることにした。オムニチャネルもそうだが考え方であるので正解は無いが、S社としての考えがブレると効果が低いオムニチャネル施策になってしまうことを心配した。
オムニチャネルをどのように認識しているか、整理することにした。

  1. 店舗とECの融合
  2. 店舗への誘導
  3. 在庫を見つけ機会損失を減らす

の意見が多かった。
D社小林「ご意見ありがとうございます。まとめると、店舗とEC・インターネット・在庫がキーワードでした。各部門にヒアリングをした時もそうでしたが、店舗とEC は、共通して売上向上に個別に取り組んでいました。ですので、S社のオムニチャネルは「売上を最大にする」と定義しましょう。店舗でも、ECでも、お客様からすれば、どこで買っても同じです。在庫も機会損失を減らすためです。また、現在のように、個別に対応していては非効率でマーケティングコストが多く掛かってしまいますしね。」
山田・佐々木「皆さんも納得されているようですので、売上を最大する視点でオムニチャネルを考えましょう。」
D社小林「そのためには、S社サービスの統一が必要です。そのためには、店舗、EC で主張し合うのではなく、ベクトルを合わせて協力することが大切です。店舗の強みは強化し、弱いところはEC が補う。その逆で、ECの強みは強化し、ECの弱いところを店舗が補う。そうすることで、お互いに相乗効果が期待され、S社としてのオムニチャネルが実践できることになります。」
佐々木「でも、店舗もECも売上目標があります。たとえば、店舗がECを補った場合、売上は店舗になるのか、ECになるのかで問題になりそうです。」
D社小林「お客様からすれば関係ありませんが、目標制度がある限りは問題として取り上げるべき課題です。では、考えてみてください。いままででも、無意識に他店舗やEC に貢献していることは多々発生しています。在庫切れで、他店舗へ案内することもありますし、取り寄せもします。この場合、お客様が他店舗へ移動して購入したら、他店舗の売上です。在庫であれば、取り寄せをすることで、他店舗では機会損失リスクが高まります。ですが、皆さん協力して対応していますよね。ですから、課題ではあるものの大きな問題ではなく、気持ち的に不公平になることが不満であり、公平性を保てるような制度へと工夫をすることでクリアできるのではないでしょうか。それに、全社売上が達成しなければ、ダントツでトップの成績をだしたとしても、店舗は評価はされますが、ボーナスは原資がありませんので期待できません。どうせなら、がっちりと頑張った対価がもらえた方がよいですよね。」
佐々木「いわれてみれば、そうかもしれません。特に間接部門の評価は全社の成績で決まりますので、全社視点で目標達成に向けた動きをしていきたいです。この件は、課題として管理していきますが、評価に他店サポートポイントのようなものがあると良い感じもしますので、渡辺COOに相談してみます。」
3日後
渡辺「小林さん。佐々木から評価について相談があるとのことだが、知っていますか?」
D社小林「オムニチャネルの話ですね。店舗、ECを連携させると評価がどうなるか気にしていました。」
渡辺「給与に関係するからか。でも、小林さんとよく話しをしているが、数字だけで評価をすると会社は成長しない。それに間接部門は数字がないから評価軸が違う。会社は人で成り立っているので、部門に関係なくひとり一人の従業員が力を発揮できることが良い環境であると思います。評価は動機付けになるが、足を引っ張るようであれば意味がない。」
D社小林「その通りだと思います。渡辺さんは、大学院でも組織行動論には熱が入っていましたものね。」
渡辺「そうだったかな。佐々木の件は承知した。佐々木の勉強にもなるから、相談を聞いて宿題を出そうかな。」

【連載】ベンダーには何を求めるか?

ベンダーには何を求めるか?

山田は、ベンダー選定にあたり、田中部長から「プロジェクトはベンダーに任せて、ベンダー管理をすれば良い」と言われた。
しかし、山田には若かりし頃のベンダーにいた時の経験から、あの時のような仕事では、期待に応えられる結果が出せない不安になっていた。ベンダーにいた時は、納期に間にあわせるために連日の徹夜での突貫工事であった。やりきった感はあるが、お客様に期待した通りの開発ができたと思えなかったからである。要件定義を担当していた先輩に言われたことを設計・開発していたが、仕様変更が相次いだ。どうも、いろいろとお客様から指摘されていたようである。
振り返ってみると、お客様から言われたことを並べていただけの要件定義で、議事録と変わらず、ヒアリングの羅列でしかなかった。ビジネスは線であり広がりがあることを無視していたようである。
このような経験から、自分たちで納得するシステム化になるように、ベンダーには任せられないと思っていた。
改めて田中部長に相談してみたが「無理だ。ベンダーに任せろ!」と言われてしまった。
そこで、こっそりとコンサルタントの小林に相談してみた。
D社小林「田中部長の言われる背景には、皆さんには、通常業務があり、時間を割いてプロジェクトに参加している。情報システム部含めて全社員がプロジェクト以外の業務がある。だから、片手間ではプロジェクトを推進するのは厳しいので、ベンダーに任せることを指示していると思いますよ。しかしながら、山田さんの意見も理解します。失敗プロジェクトの多くは、山田さんの経験されたことと一致するからです。ベンダーは、コンサルティングをすると売り込むが、実際はシステムエンジニアが担当するので、コンサルティングというよりは、何を作るかヒアリングをまとめるだけである。ヒアリングが結果に矛盾があろうが、業務が非効率になろうが、疑問を感じない。全てのベンダーが、ダメというわけではなく、正直言えば、担当する人の当たり外れで決まるのが、現実です。」

プロジェクトにおけるベンダーの役割を考える

山田は、小林の話に納得しているもののベンダー選定をどうして良いか困っていた。
D社小林「山田さん。具体的にどうすれば良いか考察してみましょう。プロジェクトを成功させるには『人数ではなく、必要なスキルを持ったチームであることが重要です。』わかり易くいえば、プログラミングに強い人だけのチームでは、要件定義ができないので、プロジェクトは成功しませんよね。まずは、情報システム部の社員スキルを確認しましょう。」

  • 田中部長は大手SI企業でプロジェクトマネジャー
  • 山田も中堅のSI企業でプロジェクトマネジャー兼システムエンジニア
  • 他の情報システム部部員は小さな開発会社で大手SI企業の下請けで設計と開発を担当

D社小林「情報システム部のメンバーの経験はわかりました。では、このプロジェクトを成功させるために何が不足しているか考えてみましょう。」
山田「小林さん。プロジェクトには、どのようなスキルが必要ですか?」
山田と小林で話し合った結果、上流含めた開発以外は、社員とコンサルタントを主軸とし、ベンダーには開発を主軸に期待することにした。
山田「PMOには、小林さんにも参画してほしいのですが、いいですか?」
D社小林「良いですよ。ただ、わたし一人では人数が足りないので、丁度わたしの会社に良い人財がいますので、参画させます。」
山田「でも、予算が・・・」
D社小林「開発ベンダーの予算から捻出してはどうでしょうか? もともとベンダーに依頼する予定の上流工程の予算があるので、この費用を使えると思いますよ。」
山田「そうですね。同じお金を払うなら、適材な企業・人財に投資をした方が期待できます。」
D社小林「田中部長には、ベンダー丸投げにならないように注意するように、うまく伝えておきます。」

  • プロジェクトマネジャーを補佐するPMO・ベンダーコントロールは、D社も参画
  • 課題整理・ASIS、TOBEの可視化は、社員、プロジェクトメンバー、D社が担当
  • 開発のための要件定義以降は、ベンダーが担当

ベンダーにはベンダーの価値がある。企業がベンダーに求めている価値とベンダーが得意とする領域がマッチしているとよいが、必ずしも成功するとは限らない。
情報システム部が、広域に渡るITスキルとビジネスとの親和性が高い設計をすることで、コストを抑えベストなシステムを作ることができる。理想かもしれないが、全従業員で稼いだお金は大切にしなければならず、無駄なコストは申し訳が立たない。できる限りでも理想を求めても良いかもしれない。悪い言い方をすれば、丸投げは失敗します。使うのは、皆さんであり、ベンダーではありませんからね。

【連載】アーキテクチャを甘く見てはいけない!

アーキテクチャーを気にしないと失敗します

アーキテクチャーは設計思想ですが、重要性に気が付いていない人が多いと感じています。
システムリニューアルする理由には、メンテナンス性が悪く何をするにもコストが高い。何かすると不具合が発生する。OSやミドルウェアのバージョンアップに対応するにはコストがかかる等々あると思いますが、実はアーキテクチャが大きく関係しています。
勝手な感覚値ですが、設計思想を持って設計する/しないでは、リリース後のメンテナンス性含めて、コストは、数十%の違いがでると思っています。
イメージして欲しいのですが、新築の家を建てる時に建築士が設計し、大工が建てます。アーキテクチャを甘く見ると言うことは、大工が設計書無しに経験だけで設計して建てることと同じです。違法しているかもしれませんし、窓の明るさが確保出来ないかもしれません。ようは、住む人の家ではなく、大工が立てやすい家になってしまう心配があります。
できてしまった後に、使い勝手悪いから直すとしても、ここに柱があるから動かせないとか、やるなら補強しないとダメとか想定外のコストと時間がかかってしまします。
そうならないように、将来の家族構成や趣味などを考慮して住む家を考えます。システムも一緒で、事業を考えて拡張性を持てる設計にする必要があります。

【連載】店舗へのヒアリング

店舗へのヒアリング

山田たちは、旗艦店に出向きヒアリングすることにした。
店舗担当者からは、

  1. 店舗の営業成績がわからない。
  2. 売れ筋を感覚で管理している。
  3. いまのシステムには、欲しい機能が追加されないので、東京店は独自で管理しているようだ。
  4. 全社キャンペーンが、店舗のキャンペーンを無視して企画されている。
  5. 在庫の奪い合い!売れる商品はECに持っていかれる。
  6. 在庫不足で予約を承るが、何度も来店いただくのが申し訳ない。
  7. 商品がマンネリ化している。似た商品になっているので、お客様の目をひく商品が欲しい。
  8. アルバイトのシフトが大変である。
  9. 倉庫スペースが小さく、何を置き、何を置かないかわからず、悩んでいる。

と、いろいろな課題があることがわかった。また、店舗は、自分たちで企画し売上に貢献していることがわかった。
店員A「せっかく店舗に来ていただいても、在庫切れや接客に必要な情報提供が出来ずに、機会損失になっている。」とのことだった。
店員B「EC独自のキャンペーンが、来店していただく機会が減っている。本社は何を考えているかわからない。」と不満である。
山田は、情報システム部には改善要望がきていないので、要望はないと思っていたが、要望が上がってきていないだけで、実は課題が多く隠れていることを認識した。社内にいると、いろんな部署から問い合わせや要望を聞くが、どれも愚痴っぽく、真剣に取り組むことをせずに、記憶から消えていく。確かに個人的な要望も多く投資する価値あるの?と疑問に思うことも多々あるからかもしれない。しかし、真剣に取り組む課題もあることを認識しないといけないと考えさせられた。
小林は、ECによる販売が拡大し、店舗の立地優位性は減ってきていて、ECに不安を感じていると思った。しかし、考えを変えれば、立地は重要で相乗効果を出せると考えていた。
小林「S社独自のオムニチャネルを考える必要があります。検討しましょう。また、要望には、ビジネスに有効な内容もあります。システムは育てるものですので、これを機に要望を反映させられるルールも考えましょう。以前、情報システム部の改革として、『要望承りますはじめました。』の張り紙をしたクライアントもいました。何でも投資するわけではありませんが、システムに対する良い雰囲気作りになりました。」
山田「いいですね。是非、検討したいです。」
また、店舗はシフト制勤務をしているが、アルバイトのシフトが組みが大変で、雑務も多く社員は無理してでも出勤しなければならないことがしばしばあった。
まとめとして、S社独自のオムニチャネルを検討すること、人財確保について人事と相談することで、ヒアリングは終わった。

【連載】進捗報告

気になることはそのままにしない

ベンダーは、オンスケジュールの報告をしたがる。遅れていても、都合の良い過大解釈をして、オンスケジュールとして報告する。
報告を受ける側からすれば、安心するが、よくみて見ると、辻褄が合わないところがある場合がある。そのときは、説明を求めなければならない。本当にオンスケジュールではない可能性があるからである。
経験的に説明を求めた場合、ほぼ都合のよい解釈をしてオンスケジュールの報告をしていた。ベンダーも結局のところはバレることになり、進捗報告会の場で指摘をされ、事実の再報告を求められる。
また、リスケをして、リスケ後のスケジュールでオンスケジュールと報告をする。だが、違う。遅れには、変わらないのである。リスクを高めているだけである。このようなことをするのは、世界に1社だけかと思いきや、何社も経験した。遅れは遅れで、遅れを認識することが大切である。リスケは、リリースを遅らせた時にするのものである。
このような経験から、ベンダーからの進捗報告は次のようにした。

数値化での報告を求める

定性(文章)は、人によって理解が違うため、認識齟齬が発生する。基本は数値化して報告をする。
注意すべきは、数値化する際の定義である。
たとえば、プログラム開発完了とした場合、完了数と総数、そして進捗率を報告する。
では、プログラム開発完了をどのように定義するかが、ポイントになる。あるベンダーは、コーディングと定義していた。あるベンダーは、単体テスト完了と定義していた。
コーディングとすると、品質のよっては時間がかかるということになる。つまり、質の良し悪しに影響する報告となる。だから、単体テスト完了と定義するべきである。
このように、進捗の数値化をする場合には、定義を決めることも忘れていはいけない。

報告のための作業は減らす(事実を知ることと分析は違う)

管理とマネジメントは違う。進捗報告は、事実を知ることを目的であるので、アレコレと分析は不要で手間の割に効果は薄い。
実は、実際にプロジェクトマネージャーとしての経験がない、コンサルタントや、理解せずにネットで調べた教科書的なことを要求する人が多い。進捗には、分析は必要だが、分析をベンダーに指示して作成させることは意味がない。また、当然ながらベンダーは手間をかけなければならないため、嫌がる。
分析が必要なら、自分たちでればよい。そもそも、進捗に分析は不要である。あるのは、品質管理図だけである。
進捗は事実を知り、プロジェクトをマネジメントする材料であることをを忘れていはいけない。

【連載】設計書レビュー

いままでのヒアリング結果を要件定義書としてまとめ、レビューすることになった。いつも、ベンダー視点のベンダーしかわからない表現で記載されていることが多く、しかし情報システム用語も多い傾向がある。D社小林から、要件定義書レビューについて、事前レクチャーがあった。また、情報システム部向けに、アーキテクチャの設計書レビューについて、説明があった。

要件定義書レビューはとても大切!

設計書レビューの仕方で、後工程の出戻り、品質、生産性は大きく変わってくる。しかし、やらなければならない業務は多数あり、期限に追われ、読み込む時間が足りないのが、実態である。そこで、押さえるべき本当のレビューポイントを理解することが、現実的である。

ヒアリングされた内容・用語が正しく理解されて記載されているか?

ベンダーは、S社の業種経験者を担当させる努力はするが、どうしても頭数を集めるには下請け構造に頼るしかなく、全員が経験者になることは現実的ではない。どうしても、一部の従事者のみになってしまう。一部のメンバーがベンダー内での内部レビューを全部こなすわけにはいかない。納期を考えると実質的に放置状態になる。このようなベンダー側の都合があるため、レビューで確認して指摘をする必要がある。S社からすれば、開発ベンダの問題と思う人もいるが、目的はS社のビジネスの成長基盤を作ることなので、割り切って自分たちの業務として取り組むことが大切である。

業務フローに矛盾・無理(運用が困難であることが予想される)がないか?

業務フローのレビューでは、矛盾・無理がないか確認をする。たとえば、物流部門に13時に当日お届けするピッキングデータが届いても、運送会社は対応できない。つまり、現実的である業務フローでなければならない。基幹システムを入れ替えるため、業務を改善したいと思うし、実際に改善をする。そこで陥りやすいのが、常に気にしている業務に特化してしまい、他の関連業務が煩雑・負荷が上がってしまうことが往々にしてある。広く、影響範囲を含めて、確認する必要がある。

機能に過不足はないか?

各部門からのヒアリングをまとめてみると、案外と機能漏れが多い。ヒアリングする人の主業務は日頃から気にしているため、説明できるが、それ以外は難しい。曖昧な記憶で説明する。だから、業務の流れで過不足を確認する。実際に細部まで見えるようにイメージする。忘れがちが、月一のルーチンワークです。派遣にお任せしている処理は忘れがちである。

機能の目的に間違いは無いか?

機能は記載されているが、利用目的が間違っていると機能の細部に影響がある。たとえば、在庫一覧の機能があるとする。商品名順に在庫数量がわかる機能を想像するが、在庫一覧の目的が、機会損失をしないため都なると、違ってくる。在庫数量の少ない順・減り方の推移・在庫切れまでの予想残日数などの表示が必要になる。在庫管理といっても目的によって違いのである。

イレギュラー時の逃げ道は、機能としてなくてもあるか?

業務にイレギュラーはつきものである。予測不能のイレギュラーもあり、想像して機能を準備するのは、投資の無駄である。
コンプライアンスの視点から不正防止の仕組みを前提に逃げ道をつくることが必要である。通常発生では無いので、少し手間がかかっても良い。万が一の対応である。事例の多くは、情報システム部門が、手作業することである。
補足となるが、パッケージだからといってカスタマイズ分だけでは、設計書のレビューにはならない。理由は、業務は流れであり、流れがレビューできなければならないからである。ユーザー部門からは、あっていると思うけど、イメージがわかないとあった。実際に動かないと疑問や間違いに気づけない。対策として、HTMLで紙芝居を作り、説明することにした。

アーキテクチャ設計は、コストに大きく関係する

アーキテクチャは、知識が必要でベンダ任せになることが多い。しかし、設計書レビューをすることで、余計な開発コスト、運用コストを削減できる重要な意味がある。
観点は、運用性、メンテナンス性と性能がある。

  • 運用性は、マスタ化してハードコーディングしないことである。そんなことしない。当たり前とご意見はあるかもしれないが、まだまだハードコーディングしている設計は多い。
  • メンテナンス性は、共通クラス化である。同じコーディングを重複して持たない。テーブル1つ1つに意味を明確にして、構造が同じ(似ている)からといって、区分で複数の意味を持たせてしまう。こうすると、メンテナンス性は大きく低下する。
  • 性能は、データベース負荷を最小限にする設計である。データベースがボトルネックになると、改善の見込みがなくなる。最近は、仮想化やクラウドサービスが充実しており、インフラの選択肢が増えている。とはいえ、性能は重要であり、利用者の不満になりやすい。
  • バッチとリアル処理は妥当か? バッチ処理は、まとめて処理をするため、処理が大量データを処理することに適している。リアル処理は、即時反映しなければならない処理に利用する。