中小企業情シス稼業

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

広告

2017年01月

今すぐ捨てるべき10の思い込み

throwing-basketball_925x


中途採用で入社すると、上司がすぐ辞めたり、
引継ぎどころかそもそも入社時に前任者が既に退職していたりします。
彼らもひとり情シスとしてそれなりに過酷な状況だったのでしょう。


ただ、彼らの残した大量の使えない資料や、作りかけの動かないツールなどを見ていると、無駄なことにエネルギーを使い、自らハマっているようにも見えます。

関連記事:


そこに共通するのは、「思い込み」だと気づきました。
以下の思い込みを捨てる瞬間が、ひとり情シスには絶対に必要な気がします。

1.全部やらなければいけない

そもそも全部できると考えるのが傲慢なのです。
全部やろうとすると、すべてが中途半端になり、結局周りに迷惑をかけます。

関連記事:

優先順位をつけて仕事をし、可能なら社外に振るべきです。

ラクをすることを考えます。サボるのとは違います。
サボるとは、社内の他の人に仕事を押し付けることです。
会社全体の仕事量としては変わっていません。

ラクをするとは自分の中で仕事を効率化することです。

関連記事:

2.公平にやらなければいけない

神様ではないので、すべて公平にはできません。
コンピュータを扱うとはいえ、ひとり情シスは生身の人間で、感情もあります。

私はその感情は大事にしてよいと思っています。
えこひいきを積極的にして良いのです。

関連記事:

但し、主観的な好き嫌いではなく、業務効率化の基準に照らして判断します。
えこひいきの延長線上に会社の業務効率化がある、という大義名分を持てなければなりません。
そうしないと、相手からの批判に反論できません。
感情論ではダメです。会社で感情を表に出すと、一気に説得力がなくなるのです。

判断の軸を正しく持つ必要があります。
すなわち勉強が必要だということです。

関連記事:

3.他部署の業務を効率化しなければいけない

「情シスは業務部門をサポートするのが仕事だ!(キリッ)」とよく言われます。
本当にそうでしょうか?

ひとり情シスは自分のことで精一杯だと思います。
自分のことも満足にできないのに、他人を助けるようなど、傲慢な考え方と言えるでしょう。

まずは自分の仕事を効率化し、できた余裕で他部署の対応をすべきなのです。
自分の仕事の効率化が、全社的な効率化につながっているのです。

関連記事:
情シス必須ノウハウ!タスク管理方法
情シスでわかりやすく効率化するにはプログラミングしかない!
Accessは情シスの効率化に最適

4.完璧にやらなければいけない

学校の試験ではないので、100点満点には絶対にできません。

代わりにスピードで補います。
明日の8割より、今日の6割を目指すのです。

作った時間的余裕で、ブラッシュアップをします。
または他の大事な作業をすれば良いのです。

5.すぐに終わらなければならない

時間がないものはないのです。
そこまで放置していた人が悪いのです。
「困る!」などと言われても知りません。所詮他人事ですしw


ただ、やると決めたら、ガタガタ言わずとにかく着手します。

途方もない量の作業があっても、最初の一歩を踏み出す勇気を持つことが大事です。
1000件あっても、1日20件やれば、3ヶ月以内で終わります。


今まで散々放置していたものは、それなりに理由があります。いきなり劇的に改善することはないと思っているほうが良いです。
もし1%でも進められたら「今までよりマシだろ」と大いばりして良いのです。

0%と1%には大きな差があります。
1%進められたものは、10%まで進められる可能性があります。
10%まで行けば、30%、60%、90%まで行けるかもしれません。
片付くスピードが加速度的に上がっていくのです。

一度動き出したものは、勢いがつくのです。

6.正直でなければならない

嘘も方便です。駆け引きも必要です。

すぐにやる、簡単にできると言わず、スケジュール・費用に余裕を持って相手に伝えて良いのです。

えこひいきとの絡みもあると思います。
「こんな簡単なのサクッとできんだろ?」「なるはやで」と言われた瞬間に、優先順位を下げることです。

情シスの価値を下げようとする相手に、まともに対応する必要はありません。
他に優先すべき人がいくらでもいます。

関連記事:

7.皆に好かれなければならない

皆に好かれるのは不可能です。

自分に協力してくれる(=会社の業務効率のことを考えてくれる)人に好かれれば良いのです。
社員から直接給料をもらっているわけではないのです。

関連記事:

8.皆に理解されなければならない

上からも下からも、まんべんなく理解されることはありません。
特に上から理解されることを期待すると、そうならないときに大きく失望します。
最初から期待しないほうが良いです。

ひとり情シスはその名の通り、孤独です。
会社は数の論理なので、必然的に社内での立場も低くなります。
簡単に異動させられたり、とても情シスの範囲とは思えない業務まで兼務させられます。


そこで対抗措置として、社内システムを人質にします。
私の場合は、AccessやExcelマクロでツールをたくさん作って、ブラックボックス化させています。
インフラも押さえます。私のインフラの知識は20年前のものがベースですw

中小企業では、このくらいのレベルで十分人質にできます。
むしろ泥臭いところを押さえることのほうが大事です。手段は関係ないです。


ひとり情シスは自分がルールというくらいの気持ちで良いです。
大きなストレスに対応するには、強い意思が必要です。
変わり者と思われても仕方ないと私は思っています。

自分のことを分かろうとしてくれない人に、説明する必要はありません。

ブラックボックス化したはずのツールを他の手段に置き換えられてしまったら、
所詮自分にはその位の価値しかないのだと諦め、転職すれば良いのです。

関連記事:

9.ITはハマるのが当たり前

仕事は順調に進めるのが当たり前です。

IT業界の考え方は異常です。だからITの格がいつまでも上がらないのです。
デスマーチなどプロジェクトの失敗はトラウマになってしまいます。次の一歩にためらいが出てしまいます。

社内調整の場だろうがベンダー相手だろうが、
費用対効果を無視した要件、必要最低限のところに予算をかけない、余裕の無いスケジュールなど、
ハマることを前提とした考え方には抵抗すべきです。


抵抗の仕方としては、
 ・積極的に協力しない
 ・抵抗勢力となる
 ・全部丸呑みしてブラックボックス化させる
などがありますが、できれば抵抗などせず、
情シスに事前に相談しておくと、仕事が順調に進む、と思わせたいところです・・・

関連記事:
無駄な残業は意地でもすべきではない理由
残業せず定時で帰る8つのコツ

10.諦めるしかない

諦めてはいけません。

思考停止しないことです。思考停止したら終わりです。
1ミリでも進めるように、何らかの策を考えます。
1ミリ進んだことで、その後一気に状況が打開することもあります。


制約の中で考えるのが仕事なのです。

すべての制約がなくなることは永遠にありません。
「制約がなくなってからやる」というのは、「やらない」と言っているのと同じです。

本当に諦めたのなら、文句を言わず黙って仕事をするしかないのです。

関連記事:


私も最初、これらの思い込みの罠にハマりそうになりました。
ほとんどが正論なので、これを捨てようとすると自己嫌悪に陥りました。


発想の転換ができたのは、前社で上司が突然辞めることになった時です。
転職してまだ半年で上司が辞めると聞き、しばらくは眠れない夜を過ごしましたが、
その後吹っ切れました。

それからは自分にできることをやりました。
そして、ひどいため息ばかりついている上司に付き合って残業するのをやめ、さっさと帰ることにしました。

その時、自分にできることをやろう、何か問題が起きても逃げずに受け止めよう、という覚悟をしたのだと思います。


その後も、ひとり情シスとして生き残るため、思い込みを捨てて仕事をしました。
社員のために尽くす模範的な情シスではないので、仲の良くない人もいました。「あいつは仕事をしていない」と役員に睨まれたりもしました。

でも決して全員に嫌われたわけではなく、むしろ人間関係にメリハリがついた気がします。
今までの会社で一番長く勤めました。

結局その会社を辞めましたが、今でもその会社の人と飲みます。
あるとき私が在籍していたときの感想を改めて聞いてみました。
自分では反感を持たれていたと思っていましたが、全く逆の評価でした。
「しっかりやっていた」という印象を持たれていたのです。

完璧を目指すのをやめたおかげで、かえって道が開けた、というのは皮肉だなと思っています。

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

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-キックオフミーティング


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

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


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

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

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


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


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


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

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


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

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


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


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

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

基幹システム導入のホントのところ-仕様策定3/3-データ移行内容の明確化

 ※このフェーズは長いので、3つに分けて書きます。
user-phase2

システムはアプリケーションだけでは使えません。データが必要です。

マスタデータ、在庫データ、債務・債権データなどを現行システムから持ってこなければいけません。

データ移行は典型的なグレーゾーン

かなり重たい作業ですが、システムの仕様策定のほうに集中してしまい、つい見落としがちです。
移行費用を見積に入れるよう必ず議題に上げるべきです。

ここで議題に上げておかなければ、後から追加しにくくなります。結構な費用がかかるからです。

それでも安いものです。情シスが四苦八苦しながらデータ整備するのに比べれば。
これも経営者の理解を得づらいところです・・・


私のときは販売管理システムの受注残・発注残データの移行を見落としました。ベンダーに泣きついて作業をお願いしました。

事前にベンダーが指摘してくれなかったのも原因です。面倒な作業なので、わざとグレーゾーンにしているのです。
ベンダーから積極的に言ってくることはありません。フェーズの最後の最後で「移行データの準備をお願いします」としれっと言ってきます。

こちらから早めに言うしかありません。
具体的にどのデータを、どのように移行するのかをはっきりさせておくべきです。


移行費用を払っているにも関わらず、「Excelフォーマットを用意するので、現行データを加工してそのフォーマットに入力してくれれば、それを新システムに移行します」とぬけぬけと言ってくるケースもありました。

その加工部分が一番大変な作業なのに。何度も罠にかかり泣かされました。ホントベンダーは汚いです。

ベンダー主体ですべてのデータを移行させる

情シスで移行作業を行うのは、大変な労力がかかります。

以降のフェーズでも、こういったグレーゾーン作業のしわ寄せはすべて情シスに押し付けられます
ベンダーも打ち合わせの場で煮詰まると「それは情シス作業ですかね・・・」と簡単に言い放ちます。


上流フェーズからこのような細かい作業を安請け合いしていたら、間違いなく破綻です。誰かに頼ろうにも、ひとり情シスにマンパワーはないのです。

細かい作業は基本受けないように立ち回る必要があります。

別に情シスがサボろうというわけではないのです。
予期せぬところで、手を動かさなければいけない場面が必ず出てきます。そのときのためにも余力を残しておく必要があるのです。


すべてベンダー主体で移行されるように全力でもっていきましょう。上司を使いベンダー営業を動かすなど、なりふり構わずで良いと思います。


もし今回のプロジェクトが基幹システムの更改で、新旧システムのベンダーが同じ場合、
データ移行をやってもらえなければ、同一ベンダーにする理由が無いです。

プロジェクトを振り出しに戻すくらいの気迫で主張すべきです。


もしこの交渉に失敗すると、以降のフェーズでデータ移行作業の負荷が増えることになります。
情シスが現場レベルで手を動かしている時点でプロジェクトは終わっています。

情シスは全体のコントローラーに徹するべきです。
この辺も経営者の理解があると良いのですが・・・


このフェーズでは、開発範囲の拡大を抑えつつ、情シスに細かい作業が来ないようにするのが目標と言えます。


次のフェーズに進みます。要件定義と並んで重要なフェーズです。

関連記事:
基幹システム導入 仕様策定3/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を無効にすることで収集を拒否することが出来ますので、お使いのブラウザの設定をご確認ください。
この規約に関して、詳しくはこちら、またはこちらをクリックしてください。