Excelの孤立とリスク
お疲れ様です。経営企画のたばこ部屋、39回目の配信です。今日も、きりんがお届けします。
今日はExcelの話題をお届けしようと思いまして、Excelマスター、Excelに詳しい人ですね、詳しくなればなるほど、どんどん孤立してしまうという、ちょっと恐ろしい話をしようと思います。
自分だけで完結できる仕事なのであれば、どれだけExcelの関数とかマニアックなものを作って作り込んでも、全然問題ないというのは、そりゃあそうです。
なんですが、基本仕事というものは、自分だけで完結するものではないですし、自分だけで完結させてしまうというのは、それはすなわち組織として危険な状態ですから、そういった状態は好ましくはない。
あるいは、仮にあなたが倒れたとしても、誰もできないってなったとしても、別に問題ないっていう、その程度の重要性の業務であるっていう言い方もできるかもしれません。
そもそも経営企画の仕事ということを振り返ってみると、例えば月次の業務がありますね。
毎月の決算を取りまとめるとか、着地見込みを出すとか、数字系の話が当然毎月あります。
これは当然止めるわけにはいきませんので、冗長性を確保することが必要です。
私が倒れても、誰かが倒れても代わりにできる人がいる状態、これを担保しないといけない。
あるいは経営企画ですから、事業部門とかグループ会社とか、そういったところを支援する場合、何かExcelを作って渡すっていうことが基本の仕事の形になると思います。
その方々が自分で仕事を持って回し続けられなければ、それは本当の意味で支援したことになりませんので、
自分がずっとExcelの業務を持ち続けて回し続けるっていうのは支援であるようで甘やかしているというか、本当にその会社を強くしたわけではないと言えるんじゃないでしょうか。
引き継ぎの難しさ
このように経営企画の仕事というのは複数人でやることが前提ですし、何か外部の支援をする場合は作って渡すっていうのが基本形だと言えそうですね。
なれば、マネジメントの立場からもちょっと考えてみましょう。
私だったり、誰かExcelにとても精通している人がいるとしましょう。
その人の上司は、あなたがExcelに引き出ているということなどもう十分知っています。
十分知っていると思います。
それよりも、あなたがExcelが得意であるということよりも、その業務があなたしかできないということについての常常性のなさを心配されていると思います。
何倍も心配していると思います。
そして、そのむしろ業務をブラックボックス化するということが一番のリスクでして、
なんなら、あなたがExcelに引き出ているからそれを囲い込んで自分の重要感を満たそうとしているのではないかとか、そういうふうに思われることすらあるかもしれません。
ちょっと意地悪な言い方をしましたけれども、引き継がれる立場からちょっとそれを考えてみるといいわけですね。
難しいExcelを引き継がれたときに、それを見たときにあなたはどう思いますかと、
前任者がすごく作り込まれた難しい関数が複雑なものとして渡された場合ですね。
それを見て、これを作った人はかっこいいって思うでしょうか。
思わないじゃないですか。
自分がこれを回さなきゃいけないのか。
うわーっていうふうに思うわけで、不適切、不親切な設計だなというふうに思うだけなわけですよ。
こんなん自分で回せないなと。
もしこれが壊れたら、もう前任者の人にまた聞けばいいかとか、この人に頼り続けるかと。
逆に言うと、こんなものを回せるわけがないっていうふうに思うでしょうから、
自分には無理でしたって言って、その業務自体なくしてしまおうとか、そういうふうに思うかもしれません。
要は難しいExcelで引き継いだところで、その業務が消滅してしまうか、
本当に重要なものであれば、そのExcelを作った人に戻ってきてしまうか、どっちかになってしまうわけですね。
要はこういう形でExcelができるということをひけらかすというか、難しいものを難しいまま表現したExcelなんていうものは、
遅かれ早かれ崩壊してしまうという、そんな話でございます。
簡潔なExcel設計の重要性
どうすればいいのかっていう話なんですが、Do'sとDon'tsとにそれぞれ分けて考えましょうか。
まずはDon'ts、やってはいけないこと。もう分かりやすい話です。
一般的に知られていない関数を使ってはいけません。
ラムダ関数とか、いろんな、最近であれば新しい関数がどんどん開発されてきていますが、
そんなものを使わずとも、簡単な関数の組み合わせで何とかできることがほとんどだと思います。
配列系の関数とかもギリギリだと思います。
アレーフォーミュラとか、例えばスプレッドシートだと、一セルだけ入力しておけば、
下のセルとか横のセルについて、すべて同じような表現で作ることができるみたいなものがあったり、
サムプロダクトも配列的な関数ですけれども、こういったものもたぶんギリギリだと思います。
サムプロダクトをうまく使いこなせる人っていうのは、あんまり多くないんじゃないですかね。
これが一つ入っているだけで、知らない関数があるというだけで、
引き継ぐ側の心理的障壁は非常に高まりますので、ギリギリですがアウトぐらいに考えてもいいかもしれませんね。
VBAとかパワークエリとか、そういったものも基本的には使える人が少ないという意味では、
あまり使わないほうがいいでしょう。
どうしても使うような業務なのであれば、最低限のルールとして相対パスで組んでおくとか、
フォルダを移動させたとしても壊れないようにしておく。
壊れたら最悪自分が責任を持つというふうに思えない限りは、そういったものを引き継ぐというふうに考えないほうがいいと思います。
引き継ぐ方がそれに精通しているのであればもちろん問題ないんですけれども、
基本的には難しいと考えたほうがいいでしょう。
どうしましょうという他の話ですね。
やってはいけないのは今の話でしたが、こういうふうにしましょう。
裏返しではありますが、可能な限り簡単な関数を使う。
関数は可能な限り組み合わせて使わないほうがいいと思います。
if関数と&関数の組み合わせとか、それぐらいであれば読み解けないことはないとは思いますが、
それですら一文で表現せずとも、あえてそれを分けて別の行に切り出して、
&とかorとかの論理的な関数のフラグを別の行に分けて、
そこをさらに参照してif文を作るとかにすれば、
2段階にはなりますけれども、読みやすい形式にはなったりすると思うんですね。
そういう一つ一つの思いやりが大切だと思います。
関数をできるだけ組み合わせない。
解読をしてもらうために、このExcel一つ一つのセルを読み解く必要があるわけですけれども、
常に一貫した思想を持ってそれを設計するということもマナーだと思います。
よくある話ですけれども、1シートでは必ず位置処理をすると。
複数のテーブルを1シート内に混在させて見づらい、
こんなところにもテーブルがあったのかみたいな、
そんな発見をさせないというのも重要な聞くばりかと思います。
シートの参照というものも一方向にしておきましょうというのがあるかと思います。
例えばシートあるじゃないですか、Excelでいうと下の方にタブがずっと並ぶあれですね、
あれをシートと言いますが、
左にあるものほどアウトプット、右に集計プロセスやインプットを持ってくるというふうにしておくと、
頭の流れとして、データの流れとして理解がしやすいようになると思います。
Excelの設計思想と使い方
インプットがあってプロセスがあってアウトプットがあってというフレームワークで、
それぞれを表現しておくと読み解きやすくなるという話ですね。
他にも同じ行とか同じ列については常に同じ関数を使いましょう。
どうしてもイレギュラーな値があるとしたら、それは色とかコメントとかそういったもので分かりやすく示しておきましょうというマナーもあったりとか、
結構グローバル的なルールがあって、財務デューデリとかファズとかでも結構当たり前の話なんですが、
値を直接入力するときは青色とか、計算式の場合は普通に黒色、
別シートから参照して持ってくる場合なんかは緑色を使いましょうとか、そういう作法があったりするんですね。
文字を色付けするというのはそういった誤解を与える色でもあるので、
このグローバルルールというものに基づいて使うほうがいいでしょうという話もあります。
あと加減算、足し算、引き算ですね。
これを可能な限り引き算は使わずに、足し算で表現したほうがこれは読み解きやすいですねという話もあったりします。
全然全てを表現、紹介しきることはこの場ではできないんですけれども、
そういった設計思想のようなものは一般によく言われているものがありますので、
これは引き継がれた人がそれを知っているかどうかは別の問題ですけれども、
習っておくほうが読み解きやすくなると。
そしてその思想があればそれをどこかのシートに書いておけばですね、
そういう意味でこの色は使っているんだなということがまた、
引き継がれた人にも分かるという意味では望ましいんじゃないでしょうか。
あとはこういったマニュアルですね。今みたいな思想もそうですし、
そもそもの使い方、このExcel、引き継がれた業務のマニュアルは当然作るわけだと思いますけれども、
Excelのどこに何を入力するとどこにデータが引き継がれて、
そのデータがどのような処理をもってアウトプットされているのかという部分についても、
裏側の設計思想についても書いておくと非常に親切でしょう。
業務の引き継ぎと協力
理想論的にはですね、基本的に他人が作ったExcelなんてそんな誰も見たいわけがないわけですよ。
見たいわけがない。なので本当はですね、本人が作るのが一番いいと思います。
これ本人というのは引き継がれる側の人が先陣からExcelを引き継がれるのではなくて、
やりたいことを引き継げばいいと思うんですよね、本当のことを言えば。
こういう業務があってこういう数字を出す必要があるということを引き継いで、
ではこれまでのExcelは別に使わなくてもいいが、新しくそのデータを作るために、
自分ならどういうふうに設計しますかというところからその本人に作らせるということ、
そしてその本人がそれを作る上でのサポートをするというのが本当の引き継ぎだと私は思います。
Excelをそのまま渡してそのままやってくださいというのはもういわゆる作業者的なものになってしまうので、
それを他人が作ったExcelをですね、一回ばらして作り直すとか、
何か例えば壊れた時にそれを作り直すとかというのは非常に負荷が高いことなので、
そんなことをさせるよりはもう本人にゼロからExcelでも何でもいいので、
その業務を作り直してもらうということができると一番効率的ですよね。
結構理想的な話なんで理想論かもしれませんが、
もしそういうことができるならそういう引き継ぎをしてみてもいいんじゃないかというふうにも思います。
Excelの話、最後にあるとしたら冗長化をするのであれば、
実際そのExcelをいじるときの作業を見てもらうとか、そのいじっているときの様子を録画をしてもらうとか、
質問の時間を設けるというのももちろん一案でしょう。
そういったことですね、Excelを引き継ぐということは最新の注意を払わなければなりませんし、
自分がこのExcelマスターであるということを示そうとした瞬間にですね、
そういった仕事は破綻するし、やがて誰もやらなくなる。
そんなふうなものになってしまうと、せっかく作った本人としてももったいないじゃないですか。
なので、孤立しないようにですね、他の人と一緒にやるのが仕事であって、
Excelも他の人が使えるようなレベルのものを本当に簡単に書くということがExcelができるということなんじゃないでしょうか。
自分の力をひけらかすとか、難しい関数が使えるというアピールではなくて、
簡単に難しいことを組むということが真のExcelマスターなんじゃないかということで、
今日は締めたいと思います。
以上となります。
もしよろしければ、いいねやフォローなどいただけますと大変励みになります。
お疲れ様でした。
