戯言
忘れない。
お前の声を、言葉を、笑顔を。
忘れない。
その固くなった体を。
忘れない。
助けられなかった自分の非力を。
忘れない。絶対に。
れっつ営業
久々の営業活動
今のプロジェクトは移行もひと段落し、6月末で終了。元請の皆様ごと、きれいにさようならと相成りました。
ま〜、実際、最初に書いた絵（もう5年前だな〜）からみると、いいとこ50%くらいしかできていない感じなわけですが、ミニマムスコープとしては、確かに完了。5年もやったし、潮時ってやつかな、とは思います。
ということで、5年ぶりに、自分自身の営業活動をしてみました次第。
もしかすると、系列化ってやつかな、これ。
5年も外界から隔離されていると、カンもへったくれもないわけで、今、どういう市況かもわからない。とりあえず、手探りなんですが、ほんと、混沌ですなあ。
たとえば、ですよ。
ロジ系のサブリーダークラスがやれて、SAPのことを知っていて、TOEIC750点あって、海外とコミュニケーションできて、希望単価1.2Mとか、なんでっしゃろ、これ？というようなお話があると思えば、金に糸目はつけんから、今入っているだらしない某コンサルファームを、ユーザ側で入って仕切ってくれ！！みたいな、別の意味でなんでっしゃろ、これ？というネタもあり。
う〜ん、なんかね、昔と、様相が違うんですよ、確実に。
昔は、SAP案件市場というのが、確実にあって、その市場の中で、市況というものが存在し、単価の相場が変動する、という、自由競争市場だったはずなんですよ。
ところが、上で書いたみたいに、景気がいいのか悪いのか、わかったもんじゃない、玉石混合みたいな感じになっているような印象なんですな。
なんでこうなったのか、これも、自分の印象だけなんですけれど、いわゆるサブコン組も、元請を頂点とする「系列化」が進んでるんじゃないかな〜、なんて、感じております。
前あったSAP案件市場、というのが、元請を頂点とする「系列化」で、その元請けの案件の中で、市場がクローズしてしまい、全体としての市場を形成しなくなっている。そんな印象ですなあ。
だから、ある元請が、仕事が少なく、ついでに社内のリソースがあまっていると、そんなハイスペックでその値段で、人がいると本気で思っているんだろ〜か、というリクエストになり、ある元請が、なんの拍子かしらないけれども、がっつり案件とっちゃったら、「値段に糸目はつけね〜ぜ！」とかいう、別の意味で本気なの？？という話になっちゃう、そんな感じでございましょうか。
純粋国内案件ってやつは・・・
で、これまた、単なる印象なんですが、いわゆる日系のSI会社は、ちょっと分が悪い感じがしております。
原因は、キーワード「海外展開」。
やっぱり時流なんですかね〜。海外の工場なり、販社なり、M&Aで買った会社なり、そこへの展開を想定しているお客さんが多い感じなんですよ。そうすると、外資系のほうが、安心できるイメージがあるんでしょうね。日系のSI会社は、外資に負けちゃうケースが多いっぽいです。
まあ、実際は、外資系っていっても、ドロドロの縄張り争いを内部ではしているわけで、イメージ通りの海外サポートができるか、というと、かなりウフフ、な世界なわけですが、ま、そんなのは、お客さんのほうからは見えないんだろ〜な〜と。
まあ、考えてみれば、国内一巡しちゃったね〜というお話は、5年も前から言われていましたし、この10年で、新たにSAP入れましょうか、みたいな規模に、大きくなった企業って、そうないし。大企業は10年前も大企業。例外は、ユニクロや楽天くらいかな〜って感じです。そいつらに、SAPが入っているかどうかは知らんけど。
そうなると、純粋国内案件って、バージョンアップだとか、そういう案件だけなのかな〜なんて、思う今日この頃ですな。
まあ、ツイてましたが
そんななかなので、2ヶ月くらい遊ぶことになるかなあ、なんて思ってましたが、運よくお仕事にはありつけた次第。
英語が今現在怪しい私としては、なんとか執行猶予をもらった、って感じですかね。
何年も「英語やらなきゃ」って言って、さぼっておりましたが、今度こそやらないとな〜と思う、今日この頃ですわ〜
いまさらながら：パッケージで統一！は、是か非か その２
前回は、やったほうがいいんじゃね？ネタでしたが、今回は、やらないほうがいいんじゃね？ネタでございます。
統一の定義・・・同一インスタンスか複数インスタンス同一パッケージか
ちょっとこの話を考えるときに、「統一」ってやつにも、程度があるなあ、ということに思い至り、最初に少々書いてみようかと。ひとつのインスタンスで全部やってしまおう、というお話と、複数のインスタンスを立ち上げて運用するんだけれど、その中身は同一パッケージ、というお話がございまして、同一インスタンスで全部運用する、ってのが成り立つかどうかから、行ってみようかなあ、と思います、はい。
同一インスタンスで運用しよう！というのは、会社がひとつなら、まあ当たり前のことですが、じゃあ、海外子会社も一緒のインスタンスで運用しよう、というお話が、成り立つかどうか。
前述したように、業務のサービス化ができる分野では、会社が違っても同じシステムに対してオペレーションできたほうがいいね〜というのは、間違いないと思うんですよ。
しかしながら、大胆に時差がある地域を含めて同一インスタンスにしてしまうと、バッチ処理の時間がなくなってしまう。最悪それは大丈夫だとしても、システム変更するときの、移送ウインドウがなくなる、もしくはすごく小さくなってしまう。これは痛いなあ、と、思うわけです。
ですんで、海外子会社がヨーロッパとか、アフリカ、アメリカとか、豪快に時差があるところは、同一パッケージであっても、別インスタンスにするのが吉。業務としても、サービス化をいくらしたって、夜中に通常業務をするわけにはいかないですから、そのほうが素直だし。同一パッケージにしておけば、マネージャが見慣れた数字で管理できますよ〜というメリットもそのままでございます。
逆に、時差がない地域なら、同一インスタンスでがんばる、は、ありでしょうね。
複数インスタンスにしてみても
とはいうものの、複数インスタンスにしたときに、伝票構成にかかわるカスタマイズや、アドオンを各インスタンス別々にしてしまうと、それはすでに、「統一」の観点ではなくなる感じ。インスタンスは別々でも、資源は統一にしておかないと、メンテナンスの手間や、テストパターンの増加など、マイナスの要素が多い。
ですんで、資源は、全インスタンス共通にするのがいいんだろうな、と、思います。
その前提で考えると、もし、パッケージで全業務を統一したとすると、そのシステムは、各国の事情をすべて包含した、最大公約数的なシステムにならざるを得ない。それはそれで、ムチャムチャ巨大なシステムなわけで、メンテナンスコストが大きくなる、というか、あっという間にメンテナンス不能の状態になるのでは、と、予想されるわけで。
実際、もう10年近く前になりますが、某ERPパッケージベンダーが、全世界全業務統一インスタンス！！という荒業を、自社でやったらしいという話を聞きましたが、やっぱりやめたそうです。でかくなりすぎて、無理無理って話で。
となると、物事の流れとしては、全社共通で使う部分、つまり、サービス化の恩恵が大きいところや、定型的なバックエンドの仕組みは、全社資源として、時差を考慮した複数インスタンス構成にしておき、各国個別の事情の部分は、別のシステムを各国ごとに立てるのがいいんじゃね？という話になりますね。
具体的に、どこを外だしにするべきか
なんだか、ここまでのの結論は、すごく一般的なセールストークに落ち着いてしまった感じ。
けど、真面目にそうだと思うんですよ。
情報システム部から見れば、同一パッケージを使うメリットは、バラバラのときに比べて、同じスキルセットの人の中で融通が利くから、運用コストがさがる、ということ。ところが、いくら同じSAPだからって、たとえば、中国の商慣習なんてわかりゃしない。日本の本社の統一パッケージシステムにビルドインするっつったって、SAPスキルとしてはOKだとしても、業務前提がわからないわけだから、メンテナンスしようもないわけで、「同じスキルセットの人の中で融通が利く」という前提が崩れている。それなら、その部分だけ中国で作ってもらって、共通部分とIFしてもらおうかな〜っていう流れになり、ついでに、その中国で作ってもらう開発予算も、中国内から融通してもらって、金の出所とシステムサービスを対比させよう、という発想に落ち着きますよ。
となると、どこまでが統一システムの範囲で、どこからが各国固有なのか、ということになるわけで。各国固有のところ、その最大の部分は、やっぱり、販売側かな、と、思います。
受注までのプロセスは、やっぱり圧倒的に違うし、仮にそのプロセスがシステム構築の対象外だったとしても、国が違えば、収益性分析にまわす分析軸も違ってくるのが当然でしょうねえ。そうなると、これを共通化しちゃうと、分析軸、分析値の最大公約数を共通システム側にもたなければいけなくなる。いや、こりゃつらい。
さらに、受注でのネックは、価格決定だったりする。商売が違えば、価格決定のキーも変わってくるわけですが、それが最大公約数として設定することになると、それだけで大変な労力になりますわね。あら大変。
ということで、共通にしないほうがいいのは販売側。それに伴う、国ごと販売分析の分野も、各国ごとのほうがいい感んじゃないでしょうかね。
もうひとつの「最大公約数」･･･いろいろな商売をやっている場合
もうひとつ、統一しないほうがいいんじゃない？というケースは、グループ会社がいろいろな商売をいろいろな規模でやっている場合。
実は、こっそり前回、ERPだけで全部の業務はOKか、という話のなかに、「主力の商売ってのはひとつで、商売の形態がいくつもあるわけではない、という状態なら」という文言を入れていたりするんですよ。グループ会社が、いろいろな商売をやっている、という状況だと、統一ってやらないほうがいいかな〜と、私も思います。
やっぱり、統一しようと思うと、販売系のお話がネックになってきますね、こちらも。理由は各国共通にしない理由とまったく一緒。
製造から購買のところも、ちょっと考えないといけないでしょうね。こちらは、業務の違い自体は、会社ごとの設定ってやつで、機能的には吸収できそうかな〜と思うんですが、グループ会社ってのは、企業規模がさまざまであることが当然多い。小さい規模の会社に、軍艦みたいなSAP ERPを入れて、ライセンス料がペイするか、というと、全然ダメなわけですよ。商売が違うから、複数国パターンみたいに、複数会社でセンター化ってのも難しいわけで。
逆に、会計系は、グループ会社内で資金の融通をしてみたり、というオペレーションを考えると、サービス化ができる部分なので、パッケージで統一っていうのはアリでしょう。
結論。いろいろな商売をグループ会社でやっている場合、会計系はグループ会社共通で同一パッケージを同一インスタンスで運用するのがよさそう。そうなると、複数会社を同一インスタンスで運用できる、大規模ERPが微妙に有利。ロジ系は、そのグループ会社の規模を考えつつ、適切なパッケージで構築というのが最適ですね、きっと。
以上でございます〜
備忘
ずいぶん悩んだのだが、やはり書き留めておこうと思う。
非常時にできることは、日常の延長でしかない。
だから、日常を大事にしなければならない。
今から、ソフトバンクの社長になって、100億義援金を出してみたり、チャリティマッチで劇的なゴールとダンスをキメるなんてことは、できるわけない。
けれど、日常を大事にすれば、確実に、やれることは増える。
16年前はもらう側だった。
今回は、出せるし、出した。
出せる金額を増やすことが、私の日常の延長だ。
そりゃ、ソフトバンクの社長に比べれば微々たるものだ。ただ、自分が大事に思う人なり、コミュニティに、ピンポイントで出せる金を、もうひとふんばりして用意することは、そんなに無駄なことではないだろう、そう思う。
もしかすると、時間的に間に合わないかも知れない。金額的に小さすぎるかもしれない。
それは、所詮、今までの日常がそれだけの価値しかなかった、ということだ。
やるべきことはなにか。
日常を大事にすることだ。それに変わりはない。
募金すっか。
そーいや、神戸の震災で、20万くらい義援金もらったな〜
16年経ったし、ちょっと増やして返しておきますか。
えいっ！（字汚いな〜）
では、あまり一般的ではないTipsを。
今回、法人名義でやりました。
決算の時に、寄付金額分が今年の会社の所得から引かれるので、実質自己負担は額面のだいたい7割から8割ってとこです。
で、申告には受領書が必要とのことなので、郵便局で振り込んだわけですが、10万以上だと本人確認というルールが、赤十字社への寄付金でも適用とのこと。ちょっとびっくりです。
会社名義の本人確認とは、つまり登記簿をもってこい、というお話でございまして、用意していかないと、見事に空振りです。私は、たまたま別件で持っていた登記簿があったので、振込みできました。あとは、会社と本人との関係の証明。当方一人会社ですんで、登記簿の代表者住所・名前と、免許証をつき合わせてOK。普通は、名刺とか、社員証なんてのを提示するらしいっす。
ちなみに、郵便局の方の説明によると、いわゆる財団法人（赤十字社含む）への振込みは、寄付金であっても本人確認（つまり、会社名義の場合は登記簿）が必要で、各地方自治体への振込みは、本人確認不要とのことでした。公共料金や、税金の振込みと同じ扱いってことかしら？よくわかんないけど。
いまさらながら：パッケージで統一！は、是か非か その１
勝手に立ち上げるいまさらシリーズ。
タイミングよく、久しぶりに提案活動をやったところに持ってきて、だれおさんにかまってもらったので、パッケージでシステム統一、なんてのはなりたつの？なんて、大きく出てみようかなと思う次第でございます。
そもそもの話・・・ERPパッケージだけで業務はOK！！は成り立つのか？
いや、成り立つと思いますよ、本当に。
当然、メールとかワークフローとかはともかくとして、という前提であるんですけれど、主力の商売ってのはひとつで、商売の形態がいくつもあるわけではない、という状態なら、基本的にERPだけで、業務はまわせるんじゃないか、と。
もちろん、商談のパイプライン管理したいね〜とか、ウチはサービス業で、人員のアサインを自動でやりたいね〜みたいな話だと、単品では相手にならないだろうな、とは思いますが、大抵は大丈夫。それこそ、「なんでできないんでしたっけ？」って感じ。
つい最近、「ERPでは対応の難しい要件は、WEBシステムを作り、そこで吸収！！」というお題目のプロジェクトを見かけたんだが、そこの企業、主力の商売はひとつしかなく、別に商談のパイプライン管理みたいなお題目もない。「？」と思って、「ERPでは対応の難しい要件は、WEBシステムを作り、そこで吸収！！」の中身を追っていくと、実は単に現場のUIへの要望に答えれるように、外だしで作りますよ〜って話だけだった、なんてオチだったのがありまして。パッケージに合わせる気がないなら、パッケージ入れるなんて言わなきゃいいのにな〜なんていう、典型的な例だったりするわけです。
こういう感じの、ストレートに言ってしまうと勘違い（「この門をくぐるものは、すべての望みを捨てよ by だれおさん）をしなければ、パッケージ導入って、すごく意味のあることだと思うわけですよ。
ただ、自分の商売の主戦場である、SAPだったり、Oracleだったりの、バカ高いパッケージってどうなのよ？という話はあるわけです。もっと軽い、もっとストレートに言うと、もっと安いパッケージ、いくらでもあるんじゃない？なんて思うわけで。親会社が一括でライセンスを買っていて、それを流用できる、なんて特殊な状況でなければ、安いので十分だよな〜と、私自身も思います。昨今はSaaSなんてのも流行らしいけど、そいつについては、またちょっと別に考えるとして。
複数の国に拠点がある場合・・・統一システムのメリット
じゃあ、どういうときに、SAPとかOracleとかほしくなるかなあ、と、思うと、複数の海外法人がある、という状態だと、やっぱりSAPとかOracleとかほしくなってきちゃいますね。
まず、前提として、複数の国で同じシステムを使いたい！という視点は、業務観点でも結構あったりするわけです。特に、サービスのセンター化を行う余地のある業務で大きい感じです。
最初に会計のお話でいけば、できれば会計関係のグローバルサービス、みたいなのをやりたくなるわけですよ。例えば、入金消し込みであるとか、支払であるとか、そういう業務は経理サービスセンター見たいのを作って、複数の海外法人まとめて面倒みちゃいますよ〜って感じで、コストダウンだぜ！！というのが、経営者の考えることだったりするわけです。
購買、生産といった部分も、作っているものが一緒なら、特に違いはないかな〜というところ。どころか、製造プロセスや、購買プロセスが標準化されれば、他国比較で、無駄っぽいところが分かりやすくなったり。まあ、大量生産バッチ主義でどんどん作れ、というところと、需要ドリブンで少量生産、というところが、国によって変わってくる、なんて話はあるかもしれないんだが、製造指図さえ出てしまえば、それに基づいて生産、資材の消費に基づいて発注、というプロセスに、そう大きな差が出るわけではなく。
メリットとしては、購買関係は、やっぱりセンター化ができる。購買センターで発注かけて、受け入れだけ、各拠点で。製造プロセスが標準化されていれば、原価構造の分析も基本的には同じで、複数国での対比が容易。人材の点でも、ある工場の工場長を、別の国の工場立ち上げに派遣、と、いった場合でも、同じシステムから同じようにレポートが出るわけで、少なくとも使い慣れないシステムで、数字を読むのに四苦八苦、という事故は起こりにくい。
つまり、複数の国のオペレーションを一箇所でサービス化したり、基本的に同じようなモノを作っている工場が複数の国にあったり、という状態だと、同じシステムで動いているほうが、コストダウンという営業トークだけではなく、ちゃんとした実利はあるんじゃないか、そう思うわけですよ。
バカ高パッケージの出番
で、じゃあ、同じシステムで行こうというのはわかった。それなら、具体的には自社開発するのか？パッケージで行くのか？パッケージで行くならどのパッケージだ？という話になると、SAPさんやOracleさんがご登場なさいます。
自社開発、というオプションは、とりあえず無条件でさよなら。だって、APとDBを分割してスケールアウトをうまくしましょうとか、セッション管理をちゃんとやりましょうとか、そんな足回りから考え実装できる技術があるんなら、とっととその技術を売りに行けばいいんです。大抵は、そんな部分を丸抱えなんてできないから、パッケージになるわけですな。
じゃあ、パッケージで行きましょう、となったときに、当然のことながら、日本語しか対応していない、だとか、外貨が扱えない、なんてパッケージは、無条件で候補から外れます。
その条件を満たしていればいいか、というと、今度はグローバルシェアみたいな話が出てくる。要するに、マイナーなパッケージ使うよりも、名の通ったパッケージ使ったほうが、使ったことのある人が多いので、人を集めやすいわけ。そうなると、今残っているメジャーパッケージといえば、SAPかPracleかぐらいしかないわけで、そうすると、まあ、そっち使っておこうか、という話になりがちな感じでございますね。
ちょっと長くなったので、「統一なんて考えないほうがいいんじゃね？」ネタは、次回にでも。
いまさらながらプロトタイプ
パッケージ導入をやっていれば、避けては通れないプロトタイプ。今回は、今さらながら、プロトタイプの話でもしてみようか、と、思う次第。
これも今さら。プロトタイプとは
プロトタイプっていうのは、一通り動くまでパッケージの設定をして、お客さんに見せること。
大抵の導入方法論では、プロトタイプを作って、お客さんに見せて、そのフィードバックを受け、設定の修正をして、場合によっては追加開発をするモノを追加、決定する、なんてことになってます。
そのメリットは、教科書的なお話だと、お客さんに完成形をプロジェクトの早い段階から見せることで、最終的なシステムのイメージを持ってもらい、ウォーターフォール開発にありがちな、出来上がってみたら、思っていたのと全然ちがうやんけ！というのを防ぐ、なんてのが効用としてあがっとります。
ちょっとした違和感
で、ですね。今回久々に提案活動のお手伝いなんてのをして、作業プラン作成なんてのをやってみたわけですよ。パッケージ導入の提案なので、当然プロトタイプの実施、なんてワークアイテムがあるわけですな。
私は期間から見て、プロトタイプは1回やって、その後は、お客さんが気にしたところに絞って、個別機能ベースで4回くらいのセッションをやる、みたいな計画を作ったんですよ。
それを、プライムベンダーのマネージャに見せたところ、以下の会話になったわけですよ。
「プロトタイプ1回で大丈夫かな」
「？スケジュールから考えると、1回とちょっとってとこですよ」
「いや、本来なら何回必要か、ということを考えたいんだよね」
「本来？」
「当然回数を増やせば、品質は上がるわけでしょ。一般的な品質を担保するには、何回必要か、ということが知りたいんだよね。スケジュールから1回半っていうのは、それはそれでわかるんだけど、どんなリスクがあるのか知っとく必要があるんだよ」
うーん、この論法、やっぱり違和感があるんですよ、私には。
プロトタイプは回数を増やすほどリスクが高くなる
実際問題として、プロトタイプは回数を増やせば、完成するシステムの品質が上がるってのは、ちょっと違う、そう私は思っているわけです。
まあ、「品質」の定義にもよるんですがね、「品質」ってのが、バグが少ないこと、という定義であるならば、プロトタイプで品質が上がることはない。だって、標準機能はそもそも「動く」のであり、考えうる限り、品質はいいわけですよ。業務フローがきちんと出来ていれば、動かないはずはない。
じゃあ、なんのためにプロトタイプをするか、というと、エンドユーザの代表の皆さんの変な幻想を打ち砕き、「パッケージってこんなもんですよ」という紹介をし、納得をしてもらうプロセスだ、と、私は思っているわけです。
前提としているのは、トップダウンでの導入ですよ、もちろん。できるだけ、追加開発はしないでおきましょう、という大方針が出ている前提。これがなく、パッケージ入れるのに、エンドユーザの皆さんの言うことを全部聞いていたら、できるものもできなくなる。だから、「80点くらいはいけてるんじゃないですかね〜」ということを、納得してもらうプロセスが、プロトタイプなんだと、そいう思うわけです。
もちろん、どうしようもないところは出てくるだろうから、それは、追加開発のリストにいれますよ、もちろん。しかし、それは、ある程度事前に分かっておかないといけないとも思うわけです。業務フローを作ったときに分からないようじゃ、お金もらってる価値はないなあ、なんて。
ちょっと話が脱線したわけですが、じゃあ、このプロトタイプの回数を増やすとどうなるか。
迷いが出るわけです、プロトタイプに入ってもらう、エンドユーザの代表の皆さんに。
やっぱり、これじゃ使えないんじゃないかな〜、帳票のレイアウトをきちんとしないと、ｘｘさんから噛み付かれるんじゃないかな〜
やっぱり、こういう迷いが出るんですね。そうすると、追加開発のリストが増える。追加開発は、最後には審査会なんてのをやって、スクリーニングをかけるんですが、それでも残るわけです。全体が大きければ、「これを切ったから、こっちは残そう」なんていう、出し引きの世界は必ず現れますから。
つまり、プロトタイプの回数を増やすと、品質は上がらず、追加開発というリスクが増えていく。そういうものだ、と。
その証拠に、というと語弊があるんですが、初期のASAPというSAPの導入方法論、プロトタイプというステップがないんですよ。とっとと設定して、とっとと動かしてしまえ！動くんだから！！という、かなりの原理主義方法論ですな。今はどうか知らないんですが、セレモニーすらやらないっていうのは、さすがの私も、かなり違和感を覚えたもんです。
お前、何様
で、この考え方から行くと、プロトタイプは「セレモニー」なので、一連のセレモニーをやるスケジュールを組んでおけばOK。基本的に、1回だ！というのが、私の論法だったりするんですが・・・
ただ、この論法、「要件を確定させるのがプロトタイプで、回数を増やせば、要件はより厳密に確定するので、品質が上がる」っていう論法に比べれば、はるかに違和感があるんだろうな〜、やっぱりそう思うわけですよ。まあ、客観的には「お前、何様だ！」って感じですわね、実際。
ただねえ、パッケージ導入って、本質的に「お前、何様だ！」っていう行為だと思うんですよ。なので、これからも「お前、何様！」で、生きていこうと思います、はい。
