中小企業情シス稼業

2社連続で中小企業ひとり情シスやっています。 同じ境遇の方のお役に立てればと思います。

広告

基幹システム更改プロジェクト

システムが老朽化してから、「システムと一緒に業務改善だ!」では遅い

close-up-of-a-snail

再リースに入る頃になると、基幹システムベンダーが「次のシステムいかがっすか」と提案に来るようになります。

もちろんこちらも「今のが使えるからいらないよ」と言うので、ベンダーはハード・ソフトの保守期限を盾にリプレースを迫ってきます


「なぜほぼ5年に1回、まだ使えるシステムのために大金払わなきゃいけないんだ!」
基幹システムでよく経営者から聞かれる言葉です。

もちろん金額の問題はありますが、ITへの投資って定期的に必要だと思うのですが・・・


まあ駄々をこねても結局、ハード・ソフトの保守期限には勝てません。渋々リプレースをすることにします。

で、その時必ず腹いせに(笑)、「これを機に業務改善だ!」「基幹システムベンダーも変える!」と言い始めます。
何でこいつら同じ動きばかりするんだろw


システムの老朽化に迫られてから業務改善なんて無理なんですよ。

特に期限に迫られて無理やり新規ベンダーにやらせると、結局既存ベンダーより費用がかかります。
プロジェクトが失敗した後に「これまでのベンダーで良かったよね」と何度聞いたことか・・・疲れます。

ではどうすべきか。

今回のシステム導入は「捨てる」

今回導入するシステムは「捨てシステム」と位置づけるべきです。

期限が迫っている状況では、諦めて現在のベンダーに移行を頼むのが安全です。
限られた時間で、慌ててあれもこれもやろうとすると、必ず破綻します。


腐っても基幹システムベンダーです。
既存のシステムについては熟知しているので、移行のリスクが下がります。

データ移行の部分も地味ですが重要です。その辺りを「ある程度は」おまかせできるのは強いのです。
落とし穴もありますが・・・

関連記事:
基幹システム導入 仕様策定3/3-データ移行内容の明確化


それ以外でも無傷ではないです。トラブルは必ず起こります。
でも破綻まではいかないだろうというところです。


これ別に既存の基幹システムベンダーを擁護するわけではないですよ。

そもそもリプレース提案が毎回同じ手口なのがいけないんですよね。もっと上手にアプローチできないんですかね。

おかげで外資のPowerPointが上手な営業が、直接経営者にクラウド提案しちゃって、頭がお花畑になっちゃうんですよ・・・


既存ベンダーに頼むのは、無謀なプロジェクトよりはマシということです。
一見、芸が無いように見えますが、結果として安く上がるし、トラブルも最小限になるのです。

芸が無いという言い方をされるのも実は心外です。
そもそも時間に余裕のある時から、次期システムの検討を開始していないのが悪いのです。

社内SEとしては、早めに「次のシステム検討を始めましょう」と上に提案して、後で責められないようにしておく必要があります。
一笑に付される可能性が高いですが、実際に検討をやるやらないはどうでもいいです。「警告したぞ」というポーズになればいいのです。

「捨てシステム」が安定稼働したら、見直し検討を開始する

今回の「捨てシステム」が安定稼働したら、速やかに見直し検討を開始します。
不要な業務・代替可能な業務を洗い出して、次のシステムには実装しないようにします。

期限に迫られることも無いので、余裕をもって検討できます。
作ったばかりのシステムの資料があるでしょうし、不要だなと思いつつ、泣く泣く実装した機能など、まだ記憶に新しい部分もたくさんありますから、検討もしやすいと思います。


要件がまとまれば、他のベンダーから「精度の高い」相見積も取れるようになります。

相見積は精度が高くないと意味がありません。
新規で売り込んでくるベンダーの見積は、当然業務の理解が浅いので、必ず安い見積になります。
それだと見積を比較する意味が無くなります。で値段に食いつくと、安かろう悪かろうということに・・・

相見積が取れるということは、既存ベンダーには相当プレッシャーをかけることができます。
彼らは「相見積なんて取れっこない」とあぐらをかいていますから。

関連記事:


現場も努力が必要です。
安定稼働している時こそ、課題をピックアップして蓄積すべきです。
プロジェクトが始まってから慌ててネタ集めでは遅すぎます。

また無視されるんでしょうけど・・・

「捨てシステム」の提案をしても、まあこんな地味で無駄金使うように見える話は無視されるでしょうね・・・

無駄金に見えるものは、実はこれまで満足にITに投資してこなかった報いなんですが・・・

ITを使う限り、結局どこかで投資しなきゃいけないんですよ。
それが嫌なら紙に戻ればいい。



社内SEは経営層とのコミュニケーションが大事なんですよね。

今の会社では、どうも方向性の面でコミュニケーションが難しく・・・
初めからプロダクトありきで話を進めようとされるので・・・
だから余計コミュニケーション取りたくなく・・・w

プロダクトは決まったよ。あと面倒なところはよろしく~
できるかそんなもんw


首突っ込んでくるなら最後までやれ!
それができないなら首突っ込んでくるんじゃない!

もうついていけません・・・

基幹システムのマニュアルをベンダーに作らせても、どうせ使いものにならないよ

afternoon-picnic-table-reading_925x

エンドユーザはよく「基幹システムのマニュアル作って」とベンダーに言います。
「こっちは客なんだから」とドヤ顔で。

一瞬、筋が通っているように聞こえるんですよね。


社内SE的には「あーあ、言っちゃった・・・」と内心苦々しく見ています。
私はガマンできないときは、ベンダーに助け舟を出してしまいます。珍しくw

ベンダー側もため息交じりです。
ちゃんと反論すればいいのにしないんですよね。
まあ使えないマニュアル作るだけで小銭が稼げますからねw


この部分、結構スルーしてしまいがちですが、実は基幹システム開発のゆくえを占う象徴的なシーンなんですよね。その後の流れが決まるというか。

ベンダーだけが被害こうむるならいいのですが、結果として社内SEひいては会社に、ブーメランのように返ってくるところなんですよ。

以下にその理由を書いてみます。

システム開発にエンドユーザがコミットしなくなる

まずエンドユーザの、基幹システムプロジェクトに主体的に関わる雰囲気が薄れるのが怖いんですよね。

マニュアル作りをベンダー任せにすると、
 「あなた(=ベンダー)作る人、私(=エンドユーザ)食べる人
という受身の態勢になっていくんですよ。その後もずっとです。癖になっていきます。

開発が終われば自分たちが使うシステムなのに、他人事として関わるようになります。
使う人がコミットしないシステム開発がどうなるか・・・

いったん上げ膳据え膳に慣れた人の考え方を変えるのは、大変難しいです。
誰だってラクなほうがいいですから。


そんな状態でも、ベンダーは適当に開発をしてしまいます。
彼らは¥さえもらえれば何でもいいですからね。後は野となれ山となれ。

で、使えないシステムの一丁上がりです。
最初はマニュアルだけの問題と思ったら、システムの存在意義をも揺るがす大問題になってしまうのです。

これを防ぐには、
マニュアル作成は現場の責任」と、キックオフミーティングでグランドルールとして宣言しておくべきなんです。

マニュアルはベンダーが作るものではない

そもそも、
 基幹システムのマニュアル≒業務マニュアル
なんですよね。
そして「業務マニュアルはユーザ側が作るべし」とはよく言われることです。

何故ユーザ側が作らなければいけないのかと言うと、ベンダーが作っても使い物にならないからなんですね。

彼らにマニュアルを作る能力がないというわけではありません。
問題なのは「重み付けができない」ということなのです。


ベンダーがマニュアルを作るとどうなるか。
画面に出てくる「○○区分」などの選択肢1つ1つについて、全部解説したようなものが出来上がります。
「○○区分のボタンを押すと、A・B・C・D・Eの選択肢が表示される」のような、画面を見たらわかるような情報しか書いてありません。

ベンダーが作るマニュアルは、メリハリのない、のっぺりとした辞書のようなものになるのです。
辞書を物語として読む人はいませんよね。

上の例で言えば、
 ・Aの値に何の意味があるのか
 ・業務ではほぼ9割方Aしか選択しない
といったことも書いて欲しいのですが、それはベンダーには書けません。

だから「業務マニュアルはユーザ側が作るべし」なんですよね。

テストシナリオを利用してマニュアルを作る

ではどうやってマニュアルを作るべきか。

実は基幹システム導入のプロジェクトをやっていれば、マニュアルを作る機会は必ずやってきます
それは社内SEのスケジュール感で言うところの、テスト作成フェーズ・テスト実施フェーズの時です。

・テスト作成フェーズ:要件定義・仕様策定後、ベンダーがプログラム開発を行っている期間
           (ベンダーで言うところの「開発」フェーズ)
・テスト実施フェーズ:ベンダーがプログラム開発後に、ユーザ側でテストを実施する期間
           (ベンダーで言うところの「仮稼動フェーズ」)

こちらとベンダーではフェーズ認識が違いますので、注意が必要です。
こちらがベンダー側の認識に合わせる必要はないです。

関連記事:


テストには実際の業務に合わせたテストシナリオが必要です。

テストシナリオは、頻度の高い業務から記載していきます。
業務には、毎日行うものから数年に1回しかやらないものまでありますから、毎日行うものから書きます。

これが重み付けなのです。ベンダーにはこの重み付けをつけられないのです。

丁寧にヒアリングしていればわかるはずなのですが、ベンダーは面倒くさがってやりませんね。
だからユーザに振り回されるんですよ。
「この機能がないと困る!」なんて言われて苦労してプログラム開発したら、実は年に1回しかやらないその人の趣味の世界の業務だったなんてことがあります。


重み付けのあるテストシナリオを文書化すれば、業務マニュアルになるはずなのです。
テストシナリオは業務マニュアルの骨子と言えます。

関連記事:


もちろん最初から完璧なものはできません。
だんだん継ぎ足していけばいいんです。

でもそれを継続するのは大変難しいんですよね・・・
そういう地味な作業こそ仕事の肝だし、評価されるべきなのですが、派手な動きが好きな経営者にはまるで響きませんね。

関連記事:
働き方改革において100点満点主義が有害である5つの理由
記録に始まり、記録し続ける



「基幹システムの全体を知らないから、全部使いこなせていないかもしれない」と言うエンドユーザがどの会社にもいます。
そういう完璧主義(?)が「マニュアル作ってよ」のセリフを言わせている面もあります。

メリハリのないのっぺりした辞書のようなマニュアルがあれば、使いこなせるのかな?といつも不思議に思います。
辞書は何か知りたいことがある際に引くものであって、起点になるものではないですからね。

システム設計など上流工程の勉強をし、高い視座からベンダーに質問するほうが早いと思うのですが、そういう地味な意見は聞く耳持たないんですよね。経営者も含め。


あとそうそう、マニュアルに限らず、最初からベンダーに期待するのが間違いというのもありますね。

結局いつもこの結論になりますがw

基幹システム導入のホントのところ-本稼働

user-phase5
 
前フェーズでのデータ突き合わせ一致度、バグなどの障害発生度合いを判断材料とし、本稼動してよいかどうかの判定会議を行います。
たぶんベンダーからやろうと言ってくるでしょう。

そこでメンバー全員と確認をします。

もし会議できない状況だとしたら、本稼動なんて無理ですけどね。

いざ本稼動!

「本稼動移行OK」となっても、特別何かセレモニーはありません。順調に来ているなら、意外と静かに進みます。

変わることと言えば、現場が新旧システムへの二重入力から、新システムにのみ入力するようになるだけです。二重入力から解放されるので、現場の負荷が下がります。


ここまでくれば、何か起きても腹をくくって対応しましょう。
細かいトラブルはあるかもしれませんが、致命的なことは起きないはずです。

正直、本稼動当日のことをあまり思い出せないんです。すみません。
それほどひどい目にあっていないので、印象に残っていないのかもしれません。

破綻している場合

これまでの作業が不十分なら、QCDのいずれかが破綻していると思います。

機能の不足やバグだらけだったり、その対応のために追加費用が必要になったり、そもそも本稼動の予定に間に合わなかったりということです。


この段階で何とかするのはもう無理です。もっと手前のフェーズで何とかする手があったはずですので。

事ここに至っては、QCDを変更するしかないでしょう。
品質を下げて運用でカバーして使うか、追加費用を払ってプログラム修正するか、本稼動の予定を延期するということです。



以上長々と書いてきましたが、基幹システム導入プロジェクトについて、私の少ない経験で書けることを書きました。

キーワードはメモしていたのですが、いざ文章を書く段になると、いかにまとまっていないか再認識しました。情報を整理する良い機会になりました。


「ITの、なかでも基幹システムのプロジェクトはハマって当然」
という思い込みに囚われず、プロジェクトの精度を上げていきたいです。

関連記事:


これからも追記すべきことがあれば、ブラッシュアップしていきます。

関連記事:
基幹システム導入 本稼働(この記事)

基幹システム導入のホントのところ-テストの実施・二重入力・マニュアル作成

user-phase4
 
プログラム開発が完了し、ベンダーから急かされるフェーズです。

ここからは一気に本稼動へ向けて進んでいくことになります。

同時並行でにやるべきことが多く、混乱しそうになりますが、冷静にこなしていけば大丈夫です。

テストの実施

前フェーズでの準備を生かし、淡々とやります。

作成したテストシナリオを各部門で実施してもらいます。
情シス業務部分のテストも忘れずに。


下記の二重入力作業もあるので、テストシナリオができていて、テストがスムーズに実施できることがプロジェクト成功の前提になります。

逆に言えば、テストシナリオの出来が不十分だと、非常に苦しい思いをすることになります。

バグなのか、仕様変更なのか

テストをしているとさまざまな課題が出てきます。
今までと同様、各チームから上がってくる課題は、すべてExcelなどで記録しておきます。


その課題はバグなのか、仕様変更なのか。ベンダーともめる永遠のテーマです。

これまでのフェーズで、こちらがきちんと作業していれば、基本的に細かい不具合はバグと認定され、ベンダーもすぐに修正するはずです。


現場からの「使い物にならない!」と言った根本的な問題は、その言葉をそのまま受け取ることはできないでしょう。

要件定義や仕様策定の際にきちんと検討されていなかったためと考えられるからです。そもそも議題に挙げていなかったり、または詳細まで詰めて考えていなかったり。

遅くともテスト作成の時に気づけば、ベンダーはまだ開発中ですので、交渉の余地はあったかもしれませんが。

どちらにせよ手遅れなのです。


この件に限っては、珍しく(笑)ベンダー側に立ちます。

プログラム修正するにも予算はないですし、慌てて修正することで、却って別のトラブルを誘発する可能性があるからです。


ひとまずは「本稼動後に考えましょう」と現場をなだめ、時間を稼ぎます

そのまま運用でカバーできるなら、本稼動後もそのままにします。
問題となり続けているなら、プログラム修正予算を確保し、実装します。

予算確保の際は、もちろんいきさつも経営層に説明する必要がありますので、きちんと記録しておきましょう。大金を使ったばかりなので、そう簡単に追加投資に許可は下りないでしょうから。


ベンダーは所詮外部の人です。こちらから積極的に議題に挙げていかないと、最後にこういうことになるのです。

グレーゾーンを残しておいて、こちらに良いことは何もありません。その曖昧さはすべて、QCDのどれかの形をとって、こちらに押し付けられると考えてよいです。

二重入力

新旧システム両方に入力を行います。
データは突き合わせて、本稼動に移行してよいかの判断材料にします。

「二重入力」とベンダーはあっさりと言いますが、現場の負担は相当なものです。
それぞれのチームは自分たちの伝票入力とチェックで手一杯となります。


そうなると、データの突き合わせにおいて、全体をチェックできる人は情シス以外いません。
ベンダーは合計金額くらいはやるかもしれませんが、それ以上に細かい突き合わせはしません。冷たいですね。

新旧システムのデータが合致しないと、いつまで経っても新システムに本番移行できません。
プロジェクトを早く終わらせるために、ここは情シスが腹を括って皆のために手を動かしましょう


具体的には、ExcelマクロやAccessなどで突合チェックデータを作って、毎日メンバーに配信します。
二重入力期間中は、旧システムのデータが正なので、旧システムを中心としたチェックデータを作ります。

新旧システムのベンダーが同じなら、どうやってデータ突き合わせをすると正確か、どのデータをチェックすべきか、相談したほうが良いです。


販売システムですと、受注・仕入データを月次/日時単位・取引先単位・明細単位などの複数の切り口でチェックデータを作ると良いです。
大きな単位でズレを発見し、明細単位まで追跡することができるので、現場も修正入力しやすくなります。

私は以前の会社では以下6種類のチェックデータを毎日作ってメンバーに配信しました。

①【月次合計】仕入先ごとの仕入金額
旧仕入先コード、旧仕入先名、旧仕入金額、新仕入先コード、新旧仕入金額
→仕入金額の一致チェック
@5-1

②【月次合計】得意先ごとの売上金額・粗利金額
旧得意先コード、旧得意先名、旧売上金額、旧粗利金額、新得意先コード、新売上金額、新粗利金額
→売上金額、粗利金額の一致チェック
@5-2

③【日次合計】仕入先ごとの仕入金額
旧仕入計上日、旧仕入先コード、旧仕入先名、旧仕入金額、新仕入先コード、新仕入金額
→仕入金額の一致チェック
@5-3

④【日次合計】得意先ごとの売上金額・粗利金額
旧売上計上日、旧得意先コード、旧得意先名、旧売上金額、旧粗利金額、新得意先コード、新売上金額、新粗利金額
→売上金額、粗利金額の一致チェック
@5-4

⑤【日次明細】仕入先ごとの仕入金額
旧仕入先コード、旧仕入先名、旧商品コード、旧商品名、旧仕入金額、旧仕入計上日、旧伝票番号、新仕入先コード、新商品コード、新商品名、新仕入金額、新仕入計上日、新伝票番号
→仕入金額、仕入計上日の一致チェック
@5-5

⑥【日次明細】得意先ごとの売上金額・粗利金額
旧得意先コード、旧得意先名、旧商品コード、旧商品名、旧売上金額、旧粗利金額、旧売上計上日、旧伝票番号、新得意先コード、新商品コード、新商品名、新売上金額、新粗利金額、新売上計上日、新伝票番号
→売上金額、粗利金額、売上計上日の一致チェック
@5-6


ここでマスタのコードを変更していると、間にコード変換処理をかませる必要が出てきます。
だからプロジェクト中にマスタのコード変更はやらないほうが良いのです。


「ほぼデータが一致している」と判断できれば、本稼動に移行することになります。
「完全にデータが一致している」ではないところがミソです。

マニュアル作成

マニュアル作成は、各チームの責任です。
キックオフミーティングで言ってあるはずです。

関連記事:


ただ実はテストシナリオが充実していれば、マニュアルの骨子はできたも同然なんですよね。
頻度の高い業務から順にテストシナリオを作っているはずです。
全部のマニュアルは作れないにしても、2割の主要業務を押さえれば、全体の8割はカバーできるはずです。パレートの法則ですね。


各チームがどう動くかはわかりませんが、どちらにせよ情シス用のマニュアルは早めに作ったほうが良いです。

ここから本稼動に入ってしばらく経つまで、他部門のフォローをする必要が出てきます。
いくら事前に手作業が来ないように予防していたとしても、最後は情シスがやらざるを得なくなることも多いです。


手作業が集中しても、新システムの情シスルーティンワークは継続しなければならないのです。
ひとり情シスは誰も助けてくれないので、安定的に新システムのルーティンワークをこなす必要があります。

マニュアルがあれば、作業に迷ったり間違ったりするリスクを最小限にでき、最短で作業することができます。
そうなれば他部門のフォローに注力できます。

関連記事:



その他データ移行もありますが、それはベンダーさんにお任せで(笑)


いよいよ本稼動です。

関連記事:
基幹システム導入 テストの実施・二重入力・マニュアル作成(この記事)

基幹システム導入のホントのところ-仕様確認・テスト作成

user-phase3

ベンダーがプログラム開発期間に入ります。ベンダーとの打ち合わせの間隔が空きます。
ほっと一息つきたいところです。

しかし最近は開発期間が短めになっていることもあり、まだまだ気を抜けません。

仕様確認

いざ開発の段階で仕様の問題点が具体化し、ベンダーから「どうしましょう」と連絡が入ります。

基本的には、仕様策定のフェーズと同様のやり方で対応します。

細かいことはメーリングリストで同意を取り、必要ならすぐに社内打ち合わせを行います。
もちろん打ち合わせを行う際は、解決策の叩き台を持って・・・


恐らくベンダーはExcelなどの課題管理表で管理しているでしょうから、それをメンバーに配布し、更新してベンダーに返す、を繰り返す流れとなります。
※最近はBacklogとかクラウドで管理ですかね。やり取りの手間が省けますね。

テスト作成

要件定義と並ぶもう一つの重要ポイントです。

ベンダーとのフェーズ認識の違いでも書きましたが、次の仮稼動フェーズは時間が足りません
準備なしでは慌ててしまい、抜け・漏れなくテストなどできません。

事前にテスト内容を細かく考えて、テストの効率化につなげます。

関連記事:


テストシナリオは必ず各チームに考えてもらいます。
情シスでは現場の業務がわからないので、必ず抜け・漏れがあるからです。

もちろん量的にも情シスがこなせるものではありませんし。


各チームのやる気がない場合は「やらないならその部門が困るだけです」という突き放すスタンスで行きます。皆の前で言ってしまって良いです。
テストの作成と実施は、キックオフミーティングで各チームの役割に入っていたはずです。

関連記事:
基幹システム導入 仕様策定1/3-キックオフミーティング


テストシナリオは、業務的な視点で作ります。販売管理システムなら、通常の受注業務から、受注キャンセルや返品など、業務上ありうるパターンを考えます。
頻度の高い業務からイレギュラーな処理を考えると漏れが少なくなります。

最初は作るのが大変かもしれませんが、慣れるとどんどん作業が進みます
「まず着手してみることです」と現場に伝えると良いです。


挙げた業務ごとにシナリオを考えるのですが、その際は入力値も予め記入しておきます。
具体的には、受注日や得意先コード、商品コードなどです。

販売管理システムなら、受注→出荷→売上と整合性が取れていないといけないので、それを追う際には具体的なコード類が記載されているほうが良いのです。

業務内容だけの記載ですと「さっき受注で何て打ったっけ?」となります。
コードなどをテストシナリオに記載しておくことで、テスト作業自体に集中できるようにします。


また明細部が空白状態で伝票登録するなど、ユーザは思わぬ操作をします。その辺りもテストに盛り込んでおくよう周知しておきます。


情シスの業務のテスト作成も忘れずに・・・


テストシナリオの作成状況は、定期的に全体打ち合わせでチェックし、遅れているチームにプレッシャーをかけます。

それでもやらないチームは、上司や役員に報告しておきましょう。後でトラブルだらけになった時に、情シスのせいにされないためです。


テストシナリオが出来上がったらベンダーに渡し、納品前にテストしておいてもらいます。

先にテスト内容を渡すのは邪道ですが、バグを出すこと自体がテストの目的ではないです。予めバグを取っておけるならそれで良しと考えます。


事前にテスト問題をカンニングさせているのに、それでもバグが出ます。
ベンダーさん、それは恥ずかしいことなんですよ。


次は仮稼動フェーズです。

関連記事:
基幹システム導入 仕様確認・テスト作成(この記事)

広告
広告
プロフィール
40過ぎて何とか結婚し、2015年末に子どもができた、左利き初老オヤジです。日本史を再勉強中。株、囲碁、鼻炎、眼振少々。中小企業ハッタリテキトー情シス(社内SE)。Access/ExcelVBAしか武器(?)はなし。情試はPM/SM/SA/NW。 ベンダーSEを数年やり、その後情シスに転職しました。 情シスでは中小企業ばかり3社見てきました。現職と前職ではひとり情シスです。 会社では「いないとヤバいが、評価はしない」という扱いです。 ノウハウを伝える相手もいないので、せっかくなので自分なりのコツを公開したいと思います。 同じような環境で苦労されている方のお役に立てればと思います。 「情シスの格を上げる」が目標です。 Twitterをフォローいただくと、ブログ更新時に通知されます。http://twitter.com/suiton_everyday よろしくお願いいたします。
お問い合わせ
お問い合わせはこちら
プライバシーポリシー
・当サイトに掲載されている広告について
当サイトでは、第三者配信の広告サービス(Googleアドセンス)を利用しています。
このような広告配信事業者は、ユーザーの興味に応じた商品やサービスの広告を表示するため、当サイトや他サイトへのアクセスに関する情報 『Cookie』(氏名、住所、メール アドレス、電話番号は含まれません) を使用することがあります。
またGoogleアドセンスに関して、このプロセスの詳細やこのような情報が広告配信事業者に使用されないようにする方法については、こちらをクリックしてください。

・当サイトが使用しているアクセス解析ツールについて
当サイトでは、Googleによるアクセス解析ツール「Googleアナリティクス」を利用しています。
このGoogleアナリティクスはトラフィックデータの収集のためにCookieを使用しています。
このトラフィックデータは匿名で収集されており、個人を特定するものではありません。
この機能はCookieを無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
この規約に関して、詳しくはこちら、またはこちらをクリックしてください。