かつて、ITホワイトボックスという番組に関わらせていただいて以来、NHKのIT番組のお手伝いをちょこちょこさせていただいています。
今回は、NHKコネクトという番組の用語辞典を監修させていただきました。番組でも紹介されました(再放送は4月4日午後4:05~4:48)。
かつて、ITホワイトボックスという番組に関わらせていただいて以来、NHKのIT番組のお手伝いをちょこちょこさせていただいています。
今回は、NHKコネクトという番組の用語辞典を監修させていただきました。番組でも紹介されました(再放送は4月4日午後4:05~4:48)。
大河ドラマ”八重の桜”を見ていて、思ったことがあった。
今回のシーンは、蛤御門の変、8月18日の政変で京を追われた長州藩が、何とかしてその勢力を巻き返そうと、御所に攻め入る。もちろん、このドラマは、会津藩からのドラマなので、長州藩は、敵以外の何でもない。でも、自分はあえて、敵たる長州藩の”粘る力”に深く感じるところがあった。
蛤御門の変では、薩摩藩の力添えもあり、結局、長州藩は完敗、松下村塾の逸材である久坂玄瑞も自刃する。くわえて、追い打ちをかけるように、御所を攻撃した朝敵たる長州藩に対して幕府が全国の大名に命じて第1次長州征伐を実施する。軍力では勝負にならない長州藩は降伏し、高杉晋作を中心とした倒幕派は散り散りになる。歴史に”if(もし)”はありえないけど、これで長州の倒幕派が倒幕を諦めてしまったら、もしかしたら、今は違った世の中になったかもしれない。でも、高杉晋作をはじめ長州倒幕派は、決して諦めることなく、そして、遂には、薩長同盟という形で、一気に流れを変えた。
これはビジネスでも同じだなと思う。ビジネスにおいて、”新しいことをやろう”と言っても、普通は反対されることが多い、むしろ、これは”素晴らしいから是非やるべし”、と最初から全面的に会社からバックアップされて進むパターンは自分が知っている限り稀だし、これで上手くいく例はあまり知らない。むしろ、”こんなの売れるわけがない、時間の無駄だ”と言われて、お蔵入りになるケースの方が多い。でも、長州藩のように、打たれて(8月18日の政変)、打たれて(蛤御門の変)、ノックアウトされて(第1次長州征伐)、でも、粘って信念を貫く。そして、粘った結果、製品の成功、新しいフロンティア、収益につながるんだと思う。まさに、never never never give upです。
では、何が長州藩の”粘る力”を生み出すか?司馬遼太郎は「世に棲む日々」でとても的確な指摘をしている。
分類すれば、革命は3代で成立するのかもしれない。初代は松陰のように思想家として登場し、自分の思想を結晶化しようとし、それに忠実であろうとあまり、自分の人生そのものを喪ってしまう。初代は、多くは刑死する。2代は、晋作のような乱世の雄であろう。刑死することはないにしても、多くは乱刃のなかで逃走し、結局は非業に斃れねばならない。3代目は、伊藤博文、山県有朋が、もっともその形を代表しているであろう。 (「世に棲む日々(4)p97)
吉田松陰が播いた種が、高杉晋作で実を結び、伊藤博文、山県有朋で収穫を迎えると。もちろん、収穫も重要だけど、やっぱり、一番重要なのは、”種をまくこと”だと思う。吉田松陰は、安政の大獄に座して、非業の死を遂げたけれども、その”種”=理念が後々になって結実した。言ってみれば、理念があるからこそ、”粘る力”が生まれたとも言える。自分もいろいろな会社を見ているけど、やはり、”これだけは絶対にやりとげる”という理念を持っている会社は強い。それは、まさに長州藩のように”粘る力”があるからだと思う。”粘る力”を育てる、これが成功の秘訣なのかもしれない。
大学のころからITに関わるようになって、もう15年近く経ちます。その経験から、IT≒システムにとって一番重要なのは何かといえば、アーキテクチャ(構造)だと思う。
結局、システムは人間が作るもので、システム自ら何を生みだすことはない。もしかしたら、30年後はコンピュータが進化しすぎて、コンピュータ自身が考えてプログラミングする、いわゆる2045年問題、が現実になるかもしれないけど、少なくとも、これから10年くらいは、人間がシステムを作る状況は変わらないだろう。人間がつくるからには、何かしらの設計思想が必要であり、それがアーキテクチャともいえる。
たとえば、SNSでは、友達間で情報を共有したいという思いがあったとして、その友達と友達をつなぐアーキテクチャを考えて、それをシステムに落とし込む。逆に言えば、アーキテクチャのないシステムは、何も用をなさない。自分が大学生のころ、いろいろプログラミングをして作ったけど、作りっぱなしで、ほとんど使っていないのは、結局、アーキテクチャがないシステムだったと思う。
それで、最近思うのは、企業もこの”アーキテクチャ”という概念がとてもあてはまる。そして、その企業のアーキテクチャは、組織とビジネスモデルにある程度集約できると最近思う。
組織:個人事業と企業が違うのは企業は組織であること。そして、その組織は、誰が株式を所有して、今度誰に所有してもらうのか(資本政策、最初はあまり関係ないけど、会社が大きくなると避けて通れない問題)、どのように意思決定するか(取締役会、これもスタートアップは、オーナー=株主=取締役だけど、これも大きくなると構成が変わらざるを得ない)、そして、従業員、から構成される。
ビジネスモデル:組織はできても、それを適正価格で販売して、そこからキャッシュを得る仕組み、すなわち、ビジネスモデル、がないと企業として立ち行かない(永遠におカネが入ってこなくて、出ていくだけだったら、資本金を食いつぶして、倒産してしまう)。
そして、最近思うのは、良い企業のアーキテクチャとは、シンプル、わかりやすいこと。組織もシンプルで、ビジネスモデルもシンプル。エレベーターが下りているほんのわずかな間に上司にプレゼンをする”エレベータートーク”がプレゼンの基本というように、一言で説明できること。システムも同じで、一言で説明できないシステムはたいてい使われない、それは何ができるかわからないから。シンプルが一番、これがシステム、企業いずれにも共通する良いアーキテクチャなんだと思う。
これまで、ビジネスとしてシステムのスペック(仕様)を書く仕事をしてきて、スペックの書き方にはコツがあるなあと思うようになってきた。
ちなみに、ここでいう、スペックは、システムをつくる上流工程での要件定義・基本設計で、それをもとにシステムを作ったり、あるいは、ベンダーにRFP(Request For Proposal)として提示して、見積もりをお願いしたりする。そして、要件定義・基本設計を大きく外さなければ、それに続く設計・実装もそれほど大きく外れることはない。言ってみれば、建物の設計図に相当するもので、作ってみたら、”柱が足りなかった”、”家が傾いていた”、ということがあってはならない。
それで、どうやってスペックを書くか、一言でいえば、”漏れをなくし、重複をなくす”だと思う。
これはコンサル用語でいうところ”MECE(Mutually Exclusive and Collectively Exhaustive)”であり、漏れなく、重複なく、は当たり前のことなんだけど、これが以外と難しい。結局のところ、何が漏れているのか、全体像が見えていないとわからないし、経験を積まないと、失敗するポイントも見えてこない。
どうやって漏れと重複をなくすか?その一つのアプローチとして、自分がいつも心がけているのが、証券アナリストをしているときに教わった”分解して考えるべし”という考え方だ。たとえば、ある会社の売上高が100億円だったとして、その100億円が、業種別(金融30億円、製造業70億円など)、セグメント別(コンサル10億円、システム開発60億円、物品販売30億円など、そして、この組み合わせによって粗利が決定される)に分解することができる。そして、その分解の粒度(金融であれば、そのうち、銀行、証券、保険など、さらに銀行であれば都市銀行、地方銀行、最終的には個社(MUFJなど)に帰着する)を上げれば上げるほど、その会社の特性、何が伸びて、何が落ち込むのか、おぼろげながらわかってくる。
これはスペックを書くときも同じで、結局、経営もしくは発注側は、”ECのシステム作りたい”など漠然としたリクエストが多い。その漠然としたコンセプトを漠然としたままでいくと、結局できるものも漠然としてしまう。だからこそ、分解して、分解して、分解する、その過程で、不必要なところを削り、必要なところをさらに深堀りする。これを繰り返すことで、漏れなく、重複なく(MECE)を実現できるケースが多い。もちろん、分解しすぎて、全く当てが外れることもあり、どこを捨てて、どこを深堀りするかの勘所を押さえるのは経験によるものだと思う。
いってみれば、このMECEは分解した後の結果であり、それ自体は目的じゃないと思う。そして、分解して、分解して、分解する、これが重要なんだと思う。
自分自身もCIO代行のような立場で企業の情報システムのコスト分析・提案をするので、CIO(Chief Information Officer、最高情報管理責任者)はどうあるべきか、については折に触れて考えることがあります。
そして、この記事、結構、大胆にCIOは使い物にならないので、CDO(Chief Digital Offier、金融の人にとって良い思い出がない略語かもしれない)を登用すべきだと主張する。
なぜ、CIOが使いものならないのか。この記事によれば、その理由は2つ。まず一つは、CIOは、Exchange(メールサーバ)、SAP(企業の財務・販売などの基幹システムパッケージ)の知識はあっても、デジタルマーケティング、ビックデータ、ソーシャルネットワーキングなど、経営が”攻め”に活用する知識・経験がない。2つ目として、CIOの役割は、情報システムをちゃんと動かすこと。したがって、何か会社でチャレンジをやろうとして、少しでも情報システムを変更することがあれば、CIOはそのリスクを取りたがらない。すなわち、もし、そのプロジェクトが失敗すると、CIOの評判に傷がつくので、できるだけだけそのリスクを避けるように行動する。とはいうものの、最近の企業活動において,デジタルマーケティング(ネット広告など)は切っても切り離せなくなってきている、だから、IT部門でないところから、CDO(最高デジタル責任者)を登用すべきという主張だ。
自分としては、例外を除いて、だいたいこの主張に同意できる。例外とは、CIOがいなくてはいけない業種。そのわかりやすい例は、銀行を含めた金融。金融が扱っているのは、つまるところ、おカネという情報、なので、すべてのやりとりは情報システム経由で行われる。だからこそ、情報システムは、止まってはいけない。ちょっと前の話では、三菱UFJ銀行元頭取の畔柳氏は、旧三菱銀行と旧東京銀行の情報システム部門統合を総轄し、その経験から、UFJ銀行とのシステム統合もトップダウンで実行したのは、業界ではよく知られている話。こうした情報システムが企業の生死に関わる業界であれば、CIOを取っ払って、CDOにせよ、というのはナンセンスだろう。
だからといって、すべての業界でCIOが必要というわけではない。逆に言えば、金融以外について、CIOががっちり情報システムを守るという会社は、よほどの大企業以外はなくなりつつあると思う。むしろ、”止まらないように情報システムを守る”というCIOアプローチよりは、”リスクを冒してでも、デジタル分野を開拓する”というCDOアプローチの方が、企業価値を上げる手段としては有効だと思う。
今日、明日にCIOがなくなって、CDOにリプレースされるということはない。でも、長い目でみると、”情報システムのおもり”は重要だけど、それだけだと、生み出す価値も限定的だと思う。だからこそ、CDOよりな、デジタルを使ってビジネスを生み出すアプローチが情報システムにとっても重要だと思うわけでした。
Twitterといえば、オンラインストレージのDropboxと並んで、IPO有力候補として注目されている企業。とくに、2011年8億ドルをロシアのベンチャーキャピタルから調達していることもあり、VCの出口として年内に公開するのではといわれている。
そうしたなかで、Twitterのビジネスモデルが変わりつつある。
4 Ways the Twitter You Know is Changing Foreverによれば、次の4つの道に進化し、プラットフォーム化しつつあるという。
すくなくとも、この4つを確実に実行すれば、投資家が満足するようなマネタイズ(収益化)は可能になると思う。ただ、マネタイズに走るあまりに、ユーザが離れてしまう場合もすくなくない。たとえば、ツィートの優先度をカネで買うことができれば、たちまち、ツィートが広告だらけになって、”いつものTwitter”ではなくなる可能性もある。たしかに、Twitterはマネタイズのプラットフォームに近づきつつあると思うけど、楽しくツィートできる”いつものTwitter”であってほしいと一ユーザとして願うところです。
著者仲間の川口宏之さんよりいただきました。ありがとうございます。
自分が初めて決算書を読むようになったのは、ドクター終わって、証券会社に入った2006年3月なので、もう7年近くたちます。
アナリストのころは、PL(損益計算書)が中心でBSはほとんど理解してなかったけど、経営管理をやるようになって、BSの重要性に気づいたり、たった7年の決算書の付き合いでも、いろいろな発見があります。それは、まさに筆者が指摘している
どのような役職に就いても、どのような業界に転職しても「決算書を読む技術」がムダになることは絶対にありません(p11)
という指摘は本当にそうだと思います。そして、どうやってその決算書を読むか。そのアプローチが、”数字の羅列にしか見えない決算書を、いったん図に置き換える”こと(p37)。そして、以下のように、貸借対照表、損益計算書、キャッシュフロー計算書の財務3表について、レベルに合わせた”図解”を提示するアプローチです。これによって、財務3表の関係(損益計算書の当期純利益が、貸借対照表の利益余剰金とリンクしているなど)が把握できるようになっています。
ただし、財務3表は、あくまでも企業の経営状態を示したものだけであり、誰(銀行、お客さん、仕入れ先など)がどれだけ支払うかといった情報は記載されていない(ちなみに、上場企業が提出する有価証券報告書には、主な相手先別販売実績という開示事項があって、売上のうち10%を超える取引相手を開示しています、アナリストのときはこの情報がとても重要でした)。そこで、取引フロー図によって、A.顧客、B.仕入先等、C.投資先等、D.銀行・株主の自社を取り巻くステークホルダーのお金の動き、モノの動きを図示することで、「損益」と「収支」(会計上の利益とキャッシュフロー)の違いがわかります。
以上がだいたいのあらまして、ベーシックなところから始まっているけど、負債項目にある前受金の扱い(p63、流動負債は1年以内にお金を支払うものだけど、前受金は例外で先に代金を受け取る)など、会計をそれなりに知っている人でも、なるほど、と思わせるところが多い。そういう意味で、はじめて決算書を読む人にも、ある程度、決算書を読める人にも、それぞれ得るものがあるおススメの一冊です。
ビジネス基礎体力が身につく 決算書を読む技術 | |
![]() |
川口宏之
かんき出版 2013-01-09 |
先日、写真の便利屋のチラシが入っていて、いろいろとビジネスを考えるきっかけになりました。
かのピーター・ドラッガーは、企業活動の目的について、”顧客の創造”と定義しました。それは当たり前の話で、お客さんがいなくては、ビジネスにならない。
そして、この便利屋のビジネスも、”ゲームの相手がいない”、”犬の散歩の時間がない”、”洗車の時間がない”といった”時間をお金で買う”顧客にハマるモデルだと思う。
ただ、これでビジネスとしてマネタイズできているのか。これは、どこまでお客さんのわがままを聞くか、だと思う。
”お客様は神様です”よろしく、お客さんのわがままをすべて聞く、もちろん、これは顧客満足度を高める最大の方法だけど、ビジネスとして成り立つとは限らない。
たとえば、自分のなじみのあるIT業界では、システムをつくる際、顧客のシステム設計をする際に、”お客様は神様です”とばかりに、、”ECと連動したい”、”ボタン一発で経営状態が見えるようにしたい”など、お客さんの言い分をすべて聞いて、システムを作ろうとすると、ほとんどの場合、予算、制限時間オーバー、もしくは、ひどいとシステム会社の持ち出しになってしまう。やはり、お客さんのわがままをすべて聞くいわゆる”御用聞き”は必要とされていない。むしろ、腕利きのプロマネは、お客さんのやりたいことを制約条件(予算、時間)のなかでうまく調整する、あるいは、断る能力に長けていると思う。ちなみに、当社では、このシステムと経営とのギャップをセカンドオピニオンサービスという形でギャップ分析を提供しておりますので、お気軽にお問い合わせください。
便利屋もこのシステム開発の話と同じで、お客さんのやりたいことをすべて聞いていると、たぶん、ビジネスとして成り立たないと思う。だからといって、”これはできません”と断り続けては、便利屋の沽券に関わる問題で、その折り合いの付け方が、便利屋ビジネスモデルの肝・ノウハウなんだと思う。ちなみに、システムの話に戻ると、システムでは、この肝・ノウハウは、パッケージに相当します。極端な話だけど、Windowsには、製造業向け専用Windowsもなければ、医療向け専用Windowsもない、どの業種でも同じ。パッケージを買って、インストールするだけで終わり、ものすごくレバレッジの効くビジネスだと思う。Windowsまでいかないにせよ、多くのパッケージは、”お客さんのやりたいこと”がだいたい凝縮されていて、それをインストール&カスタマイズである程度のことができる。そして、”だいたい”という最大公約数をどこに設定するのかが、企業の腕の見せ所、ニーズの捉えどころなんだと思う。
こう考えると、最初の”顧客の創造”とは、単に、お客さんのわがままを叶えておカネをもらうのではなく、お客さんがおカネを払ってでも、その成果に満足する仕組み(イノベーションとも言えるかもしれない)を作ることなんだろうと思いました。改めてドラッガーの教えての深さが身に沁みます。
上杉鷹山に経営を学ぶ
高校時代のころから歴史が好きで、今でも機会を見ては歴史の本を読んでいます。
そのなかで、今回紹介するのは、童門冬二の「上杉鷹山の経営学」。
上杉鷹山と言えば、かのJ・F・ケネディが尊敬する日本人と言わしめた人物だけど、いままで何がすごいのかあまり知らなかった。
でも、自分が経営に身を置くようになって、その素晴らしさがわかりました。
彼が藩主を務めた米沢藩は、初代上杉謙信の時代は、越後で200万石を越える収入があり、2代景勝の時代は会津に移されて120万石。さらに、江戸時代になって、米沢に移され30万石に減封、くわえて、4代目から5代目の継承に不備があり、15万石に減らされた。収入が減る一方で、家臣の数を減らすわけでもなく、藩の収入のうち、90%が人件費だったという。企業でいえば、売上が激減しているにも関わらず、コスト(固定費)は変わらない状態。給料のベースダウンを実施するも、一向に財政状況が改善することなく、先代の上杉重定は一時は版籍を幕府に返すことも検討したという、その中で、上杉鷹山が17歳で藩主となる。
こうした絶望的な状況のなかで、彼はどう藩を変えたか。その改革の一つが、米作一本足打法をやめて、収益を多角化すること。具体的には、和紙を作るために楮100万本、漆100万本、絹を作るために桑100万本植える計画を立て、これを実行した。この収益の多角化は、天明年間に会津藩の家老田中玄宰(会津の酒蔵末廣では、彼へのオマージュとして「玄宰」という大吟醸を作ってます)が、会津で漆、酒などの生産を強化するなど、上杉鷹山の専売特許ではない、でも、それを”ダントツ”にやり遂げるところ、ここに経営者としての上杉鷹山のすごさがあると思う。
そして、これは現在にもとてもよくあてはまる。江戸時代の米作のような”一本足打法”はビジネスとしては当たり前。たとえば、かつて、吉野家のメニューは牛丼のみで、牛丼一筋に絞るからこそ、原材料を安く調達できたり、一度に大量に生産できたり、オペレーションをマニュアル化したり、メリットが多い。自分の馴染みのあるIT業界でも同じで、システム開発だけの”一本足打法”はメリットが多い。システム開発、お客さんからシステム開発案件を受注して、自社で賄えない分は、協力会社(外注)をつかってシステムを開発をする。そして、協力会社を使える分だけレバレッジが効くので、うまく協力会社を使えれば、もたらすリターンも大きい、まさにシステム開発”一本足打法”だ。
ただ、一本足打法は米作しかり、吉野家の牛丼しかり、システム開発しかり、リターンも大きいけど、一度、不の循環、米作では不作(とくに東北は不作の不作の年が多い)、吉野家の牛丼は米国牛の輸入停止、システム開発はリーマンショックのようなシステム開発全面ストップ、に陥ると、致命的な痛手を受ける。その痛手を受けて、構造的に立ち行かなくなったとき、どうするか、それは、これまでのしがらみを捨てて、収益の多角化を”すぐにやるしかない”。それをやるのが経営者の役割なんだと思う。
上杉鷹山が生きた時代からまだ200年くらいしか経っていない、その間、人間が劇的に進化したわけでもなく、まだまだ、歴史から学ぶことはたくさんありそうです。
上杉鷹山の経営学―危機を乗り切るリーダーの条件 (PHP文庫) | |
![]() |
童門 冬二
PHP研究所 1990-08 |
PLアプローチとBSアプローチ
財務諸表を見る(アナリスト)・作る(経営管理)仕事をトータルで7年近くやってきて、世の中には2つのアプローチがあると思う。
まず、一つはPLアプローチ。一番わかやすいのは、確定申告。確定申告は、その年の給与、不動産、雑収入から、医療費、保険等の控除を引いて、最終的な納税すべき、もしくは、還付する金額を確定する。言ってみれば、個人の1年のPL(Profit & Loss)をまとめたモノともいえる。セクターによって、異なるけど、アナリストの分析も、どちらかといえば、PLアプローチが多い。株価は、EPS(一株あたり純利益)×PER(株価収益率)で表すことができて、EPSとPERを当てることができれば、株価は予測できる(が、実際、これはとても難しい、とくに、PERは人間の期待値なので、合理的に見積もるのは困難)。要するに、1年にどれだけの損得をしたか、これがPLアプローチ。
一方、BSアプローチはちょっと違う。身近の例では、銀行口座の預金残高(バランス)。預金残高は1年で完結する話ではなくて、何年、何十年と続く話。そして、預金残高がマイナスになったら、企業は立ち行かなくなる。だから、売上を増やす、経費を削減する、もしくは、売掛金(入金)と買掛金(出金)のサイクルを調整する(できるだけ早く入金して、できるだけ遅く出金する)、どれだけ預金残高を増やして、ひいては、会社の規模を大きくすることができるか、これは企業戦略によるところが多い。で、この預金に限らず企業の財産の残高(バランス)を記録しているのが、BS(バランスシート)であり、BSアプローチは、積み重ね(ストック)ともいえるかもしれない。
PLアプローチとBSアプローチ、どちらが良いというわけでもないけど、自分はBSアプローチが好きだ。PLアプローチは、企業の長い歴史のなかでの、ほんの一つのスナップショットにしか過ぎない。一方、BSアプローチの場合は、”創業以来継ぎ足してきたツユ”のように、会社の歴史が色濃くBSに反映されている。ある方に、”企業の経営はBSをみればわかる”と教えられたけど、まったくその通りだと思う、やっぱり、BSは大事です。