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

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

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

都内在住ですので、東京近郊ならば気軽に動きますよ。
ただこの場合、交通費と、拘束される時間分くらいのお金はほしいですね（下記「作業をしてほしい」と同じ分類になりますので、そちらもご覧ください）。 でも、もしメールで完結しちゃうのであれば、お代は結構です。

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

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

お代は、業務内容によって異なりますが、おおよその目安として、
作業１時間につき：2,500円～
１日使役して：20,000円～
となります（交通費・経費別）。
実際には作業量や作業難易度によって価格を設定しておりますので、上記はほんとうに単なる目安でしかないのですが、ご参考までに。
ただし、ぼくは個人事業主で、法人ではありません。 なのでその辺り、気になさる方はご熟慮ください。

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

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

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

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

仕事に対する姿勢について、以前コチラに書いたものを転載します。
マクロ開発を発注された際の、思うところを書いたものです。

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


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

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


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

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

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

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

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


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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

ぼくが作るマニュアルを２例アップしておきます。

こちらは、２つの表の差分箇所割り出しの手順をまとめたものです。 「指示を受けてExcel表を修正したんだけど、指示以外の箇所をいじっていないか（いわゆる「指定外変化」）をチェックしたい」というオーダーを受けて作成しました。 相手がExcelが得意でない方でしたので、イコール式から解説してます。 パワーポイントで制作してます。
画像を意図的にぼやかしているので、何のことかよくわからない箇所も多いかと思いますが、ぼくが制作するマニュアルの質について、ご参考にしていただければ。

もうひとつ。

こちらもパワーポイントで制作。
「InDesignから抽出した文字データを使ってインデックスを作る」のだけれども、InDesignから抽出したデータって「よみがな」が設定されていなくて。 よみがながないとあいうえお順に並べられないから、目次にするのにすごい手間がかかってしまう。
あと、「複数ページに同じ商品がある場合、記載ページ表記をひとつにまとめる」までの手順をまとめています。 どういうことかと言うと、例えば、大本のExcelだと、

あああ　P015
あああ　P043

と２レコードになっているのを、

あああ　P015・P043

と１レコードにする、その作業です（インデックス作成に不可欠な作業）。
なので、おおまかにまとめると、
１．よみがなをつける
２．並べ替えをする
３．１レコードにまとめる
４．ふたたび「あいうえお」順に並べ替えて、目次のかたちにする
ということなのですが、その手順をまとめました。

DTPオペレーションを主な業務としている方に渡したので、やさしい記述をこころがけています。 また、実際には「よみがなをつけるマクロ」も渡し、業務効率化を図っています。

ぼくはこのようなマニュアルを現場に渡し、業務の「見える化」・円滑化を図っています。 なので、ご参考までに。

メールください。