とりあえずご相談内容をメールください。

「こういうとき、どうしたらいいの？」とか「今までこうやってきたんだけど、効率の良いやり方ある？」、はたまた「どんな勉強したらいい？」などなど、お悩みの件についてご相談ください。

こちらもひとまずメールでご連絡ください。

都内在住ですので、東京近郊ならば気軽に動きます。
ただ、メールで完結する方が、お互いのためによいかも…。
個人に教えるのでしたら、料金は１時間につき：2,500円になります。交通費は別途いただきます。
会社等でグループで教える場合は別の料金設定になります。 人数やレベルによって教材も異なりますので、そこは別途お見積りさせてください。

メールなら、移動がないのと、アポ時間のすり合わせ等もないですし、こちらもスキマ時間を使えるということで、ツール等を作成するという特段のお話でなければ料金はかかりません。 なので、お気軽にメールください。
（過去にもたくさんメールいただき、みなさん何かを掴んだご様子でした。）

ぼくの教えるスキルについては、Excel四十八手を参考にしてください。 実際のぼくの語り口も、あんな感じです。

まずはメールでご連絡ください。

お代は業務内容によって異なります。 Excelの仕事は作業量、作業難易度がほんとうに多岐にわたるので、料金は、申し訳ありませんが「案件による」という言い方しかできません。 申し訳ありません。

さて、以下、ぼくにできることをまとめます。

・Excel作業全般
Excel屋なので、そりゃそうですね。
データ加工、VBA開発、業務設計、etc。
作業場所は、ぼくのルームでもよいですし、赴いての作業も都内近郊であれば可能です。

・Excel業務のディレクター
上記が「自分が作業する」のに対し、こちらは「他人に作業してもらう」です。 作業チームのリーダーとして、チームのマネジメントを行います。
この役割のときぼくがよくやるのが、「みんなが仕事をやりやすくなるツールを用意すること」です。 共通のツールを配布すれば、成果の質を均一にすることができます。
また、「マニュアルを配布しチーム全体の理解度を上げる」ことも得意です。
過去、「停滞してる業務を整流化し、次の人にバトンを渡す」ということをさまざまな現場で行ってきました。
なのでもし、このようなご要望ありましたら、ご相談ください。

・業務効率化提案
効率よい業務、ミスのない業務のために、どうしたらよいか。 一緒に考えましょう。
…ただ、何でもかんでも「変える」のがイコール「良い」とは限りません。 既存のフローは、たとえそれがどれほど非効率であろうとも存在する理由があるはずで、そこを解きほぐさないうちに大ナタを振るってしまうと大事なものまで失ってしまいかねません。
変えることの、利点とリスク。 両方を踏まえたうえで、バランスのよい着地点を見つけていければ、と思います。

仕事に対する姿勢について、過去書いたものを転載します。 エッセイ形式で申し訳ないのですが。
マクロ開発を発注された際の、思うところを書いたものです。

「ボタンをポチッとやったら処理が終わるようなマクロ、作ってくれないか？」


Excelマクロ開発において非常によくある発注時の光景であるが、こういう発注の仕方をされると、正直、悩んでしまう。

ボタンにマクロを仕込むのは何も難しいことではない。 僕が抵抗を覚えるのはそこじゃない。


他人のためのマクロを作るとき僕が一番に考えるのは、「できたマクロを現場の人がどのように使うのか」である。

仮にぼくが「ボタンポチッ」マクロを組んだとしよう。

ぼくは発注者にマクロを渡す。

それを発注者は「実際に使う人」に渡す。 「実際に使う人」は発注者とは別の人であるのが大半だ。 実際に使うのは現場の人間であり、「指示を受ける」側である。

マクロの使い方を、発注者は現場の人間にこう説明するだろう、「このボタンを押せばいいから」と。


「ボタンを押せばいいから」。 発注者はおそらく、というかほぼ間違いなく、こう説明する。 そこには、「ボタンを押せば作業が完了します。ボタンひとつであんな作業やこんな作業が自動化されて、ラクになるでしょ？」という意味以上に、「それ以上のことをオレに聞いてくれるな」ということが含意されている。

それは、発注者がプログラムの内容をわかってないからかもしれないし、それ以上のコミュニケーションを現場の人間と取りたくないからかもしれないし、その両方かもしれない。

発注者がプログラムをわかっていないケースというのはもうたいていがそうなのであまり気にしないのだが（そもそも発注者が「わかってる」人なら、ぼくは何も心配しないだろう）、それ以上に、ていねいに教えたがらない人というのは意外に多い。 細かい内容について質問すると露骨に嫌な顔をされることも多い。 「わかってない」ことが露呈するのが嫌なのか、それとも現場の人間と話をするのを「時間の無駄」とでも考えているのだろうか。
いずれにせよ、現場の人間は言われるまま、ただボタンを押すだけだ。 そこに創意や工夫はない。


「マクロを作ってくれ」と言われても、ぼくはそれだけでいいとは思ってない。
せっかくマクロを作っても、仕様変更があったらかんたんにマクロが動かなくなるからだ。 例えば、ベースとなるExcelの列が追加されたり、項目名が変更されたり。 Excelは定義がガチガチでない分、そういうことがかんたんにできてしまう。 しかし、それをやられると、たいていのマクロはうまくいかなくなる。 そうするとまたぼくが呼び出され、別にぼくが動く分には良いのだけどその分追加費用がかかっちゃうし（ちゃんと請求します）、何よりマクロが動かないあいだは現場が止まってしまう。

それはあなたの会社にとって困るでしょう、と。

だからぼくはまず最初に、手作業でなんとかする方法をマニュアルにして渡す。 なんなら現場に行って教えるところまでやる。 そのうえで、便利ツールとしてマクロ「も」渡す。 もちろんマクロの使い方も教える。

手作業なら、多少の仕様変更があっても対応できる。 アドリブが効くのが手作業最大の利点だ。 一番悲惨なのは「マクロに完全に依存してる現場で、そのマクロが動かなくなった状況」で、現場はボタンポチッに慣れ切ってしまって知見がないから、もう詰み確定である。 でも、もし現場が手作業でのやり方を知ってさえいれば、なんとかなる。
結局、一番大事なのは「人」だ。

だからぼくは、「手作業でなんとかする方法マニュアル」を作るし、積極的に教えるし、ついでにマクロも作る（現場の人にラクしてほしいから）。 ここまでがぼくの提供する商品であり、基本的にワンセットである。

マクロをボタンに仕込むということも、積極的なオーダーがないかぎり、あまりやらない。 「開発」タブから使ってもらうやり方で動かしてもらうことがほとんどである。 手順さえ知っていればボタンを使うのとあまり手間は変わらないし、それは何より「ボタンを押すだけ」という手軽さの裏にある怠惰な精神へのせめてもの抵抗だったりする（オーダーがあればもちろんボタン作るけど）。 もちろん「開発」タブを使ったことのない人には使い方を教える。 「開発」が表示されていないなら表示の仕方も教えるし（そもそも初期状態では表示されてなかったりする）、何ならそこまでの手順だってパワポにまとめたってよい。

作るマクロも、あえて柔軟なもの、こっちがコントロールできる余地を残したものにすることが多い。
ぼくは「選択した列に対して処理をする」みたいな、ふつうに考えると現場作業者の手間が一つ増えるようなマクロを組むことが多いのだけれど、それは、現場でマクロを使っていて「（元々の仕様範囲を越えて）この範囲に対してだけでなく、あっちの列に対しても処理したい」といったよくある事態を吸収するためである。 あるいは、エラー文字チェックみたいなマクロであれば、エラー文字がかんたんに追加できるようにあえてしておく。 それは、仕事をしていくなかで、当初想定していたものからエラー文字の種類がどんどん増えていくことの方が多いからである（たいていのマクロ制作者は逆に、そこをいじれないようにするケースが多い）。 もちろんソースコードにパスをかけるなんてケチなことはしない。 もし「ソースコード勝手にいじってわけわかんなくなっちゃった」ってなっても、ぼくの手元に元データがあるんだから言ってくれればまた渡します。 ぼくが作るマクロは、あえてちょっとアナログ要素を残してあるから人によっては不便に感じるかもしれないのだけど、おおむね好評。


こういうぼくの考え方を、「サービス」ととらえるか、「時間のムダ」ととらえるか。

人によっては、「言われたことだけさっさとやれよ、お願いしたマクロをさっさと作れよ」となるかもしれない。
そういう人とは「ああ、考え方がちがうんだな」と思う。
そして、ほんとうに失礼な言い方になるが、「別の人にお願いしたら？」と思う。 マクロ組める人なんて他にいくらでもいるのだし。

ぼくは、自分の設計思想、というか、「仕事」に対する考え方に共感してくれる人と、仕事がしたい。
ぼくが一番に考えるのは「現場」だし、「現場からのボトムアップ」が仕事において一番大事だと信じてるし、現場の人間がもってる「無形の力」を信じてるし、「経験」を信じてるし、「人間」を信じてる。

オレたちは機械じゃない。 自動処理するマシンでもない。 大事なのはマクロじゃない。 「人」だ。

「人」を育み、そして「仕事」を、未来に向けて、一日でも長くつづけていけるようお手伝いする。 それがぼくの、森田表計算の仕事なのです。

メールください。