読書」カテゴリーアーカイブ

書評:「SQLデータ分析・活用入門 データサイエンスの扉を開くための技術」② 西潤史郎 (著), 山田祥寛 (監修) 

第10章は、これまでの集大成としてデータ分析の目的と成果について述べられている。

 第10章 データ分析で成果を出すために
  10.1 データ分析が成果を出すために必要なこと
   モデルとは
   モデルはどう作成するのか
   「式」はモデルの代表的な形
   データ分析はプロセスであり成果物ではない
   意思決定者とデータ分析者は分ける
   国家の意思決定から発展した「インテリジェンス」
   意思決定者とデータ分析者の壁
   ビジョンとスキルで壁を越える
   データサイエンスの実践に求められるスキル
   データサイエンスのタスク
   チームとしてのデータサイエンティスト
   社内SQL勉強会のすすめ
  10.2 さらにデータサイエンスのスキルを身につけるための参考書籍
   SQL関連
   エンジニアリング関連
   データサイエンス関連
   ビジネス関連
  10.3 結びにかえて

モデルとは

まず、ここではモデルについて明確化している。モデルとは現実世界を抽象化したものであり、データ分析とはデータからモデルを作成する役割を指す。

そもそも、データとは何であるか?本書に面白い表現があったので紹介する。

「データというものは、現象が放つ光です。そのさまざまな色合いの光を集めて現象を理解します。」P.332

ところで最近、別の本を読んでいて似たような表現を目にした。「私たちは、物に当たった太陽の光や照明の光のうち、吸収されずに反射された光を見ている。どんな種類の光を吸収しやすいかは物質によって異なるため、反射される光の種類も異なる。それによって、物の色が決まる。」~文系でもよくわかる 世界の仕組みを物理学で知る~

つまり、我々が赤いリンゴを視認することは、(太陽等の)光が当たって赤以外の光が吸収された結果、赤の波長の光だけが目に届くという仕組みによる。従って、本物のリンゴではなくて写真のリンゴを見ても同じようにリンゴと認識できる。

言い換えると、光(データ)を注意深く観察することでリンゴという実体(現実世界)を認識することができるということであり、リンゴの特徴を描いた絵や写真がモデルであると理解した。

例えば、顧客の購買データを分析することで、「顧客の買う/買わない」という現象をとらえモデル化を行う。モデルを作ることにより顧客にとってより購買につながる行動とは何かが見えてくる。

このように整理することでデータ分析の目的がストンと腑に落ちた。

データ分析はプロセスであり成果物ではない

つぎに、「データ分析はプロセスであり成果物ではない」という箇所であるが、著者は、
データ分析者によるデータ分析を、料理人による食材の調理にたとえている。

食材(データ)を調理道具(SQLやツール)によって調理し、最終的に美味しい料理(データ分析結果)として客(意思決定者)に提供する。

料理人の役割は客に料理を提供するところまでであり、どんなに自分の作った料理に自信があったとしても客が「美味しい」と思わない限り何の意味もない。

「データ分析も、データを活用して経営に影響を与え、業績に貢献するなどの価値が生まれて、はじめて意味をなす。」(P.337)

意思決定者とデータ分析者は分ける

また、「意思決定者とデータ分析者は分ける」という箇所も興味深い。

これは、意思決定者がデータ分析を行うと、結論ありきの分析に陥りやすいことを示している。(思考バイアス)

「データ分析者は、客観的な立場で分析を行い、データと向き合い客観的な結果を出します。意思決定者は、その分析結果に基づいて意思決定を行うようにします。」(P.338)

国家の意思決定から発展した「インテリジェンス」

そもそも、「インテリジェンス」とは国家の意思決定に必要な「情報分析」であり、インテリジェンス機関の例としてCIA(Central Intelligence Agency)が挙げられる。CIAは米国が国家として安全保障上の重要な決定を下す際に必要な情報を分析する機関である。

もし、大統領を忖度し思考バイアスがかかった分析が行われてしまうと、国家にとって誤った判断を犯す重大なリスクがある。

実際に、米国はCIAがもたらした「イラクには大量破壊兵器が存在する」という誤った分析結果によりイラク戦争を起こした。これは、インテリジェンスの失敗例として検証が必要であろう。

インターネットにせよ米国発の技術は軍事からのスピンオフが多いが、このインテリジェンスをビジネスにおいても活用しようとするのが「ビジネス・インテリジェンス」である。

はじめて 「ビジネス・インテリジェンス」という言葉を聞いた時、なぜ「インテリジェンス」なのだろうかという素朴な疑問を持ったのだが、意思決定者とデータ分析者を分けるという観点では全く同じ発想であることに、本書を読んで大いに納得できた。

チームとしてのデータサイエンティスト

データ分析者が「自分がせっかく作ったデータ分析の価値をわかってもらえない」と嘆き、一方で意思決定者が「データ分析結果がさっぱりわからない」といらだつ。。。というのは著者が今まで沢山目にしてきたことなのだろうが、両者の間に立ちはだかる壁を乗り越える必要がある。

著者は、これを「 ある時点までに達成したいと考える到達点を表明したビジョンを共有すること」と 「 データサイエンスの実践に求められるスキル を磨くこと」で乗り越えられることを強調している。

後者には

  • ビジネス力(Business problem solving)
  • データサイエンス力(Data science)
  • データエンジニアリング力(Data engineering)

という3つのスキルセットが必要だが、いわゆるデータサイエンティストとは一般的に一人でこれらすべてに精通したスーパーマンという印象がある。

”Harvard Business review誌のシニアエディターであるスコット・ベリナートは、「そのような人物はユニコーン級に希少である」と断じています。”(P.346)

ところが、著者は「それぞれの能力を持つ人達が集まり、チームとしてデータサイエンスの価値を生み出す」(P.346)ことができると主張する。つまりスペシャリスト集団としてのチーム力で乗り越えられるとの考えである。

これは、基幹系のエンジニアにとってもスキルシフトする道が開けるのではないかと思った。

まとめ

今更であるが、経済産業省が昨年出した「DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~」が気になって最近読んでいた。

そこに、今回の書評のお話がありデータ分析について学ぶ機会に恵まれたのであるが、「デジタルトランスフォーメーション」を単なるバズワードにしないためには、やはりデータ分析が不可欠であると感じた。

現在の私はデータベースの性能問題解決に特化した仕事が多いのだが、多くのプロジェクトでは「〇〇刷新」と言いながら、インフラ周りをリプレースするだけで、業務アプリケーションは「現行踏襲」が原則で、データを利活用した業務の大幅な見直しなどというケースには残念ながらほとんど遭遇したことがない。

”IT関連費用のうち8割以上が既存システムの運用・保守に充てられている”

”複雑化・老朽化・ブラックボックス化した既存システムが残存した場合、2025年までに予想されるIT人材の引退やサポート終了等によるリスクの高まり等に伴う経済損失は、2025年以降、最大12兆円/年(現在の約3倍)にのぼる可能性がある”

上記レポートにはこのような悲惨な現状および近未来が描かれているが、やはり根本原因は経営者のITに対する無理解と無関心にあるのではないかと思っている。

しかしながら、データ分析が経営にもたらす成果を経営者が実感できれば、世界は大きく変わるとも思う。

つまり、データ分析は真のデジタルトランスフォーメーションにとって必要不可欠と思うのである。

その意味でも、本書の内容は多くに人に知ってもらいたい。

このような機会を与えてくださった西潤史郎さんに感謝しつつ、この書評を締めくくりたいと思う。

終わり

書評:「SQLデータ分析・活用入門 データサイエンスの扉を開くための技術」① 西潤史郎 (著), 山田祥寛 (監修)

はじめに

著者の西潤史郎さんとは、2011年に倉園佳三さんのITガジェット系セミナーでお知り合いになったのだが、当時は歯科開業に関するコンサルティングのお仕事をされていたと記憶している。

Facebookで繋がってたまにメッセージをやり取りする間柄だったのだが、この度SQLの入門書を執筆されたと知り大変驚いた。

早速、購入しようと思っていたのだが、「ブログで紹介してくれたら献本します。」という書き込みがあったので手を挙げることにした。

現在西さんは、データ・サイエンティスト株式会社のチーフデータエンジニアということで、本書は分析系エンジニア向けの入門書という位置付けで書かれている。私はどちらかというと基幹系データベースのエンジニアであるので、自分の周りのエンジニアを意識しながらこの本の紹介をしたいと思う。

基幹系データベース・エンジニアが分析ツールとしてのSQLを学ぶ意義とは

誤解を恐れずに基幹系と分析系の違いを図示すると以下のようになると思う。

両者は相容れない分野という印象を受けるが、共通言語としてのSQL特にウィンドウ関数に精通すれば、基幹系データベース・エンジニアが自らの領域を広げるよいきっかけになるのではということを本書を読んで感じた。(下図)

特定の業務に精通することは大事だが、長いエンジニアとしてのキャリアを考えた場合、汎用的例えばパフォーマンスチューニングやデータモデリング等の知識を得ることは重要だと思う。

汎用的知識の一つとしての分析系領域にSQLをきっかけとして入り込んでいくことを、基幹系に携わる若いエンジニアには是非意識して欲しいと思った。

そのための入門書としても本書は非常に良書と考える。

本書の構成

本書は第一部と第二部に分かれており、 第一部はデータ分析とSQLの世界の全体像の把握と分析SQLの基本的な理解を目的としている。

第二部では、具体的な分析例とデータ分析の目的および実現方法に対する著者の熱い想いが描かれている。

概要と環境

それでは、目次を最初から見ていこう。

第一部 SQLによるデータ分析の基礎
 第1章 SQLデータ分析の世界
  1.1 SQLによるデータ分析とは
   データ分析ニーズの広がり
   データとデータベース
   リレーショナルデータベース管理システムとSQL
   データ分析の流れ
  1.2 分析システムの広がりとSQL
   基幹システムと分析システムの違い
   分析システムのSQLとデータベースの特徴
   コラム ウィンドウ関数という革新で第2の生を得たSQL
  1.3 なぜ分析SQLのスキルが必要なのか
   データベースにある一次データを取得する
   SQLは分析担当者とエンジニアにとっての「英語」
   コラム ビッグデータに対応するデータベースNoSQLによるSQLへの回帰

第1章はSQLによるデータ分析の概要に関する解説となっている。ここで注目したいのは”SQLは分析担当者とエンジニアにとっての「英語」 ”という箇所である。

共通言語としてのSQL を通してデータ分析者とエンジニアが会話できれば、つまり、SQLを使えば何ができるのかということを分析結果のユーザであるデータ分析者が理解していれば、同じ目的を明確化した分析が可能となるということである。

また、2つのコラムも非常に興味深い。ここは是非ミック氏の「達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへー17 順序をめぐる冒険」を併読して欲しい。

第2章はデータ分析環境についての解説である。サンプルコードはDDLと共に書籍内で指定されたURLからダウンロードできるので、第3章以降の内容は手元の検証環境で実際に確認することが可能である。

私はPostgreSQLの環境で、付録の情報を参考にしながら「SQL Workbench/J」を使って確認を行った。

 第2章 データ分析環境を整える
  2.1 データ分析環境の準備
  2.2 アドホック分析とレポーティングの環境
  2.3 その他の分析ツール
  2.4 SQLクライアントをデータ分析で活用する

 付録
  A.1 SQLクライアント「SQL Workbench/J」の導入方法
  A.2 ダッシュボードツール「Redash」の導入方法と可視化手順

SQLの基本

第3章から第6章はSQLの基本についての解説である。SQLをすでに習得している読者であればざっと読み進めてもかまわないが、基本知識のおさらいにはちょうどよい内容である。

 第3章 データの「分ける」「数える」が分析の基本
  3.1 SELECT文でデータを分析する基本
  3.2 WHEREでデータを絞り込む
  3.3 GROUP BYでデータをグループ化する
  3.4 HAVINGでデータをさらに絞り込む
  3.5 ORDER BY句/LIMIT句でデータをさらに整える
 第4章 分析を効率化するSQLによる前処理
  4.1 異なるデータ型への変換
  4.2 数値のデータ加工
  4.3 日付・時間のデータ加工
  4.4 文字列のデータ加工
 第5章 データをさらに活用するためのテクニック
  5.1 サブクエリを使いこなす
  5.2 INとEXISTSによるデータの調査
  5.3 SQLで基本統計量を求める
  5.4 ログデータひとつでできるユーザ分析
 第6章 複数のテーブルを扱うJOINとUNION
  6.1 テーブルの結合とテーブルの正規化
  6.2 JOIN句によるテーブルの結合
  6.3 特殊な結合
  6.4 UNIONで複数のテーブルを扱う

ウィンドウ関数

第7章は第一部の中でも特に強調しておきたい箇所なので小見出しレベルまで紹介する。

 第7章 分析SQLの主役「ウィンドウ関数」徹底入門
  7.1 ウィンドウ関数の概要
   ウィンドウ関数とは
   ウィンドウ関数でランキングを求める
   ウィンドウ関数の構文
   ウィンドウを明記する、別の表記方法
  7.2 ウィンドウの範囲と順序を指定するPARTITION BYとORDER BY
   PARTITION BYでグループ分け
   PARTITION BYを指定しない場合のウィンドウ
   ORDER BYで並び替える
  7.3 ウィンドウ関数に変身する関数と専用の関数
   順序を扱うウィンドウ関数専用の関数
   集約関数からウィンドウ関数に変身する関数
  7.4 フレーム句を使いこなし分析SQLの達人になる
   フレーム句の構文とフレームのイメージ
   フレームで直近の日付を求める
   RANGEによる値単位での行指定

この章のサンプルSQLを実際に試してみるとウィンドウ関数がどのように機能するかよく理解することができる。ウィンドウ関数についてここまで徹底的に解説してくれる入門書にはあまりお目にかかったことがないので、非常に参考になる。

ウィンドウ関数自体に「WINDOW」 という単語は出てこないことが取っつきにくい印象を与えるが、「ウィンドウ=フレーム」という理解をしていればイメージしやすいのではないかと思った。

基幹系のバッチSQLでも集計を行っているものがあるが、各行ごとに合計値列を追加するためだけにテーブルを自己結合しているような事例をよく目にする。

もし、ウィンドウ関数のテクニックがあれば無駄な結合を解消し、よりシンプルなSQLに書き直すことができるかもしれない。

一般的なSQL入門書は数ある機能の一つとしてウィンドウ関数を簡単に 紹介しているものが多いが、本書は第二部以降の実践編へスムーズに入っていくことができるような構成になっているのが非常によいと感じた。

第二部は実践編

本書のメインは第二部の実践編である。第8章はデータ分析の基本的な実践としてアドホック分析を紹介している。

基幹系システムに関わるエンジニアは、SQLとは定型的な業務を実行するためのツールであり、常に期待された正しい結果を正しい時間内に返すクエリーの作成が最も重要であるという共通認識がある。

従って、オンライン処理にせよバッチ処理にせよ、データの内容によって実行計画が変動し、性能が急激に劣化するような状況が最も問題である。

一方、分析系の世界はその場一回限りの(アドホックな)クエリーを対話的に何度も実行することで、求めるモデルを追求していくという特徴がある。

私は本格的な分析業務の経験がないのであるが、第8章のサンプルを丁寧に実行することで、データ分析の実際を簡単に体験することができた。

第二部 SQLによるデータ分析の実践
 第8章 SQLで小さな分析を積み重ねる
  8.1 小さな分析を積み重ねるアドホック分析
  8.2 ファクトデータを活かす時系列分析
   時系列分析とは
   ウィンドウ関数で簡単、SQLで時系列分析
  8.3 グループ分けを組み合わせるクロス集計
   クロス集計とは
   データの確認
  8.4 実践アドホック分析1〜全体から部分へ分析を進める〜
   モデルのイメージ
   全体の把握
   GROUP BY句でグループを分ける
   ウィンドウ関数によるランク付け
   CASE式によるランク付け
   クロス集計で表を整える
  8.5 実践アドホック分析2〜集計と深掘り〜
   指標を追加し、3指標のランクを求める
   3指標でランクを求める
   ランク値ごとに集計する
   集計値を求める

「8.4 実践アドホック分析1」では、「直近購買日」と「購買頻度」という2つの軸(指標)によるクロス集計をゴールとしている。

GROUP BY句で分けられたグループにおけるランク付けを、ウィンドウ関数とCASE式の2つの方法でランク付けする実習を行うことでそれぞれの特徴を理解することができる。

「8.5 実践アドホック分析2」はさらに「購入金額」という指標を加えることで、最終的にRFM分析を体験することができる。

RFM分析というのは本書で初めて知ったのだが、顧客の購買行動をRecency(最新購買日)、Frequency(購買頻度)、Monetary(購買金額)の3指標で顧客動向を分析することである。

第一部から始まって第8章最後のRFM分析に至る流れを感じることができるので、なかなか練られた構成だと思った。

更なる実践Tips

第9章ではより本格的な分析を行う場合に必要なTipsが解説されている。

 
 第9章 長いSQLを読み解く
  9.1 データ分析でよくある長いSQLの読み方
   内側のSELECT文から読む
   SELECT文は句の処理順に読む
  9.2 統計量「四分位数」を求めるSQLを読み解く
   四分位数とSQL全体像
   SQL全体像と読み解き順序
   ランキングを算出するための相関サブクエリ
   ランキングを算出するクエリ
   ランキングをもとに四分位に振り分ける
  9.3 「バスケット分析」のSQLを読み解く
   バスケット分析について
   データとSQLの関係
   SQL全体像と読み解き順序
   1つめの文「商品の組み合わせと購入回数」
  9.4 「ユーザーの利用機能分析」のSQLを読み解く
  9.5 [番外編]既存のSQLをよりよく改善する

「長いSQLを読み解く」というテーマの章であるが、本ブログでも以前 SQLフォーマッターFor WEB というSQL整形ツールを紹介したことがある。

分析系、基幹系問わず長いSQLをいかに的確に読み解けるかが生産性に大きく寄与するが、この章には本当に必要なエッセンスが書いてある。

第10章はまとめであるが長くなりそうなので次回に続く…

書籍紹介:『アポロ13』に学ぶITサービスマネジメント ~映画を観るだけでITILの実践方法がわかる! ~

書籍紹介:『アポロ13』に学ぶITサービスマネジメント ~映画を観るだけでITILの実践方法がわかる!

アポロ13号でなぜITILを学ぶのか?

アポロ13号の事故は1970年、一方ITIL:Information Technology Infrastructure Library1989年イギリスで初版が公開された。

従ってこれらには直接の関連性はなく、それは本書の中でも再三繰り返されている。
しかし、ITILがアメリカの成功体験を分析することで策定されたという逸話もあるので、「成功した失敗」と呼ばれるアポロ13号の教訓からITILの本質を学ぶという筆者の考えには共感できる。

目次

■第1部 ITサービスマネジメントとアポロ13
●第1章 ITサービスマネジメントとは
-ITサービスの価値を高めるために-
●第2章 『アポロ13』でITSMを学ぶ意義
-アポロ計画とビジネスストラテジの共通点-

■第2部 サービスストラテジ
●第3章 「ニール・アームストロングが月に降り立ちました」
-アポロ計画における戦略-
●第4章 「14号があればだが」
-アポロ計画における「顧客」とは-
●第5章 「月を歩くんだね」
-サービスという単位を考える-

■第3部 サービスオペレーション
●第6章 「ヒューストン、 センターエンジンが停止した」
-インシデント管理-
●第7章 「反応バルブを閉じろ、と伝えろ」
-サービスデスク-
●第8章 「自分の字が読めないんだ。思ったより疲れているみたいだな」
-問題管理-

■第4部 サービスデザイン
●第9章 「絶対に死なせません」
-サービスレベル管理-
●第10章 「チャーリー・デュークが風疹にかかっている」
-可用性管理-
●第11章 「問題は電力だ。電力がすべて」
-キャパシティ管理-
●第12章 「トラブルが発生した」
-ITサービス継続性管理-

■第5部 サービストランジション
●第13章 「なんとかして、この四角をこの筒にはめ込むんだ」
-構成管理-
●第14章 「この飛行計画は忘れよう」
-変更管理-
●第15章 「こちらヒューストン。打ち上げ準備完了です」
-リリース管理-

■第6部 継続的サービス改善
●第16章 アポロ計画は改善のかたまり
-継続的サービス改善-

読後感

「アポロ13号」というタイトルに惹き付けられて手にした本書だったが、予想以上に面白い本だった。

例えば、
●第4章-アポロ計画における「顧客」とは-では

  • 顧客:アメリカ大統領、政府役人
  • ITサービス・プロバイダ:NASAヒューストン管制センターと管制官
  • ユーザ:3名の宇宙飛行士、バックアップ宇宙飛行士
  • インシデント管理マネージャー:主席飛行管理官

のように、具体的な登場人物を映画「アポロ13」の場面から引用することで、ステークホルダーやその他ITILの重要なキーワードをわかりやすく説明している。

これは、各章で一貫しているスタイルなので、DVDを観ながら読み進めると非常に面白い。

実践には概念を現実に昇華させる方法が必要であり、この本の手法はとても参考になる。

なぜ日本ではITILが浸透しないのか?

IT業界に長く身を置いているのだが、ITILを始めて聞いた2004年ごろから現在までITILの考え方を取り入れて成功した例をあまり聞いた実感がない。単純に成功体験に接する機会に恵まれなかった結果なのかもしれないが、行った現場はことごとくITIL的でない状況だった。

ただし
「多くの会社でSLAとして作成された文書を実際に確認してみると、現状そのほとんどは単なる契約書であり、ITILで解説しているSLAとはまったく違っていて、愕然とします。しかし、すでにSLAがあることになっていますので、別途(本来の)SLAが策定されることはありません。SLAという名の契約書(実際には、法務部門のレビューまで受けて押印された、ただの契約書)が存在していますので、SLAを権威づけするような契約書が別途交わされることもありません(本当の意味でのSLAが存在しないのですから、当たり前と言えば当たり前なのですが…)。このような状況ですので、外部プロバイダとの間でUCを取り交わすようなことはあっても、プロバイダ内部でOLAを策定しようと考えるIT部門は、残念ながらもほぼ皆無です(筆者の知る限り、きちんとOLAを策定していたITサービス・プロバイダは1社だけでした)」(読書位置:1672)
とあるように、ITILを正しく実践できている会社がほとんどないというのが現実なのかもしれない。

構成管理データベース(CMDB)から始めよう。

データベースに深く関わっている立場から感じることは、ITILを実践できないのは中核となる構成管理データベース(CMDB)がないからだと思う。本の中から構成管理について述べられた部分を抜粋する。

「この構成管理、実はこれそのものは何の利益もユーザ満足ももたらしません。そのため、つい後回しに、ないがしろにされてしまいがちなプロセスです。しかし、構成管理は前述のとおり、構成管理データベースを常に最新の、正確な状態に保つことを目的としたプロセスです。構成管理データベースは、ほかの重要なプロセスがITサービスの提供に利益をもたらすことを確実にするために、とても重要な情報を提供します。したがって、構成管理は(地味なプロセスなんですが)非常に重要である、と言えるでしょう。」(読書位置:2693)

「構成管理の観点では、ストレージは単なるサーバーの属性の1つ(どのサーバーに何テラバイトの容量のストレージが割り当てられているか)に過ぎないかもしれません。また、物理的なサーバーの中に仮想サーバーが10台存在するなら、構成管理としては、その仮想サーバー10台もそれぞれ構成アイテムとして管理する必要があるでしょう。さらに、SLAや組織図などの文書は資産管理では扱いませんが、構成管理では非常に重要な構成アイテムとして管理対象に含めます。」(読書位置:2706)

「筆者がJAXAに勤めている人から話を伺ったところ、世界初のデータベース管理システムは、このアポロ計画で宇宙船に積み込む備品のリストを作るために作られたのだそうです。ヒューストンの管制センターで全体の管理をしていたコンピュータ・システムはIBM社のSystem/360でしたから、おそらくこの世界初のデータベース管理システムは、System/360上で稼働していたことでしょう。もっとも、IBM社初のリレーショナル・データベースである System R は1977年に初めて売れた、ということですので、この世界初のデータベース管理システムは、現代風のリレーショナル・データベースではなかったのかもしれません。」(読書位置:2731)

以前、某ITサービス・プロバイダに在籍していた時、構成管理データベースの重要性を実感していたにも関わらず日々の業務に追われ結局実現することができなかった。

構成管理データベースはオープンソースのツールが存在したりしているが、出来合いのツールに合せていくのではなく、現状どこにでもあるExcelベースで管理している構成情報をモデリングしCMDB構築のヒントを模索していこうと思う。

これが漠然とした今年のテーマである。

書籍紹介:イギリス人アナリストだからわかった日本の「強み」「弱み」 (講談社+α新書)

8199+gpS69L._SL1500_

著者は異色の経営者

著者はイギリス人の証券アナリストとして、バブル崩壊後の日本において不良債権処理に関する鋭い指摘で名を馳せましたが、2009年にゴールドマン・サックス証券を最後にアナリストを引退、その後は文化財などの修理、施工を行っている「小西美術工藝社」という社長から猛烈なアプローチを受け経営を託されているという異色の経営者です。

テレビ東京のカンブリア宮殿で紹介されたこともありますが、以前からこの方には興味を持っていたので、Kindleでを買って読んでみました。

Kindleのハイライトは便利だけど。。。

親日家のイギリス人が、日本人をヨイショしている本かと思いきや、タイトルにもあるように日本人の「弱み」を鋭く指摘しているところが非常に的確で、グイグイ引き込まれてしまい1時間半くらいで一気に読んでしまいました。

Kindleはハイライトを後でまとめて見返すことができる便利な機能があるので、私の印象に残ったところを紹介したいと思います。(最近なるべく後から思い出しやすいように、ハイライトさせる箇所を少し広めにしています。このように紹介することが著作権にどのように関わるかちょっとグレーな感じがしますが、これを読んで本を買いたい気持ちになればそれもありなので、そのまま紹介します。)

私のハイライト紹介


ただ、これらの動きのなかで、ひとつだけ気になることがあります。  それは海外の文化や風習などと日本の文化や風習を比較した後で、結局はランキング、すなわち、優劣をつけて「やっぱり日本はすごい」と自画自賛するという結論になっていることが非常に多い印象なのです。  特にテレビは、視聴者を良い気分にさせなければいけないからでしょうが、あまりにもこの予定調和が多いのです

読書位置29


このような結論にもっていくという手法は、私のようなイギリス人にはあまりにも無理があるというか、かなり抵抗があります。  なぜかと言いますと、こうした番組は日本の強みの検証ではなく、日本が強くかつ相手国が弱い特徴だけを取り上げて優劣を競うという、結論ありきで、フェアではないことが多い印象だからです。  海外において、自分たちの国の強みと弱みをテーマにした本を探しましたが、あまり確認できませんでした。なぜこのような類の本がないのでしょうか。  これはあくまで私の想像ですが、まず強み弱みをテーマにした本をつくるのは大変だということがあるかもしれません。たとえば、イギリスが国の強み弱みの本を出そうと思ったら徹底的にデータや事例を並べて、一時的な強み弱みなのかどうか、因果関係があるのかどうかという分析などで、すさまじいページ数を費やしてしまうでしょう。  次に考えられるのは単純に興味がないということです。多くの国の国民は、他国からどう思われているのかにあまり興味がありません。それが分かったからといって、それは他国と比較したものである以上、その他国に住んでいるわけではないので、あまり意味がないと考えているのです。  国際比較をするときに、そもそも、どこの国の何を比べて、誰が何をもってどういう価値観で強み弱みを決めるか、ということをめぐってかなり激しい議論が交わされることが予想されます。そういう意味でも海外では自国の「強み弱み」を論じるというのは非常に難解なテーマなのです

読書位置40


ひとつは、一九九〇年代以降の「ポリティカルコレクトネス(political correctness 以下、PC)」の流行があります。PCとは、人種の別、性別などによる差別廃止の立場での政治的正当性を訴える運動のことです

読書位置63


実際に、比較する側とされる側の両方がいるなかで、国際比較はどんなに難しいのかということが明確に浮き彫りになってきました。要するに、PCに対して批判的な人は、PCによって何も言えなくなってしまったというわけです。自国への礼賛というのは他国への侮辱と表裏一体だからでしょう。

読書位置75


申し遅れましたが、私の名はデービッド・アトキンソン。イギリスの中東部の小さな町で生まれました。父親はエンジニア・重機の会社の経営者として、大英帝国時代の名残りもあって、仕事で世界各国に出張していました。そのような家庭の四人兄弟の三男として生まれた私は、アイザック・ニュートンが通った地元の高校を卒業した後、オックスフォード大学にて、戦後経済の発展を専攻に、日本学を学びました。  卒業後は、日本の金融機関をお客様にして、ニューヨークでコンサルティングをした後に、一九九〇年からはソロモン・ブラザーズ証券のアナリストになり、バブル崩壊後の不良債権問題などを指摘させていただきました。  その後、ゴールドマン・サックス証券に移籍をし、二〇〇九年に引退。趣味であるお茶を楽しむなどの生活を送っていたのですが、二〇〇九年にひょんなことから「小西美術工藝社」という会社の社長から熱烈なアプローチを受けて、経営を任せられることになりました

読書位置88


アナリストがなぜ客観的分析をこころがけるかというと、企業や経営の姿を正しく把握しなければ、何がいけないのか、何が問題なのかという事実がわからなくなってしまうからです。事実を直視すれば、おのずと何をすべきかという解決策が見えてきますが、事実から目を背けて、自分たちに都合の良い分析に固執していると、良くない結果を招きます。それは先ほどの不良債権問題でも明らかではないでしょうか

読書位置103


私から見ると、日本ははっきり言ってしまうと「宝の持ち腐れ」という印象です。  力はあるもののその本来の力を引き出すことなく、それほど力のないポイントを、アンフェアな分析で強引に力があると思い込んでいる。  つまり、自分たちが本来もっている力を見誤っているのです。これが日本という国と、みなさん日本人にとって大きな損失であることは言うまでもありません

読書位置121


本書で最も申し上げたいのは、日本にはまだまだ日本のみなさんが気づいていない「強み」がある、という事実であり、それを活かしきれていないことこそ最大の「弱み」だということです

読書位置141


不良債権問題の時、私は日本の銀行の「弱み」について客観的分析をして、それをレポートなどで指摘をしました。自分としてはその「弱み」をどのように解決していけば成長できるというところまで提言をしたつもりでしたが、残念ながらあの時は耳を貸していただけませんでした

読書位置144


日本と比較した場合、中国の人口は日本の一〇倍強なので、一人当たりのGDPが日本の一〇分の一になるだけで、中国経済が日本経済の絶対額を抜きます。  ただ、それは総額だけの話です。一人当たりのGDPは中国は世界八〇位にすぎないので、客観的に見れば、まだ先進国ではありません。

読書位置241


一億人の人口を超えている一二ヵ国の中で、先進国になっているのは二ヵ国のみです。それは、アメリカと日本だけです。人口が非常に多くて、なおかつインフラ整備され、教育水準も高く、技術力なども揃っている人口大国は、この二つしかありません。

読書位置254


誰もがうなずく話ですが、やはり先進国の中で日本のエンジニアは別格です。これまでの経済史を振り返っても、商品開発などの功績において多くの足跡を残しています。  この原動力になっているものには、やはり「職人魂」と言いますか、「極める美学」があると思います。海外赴任をしても、祭日祝日でも休むことなく、徹底的に自分の技術を磨く日本のエンジニアの働きぶりは世界の誰もに認められていますし、日本社会でも尊敬の対象になっています。海外のエンジニアが何回も試したけれどできなかったことが、日本人エンジニアによってなしとげられたというケースは少なくありません。

読書位置272


ここで私が言いたいのは、日本人労働者は勤勉で技術力が高いというのはまぎれもない事実であり、日本の強みでもありますが、それを実態以上に評価するのは間違いだということなのです。

読書位置303


日本が経済大国になったのは、戦後の奇跡の経済成長があったからだという主張は、明治から大正にかけて日本を先進国に押し上げた先人たちをあまりにも軽んじているのではないかと、私などは感じてしまうのです。

読書位置350


そのような「弱み」として、私がまず申し上げたいのは、日本の効率性と生産性の低さです。  これは私だけではなく、日本人でも多くの方たちが指摘をしていることです。

読書位置410


日本人は非常に勤勉であり、労働者もよく働くというのは紛れもない事実であり、明らかに価値の有無が問われる仕事までも非常にまじめにこなします。  ただ、一方で柔軟性に欠けている、つまり頭が固い傾向があります。本当はずっと前に止めたほうが良いとだれもが気づいている仕事の仕方は改善をしないで、それに対しても、むしろ美徳を見出そうとする傾向がある印象さえ受けます。

読書位置468


長時間労働もこれと同じです。日本人は非常によく働きますが、Euroslarによりますと、一時間当たりのGDPは二〇一三年で世界二一位。やはり長く働けば働くほど、疲れるので効率が下がるのではないでしょうか。

読書位置482


つまり、文化財修理に力を入れるということは、内外からの観光客を呼ぶ一助になるだけではなく、国の雇用対策にとっても非常に良い投資先であるといえます。

読書位置555


会社というものが組織の生産性を上げるのに、経営者が及ぼす影響というのは極めて大きいということを申し上げたいのです。  つまり、日本の「効率性が良くない」という問題は辿っていくと、じつは日本の経営者につきあたるのではないかということです。

読書位置602


日本の仕事の進め方があまり「効率が良くない」というのは、一人ひとりの日本人労働者やビジネスマンたちに原因があるのではなく、経営者などのリーダーにある可能性が極めて高いのです。

読書位置620


アメリカとイギリスでは、労働者は日本のように優れてはないので、それでも国が成り立つようにするために、かえって経営者が鍛えられて、強くなるのだと思います。  逆に、日本は労働者の質が良くて、おまけに今まで高度成長の環境にも恵まれてきたので、経営者が鍛えられず、海外の一部に比べて、弱いように見えてしまうと思います。

読書位置646


日本の経営者はプロセスに重きを置く傾向があります。そして、この傾向が舵取りをする組織に波及し、そこで働く従業員たちに波及し、その結果、仕事の進め方の効率が悪くなっている可能性があるのです。さらに言わせていただきたいのは、「やや行き過ぎではないか」ということです。

読書位置685


コンサルタントをやっている時代に、研修で、商品を九〇パーセントまで仕上げるには一〇のコストがかかるとしたら、一〇〇パーセントにもっていくには、そこからは一パーセントを上げるたびに、さらに九ずつのコストがかかるというのが鉄則だと教わりました。

読書位置717


日本人の一部は仕事を美徳と見なしたり、修行と見なしたり、本来は別な場所で求める夢を仕事に持ち込み過ぎている感じがありまして、それが一人当たりGDPの数字の伸び悩みとして表面化しているのではないかとの仮説を、私は立てています。

読書位置722


先進国のなかでも比較的恵まれている経済のなか、日本の経営者が「数字」に基づいた経営、さらには今までよりも株価を重視した経営へと切り替えれば、今まで以上に素晴らしい経済になる可能性を秘めています。

読書位置768


日本の「効率が良くない」というものの問題を辿っていくと、かなりの部分はこの「面倒くさい」という言葉に帰結する感じがします。

読書位置853


経済という数字については、これを直せばすぐに改善するというようなシンプルアンサーでは、なかなか解決ができません。しかし、何が悪い、どこが劣っているという問題点というのは、その本質は非常にシンプルなのです。難しい言葉や表現をつかって粉飾をしても、「結局、何を言いたいのですか」という質問を繰り返していくことで、問題に対する本当の原因が見えてきます。

読書位置856


イギリスでは「too much trouble」という概念はありますが、それは問題を解決しない理由として今はなかなか認められません。 「troublesome」を解決することが「仕事」なわけですから、「面倒くさいことになるのでやめたほうがいい」というような結論にはなかなかなりません。昔はそうではなかったかもしれませんが、とくにイギリスでは「面倒」なことを解決することがGDPの成長につながるという考え方に変わっていきました。

読書位置873


日本社会では「正論」を潰すことが多々ある。その際につかわれる便利な言葉が「面倒くさいことになる」なのではないかということです。

読書位置906


戦後日本の経済成長は「奇跡」と言うよりは、ある意味で成功がかなり約束されたものだったのです。  このように黙っていても右肩上がりで成長する社会では、リスクをとる必要がありません。何か問題が発生しても、動かずじっとしていればやがて時間が解決して事態が改善されていくからです。

読書位置961


終身雇用」というのが日本人の勤勉さの礎だなんだというのはすべて後付けであり、その根底にあるのは「面倒くさい」を避ける気質なのではないでしょうか。会社側からしても、新しい人材を探したり引っ張ったりしてくるのは「面倒くさい」。まさしく日本の終身雇用制度というのは、経営者側と労働者側の「面倒くさい」がうまく合致したことによって生まれたシステムといってもいいかもしれません。

読書位置1000


物事を変えない、何もしていないことを丁寧に「なぜできない」というふうにできない理由として説明するのが、日本人は非常に得意だと思います。とくに公務員、銀行員、企業の役員のこのスキルには、むしろ逆に感動さえ覚えます。

読書位置1037


このような切り替えの早さというのは、他の先進国にはない日本の特徴と言えるでしょう。歴史を見ても、昨日まで尊王攘夷だと叫んでいた人たちがいきなり開国論者になる。このような柔軟な思考は欧米社会、少なくともイギリスにはありません。

読書位置1078


戦後、日本経済が右肩上がりで成長していくなかで、「面倒くさい文化」というものは日本の「強み」だったのかもしれません。  リスクをとる必要もなく、生産性を上げる必要もない。勤勉な労働者が企業に忠誠を誓って、コツコツと働くことで、昨日より今日、今日より明日と、企業は黙っていても大きくなっていきました。そのような高度経済成長社会で、組織のあり方、社員の働き方、経営者のあり方を問い質すような人間が「面倒くさい」と疎まれるようになるのは、ある意味では当然です。

読書位置1100


これからは人口激減時代に入りますので、これまでのような右肩上がりの恵まれた経済環境ではなく、正反対のアゲインストの環境ですので、職人魂、秩序志向などだけではこの逆風を乗り越えられないのは明白です。  賢く工夫して、しっかりとした経営をしていかないといけません。そこでインテレクチュアル(intellectual、以下インテレ)の出番です。  これは企業の経営者、評論家、マスコミの一部など、昔で言う「支配階級」を指すものです。  要するにインテレとは国策についての議論を形成したり、その議論の結果に影響を与えることのできる人、あるいはその責任を負うべき人のことなのです。日本ではまだあまり馴染みがない言葉かもしれませんが、good reasoning power(論理的に判断する力)とでも理解していただきたいと思います。

読書位置1123


woolly thinkingによって、しなければならない改革のために必要な、インテレによる議論の焦点が決まらず、問題の本質の特定自体もはっきりしないので、いつまでたってもその議論がまとまらず、そのために社会が進歩せずに、いつも表面化した問題の事後処理をするだけになってしまう傾向が強くなるのです。

読書位置1149


インドでは地方によってナンといただいたりもするものが、なぜもっぱらご飯と一緒に食べられるようになったかというと、イギリスにカレーを持ち帰ったと言われているヘイスティングズ(後のベンガル総督)が駐在していたのがベンガル地方だったからです。  ここはインドのなかでもカレーを米にかけて食べる習慣があったため、「米と一緒に食べるカレー」がイギリスに伝わったのだと考えられています。

読書位置1244


日本人は今日はフレンチ、明日はパスタ、明後日は豚カツ、と食事に多様性がありますが、イタリアならば一週間すべてがイタリア料理だけなので、ピザひとつとっても種類が無数にあるのです。日本のピザもいろいろ種類があると思うかもしれませんが、どこのレストランへ行ってもほぼ同じ数種類の内容です。

読書位置1278


言いがかりをつけたいわけではありません。woolly thinkingによって、本来もっているポテンシャルを見落としてしまう恐れがあるということが言いたいのです。たとえば、ブームと言いながらも五五〇〇軒しかないということであれば、外国人が和食のつくり方を学べるスクールを作ればどうでしょう。これをビジネスチャンスととらえれば、そこに大きな成長の芽があるかもしれないのです。

読書位置1288


英語の辞書を引くと、woolly thinkingの説明のたとえに、「木の枝を切り落とすときに、その枝に座る行為」と書いて、危険な例として書いてあります。

読書位置1448


海外においてもマナーなどが観光の主たる動機になるというデータがあれば話は別ですが、それは確認できません。たしかにその国のマナーなどは、リピーターの獲得にはつながるとは思いますが、日本を観光する主たる動機になる可能性としては低いです。ならば、それをいくらアピールしたところで、無駄な努力であり、そこに力を入れれば入れるほど、観光のアピールが失敗をする恐れが出てくるということです。

読書位置1372


あるデータによれば世界一治安の良い国がアイスランドですが、年間の観光客は八〇万人しかいません。

読書位置1382


アメリカは議論を嫌う文化です。イギリスは議論が好きですが、その議論の基本はロジックです。

読書位置1426


これは私の仮説ですが、日本人がエンジニアリングと理数系に強いというのは、数学、化学、物理学となるとロジックそのものの世界でwoolly thinkingが排除されやすいからではないでしょうか。woolly thinkingが排除された人々が能力をいかんなく発揮しているのです。ちなみに、私が一番高く評価する日本人経営陣の大半を理数系出身者が占めているという事実も、私にとって興味深いです。

読書位置1439


食卓の話といえば、今のレストランの給仕スタイルはもともとロシアからやってきた作法だというのはご存じでしょうか。ロシア作法は、コースごとにそのコースの食べ物をあらかじめお皿に盛りつけて、一人ひとりのお客様に持っていくやり方です。スタッフは大変ですが、客からすれば豪華な気分が味わえるので好まれました。

読書位置1475


フランスの作法とは、その食事会で食べるものを、食べる人が席に着く前までにすべてテーブルに並べるというものです。クリスマスの食事のときや、一部世代の人々の間にはまだ多少残っています。たとえば、野菜をボウルに入れて皆で回してとったり、お肉を大きなお皿に載せて回しておのおので取るやり方はフランス作法の名残です。かつてのイギリスでは、階級が上に行けば行くほど、ロシアの作法が好まれたということもあって、現在はこのフランスの作法はあまり残っていません。

読書位置1480


つまり、「観光」というのは、世界では発展、繁栄が約束されていると言っても過言ではない市場なのです。

読書位置1548


ものは考えようです。世界平均が九パーセントで、日本は現在は二パーセント足らずということは裏を返せば、世界平均の取り組みをおこなえば七パーセント以上の成長が見込めるということです。  つまり、ポジティブな見方をすれば、日本にはまだ大きな「伸びしろ」があるということなのです。

読書位置1561


日本は外国人観光客が少ないということにくわえて、さらにそれらの人々が思いのほかお金をつかっていないというダブルパンチで、GDP貢献度二パーセントという結果になっている可能性が高いのです。

読書位置1586


日本には「お金を落とす外国人」があまり訪れていないのです。これこそが、観光業がGDP貢献二パーセントに留まっている二つ目の大きな理由なのです。

読書位置1600


日本の観光業のGDP貢献度を上げていくには、観光客の絶対数を増やしていくということが必要なのは言うまでもありませんが、それと並行して日本にほとんどやってきていない「観光にお金を落とす外国人」を招致しなくてはいけません。  そのために「古いものが残っている」という特徴、つまり文化財というのは大きな「強み」になるのです。

読書位置1608


が京都で町家を購入したときは、さまざまな人に外国人に売るのは絶対だめだとか、外国人が日本文化を潰す権利はないなどとさんざんな批判を受けました。ただ、後で調べると、批判している人の多くは、私のように古い町家をできる限り再現したりせず、自分の町家を潰して快適な現代風の家で暮らしている人でした。

読書位置1674


解決策を探して、工夫することなく、ただ単に禁止をする、禁止の看板が至るところにあることが特徴です。役所はとりあえず文句に応えた、というふうにしたいのか、すぐに禁止に走るといった傾向が強いと感じます。

読書位置1724


日本も自分たちがどこを伸ばすべきか、また成長の余地があるのはどこなのかということを真剣に考えて、それを伸ばす政策を実行すればいいだけの話なのですから。  そういう意味では、日本の未来は明るいです。しかし、何やら不穏な空気が流れています。  それが「はじめに」でふれた、テレビや雑誌における「日本人はすごい!」「日本の技術力を世界が評価」というような「自画自賛」です。  といっても、ここで誤解をしていただきたくないのは、「愛国心」をもってはいけないということではありません。  ただ、そのような「愛国心」があるのであれば、なおさら感情的なデータに惑わされることなく、「数字」などに基づいて事実を客観的に読み解く姿勢が重要になってくるのです。感情移入をして物事を見ると、人間はどうしても自分に都合の良い結論にとびついてしまいます。それが何の問題解決にもならないことは、バブル崩壊時の不良債権問題がよく示しています。

読書位置1799


日本人エンジニアの生産性は高いのか?

アトキンソンさんは日本人の「弱み」を「伸びしろ」と言い換えてくれていますが、日本人の「勤勉だけど面倒くさがり屋」という何とも不思議な特性は、生産性の低さの原因なのではないかと大いに納得した次第ですが、翻って我々エンジニアの生産性を考えた時に、何が課題で何を変えていかなければならないのかというヒントが与えられたように思いますので、次回はその点をさらに掘り下げて考察してみたいと思います。

書籍紹介:プログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと

Kindleで即買い

この本は書店で立ち読みをして気になっていたのですが、今朝ひょんなことから著者の記事をEvernoteにクリップしていたのを読み返してみて、非常に心動かされるものがあったので、ベッドの中でiPad miniからKindleストアで即買いしてしまいました。

プログラムは技術だけでは動かないプログラムは技術だけでは動かない ~プログラミングで食べていくために知っておくべきこと [Kindle版]

私のハイライト

Kindle

Kindleというのは本当に便利です。最初自宅ではiPad miniのKindleアプリで読んで、午後から買い物に出かけたついでにスタバでKindle Paperwhiteで続きを読んで、気がついてみたら10章あるうちの9章までを一気に読んでいました。

IMG_5333

Kindleは読んで「いいね」と思った箇所にハイライトを付けることができて、あとから自宅のMacでハイライトした部分をまとめて

https://kindle.amazon.co.jp/your_highlights

のページで見返すことができます。(自分のアカウントでログインする必要があります。)

ちなみに私が付けたハイライトは以下の34箇所です。(数字は読書位置)

  • どれだけ立派なプログラムを開発しても、だれにも使われなければ、作った意味があるのかな? 215
  •  仕事としてのプログラミングとは、「技術自慢をする」のではなく「依頼者・利用者の要求を満たしてあげること」 221
  •  「小俣さんは技術力があるのに、きちんと話ができて、とてもめずらしい人だ」 245
  •  オタク度の高いプログラマに仕事を頼むと「意外と時間がかかる」「そもそも仕上がらない」「融通が利かない」と感じることが多いのです 259
  •  理想が高すぎるのが足を引っ張っている 262
  •  「仕様を満たすためのプログラム構造・データ構造が完璧に固められないと、プログラミングに着手できない 262
  •  行きすぎた共通化が原因 282
  •  凝りすぎた構造は、ほかの人がなかなか理解できず、当人以外はメンテナンスできないという心配も高くなります 290
  •  プログラマとして重要なのは、「依頼者の課題を解決できているかどうか」 298
  •  動くものを見ると、意外と違う意見も出てくるものです 326
  •  こちら側のリーダーが「それならお前に30分やるから、真のJavaと言えるレベルで作れ!」と言い、「かんたんなことだ」となりました。 361
  •  「始めたことはやめない」という意地 378
  •  「何が何でも1日1本分を書き続ける」ほうが重要 381
  •  「開発は引き受けましょう。そのかわり、ドキュメントはこちらの分もそちらで引き取ってもらえないでしょうか?」 417
  •  技術・仕様・分野などで「初めて」手がける際には、そもそも設計を最初から正しくできる可能性は低い 494
  •  多くの失敗プロジェクトは「技術力不足」で失敗したのではなく、「プロジェクトの進め方」に問題があったのだと感じています。 521
  •  新システムの売りである「自分でもカスタマイズ・機能追加ができる」という部分に対して、「自分でカスタマイズなどしたくない」という声が出てきました 565
  •  「自己満足ではダメで、売り手・使い手がきちんと満足できるものが正解」 615
  •  勉強会が盛り上がらない時は「プライドを傷つけられたくない」という思いが原因の1つなのだろうと感じています 679
  •  「この指摘はあなたの人格を否定しているのではなく、業務として必要なことだから」 804
  •  要するに「実績・成果で勝負しよう」と考えているのです。 814
  •  知識で競い合う必要はなく、「得た知識で何をなし得たか?」がポイントだと考えるようにすればいいのです 823
  •  意見が飛び交っている間は、まず説得はできないものだ 851
  •  好きな分野・得意な分野だから、作りたいと思えるのです。 1001
  •  「プロトタイプとして割り切る部分」と「最初からきちんと作る部分」を明確にして、本番にそのまま発展できるようにするのがお勧めです。 1021
  •  機能が多いプログラムは、開発自体も大変ですが、テストも大変です。私は基本的に、ソースを書いたらすぐにその部分の動作確認を行い、1つ1つを確実な状態として積み重ねていきます。全体を組み上げてからテストをしても、ソースの細かいところまで確認することは不可能です。書いた部分は、書いた直後が一番頭に入っていますから、すぐに動作確認するのが一番なのです。 1027
  •  すぐに作り上げるために、ソースやノウハウを蓄積しておく 1192
  •  周囲を巻き込みながら進める(特にテスト) 1194
  •  作っておしまいではなく、それをどう活用するかが大事 1196
  •  見積を要求された場合は、必ずプロトタイプで実験してから提案します。 1204
  •  こんなもの、作れない?」と知り合いから相談を受けて作ったものは「ほぼすべて」完成して、売れました。 1241
  •  IT業界には、技術や知識が豊富な人はたくさんいると感じています。しかし、技術や知識を活かして何かを生み出し、世に出している人はとても少ないと思います。 1289
  •  「相手に自分の専門性を必要とされる」 1386
  •  ・海外での実績がある製品しか選ばない ・日本企業の製品を選びたくても、メーカーが競合相手なので選べない 1786

仕事で実際にプログラムを書く機会は少なくなったのですが、上で挙げたところはIT業界で成功するための秘訣のような気がします。

特に最近ブログを始めた者として非常に叱咤激励される内容でした。毎日20分のブログ執筆を目標にしようと思いました!

すきやばし次郎は高いか?

20分3万円

今日はちょっと技術者の値段について考えたいと思います。

銀座に「すきやばし次郎」というミシュランの三ツ星を何年も獲得している伝説的な寿司屋があるそうです。
オバマ大統領の来日で一躍有名になりましたが、私は当然行ったことはありません。だから全部思い入れだけで書きます。

何でも、おまかせコースが3万円からだそうです。(この「から」というのがとても気になりますが。。。)
にぎり寿司が次から次へと無言で出てきて大体20分で(早い人は15分!!)食べ終わってしまい、お会計は3万円也です。驚きです!

ネットで検索したらこんな記事も見つかりました。
すきやばし次郎が20分3万円の寿司でも客が途絶えない本当の理由

文章を見た限りでは、この記事を書いた方は多分実際には食べてないでしょうし、実際にどんなお客さんが常連なのか調べたんでしょうか?

それにしても20分で3万円!時給換算で9万円!!その辺の回転寿司の店員の時給が1000円としても90倍です!!!

映画と本

2011年にはアメリカ人の監督が作った「二郎は鮨の夢を見る」という映画が公開され、私も最近WOWOWで観ました。

映画の中で私が最も印象に残った言葉は、店主の小野二郎氏が語った「お客さんの前に立った時には9割5分の仕事は終わっている。」というものです。
つまり、店主以外の店員が築地市場への仕入からネタの仕込みまで丹念な仕事をして、最後の5%の仕事は店主が握る熟練の技ということです。

それから「すきやばし次郎 旬を握る」という本を私も買って読みました。小野次郎氏は1925年生まれの88歳。寿司職人になって63年目だそうです。

この本には小野二郎氏が今まで培ってきた技術・経験のうち、文字や写真で語ることができる恐らく全体から比べるとホンの僅かな知識と技が満載です。

例えば、「第2章 本マグロを握る」ではP.97-158まで、本マグロの月毎の断面カラー写真やマグロに関する熱い想いなどがぎっしり詰まっています。何かに人生をかけるということはこういうことなのかと純粋に感動しました。

何度も言いますが私は「すきやばし次郎」に行ったことはありませんし、上の紹介記事のように私のような庶民には確かに行ってはいけない店なのかもしれません。

でも、映画と本を観て読んで、20分3万円の理由がちょっとだけわかったような気がしました。

いつ来るか分からない15分のための準備

我々エンジニアの仕事は一言で「知識集約職業」とでも言えるでしょうか?もちろん他の職業でも同じようなことは言えますが、この仕事は特にそうなのではないかと思います。

以前、ある企業から新人研修の講師として「Oracle入門」を6回シリーズくらいで教育を行うという仕事を請け負ったことがあります。大学を卒業したばかりで右も左もわからないというような集団でしたが、中に数人キラっと光る人達が居ました。

わからないことは積極的に質問してくるし、教えていないこともどんどん本を読んで吸収していく姿は本当に輝いていました。

最近その企業を5〜6年ぶりに訪問する機会があり、そんな教え子の一人と席を並べて仕事をする機会がありました。
今では技術的な打ち合わせもリーダーとして立派に取り仕切っているし、本当に生き生きと仕事をしていることを見て非常に嬉しく思いました。

私が教えた「Oracle入門」は現在の彼の業務とは直接関係ないのですが、机の上にはOracleの参考書が並んでいたり、私が少し専門的なことを話してもびっくりするくらいついてきてくれます。

逆に、かなり経験を積んだようなエンジニアでも時々がっかりする人がいます。知識はいろいろ豊富みたいなのですが、役立つ情報がサッと出て来ない。知識が整理されていなくて何を言っているのかさっぱりわからない。つまり本当に使える知識となっていないのです。

障害が起きた時に本当の姿が見える

IT運用はうまく行って当たり前の世界なので、極稀に起きるトラブル時にエンジニアの真価が発揮されるのではないかと思います。

トラブルシュートのためのコマンドが構文エラーのために実行できない!後ろでは「まだ復旧できないのか!」という無責任はギャラリー達。

こんな時に冷静に問題を分析して、何が間違っているのか知識をフル動員して見極める。こんなエンジニアが真のプロフェッショナルです。

自分の記憶だけに頼って間違ったコマンドを叩き続ける。なぜ冷静にマニュアルを見返せないのでしょう。それから安易にGoogle検索に頼るというのも考えものです。最初からGoogleに頼ると間違った情報に行き着くかもしれません。

Google検索を全面的に否定するわけではありません。最後の手段として活用するのはよいことだと思います。世界中の知識が集まっているのですから。

自分の知識データベースを育てよう

話変わって、「プロとは?」というテーマで最近「いつ来るか分からない15分のために常に準備をしているのがプロ、デザイナー奥山清行による「ムーンショット」デザイン幸福論」という記事を読みました。(これは「運用エンジニアから開発エンジニアになるためにやったこと」というなかなか秀逸な記事からたどっていったものです。)

いつ来るかわからない障害にあるいはいつ来るかわからない支援要請に備えて、プロフェッショナル・エンジニアとしての我々は何をすべきか?

  • 検証環境でとにかく手を動かして、コードを書く。コマンドを叩く。結果を確認する。
  • 文献を読んで重要な部分のコピーを手元に置いておく。
  • 経験・知識を体系的にまとめる

私はこのような用途には、Evernoteは最適な道具だと思います。

私のEvernoteには様々な知識情報が集積されています。「技術情報」というノートブックには1300件以上の「いつ来るかわからない」ことに対して役立つかもしれない情報(ノート)が蓄積されていて、日々増殖しています。

ノートはタグ付けされていて、探したいキーワードを入れると関連するノートが瞬時にピックアップされます。MacBookでまとめた情報はiPadでもiPhoneでもネットワークが繋がっていればどこでも見ることができますし、オフラインノートブックにしておけば電波が届かない場所でも参照することが可能です。

「自分だけのGoogle」これが理想です。

Evernoteを知らないエンジニアはとても不幸だと思います。

知っていても使うことができないエンジニアはもっと不幸です。私が知っているある大企業ではEvernoteのようなクラウドサービスはセキュリティ上の理由でご法度だそうです。

このような会社に限って社内サーバルームに設置してあるファイルサーバが使えなくなって大騒ぎになったりするんですね。

話がだいぶ逸れましたが、エンジニアのためのEvernote活用術は別途書きたいと思います。

結局、すきやばし次郎は高いか?

私がこの業界に入ってまだ日が浅かった頃、あるアプリケーション開発者が1日かけても解決できないことを5分足らずで解決してしまうスーパー・エンジニアが居ました。「ああなれたらいいな」と思って今日まできたと思います。

1日8時間として5分は約90分の1。次郎と回転寿司といい勝負です。でも、結局解決できないのであれば倍率は無限大です。

アマチュアに対するプロのエンジニア、生産性で比べたらミシュラン三つ星のすきやばし次郎にも匹敵する価値があるかもしれません。

価値を感じてもらえる。そんなエンジニアになりたいものです。

でも、一度は次郎に行ってみたい!