武器としてのエクセル

私はエクセルが好きである。大好きである。エクセルを作ることは自己表現と言っても過言ではない。どのくらい好きかというとCtrl+nを押して新規ファイルを起動してまっさらなスプレッドシートが目の前に現れる瞬間にはある種の高揚感を覚えるのである。（過去の数々の不出来のエクセル、通称 糞エクセルを忘れて）これからどのような美しくエレガントな分析やモデルが出来上がるのかということに想いを馳せるとワクワクするのである。秋の早朝に朝日を見るような清々しさを覚えるのである。このように書くともしかしたらこれはウケを狙って書いていると思うかもしれないが、これは大袈裟ではなく私にとっては大真面目な話である。そのくらいエクセルを愛しているのである。

幸いなことの大分前から相思相愛の関係になった自負がある。もちろん今の私の職位ではエクセルをできることは自慢にならない。むしろそんなことを言おうものならば「あいつは一生アナリスト根性が抜けない」と言われるだろう。これはいうまでもなく正論ではあるが、一方でこのくらいエクセルができるとたまに自分しかできないようなプロジェクトが発生し結果として仕事を依頼されたり、大炎上中のプロジェクトに途中で入り鎮火したりすることができたりする。これはシニアなポジションになっても役に立つのである。このようなことができたからこそ仕事を依頼されたことは何回もある。社内の会ったこともないかなり年次の高いシニアパートナーから電話があり、数字関連で炎上中のプロジェクトをとにかく手伝って欲しい、と言われて急に海外のプロジェクトに参画したこともある。言い換えると（ある意味で）コンサルティングの芸風の幅が広がるのである。

結局のところ特にあるレベルを超えてエクセルが得意になると、平均的なコンサルタントならば数時間かかる作業が10分でできたり、あるいは全く思いつかないような分析ができたりするようになる。多少得意くらいであれば（例えば1時間かかるところを30分でできるレベルであれば）エクセル作業が効率化し労働時間がいくらか短くなるだけで質的な変化は起きないが、上記のレベルになると別次元に到達し芸風が広がるのである。

なおコンサルティングでエクセルを使うときは大きくは二種類の用途があることは理解するべきである。一つは分析であり、もう一つはモデリングである。これらはそもそも全く違うのでありそれを理解するべきである。分析とは何らかの比較を行うための演算であり原則として一度きりのものである。一方でモデルとは何らかのインプットに対して演算をしアウトプットを返すものでありインプットを変えることでアウトプットも動的に変わるものである。一般にIBDのバンカーはモデリングが得意である一方で分析は不得手であり、他方でコンサルタントはその逆である。（ただし全般的なレベルとしてはIBDのバンカーの方がコンサルタントよりもはるかにエクセルには秀でている。）例えばエクセルが非常に得意なバンカーであっても分析で良く使用するピボットテーブルはほとんど使ったことがない人も多い。（なお個人的には種類にもよるが分析であってもピボットテーブルはあまり使用しない方がいいと思っている。理由はレイアウトなどで自由度がないためである。）いずれにせよ、これらは全く違うものでありそれぞれ異なるスキルが求められることは理解しておいて悪くないだろう。

エクセルを上達したいのであれば、まずはそもそも自分がエクセルに向いているのかを現実的に理解する必要がある。残念ながら私の感覚ではエクセルに向いている人たちはコンサルタントの中でもせいぜい20~30%であると思っている。これは恐らくは先天的なものであり、短距離走が得意、映像記憶が得意、文才がある、といったのと同じようなものであると思っている。もちろん後天的にも努力すれば相応にはエクセルを使いこなすことはできるが、エクセルが武器になるくらいにはなるのは極めて難しく、またそもそもその必要もない。コンサルティングファームはチームで動くので全員がエクセルを得意になる必要はないのである。むしろ自分が向いていないと思ったら、（いくらそれを得意になりたいと思っていたとしても）下手に近寄らずにジュニアとしては必要最低限のことを習得すればいいし、マネージャー・プリンシパルは品質担保するのに必要なだけを理解すれば良い。パートナー以降はそもそも（よほど特殊な芸風でない限り）触る必要はない。大事なのは冷静に自身のエクセルの適性を見極め、あるようであれば武器にすることを考えればいいし、なければ最低限だけ習得すればいいのである。そしてこれはエクセルに触らなくても大体わかる。20数年間生きてきたならば、冷静に考えれば9割方の精度で向き不向きは判るはずである。

では実際にエクセルを武器にしようとした場合は何をするべきなのか。いうまでもなく関数や機能への理解といったことはあまり重要ではなく、大事なのはエクセルに関する原則を持つことと、ファイルごとに設計思想をことであると思っている。前者の原則とはエクセルを作る上で守るべきルールのことであり、これには概念的なものも含まれる。具体的なルールであれば例えばカラーコードなどは挙げられる。このカラーコードは多少エクセルを仕事で使ったことがある人であれば当たり前と思うかもしれないが、99%の人は実際には厳密には守っていないと言っても過言ではない。カラーコードなど些末なこととと思うかもしれないが、これが守られているか否かでエラーの発生率は圧倒的に異なるし、またチームで作業する際には生産性は落ちるのである

より概念的なことではファイルの構造を意識し、なぜこのテーブルが、なぜこの位置にあるのかを全て（文字通り「全て」）説明できる必要がある。基本的にはエクセルはテーブル→テーブル群→シート→シート群で構成されており、それらは全てある一貫した流れに沿って構成されている必要がある。また全てのテーブルは①他のテーブルで参照されるための数字を返すか、②参考情報として表示されているか、③アウトプットになっているか、のいずれかを満たしている必要がある。そのためあるテーブルがあったときにこのテーブルは何を目的として存在するのかを全て理解している必要がある。

またテーブルは可能な限り正規化（＝同じ行・列の構造に）するべきである。これも一見当たり前に聞こえるかもしれないが、大体のエクセルはテーブルの正規化が徹底されておらず、結果として式が複雑になるのである。式に関してもとにかく簡潔にするべきである。理想的なモデルであれば（SUMなどを除けば）せいぜい引数は3-4つ程度であり、しかも大半はただの四則演算で構成されているべきである。それ以上に複雑な計算式ならば中間的なセルを設けるべきなのである。また引数も原則的にはテーブル内に存在しているべきであり、「遠くの」テーブル、あるいは（緑フォントの）他のシートから引用されるべきではない。（これも殆ど認識されていない原則である。）

ビジネスDDで会社の事業計画を査定し修正版事業計画を作成する場合は、①（静的な）事業計画のドライバーを炙り出す、②事業計画をドライバーを用いて動的に再現する、③ドライバーを変更して修正版事業計画を策定する、といった手順に必ずなる。そのため自分は今、どのモデル上のどのステップを踏んでいるのかを概念的に捉える必要がある。これらは例であり他にも原則はいくつも挙げられる。もちろん上達の上で大事なのはカラーコードといった具体的な原則（といってもこれを守ることは必須ではあるが）よりも概念的な原則を理解することである。これがあれば再現性が高くなる。

設計思想は個別のファイルを作る際にどのような流れにするのかを考えることである。もちろん上述の原則に従えば自ずと決まる側面はあるが、それでも具体化するためには詳細を設計する必要がある。慣れるまではエクセルを作る際は数字の概念的な流れとシートの構成を紙とペンで文字通り設計をする習慣を身に付けることが大事だろう。

またモデルを設計する際は現実的なデータの入手性も最初からかなり意識するべきである。一般の問題解決においてはデータの入手性などのHowは一旦忘れて、何を証明するべきかのWhatに注力するべきであるが、モデルの場合は現実的に一定の精度のあるデータがないと話にならないのである。いくら論理的には可能でも数字が存在しないならばロジックから見直すことも多いのである。そのためモデルを設計する段階ではデータの入手性や粒度と最終的なモデリングの目的の両面を視野に入れるべきなのである。私自身、複雑なモデルを設計する場合は数字の計算ロジックやテーブル・シートの設計などに数時間を費やすこともある。

ここに書いたことはあくまでも例であるが、言いたいことはエクセルに適性のある人が正しい原則と設計思想を持って概念レベルでエクセルを考えられるようになると一つの武器になると思っている。最初にも述べた通り基本的にはエクセルは些末なスキルではあり、経営コンサルティングの本質からは程遠い。しかし一定レベルを超えるとそれなりに職位が上がっても「飯の種」になると思っているのである。