ホンモノのエンジニアになりたい

ITやビジネス、テクノロジーの話を中心とした雑記ブログです。

【読書感想文】「LEAN ENTERPRISE」を読んで

読書感想文です。今回読んだ本はずーっと気になってたこちら。

 

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)

 

 

本のタイトルの通り、エンタープライズ(企業)にLEAN開発の手法を適用するための方法が書かれた一冊です。

 

この本を読もうと思った理由

オライリー(出版社)がシリーズ物として出版してるんだったら多分本物なんでしょ、と前から思っていました。で、こういうシリーズ物はきちんと出版された順に読んでいきたい派なんですが、ふと図書館でこの「LEAN ENTERPRISE」だけがちょこんと棚に載っているのを見つけてしまい、巡り合せを感じ借りてきてしまいました。

 

このリーンシリーズは2012年に日経BP社から「リーン・スタートアップ」が出版されたのが最初かと思います。

リーン・スタートアップ

リーン・スタートアップ

 

 

その後、オライリージャパンがシリーズ物として、6冊出版しています。「LEAN ENTERPRISE」はオライリージャパンが出版している内の一冊です。オライリーの出版は以下のリンクにまとめられています。
O'Reilly Japan - The Lean Series

  

私がリーン開発に興味を持ち始めたのは、2015年ごろだったと思います。本屋のオライリーコーナーでRunning LEANとLEAN Analytics、LEAN顧客開発が平積みで置かれていて、ポップに「今話題のLEAN開発!」といったコメントが書いてあって気になり始めたのが最初だっと思います。

それからもうかれこれ3年、さぼっていたわけではないですが、後回し後回しになってようやく巡り合ったのがこの2018年8月というわけです。

 

全体の感想

満点!まではいかないけど、すごく良い本でした。アウトプットしたいと思える本でしたね。

 

まず本書の軸になる考え方、リーンスタートアップについて振り返ってまとめてみます。ざーっくり言うと、こんな感じです。

  1. 事業のアイディア(仮説)を出す
  2. アイディアの効果を測定できるMVP(最小限の効果を持った試作品)を作る
  3. 新しモノ好きのアーリーアダプター層に使ってもらう
  4. 効果を測定し、アイディアを捨てたり方向性を変えたり、小刻みな軌道修正を繰り返す

 

スモールスタートで始めて、短期間でユーザの関心を調べたり、ユーザの声を反映させながら、ニーズに合致した製品へ仕上げていくという考え方です。

 

本書を読んでいてビビっと来たのは、MVP(最小限の効果を持った試作品)のところですね。私はSIerに勤めているので、MVPを作る状況にはなりませんが、考え方は非常に参考になりました。

 

スモールスタートは割と知られたやり方ですが、MVPは言われると当たり前なんですけど実際に作ったって話は聞いたことがありません。技術者側の立場で考えると、最小限の効果しか持たない試作品というのは作っていて悶々とするんでしょうか。技術者だけのチームであればスモールスタートで、「小さくても完璧なモノ」を作りたくなってしまうんじゃないでしょうかね。こんなサービス作りたい!という熱意が強いほど、完璧なサービスに仕上げたくなってしまう、熱が高いほどMVP作成という効率的な開発法から離れていってしまうというの面白い事象だと思いました。

 

こういったリーン開発の手法はこれからルールを作っていく新しい組織や、容易にルールの改定が可能な小規模組織で導入しやすいです。じゃあ大きな組織でリーン開発の手法は適用できないのか?この疑問に答え、実例を交えて紹介するのが本書です。

 

 

だいぶ逸れてしまいましたが、本書を読んだ上での全体視点での感想です。

  1. LEAN開発とは、という目次項目はない
  2. ちゃんとしてる本
  3. 結構難しい

 

1つ目は本書に「LEAN開発とは」という目次項目はありません。LEAN開発とか、LEANスタートアップについて真面目に知りたいなら先述の「リーンスタートアップ」あたりを読む必要があるのでしょう。本書では冒頭に書いてありますが、理屈・理論をこね回す書籍ではありません。エンタープライズ(大企業)向けにリーンを適用しようという本なので、あくまで応用のための本になります。

といっても、リーンスタートアップという仕組みの上澄み部分だけを知りたいと考えている人には良書です。電子レンジの仕組みを知らなくても誰でも使えるのと同じです。

リーンの考え方の中で、大企業に適用することの出来る部分を詳しく書いてあるので、本書だけを読んでも問題ないと思います。リーンの理屈や全体像を知りたい人は出版された順に読んでいくのがよさそうです。

 

 2つ目は「ちゃんとしてる本」です。何を言っているかと言うと、考え方の前提がきちんと提示されているという事を言っています。開発手法とかマネジメント手法というのは、他の科学分野と同じでいきなり新しい手法がぽんっと出てくるものではありません。「誰それが研究していた何とか論ではあれがこうだと言っている」と前提になった研究や書籍がくどいほど書いてある。数えたわけではないですが、全体の3割くらいのページに引用元が記されていて、巻末の参考文献は12ページもある。読みやすいライトな論文を読んでいるような感じです。

しかしちゃんとしているが故に一般書籍としては読みづらさがある。まぁ如何に今までしょうもない本を読んできたかの露呈となるので、これ以上は恥ずかしくて書けないですが、オライリーの読み物らしさはありましたね。人に薦められるかと言ったら、本気で「組織を変えたい」と思っている人以外には薦められないですね。

 

3つ目は「結構難しい」です。一つ一つのトピックは難しくないですし、それぞれ嚙み砕いて読者にわかるように”内容”が解説されています。問題は言葉です。私は割とこういう海外の開発手法の本は好んで読むのでそこまでではなかったですが、一般的なサラリーマンが手を出すと読み切れないかもしれません。ぐだぐだ書くよりも実例を出します。本書で説明なしに使われる言葉です。

デリバリー、イテレーションインサイト、エンゲージメント、バックログ、WIP、インテグレーション、バッチ、ハードニング、デプロイ、マイグレーション、コンバージョン、ロギング

この言葉の意味や指すところがわからないと本書を読むのが苦痛になると思います。

本書のタイトルをもう一度見てみると、こうなっています。

「リーンエンタープライズ イノベーションを実現する創発的な組織作り」

特にIT系を示唆する用語がタイトルに入っていないので、一般のサラリーマンが「イノベーティブな組織を作りたい!」と思って手に取ると痛い思いをすると思います(普通のサラリーマンがオライリーコーナーに行くことは殆ど無いとは思いますが)。前述の固さと相成ってギブアップしてしまうのではないだろうか。

 

最初に戻ります。満点!とまで言えなかったのは、全体的な固さとちょこちょこカタカナ英語の意味がわからなかったところからの読みづらさです。こんな固い本だとは思ってなかったので心の準備が出来てなかったというのもありますが。

ただ内容は非常に面白かった。読み進むたびに考えさせられる良書でした。

 

ビビッときたところ

この時点で長いエントリになってしまいましたが、これは書いておきたいと思うポイントだけ引用します。

 

社会学者ウェストラムの組織の分類

病的組織は不安と恐怖が蔓延しています。人々は情報をため込んだり、政治的な理由から隠したり、自分を良く見せようと改ざんしたりします。

官僚的組織は自分たちの部門を守ります。部門にいる人は自分たちの「縄張り」を維持し、自分たちのルールを主張し、何でも自分たちのやり方でやろうとします。

創発的組織はミッションに集中します。「どうすれば目標を達成できるのか?」の質問に答え、高いパフォーマンスとそのために必要な事が何よりも優先されます。

私が勤めているSIerでは病的組織1、官僚的組織8.9、創発的組織0.1、といったところです。創発的組織は見たことがないですが、それなりの規模の会社なので無いことは無いはずという意味で0ではないだろうと。私のいる部署は超がつくほどの官僚的組織です。事前に根回しして、毒にも薬にもならない指摘を頂戴しないと話が先に進まない。そんな文化なのに、やれ働き改革だ、やれイノベーションだという耳障りの良い言葉が飛び交う。まずは自分たちの部署がどういう組織なのかを理解する必要性があるのだと思いました。

 

「プロジェクト」では、顧客に届けられた価値ではなく、仕事が時間・予算通りに完了したかどうかで人々を判断します。したがって、生産性は成果(アウトカム)ではなく、結果(アウトプット)にもとづいて計測されます。

開発者たちは、実世界で大規模に使えるようにすることではなく、開発マシンでコードを書きあげることに対して報酬を得るようになります。こうして私たちは働き過ぎと高稼働に報酬を与えてしまう持続不可能な「英雄文化」を作り出すのです。

会社や部署ごとに”俺たちのやり方”がありますが、結局下っ端は”俺たちのやり方”でやるべき作業をやることが仕事になっている。本来は予算制約の中で顧客が受け取る価値の最大化を図ることが求められるのに、いつの間にか俺たちのやり方を構成する作業をこなすことが仕事になってしまう。そしてその作業を如何に効率的に多くこなすかが評価の指標となっている。

100の価値を創る仕事に10時間をかけたら生産性は10です。今のうちの会社では(殆どの日本の会社もそうだと思うが)この仕事を9時間で済ますにはどうしたらいいかという話ばかりになっています。これって働き方改革だなんだという話が出る前からみんな頑張って取り組んでいたので、乾いた雑巾を絞る行為なんです。本物の改革を目指すならば、時間を削ることも大事ですが、結局のところは価値の量を増大させることに帰着します。当然そこには先行投資が必要になったり、仕事のやり方を変えたり、痛みが伴うことが多いですが、そうやって成果を求めていくことが重要なんだろうと思います。

 

(スタートアップ買収により)優秀な人材を獲得して病的あるいは官僚的文化に入れても、その文化が変わる事はありません。その人たちを壊してしまうだけです。

文化を意図的に変えるのは難しい事です。「文化は非常に安定的で、変革が困難」であり、「成功に至るまでの考え方、感じ方、世の中に対する認識など、グループが学び、蓄積したものを象徴するものが文化」だからです。

この部分を読んで頭をよぎったのは「組織の文化は金で買えない」ということ。買えるのはせいぜい文化を変革させるきっかけ程度のものです。

 

これらを達成してもらうまでは、問題の解決や機会の追求のために大規模な計画を開始するようなことはさせません。

・達成されるべき計測可能なビジネス成果を定義する

・成果に向かって計測可能な進捗を示せる、最少限のプロトタイプを構築する

・提案する解決策が顧客のために作られ、実際に価値を提供していることを実証する

ここはLEANの考え方が端的に書いてあるところだったので引用してみました。”計測可能”な進捗と成果を計る指標を定義し、最小限のプロトタイプを作って、価値を提供していることを実証する。

以前Yコンビネータ―の本を読んだ時も同じようなことが書いてありました。1週間の目標をたてて、測定すべき指標を追いかけて対策を立てていく。似たような考え方を持っている人の本を私が好んで読んでいるだけかもしれませんが、異なる本で同じことが書いてあると、やっぱりそうなのか、と思ってきますね。

 

従来の財務会計では、業績・キャッシュフロー・収益性比率を計測します。これらはイノベーションのために作られたものではないので、新しい製品や活動を抑制したり、殺したりする恐れがあります。

 これは本書を読んで一番ビビビッときたところです。

私が務めているSIerでは厳格に業績が管理されていますが、それはSI事業であっても新事業計画でも同じ方法で管理されています。SIerではSI事業がベースになっているので、業績管理もSI事業を前提に考えられています。予算や納期、品質、使う技術などを長ったらしい計画書にまとめ、計画通りに予算を使いながら納品して、計画以上の利益を上げるというものです。

ただ新事業計画なんて不確実性だらけなんだから通常のSI事業並みの精度で計画を作ることなんて無理なんです(ちなみにSI事業にしてもそんなに高い精度で計画作れないですが)。じゃあ不確実性に対する予算をまとめてプールしておけばいいじゃない、と思う人もいるでしょうけど、業績管理システムはそんな入力項目を用意してくれていない。私が勤めている会社では不確実性なんてものはそもそも存在しないことになっています。そんなものがプロジェクトにあるんだとしたら「なぜ見積もりをすることができたのか?」という話しになり社内でボッコボコにされる。プロジェクトには不確実性が存在することをみんなが認識しているのに、社内のルール上、業績管理システム上は存在しないことになっている。表面上は会社のルールに従い、実態は不確実性に対してみんながそれぞれ独自の対処をしているのが現実です。工程ごとに多めにバッファを積んだり、計画外の要員に内緒で作業をさせたりとかやり方は色々あるようですけど。

これってすごくアホらしいんですよ。不確実性を無いものとするってのは、ただの会社や管理職の保身から出る理屈であって、プロジェクトを管理して多くの利益を生み出したいというプロジェクト管理の基本的な考えからは遠く離れています。大抵の場合は何だかんだ上手く終われているやり方ではありますが、やはり新事業をやるうえでSI事業と同じような考え方ではうまくいかないのだと思います。

本書を読んで特に考えさせられたのはここで、明確に書いてあるわけではないですが「不確実性とお友達になる」というのがリーン開発の本質なんじゃないかと思いました。不確実性を溜め込めば溜め込むほど爆発した時の威力が高いので、ほどほどにガス抜きさせてやって大爆発させないようにうまく付き合っていくのが大事なのではと。

 

小さく分散した自律的なチームをたくさん作る事です。本当に分散した組織は、補完性原則に従います。つまり、基本的に決定というものは、その決定によって直接影響を受ける人たちが下すべきなのです。官僚組織の上位レベルは、下位レベルでは効果的に行えないタスクのみを実行すべきです。上位レベルは下位レベルを「補完」すべきということです。

この考え方は初めて知ったのでメモっておく意味で引用。

以前、読書感想文を書いた「SEの教科書」にあった「上流工程で作り込んだ問題をプログラマが対処する。原因を作り出したところには、具体的な苦痛は無い場合が多い」という話と似ているなと思いました。微妙に対象が違う話ではありますが、本書に書いてある内容はより積極的に上位下位のそれぞれの人たちが”すべき事”に注目している点が面白いと感じました。

 

予防的コントロールを間違ったレベルで実行すると、不必要に高いコストをもたらします。

・簡単に自動化できる単純なタスクなのに、他のチームに実行をお願いしなければいけない。

・リスクを理解できない人から承認をもらう必要があるが、その人が多忙なのでボトルネックになっている。

・完成してもすぐに時代遅れになる不正確なドキュメントを大量に作らなければいけない。

・大きなバッチをチームや委員会に渡した後、その処理や承認が終わるまで待たなければならない。

私はSIerで金融系システムを担当することが多いのですが、これ全部あてはまる。もちろんガッチガチの運用をしているので、不必要に高いコストと一言で片づけるのは乱暴でそれが必要になった背景もあるんですが、全項目に「そうだそうだ」と思う所がある。権限や責任を厳密に定義しすぎると遅くなる(コストがかかる)という話です。アウトプットしたいと思ったのは、権限や責任所在の厳密さと、スピードやコストはトレードオフであるということ。何かまずい事が起こった時に再発防止策が実行されますが、これによって責任所在が明確になり権限が絞られていく。これ自体が悪い事ではないですが、業務の全てにこの考え方を適用していくのは誤りだと思います。金融系でガチガチのチームにいると、この再発防止の考え方がスタンダードになってしまって、何でもかんでもこの考え方を適用していってしまう。何でそうなるかと言うと、責任範囲が厳密に決められれば他の事を考えなくていいので楽になるからです。こうなると段々と上で引用した病的組織、官僚的組織の色合いが濃くなっていき、創発的組織が持つ要素は失われていく。そしてこの考え方は”文化”としてそこで働く人の心に刻み込まれる。

なので金融系SIのようなガチガチな仕事をしている人は特にこの責任所在の明確化とスピード・コストのトレードオフの関係性は強く意識して、対象の仕事によって使い分けないといけないと思う。

 

改善には決して終わりがありません。

これは覚えておきたい良い言葉なので引用。改善に取り組んですぐに良い結果が出るばかりではないですが、当たり前のように続けていくことが重要なんだなと。

 

おわりに

ここまで書いてあらためて振り返ると、良い事がいっぱい書いてある本だったなという印象です。個人的には読みづらさも感じましたが、内容はとても良い。特に基本的な考え方の部分でMVP(最小限の効果を持った試作品)は覚えておきたい。少し不思議なのは、仕事の中で資料作りをする時は、時間をかけずに粗い骨子を作ってレビューを受けるんですが、新事業や新しい取り組みの話になるとその考え方がスパッと頭から無くなってしまうということ。会社の中で予算のルールがあるからという理由もあると思いますが、なぜだか試作品を作るという考えがスパッと消えてしまう。

後は文中にも書いた「不確実性とお友達になる」。不確実性は見えないものなので、蓋をして隠しておきたいと考えてしまいますが、うまく付き合ってコントロールしていくことが重要なんだと思いました。

 

このリーン開発はとても面白い手法だったので、今後少なくともエリック・リースのリーン・スタートアップは読んでみたいと思います。

 

おわり

 

MariaDBの設定テンプレファイルが見つからないの巻

MariaDBのコンフィグテンプレファイルが見当たらなかったのであれこれ調べた内容を書き残しておく。

 

長くなったので結論だけ先に。

  • MariaDB v10.3.2以降には、それまで設定例として含まれていたmy-small.cnfなどのテンプレファイルは無くなった。
  • 基本はデフォルト値で導入して明確に実現したい要件があればconfファイルに書き込む。


 

インストールした日:2018/07/15

データベース製品 :MariaDB 10.3.8  database server(現在時点で最新)

インストール方法 :レポジトリを追加してyum

OS:CentOS 7.4

稼働環境:Oracle Virtual Box

 

事象(困ったところ)

インターネッツの情報を参考にMariaDBをインストール、それから初期セットアップのためにcnfファイル(config)の設定テンプレをコピーしようとしたら、テンプレファイルが見つからなかった。以下のようなテンプレファイルが/usr/share/mysql/ ディレクトリ配下に存在することを期待していたが無かった。

my-small.cnf
my-medium.cnf
my-large.cnf
my-huge.cnf
  

もう少し詳しくやった事を書いておく

最初は公式の情報からレポジトリを追加してyumで本体をインストール

MariaDB - Setting up MariaDB Repositories - MariaDB


次に /usr/share/mysql にあるmy-large.cnfファイルをコピーして/etc/my.cnf.dディレクトリにserver.cnfの名前で保存する。が /usr/share/mysql ディレクトリにmy-large.cnfが見当たらなかった。

 

$ ls -l /usr/share/mysql/ | grep cnf
-rw-r--r--. 1 root root 3479 72 18:31 wsrep.cnf


インストールに失敗したのかしら?設定の考え方が変わったのかしら?と思い悩みながら、とりあえず今のコンフィグの状態を見てみる。

 

$ cat /etc/my.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

 

これはインターネッツの情報通り/etc/my.cnf.d配下のファイルをインクルードしておられる。/etc/my.cnf.d配下を見てみると、こうなっている。

$ ls -l /etc/my.cnf.d
合計 12
-rw-r--r--. 1 root root 763 72 16:34 enable_encryption.preset
-rw-r--r--. 1 root root 232 72 16:34 mysql-clients.cnf
-rw-r--r--. 1 root root 1080 72 16:34 server.cnf

 

インストール後のデフォルト状態のserver.cnfを見てみるとこう。

$ head /etc/my.cnf.d/server.cnf
#
# These groups are read by MariaDB server.
# Use it for options that only the server (but not clients) should see
#
# See the examples of server my.cnf files in /usr/share/mysql/
#

 

#5: # See the examples of server my.cnf files in /usr/share/mysql/

/usr/share/mysql/ ディレクトリにあるサンプルを見ろ、と書いてある。

 

ネットで調べた初期設定手順では/usr/share/mysql/my-****.cnf をコピペしなはれと書いてあった。server.cnfには /usr/share/mysql ディレクトリを見てみろと書いてある。

 

でも/usr/share/mysqlディレクトリにはテンプレコンフィグファイルは見当たらない。

findコマンドで検索してもmy-****.cnfというファイルはシステム上に無い。

 

 

インストール時に変なパラメータを渡したわけでもなく、素直にインストールしたしエラーも無く完了していたはずなんだけどなぁ。

 

あるはずのファイルが無いってのはやっぱり何かがおかしい...でもMariaDB自体は普通に起動できている...configのテンプレファイルだけ欠落しているとは考えづらい。

 

ここで「まぁ動いてればいっか。ダメならダメで後から何か症状が出るっしょ」と考えられないのが、金融系SEとして調教された人間の考え方である。

 

調査

テンプレファイルが見当たらないというワードで調べたが、ぱっと見た感じ「同じ状態になってオラ困ったぞ」という情報も見当たらない。

やっぱりインストールの時に何かやらかしてたのかなぁと不安になったが、以下の情報を発見。

mariadb.com

上記リンクから引用します。

The following my.cnf example files were included with MariaDB until MariaDB 10.3.1. 

Google翻訳
次のmy.cnfサンプルファイルは、MariaDB 10.3.1までMariaDBに含まれていました。

 

今回インストールした最新版(v10.3.8)では含まれていないということか.....

 

さらに調べたらこんな情報も発見

https://git.launchpad.net/maria/commit/support-files?id=7fee164faf8fce7be4ebe322d2178efd3d075eae

  

このローンチパッドというサイトは公式からリンクされているページです。以下のMariaDB公式サイトの中段あたり「LaunchPadリポジトリ」から飛べます。GitHubとの住み分けがよくわからんけど、公式からリンクされているちゃんとしたソース管理システムです。

MariaDB はどこでダウンロードできるの? - MariaDB Knowledge Base

 

LaunchPadのページから引用

Remove dated my-{size}.cnf files

The dates on the these files shows they are very dated. Following the sentiments of MDEV-9882 the default values are quite decent so lets remove this old stuff.

Google翻訳
これらのファイルの日付は、日付が古いことを示しています。 MDEV-9882の感想に従えば、デフォルト値はまともですので、この古いものを取り除くことができます。

 

ここから更にもう1つ情報を発見。上記引用文中にあるMDEV-9882でググって出てきたページ。どういうサイトかはわからないけど、製品の不具合なんかを投稿するサイト?

[MDEV-9882] Lack of config defaults in 10.1.13 - JIRA

 

コンフィグデフォルトファイルが無くなった!と登録された内容に対して、Sergei Golubchikという人(ググったところMariaDBのChief Architectという立場らしい。要は中の人)のコメントにこう書いてあった。

 

This is intentional. We set generally useful defaults in the server. Configuration files are for the end user to modify the defaults, not for us to set them.  

Google翻訳
これは意図的です。一般的に有用なデフォルトをサーバーに設定します。設定ファイルはエンドユーザがデフォルトを変更するためのものであり、私たちが設定するものではありません。

 

つまりちゃんとしたデフォルト値を設定しているから、基本はデフォルトで使って大丈夫よと、で変えたいところは変えてくれよと、そういうことなのねきっと。設定の考え方が変わったと。

 

MariaDBのセットアップ手順を紹介しているサイトのいくつかは、テンプレのcnfファイルコピーをせずに、キャラクタセットだけUTF8に変更しているものがあったが、あれが正解なのかもしれない。

 

よっぽどメモリ使用量を制御したいといった要件がなければ、デフォルト+文字コードくらいで運用を開始してもいいのかも。まぁ厳しい要件で環境構築することになっても結局はメモリの動きなんかはある程度動かしながら挙動を見ていくことになるので、いずれにしても最初はあまり細かいことは考えなくていいのではないかと思われる。  

 

ちなみにではあるが、実は途中で調べるのが面倒になり、過去のバージョンであるv.10.2系をインストールしてコンフィグテンプレ(my-large.cnf)を抜き出し、最新のv10.3.8に投入するという少々乱暴なやり方でやってみていた。

 

でもやっぱしそれじゃいかん、気持ち悪いと思ってちゃんと調べ直したのですが、過去バージョンに含まれるコンフィグテンプレファイル(my-large.cnf)を投入しても別にエラーが出たり起動しなくなるといった事はありませんでした。

 

目に見えるエラーや警告は無かったので、あのテンプレはあのテンプレで特定のシチュエーションには使えるもののように思えます。もちろん廃止されているパラメータなんかもあるかもしれないので、それは調査しないと危険ですけど、とりあえず動かす分には動かせると。

 

おわり

【読書感想文】「Yコンビネーター シリコンバレー最強の~」を読んで

読書感想文です。今回読んだ本はこちら。

 

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

Yコンビネーター シリコンバレー最強のスタートアップ養成スクール

 

本文中でYCと記載しているところはYコンビネータ―の頭文字をとった略称です。

 

この本を読もうと思った理由

ハードカバーの本は嵩張るのであまり好きじゃないんですが、Yコンビネータ―というスタートアップスクールの話は何かで聞いたことがあって、面白そうだと思った記憶があったので読んでみました。

あと作者が外国人で、翻訳された本というのも選んだ理由の一つです。海外で出版された本で、クソみたいな本は翻訳されないですからね。たまに内容がクソで商業的に成功しただけの本もありますが、Amazonの評価も高かったのでまぁ大丈夫でしょと読んでみました。

 

全体の感想

書評家みたいなことは書きたくないですが、本書は劇薬です。取扱い注意です。

ITの力を信じていて、でも普段の仕事ではそれを実感できなくて、世界のテック企業と自分のいる場所に隔たりを感じ諦めてしまっている方は、本書を読むと熱気にほだされる可能性があるため注意してください。文章を通して強い熱気を感じ取れる良書ですが、熱すぎて火傷の危険性があります。

 

繰り返します。良書です。私は今まで何冊もIT系やビジネス系の書籍を読んで来ましたがトップクラスです。

タイトルにある「Yコンビネータ―」はシリコンバレーにあるスタートアップ養成スクールです。ここでは熱意と能力とアイディアを持つ起業を目指した人間を集めてきて、投資をしつつ3ヶ月かけてスタートアップ企業として鍛え上げていくスタイルで運営されています。ドロップボックスやヘロク、エアビーアンドビーがここの出身です。あと有名どころの話としてハッカーニュースもYコンビネーターが運営しています。(https://news.ycombinator.com/

 

本書はそのスタートアップ企業を鍛える3か月間のドキュメンタリーになります。本書は最初の起業アイディアがうまくいかず参加者が悪戦苦闘している様子や、それに対するYコンビネータ―運営側からのアドバイスで構成されていますが、いずれも生々しいというか生きた言葉で綴られていてすごく惹きこまれます。パートナー(運営側のアドバイスする人)の方たちのシンプルでいて本質的なアドバイスは文章というフィルター越しに見てもとても熱いものを感じます。

 

本書内で「ポール・グレアムと話をするとみんな早くコーディングしたくなる」と書いてあるところがありました。話をしながら元のアイディアを磨いていくと、そこで話した内容を早く実現したいと思ってコードを書きたくなるという意味なんですが、私は本書を読んでいるだけで『何か作りたい』と思うようになるほどでした。

これは人の思考に影響を与えるほどの大きなエネルギーを持ったYコンビネータ―のパートナーがすげぇという事ももちろんありますが、そのエネルギーを文章越しでも感じられるように書いた著者も素晴らしいですし、更にそれを翻訳した人(Tech Crunchの翻訳チーム)も良い仕事をしています。

 

Amazonのレビューを見ると投資の世界の人たちが多く読んでいる本のようですが、これは何かを為したいと思っているエンジニアこそ読むべき本です。すごくエネルギーが湧いてきます。またスタートアップをやりたいと思っている人や実際にやっている人には本当に身になることがいっぱい書いてある本ですので、オススメできます。

 

次項に本書を読んで心に響いてきたところを引用しながら書いていきますが、「ここだけは!」という二点だけここに書きます。

YCの教義

コードを書いて顧客と話せ、早く出してやり直せ、数字で測れる週間目標を決めて集中しろ。

スタートアップ企業の大切なところとして「YCの教義」と紹介されていた言葉です。これはスタートアップだけではなく、日々の仕事や生活の中でパフォーマンスをあげなければならないあらゆる時に重要なことだと思います。基本的なやるべきことをやって、ユーザとコミュニケーションをとって、それを早く出して繰り返しやり直せと。そして計測可能な目標を定めて集中してやる。何だろう書いてあることはよく言われることなんですが、たぶん本書の読後にまだ熱気が残っていてそれにあてられてるのかもしれません。

 

もう一つ。

創業者があきらめない限りスタートアップは失敗しない

これも良い言葉。上に書いた教義と合わせて、諦めずにコードを書き続けてユーザと対話し続けろ、ってことですね。スタートアップの成功率というのは極めて低いです。そういう上手くいかないことが大半という性質を持つものは、うまくいくまでやり続けることが重要。ギブアップするまで失敗ではないというメッセージです。

 

私は本書はすごく良い本だと感じましたが、なにをもって良い本だと思ったのか考えてみました。

1つは上にも書いた文章越しに伝わってくる熱気、エネルギーです。ドキュメントだからか、参加企業の苦悶やYCパートナーのアドバイスが生々しく感じられます。この本を読んでいると本当にコーディングをしたくなる。目標が見えなくなって無気力になった時のカンフル剤としてずっと手元に置いておきたいと思える本です。

もう1つは、スタートアップの考え方を学べたことです。上で書いたYCの教義なんかもそうです。この教義だけを見ると割とどこかで言われているような内容なんですが、これがドキュメント形式の本書を通して見ると見え方が変わってくるんです。うまく表現できませんが、読めばわかるとしか書きようのない説得力があります。

あとは本書を読む前の私の考え方に近い部分があって、読んでいて心地よかったというのもあります。ひょっとするとこれが全てなのかもしれません。特にYCがハッカーを好むという点です。新しいものを作る時に、その人たちがその技術に精通していない、ようは自分たちでモノを作れないというのはダメという話です。本書を通してYC参加者はハッカーであることが望ましいと繰り返し書かれていて、この点は本当に読んでいて心地よかった。

 

良い本である理由をうまく挙げられていませんが、まぁ良い本ってのはだいたいそうなんですよ。良い事がいっぱい書いてあってダイジェストにまとめられないんです。よほど斬新で正しい内容が簡潔に書いてあれば、「AはBである。と書いてあった。目からウロコである」と感想を書けますが、良い本は「AはBだし、CはDだし、・・・・」と永遠と素晴らしい内容が続いて、しかも一冊の中でそれが複雑に絡み合いながら説得力を増していくので、どうにもまとめられないわけです。

本書の感想から少し逸れてしまいましたが、それでもこの素晴らしい本の内容は紹介したい。次項に「これキタ!」という箇所を引用して紹介します。部分的に抜き出すと、それだけではどうにも薄っぺらく見えてしまうところはありますが、私は書評家のような本を評価する言葉を持っていないのでこうするしかない。

 

「これキタァ!」と思ったところ

「これキタ!」ポイントを引用しながら紹介します。

 

スタートアップの本質は新しい会社だという点には無い。非常に急速に成長する新しいビジネスでなければいけない。スケールできるビジネスでなければいけないんだ。そうでなければ、それはスモールビジネスの開業であってスタートアップの企業ではない。

うまく言葉で言い表すことができなかったんですが、本書を読んで言語化できました。私が勤めるSIerで以前ソリューションサービスコンテストというものが社内で行われたんですが、その時にニッチなハードウェア技術を持っているチームが、「自分らの技術を使って社内スタートアップ企業を作りたい」と言っていて「なんか違うよなぁ」と思っていたんですが、これですね。急速に成長、スケールできるビジネスでないから、しっくり来なかったんですね。

 

スタートアップのアイディアを生み出すための3か条

1.創業者自身が使いたいサービスであること

2.創業者以外が作り上げるのが難しいサービスであること

3.巨大に成長する可能性を秘めていることに人が気づいていないこと

これはスタートアップだけの話ではないですね。SIerに勤めていると新事業の提案というタスクが突如与えられることがありますが、これは覚えておきたい。特に3番。

 

他の連中より真剣に考え抜いた点だけが優位性になる

これもスタートアップだけの話ではない。IT戦略やシステム提案の時に思い出したい言葉です。現実には企業勤めだと考え抜くための時間が与えられないケースが殆どですが、「この部分は考えるのが大変だから、考えた分だけ自社の優位点になる」という発想は忘れたくない。

 

最初にリリースしたプロダクトが赤面するほどひどい出来でないというのなら、そのリリースは遅すぎたのだ。

巧遅拙速のバランスの話ですね。私は巧遅の方に傾倒していて、意識しないとすぐに忘れてしまう。スタートアップでは拙速側に倒れている方が優れているようですが、完全に私に向いていない世界。。。改めて拙速の意識づけができました。

 

目標設定が効果があるのは、集中力が養われるからだ。スタートアップではやるべきことは毎日無数にある。しかし毎週成長目標を決めたら、その目標を達成するのにどうしても必要な仕事はどれか、適切な時間の使い方を必死で考え抜く必要がある。

”毎週の”成長目標というのは斬新に感じた。SIerや一般企業に勤めていると半年や1年単位の目標を作ることはよくある(大抵機能しない)が、週間目標というのは発想が無かった。もちろんスタートアップの話だから手持ち資金が底をつく前に成長しないといけないということであろうけども、SIerや一般企業の個人目標の話とは次元が違う速度が求められるということか。人の成長速度とビジネスの成長速度を比較してもしょうがないかもしれないですが、シリコンバレーのスタートアップでは1週間の単位で成長度合いを測るのに対して、日本の一般企業では26週(半年)ないし52週(1年)で測ると。しかも国内企業では多くのところで儀式化されているレベルですので達成への情熱も段違いに低いわけです。こういうところから地力の差が出てくるんだろうなぁと思いました。

 

成功するスタートアップはミートアップに行かない。アドバイザーたちと話すために走り回らない、ひたすらコードを書き、顧客と話す。

すごく納得したところです。スタートアップの本質はそれまでに無かった何かを作って市場に出すことです。”作って出す”というのが最も基本的で本質的なところですから、泥臭く時間を掛けてでもやるべきことという話です。たまに「何よりも人脈と繋がりが大切マン」と知り合うことがありますが、彼らは本当に薄っぺらい。あーなったら終わり。

 

流行語や使い古されたマーケティング用語は使うべきではない。「私たちはこの市場を破壊するつもりです」といった紋切型のフレーズは、グレアムにとっては素材写真のようなものだ。「ほかのスタートアップのプレゼンにも使えるようなスライドは使うな」と彼は言う。

これスタートアップだけの話じゃないですよね。この部分を読んで思ったのは、日本のSIerの会社紹介ですよ。あれは本当に酷いものだと思います。たぶん会社名だけ変えればそのまま使えますからね。オリジナリティーなんか欠片も無いくせに、面接では「なぜウチの会社なのかね?他社と比べてなぜウチ?」と聞いてきます。バカの極地です。

 

1ビットだけでもいいから世界を進歩させるようなプロダクト

これは言葉が気に入りました。どこかで使おうと思います。 1ビットしか世界が進歩しなくてもそれができる状態になったプロダクトはさっさとローンチしろ、というお話で使われていた言葉です。

 

うまくいかなかった点も多かったが、これはいつものことだ。うまくいかなかった点はこれから直していけばいい。どうせ私は死ぬまでうまくいかない点を直し続けることになるんだろうが。

カッコいいなと思った言葉。これもいつか使いたい言葉としてここに記録しておく。こういうことを言えるおっさんになりたい。 

 

ソフトウェアが世界を食う

今やソフトウェアはあらゆる産業のバックボーンとして普遍化している。いわばソフトウェアが世界を食ってしまおうとしているのだ。

抽象的でフレーズが気に入ったというのもありますが、正に世の中がこういう風に進んでいるなと私は思っています。他のエントリでも何回か書いていますがITシステムの中で真の価値を提供しているのはアプリケーションです。言い方は悪いですが、インフラはツールであってユーザに大きな価値は提供できない。世界を食ってしまうほどの巨大な何かはアプリケーション(ソフトウェア)だと思っています。インフラはインフラで面白いんですが。

 

本人が勉強熱心であれば、ウェブやモバイルの複雑なアプリケーションを驚くほど短時間で完成させることができる。ソフトウェア・スタートアップを起業してベンチャーキャピタルの門を叩くために、マイクロソフトやオラクルのような大企業で5年、10年と下積み生活をする必要はまったくない。

こういう言葉ですよ。前項で劇薬だとか書きましたが、生きた言葉で綴られたこういう本で、「大企業で下積み生活をする必要はない」とか書かれていると、「そんじゃ俺もやったろやないかい!」って思ってきちゃうんですよ。

 

おわりに

何回も書きましたが、良書です。本当に手元に置いておきたいと思える本です。自分で言うのもなんですが、私は割と悲観的、否定的に物事を考える癖があって大抵の本は見下した状態から入るんですが、今回は完全に覆されました。私は今までビジネス系の本は50か100かくらい読んでいると思うんですが、トップクラスです。

 

このエントリを上からここまで読んでくれた方は、狂信的とか信者かと思うかもしれません。私もこのエントリを書きながらプレビューを見たらそう思えました。ちょっと気持ち悪いくらいに。でもそれだけ良い本なんです。

内容的、分量的に誰にでも薦められる本ではありませんが、スタートアップの世界を覗いてみたい方や実際にスタートアップとして走り始めている方、SIerの中で疲弊して無気力化してしまった方は是非読んでおいた方がいい本です。

 

おわり

ベネッセ情報流出事件の地裁判決が出たニュースについて

先週、2014年に発覚したベネッセ社の情報流出事件の続報が報道されてました。最近読んだ本と関連のあるニュースだったので脳内整理も兼ねてだらだら書いていこうと思います。

 

私が読んだニュースがこれ。

www.nikkei.com

 

で、最近読んだ本のレビューがこれ。

 

ニュースの概要

ベネッセ社の個人情報流出事件で被害のあった180人が計1478万円の損害賠償を求めた訴訟を起こし、東京地裁判決が出た。「慰謝料が発生するほどの精神的苦痛があるとは認められない」として請求は棄却。原告側は控訴の方針。

  • 原告側の主張

「流出情報をもとに営業電話やDMを受けたり詐欺などの犯罪に利用されるリスクがあり重大な不安感がある」

  • ベネッセ側の反論

「勧誘行為があったとしても、日常的にありふれたものだ」

  • 判決

裁判長はベネッセ側に対策や監督を怠った注意義務違反を認定。一方で氏名住所などの情報が思想信条や性的指向などの情報に比べ、他者にみだりに開示されたくない私的領域の情報という性格は低いと判断した。また実害が生じていない事、お詫びの文書と500円相当の金券を配布した事を考慮して、原告側が求めた損害賠償を認めず。

  • 判決を受けた弁護士のコメント

「プライバシー侵害を認めながら損害が生じていないということは矛盾だ」

 

考察

損害賠償の金額

180人が1478万円の損害賠償を求めているので、一人当たりの平均は82,000円ほどですね。流出した内容をあらためてみてみると以下の通り。

 

  • 個人に関する情報

 保護者と子供の氏名・性別・生年月日・続柄・出産予定日

  • 連絡するための情報

 郵便番号・住所・電話番号・FAX・メールアドレス

 

 参考:事故の概要 | お客様本部について | ベネッセお客様本部

 

個人情報流出における賠償(和解)金額の相場はどれくらいかと調べてみたところ、みずほ中央法律事務所というところが一覧で整理して公開していたので引用。

  • 秘匿性=『低』レベル→500円〜1000円

  住所・氏名など

  • 秘匿性=『中』レベル→1万円

  クレジットカード情報、収入・職業に関する情報

  • 秘匿性=『高』レベル→3万円

  スリーサイズ、エステの施術コース

 【個人情報漏洩・流出の民事的責任(賠償金額)の実例と基準や相場】 | 企業法務 | 東京・埼玉の理系弁護士

 

住所や氏名、電話番号などの情報は直接犯罪に結びつきにくいという性格からか500~1,000円コースですね。

クレジットカードや収入、職業はお金に関連して直接的な損害に結びつきやすいため1万円コース。

センシティブ情報(機微情報:思想信条、性的指向、健康情報、DNA情報、その他好き嫌いに関する情報)は3万円コース。

 

今回のベネッセ社の事件では流出した情報の秘匿性が低いので500~1000円コース。過去の賠償例に沿った妥当なところじゃないのかというのが、傍観者としての私の意見です。

とはいえ、仮に自分が被害者になったと考えると500円じゃ安いというのは確かにそう思う気がします。

 

子供と大人で個人情報の価値は同じか

上にリンクを張った元記事では詳細が書いていないだけかもしれませんが、一人当たり8万円を求める原告の主張は弱いと思います。

 

原告側

「流出情報をもとに営業電話やDMを受けたり詐欺などの犯罪に利用されるリスクがあり重大な不安感がある」

ベネッセ側

「勧誘行為があったとしても、日常的にありふれたものだ」

 

過去の事例では、原告が主張するような不安感に対して「500円で勘弁してくれ」という趣旨でお詫び金が発生しているわけです。この事件が過去の事例とどう違うのかという点で争わないと500~1,000円コースに落ち着いてしまうのは明らかです。

 

例えば、子供の情報が中心だからリスクに晒される期間が長いとか、子供個人に焦点をあてて自分で個人情報をコントロールできない子供の情報を流出させたから今までよりも重い事件であるとか、そういった主張をすべきではないのかと。してるのかもしれませんが。

 

個人情報についての考え方として、自分の情報をコントロールする権利というのがあります。個人情報に変更があったらそれを訂正する権利があるというやつです。

この権利のことを考えると、自分の情報をコントロールする権利が認められているならば、自分の情報をコントロールする判断力の無い子供の情報というのは、大人の個人情報よりも重く見られるべき、社会的に守られるべき情報だと思えます。そう考えると情報を主体的に管理・制御することのできない子供の個人情報が漏えいしたんだから、もっとお詫び金出せよという主張もありだなと思います。

 

外部犯でも内部犯でも同じなのか?

この事件は内部犯によるものなので、外部から攻撃されて情報流出した他の事件と比べ、より管理責任が問われても仕方のないことだと思います。

外部から攻撃される穴となる脆弱性を全て完全に塞ぐというのは相当難しいです。既知の脆弱性になるべくタイムリーに対応していくのが精一杯というのが多くの企業の実情です。ここは突き詰めていくと際限なく金がかかるところなので、状況にもよりますが企業が被害者顔をして世間が納得する場合もあるにはある。

しかし今回の事件は金に困った内部の人間による犯行なので、これを止めるために現実的に出来ることは割とあったんじゃないかと思います。そもそもUSBでスマホを接続しても情報を抜けない仕組みを作るとか、統制のとれる体制で運用すべきだったとか、監視を強めるだとか、いろいろと言われていることですが現実的にやれることはあった。けどベネッセはそれを怠ったと。

 

感情的な話

冒頭にリンクを張っていますが、私が最近読んだ「あなたのデータ、お金に換えてもいいですか?」にこんな事が書いてありました。(いま手元に本が無いので記憶から引用)

不幸にも幼い子供が亡くなってしまったとして、生きてれば7歳になるという時には小学生向けのDMが届く。その後も中学校入学、高校入学、成人式、新社会人と色んなタイミングでDMや営業・勧誘の知らせが届くわけだが、親はそれを見るたびに子供を亡くした事実を思い出し涙を流す。

 

これは確かに辛い。そして情報流出が無ければ「(子供が亡くなったので)もう送らないで」と連絡するだけで傷をえぐるDMは送られなくなるはずだったわけです。しかし裏で色んなところで情報が売買されもう止めることは出来ない。まぁ引越して電話番号変えれば止められはしますが。

 

これは個人情報全体の議論からするとレアケースですが、本質的なところを考えると、子供の個人情報は大人の情報と比べて影響範囲が違う、異なる性質を持っているというお話なんだと思います。

 

日本語でググってみた感じだと、子供の個人情報について特別に規定した条約や法律は無さそうです。このあたりも裁判の結果に影響しているのかもしれないですね。

 

おわりに

今回は直近で読んだ本に関連するニュースがたまたま報じられたため、思う所を含め書いてみました。このエントリを書きながら興味深いなと思ったのは、子供の個人情報に関する取り決めが(たぶん)無く、大人と同じ枠組みで考えられるということでした。

とは言ってもまだ控訴するという話なので裁判がどうなるかわかりませんが、そのうちEUあたりで同じような事件が起こって莫大な賠償額の裁判が起こりそうな予感もしています。

”個人情報”はEUGDPRにしろ国内法にしろ曖昧さが残る部分があるので、ちゃんと考えないといけないなぁと思いました。

 

おわり

麻雀のアガリ判定アルゴリズムで苦戦したこと

ひょんな事から麻雀で使う清一色チンイツ)のツールを開発することになりました。

実際に手を動かしてアプリを作っていったら、これが結構大変だったので時間がかかったところの考え方だけでもインターネッツの世界に書き記しておこうと思います。

 

 

何が大変だったか

ガリ判定のアルゴリズムです。インターネッツで情報公開している先駆者の方の情報を参考にしましたが、なかなか判定し切れなかったです。

 

何を引いてきたかはとりあえず考えないで、以下の手牌のアガリ判定を考える。

f:id:kwnflog:20180612114946p:plain

麻雀経験者からすると清一色の手の割に簡単ですね。

f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115640p:plain

頭の中でこう分解できれば和了

ただこの分解を実装しようとしたら意外に難しかった。

 

インターネッツで調べながらコードを書いてはチェケラしていったのですが、どうも全パターンは判定できない。ネッツで調べたところ大体以下の手順でした。

①頭候補を探し順に試行していく

刻子候補を探し面子確定させる

③残った手配を順子に分割できたらアガリ

 

①の頭の確定のところはたぶん正解だと思います。特殊形を除いて頭は必ず1つ必要なので先に確定させた方が試行回数が減少するはず。

で、次いで3枚以上ある牌で刻子を確定させ、残りの手牌は順子を構成するものとする。

 

順子だけの場合は端から判定して抜き出していけば、和了の時は問題なく全部抜き取れる。ただ刻子や頭と組み合わさった時が曲者なんですね。

 

上の例だと三萬と四萬が刻子候補ですが、何も考えずにこれらを面子確定させてしまうと、アガリ形とはならない。

f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612121356p:plain  f:id:kwnflog:20180612121550p:plain

 

じゃあ、とばかりに順子から面子確定させていくと、

f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612121848p:plain

 

やはりアガリ形をうまく判定できない。

 

大抵の清一色手牌だったり、清一色以外の手牌ではこういう事は発生しません。刻子と順子が同じ牌を使う場合のみに発生しうるレアケースですが、私が書いていたのは清一色で遊ぼう系アプリだったためこれは避けられない問題。

 

解決法ー刻子を組み合わせで考える

この手の場合どう考えればいいかというと、刻子候補のうち三萬のみを刻子として確定させ、残りを順子の組み合わせと考え面子確定させていくが正解です。アルゴリズム的な話にすると、

 

①牌種ごとに枚数をカウントする

②2枚以上ある牌種を頭候補として、各候補に対して以下を繰り返し

③頭を仮確定させ手牌から抜く

④3枚以上ある牌種を刻子候補として、その組み合わせを求める

刻子組み合わせ候補に対して以下を繰り返し

⑥対象の刻子を面子仮確定させ手牌から抜く

⑦残った手牌の端から順子を抜く

⑧全ての牌を抜き取れれば和了

 

もう少し具体的にみていきませう。

頭はアガリ形の中に必ず1組存在するため、順番に2枚以上ある牌を試せば問題はないかと思います。 ここでは上記手牌で八萬を頭候補とした場合を考えます。(もちろん3,4,5,6萬を頭候補としてアガリ判定を行い、全て失敗し八萬に到達した状況です)

この状況。

f:id:kwnflog:20180612131633p:plain  f:id:kwnflog:20180612115640p:plain

ここで上記④の刻子の組み合わせを求めます。

刻子自体は三萬と四萬がありますが、その組み合わせなので、

刻子無し)(三萬)(四萬)(三萬&四萬)の4パターンが存在することになります。

 

仮に刻子候補が3つあればそれぞれを刻子とするか否かの二択が3つなので、2の3乗の8パターン、刻子が4つであれば2の4乗の16パターンを考えることになります。刻子が4つであれば四暗刻なので別に四暗刻判定を入れてもいいかもしれません。

 

ではまず八萬を頭、刻子無しと考えて残りを順子分解してみましょう。

 f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612121814p:plain  f:id:kwnflog:20180612132420p:plain  f:id:kwnflog:20180612115640p:plain

ノー和了

 

次は三萬のみ刻子として考えた場合、こうなって、

f:id:kwnflog:20180612132758p:plain  f:id:kwnflog:20180612115620p:plain   f:id:kwnflog:20180612115640p:plain

こう。

f:id:kwnflog:20180612115610p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115631p:plain  f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612115640p:plain

和了

 

最後まで見てみましょう。次は四萬のみ刻子とする場合。

f:id:kwnflog:20180612133103p:plain  f:id:kwnflog:20180612121356p:plain  f:id:kwnflog:20180612115640p:plain

ノー和了

 

三萬と四萬を刻子とする場合、

f:id:kwnflog:20180612133226p:plain  f:id:kwnflog:20180612115620p:plain  f:id:kwnflog:20180612121356p:plain  f:id:kwnflog:20180612115640p:plain

これもノー和了

 

結局のところアガリと判定することができたのは、三萬のみを刻子と考えて残りを順子と見做した1パターンだけでした。

一盃口に頭がくっついた11223344であったり、それを含んだ更に複雑な形だと複数のアガリ形が存在し、アガリ役や点数に影響が出るため途中でアガリ形が求められても最後まで処理を継続する必要があると思います。

例えば、11223344456789 という形であれば頭を一萬とするか、四萬とするかで一気通貫がつくかが変わってしまうためです。

 

 

他の先駆者の方が公開している内容を見ると、頭を最初に抜き出すのは殆どの方が一致しています。

その後のアプローチに結構やり方の違いがあって、頭→刻子→順子と抜き出す人だったり頭→順子→刻子で抜き出す人がいます。

 

私がたどり着いた結論は以下。

抜き出す順番ではなく、抜き出す刻子の組み合わせが重要

刻子として抜き出せるけど、抜き出さないケースを考慮する

 

ここでは刻子の組み合わせに注目していますが、反対に順子の抜き出しの組み合わせを考えても同じようにアガリ判定ができるはずです。

ただ、

  • 刻子のほうができにくいので、数が少なく組み合わせを考えるのに適している
  • 順子は抜き出した面子によって、その後抜き出せなくなるケースが存在する

という理由で刻子の組み合わせを考える方が効率が良いと考えています。

 

例えば手牌中に以下のような形があったとして、

f:id:kwnflog:20180612140217p:plain

ここから取り出し得る順子は以下の4パターンがあります。

f:id:kwnflog:20180612140337p:plain f:id:kwnflog:20180612115610p:plain f:id:kwnflog:20180612121814p:plain f:id:kwnflog:20180612115631p:plain

ただし123を抜き出した場合は、234と345は取れなくなります。234か345で面子を作ると他の面子を作ることはできないです。

このように抜き出した面子によって、その後抜き出せる面子が変わってしまうため、事前チェックが必要となりコードとして冗長になってしまいます。

刻子であればどのように刻子面子を確定させようと、他の刻子面子には影響が出ません。

 

 

おまけ.組み合わせを考えないと判定できない牌姿一覧

清一色のアガリ形から「抜き出せるけど抜き出さない」をしないとアガリ判定ができない手牌を並べます。

この手牌は単純に刻子を全部抜き出すとか順子を全部抜き出すといった方法ではアガリ判定ができないのでテストに使えると思います。というか複雑な形が多いのでこの手牌を頭の中で瞬時に分解できれば清一色上級者と言えるかもしれません。

 

'23333444556688', '22333456667788', '22344445556677', '11123334445577', '22223333444556', '11222345556677', '22333344555667', '11333445566678', '11122223334455', '22555566677788', '23333444555566', '22566667778899', '22444567778899', '22444455666778', '12222333445599', '22223344455688', '11123334445555', '33344555566678', '44455667778999', '11112233344566', '11444556667778', '11225566778899', '44445555666778', '12222333445588', '22234555667777', '33345666778888', '11122334445666', '22223334445588', '33345666777788', '11122334445677', '22233345556677', '11223344667799', '11123444555566', '44455567778899', '33444455666778', '22234445556666', '11222334455567', '44456667778888', '11123344455688', '11222334445556', '11444566777889', '11123334445588', '11333344555667', '22234555666677', '11122333444566', '44566667778899', '55666677788899', '33334455566799', '11555667778889', '11333455566677', '22223344455699', '33344445556677', '33555566777889', '22233445556799', '11122333444588', '11122223344456', '22223334445599', '34444555666677', '44445566677899', '55556666777889', '22444556677789', '11122333444599', '11112223334499', '11334455667799', '33345566677899', '11123344455666', '33334445556699', '33444566777889', '11122233444556', '11666677788899', '33344555666788', '22233334445556', '11123334445566', '11566667778899', '11224466778899', '11224455667799', '22444556667778', '12222333444455', '22234445556677', '33444455566677', '22333344455566', '11123334445599', '33444556677789', '11122333444577', '11112223334466', '11122223334445', '22234455566667', '22223334445577', '11223355668899', '11444455666778', '11123444556688', '44555667778889', '11122334445699', '11333456667788', '11112223334488', '55566667778889', '11233334445566', '11334455668899', '33345556667799', '22233344555667', '34444555667799', '11223344557799', '11224455667788', '22333445556667', '22234445556688', '22234444555667', '11224455668899', '22234555667799', '11112233344599', '33344445556667', '44445566677888', '11112223334477', '55556677788999', '11112233344588', '11112222333445', '22234455566799', '11123444556699', '33555667778889', '22333445566678', '33566667778899', '12222333445577', '22444566777889', '22233444455567', '44455666677789', '22555677788899', '44455556677789', '44555566777889', '22233445556788', '11224455778899', '44455566777889', '33444567778899', '11444566677788', '44456667778899', '22335566778899', '33334444555667', '11223344668899', '22234455566777', '44456777888899', '33344556667899', '44455556667778', '11223344557788', '33666677788899', '11112233344555', '55567778889999', '11444455566677', '11455556667788', '33345556667788', '33344456667788', '22233444555699', '44555566677788', '11222233444556', '11122333344456', '11344445556677', '11222344555667', '44445556667799', '33555677788899', '22233444555677', '11123344455699', '11333445556667', '44456677788889', '22333455666778', '33455556667788', '11123344455556', '11334466778899', '33555566677788', '11444556677789', '44456677788999', '11122234445566', '22555667778889', '22455556667788', '33444556667778', '22233445556777', '33344445566678', '11555566677788', '33344555666799', '22555566777889', '33345566677778', '33345556667777', '33334455566788', '22233334455567', '22234445556699', '33334445556688', '11333344455566', '44455556667788', '33345566677888', '11123333444556', '33344556667888', '11222344455566', '33345555666778', '22234455566788', '22333455566677', '44455666777899', '23333444556699', '11333455666778', '11223344558899', '11444567778899', '11335566778899', '33334455566777', '45555666777788', '44456666777889', '11123344455677', '33444566677788', '11123444556666', '22444455566677', '22223344455666', '22233444555688', '11222233344455', '44456777889999', '44555677788899', '22444566677788', '22666677788899', '22233334445566', '44666677788899', '11122334445688', '22334455668899', '33344455666778', '56666777888899', '11555566777889', '55566667778899', '11112233344577', '22223344455677', '11555677788899'

 

おわりに

この問題は考えていて結構おもしろい問題でした。どう分解するアルゴリズムなら漏れなくアガリ形を捉えられるか、いい感じの難易度とコーディングの自由さがあって楽しめました。

 

色々やっているうちに結局のところアガリ判定はインデックス法(全アガリパターンの配列とマッチングする方法)を使うことにしましたが、その他の機能で部分的に生きてくるモジュールになるので書ききりました。たぶんシャンテン数を計算する機能で使うはず。

 

おわり

 

【読書感想文】「あなたのデータ、お金に換えてもいいですか?」を読んで

読書感想文です。今回読んだ本はこちら。

 

プライバシー大論争 あなたのデータ、「お金」に換えてもいいですか?

プライバシー大論争 あなたのデータ、「お金」に換えてもいいですか?

 

 

この本を読もうと思った理由

2018年6月現在、一般報道におけるITニュースで「データ」というキーワードが非常に多い印象を受けています。データ系記事も大きく2つあって、1つはビッグデータ。これはAIやIoTとの組み合わせで純粋なテック系の記事です。もう1つは個人情報に関するデータ系記事です。

代表的なのはFacebookが叩かれまくっているやつとか、

Facebookがゴタゴタしてる問題をいったん整理して、今起きていることを知ろう | ギズモード・ジャパン

中国企業に委託していた年金データのやつとかです。

年金制度を危機に晒す「年金機構」の実態…国民の個人情報を中国に漏洩、年金過少給付 | ビジネスジャーナル

 

およそ1年前の2017年に個人情報保護法が改正されましたし、先月(2018年5月)にはEU一般データ保護規則GDPR)も改正されました。「個人情報」とか「データ」という分野がホットなうちに一冊くらい本読んで勉強しておくかと思い適当に選んだのが本書でした。適当とは言っても日経コンピュータの記者が書いているので大外れは無いだろうと。

 

全体の感想

定価1,600円の本としては残念でした。表紙には「プライバシー大論争」、帯には「プライバシー論争を決着させる」とありますが、特に異なる意見がぶつかり合っていることもなく、最終的に何かが決着したとも読み取れませんでした。何かこう有りものの文章や、取材したけど形になっていない文章を集めてきて「釣り」的なタイトルで出版したような印象があります。800円くらいの新書で出版するなら納得かなという印象です。

 

内容としては、第一章でそもそもプライバシーとは?日本でのプライバシーってどう概念づけられてきたのかという歴史的な側面を見ながらプライバシー自体を定義しています。第二章では主に国内のプライバシー事件の紹介、第三章で個人情報保護法の成り立ちと改正についての内容、第四章で「データ立国になるには」という提言で締められています。一章と二章、三章と四章で著者が変わります。

 

一章と二章はよくまとまっていて読みやすかったです。歴史的な側面から直近のプライバシー事件まで網羅されているので、ここを読むだけで国内におけるプライバシーという概念がどう変化してきたか大よそのところは掴むことができました。

またプライバシー事件の発端が利用者による「(勝手に情報を売買されて)気持ち悪い」という感情から始まるという話は興味深かったです。何を以て個人情報となるか明確な線引きが無いため、利用者がどう感じるかによって炎上してしまうというのは覚えておかないといけないなと思いました。

二章でピックアップされている事件のうち、Suica事件については、乗降データから乗車駅と降車駅の組み合わせで個人の特定が出来る場合があるという話が興味深かったです。確かに乗車駅と降車駅の組み合わせや、時間帯を組み合わせると個人を特定することはそう難しくないなと思いました。本書ではデータの性質を個々に考えて、何が個人情報にあたるか、しっかりと考えることが必要だと書かれており考えさせられました。

 

三章と四章は、個人情報保護法や海外のプライバシー保護の仕組みに言及しているからというのもありますが読みづらかったです。目次や項や節の切り方がよくないのだろうと思いますが、順に文字を追って行っても「これ何が言いたいんだろうか」と思うことが結構ありました。率直な感想として三章四章は本書タイトルから読者が知りたいであろう内容を書いたというより、著者が書きたいことを書いたように感じました。

この三章四章では読んでいて怒りを感じた部分すらありました。個人情報の「保護と活用」はゼロサムゲーム(どちらかを獲ればもう一方を損なう)ではなく、プラスサム(活用するなら保護しなければならない)なものだと書いています。三章の途中に「次章で詳述する」と書いてあり、期待感を持たせてきますが四章に書いてある内容はごく当たり前のものしか記述されていなく、肩透かしをくった感がありました。

私は本書を読みながら、保護の度合いと活用の度合いが比例するような具体例やロジックを期待していましたが、「保護すれば信用が高まってよりデータが集まる。データが増えれば分析の信頼性が上がる」としか書いていませんでした。CCC社のTポイントの例が挙げられていますが、CCC社が利用規約の変更やオプトアウト(後から個人情報の提供を拒否する仕組み)の方法を変えたという例しかなかったです。CCC社の利用規約やオプトアウトの方法が変わったことで、「なら利用しよう」と考える人がどれだけいるのだろうか。当然社会的な要請として、利用者に歩み寄った優等生の例としては適当だと思いますが、「保護を強化すればデータが集まって活用の幅が広がる」というロジックに適した具体例だとは思えませんでした。三章から引っ張ってきているんだから、読者が知りたい内容を提示するのがフェアなんじゃないだろうかと思いました。

 

個別にビビッときたところ

(なぜプライバシー情報を)勝手に売買されることを、「気持ち悪い」と考えるようになったのだろうか。そこを理解できない事には誰もが納得するプライバシー保護のルールを作ることはできそうもない。

プライバシー情報は何がどうなったらダメという具体的な線引きが無いため、どうしても「気持ち悪い」という感情が発端となって問題が大きくなっていってしまうという話は興味深かった。これは気を付けないといけないなと思う反面、主に日本人が経営する企業で個人情報による炎上事件が発生しているわけなので、日本文化とか日本人の心が分からない海外企業はもっとキツイんだろうなと思いました。

 

英米で発達した「プライバシー」という概念が、日本に持ち込まれたきっかけは、1961年の「宴のあと事件」だろう。

三島由紀夫の小説「宴のあと」のモデルとなった人が、小説に書いてある内容についてプライバシーの侵害を訴えたという話です。日本における最初のプライバシー裁判となったようで、これは知らなかったので勉強になりました。

宴のあと - Wikipedia

 

欧州では、プライバシーを基本的人権の一つに位置付けており、それがプライバシー保護法制の原点にある。ナチス政権によるユダヤ人の探索や選別、東欧諸国の政治警察による国民の監視などを通じて、欧州は個人情報が悪用されることの危険性を歴史的経験として学んだ。これが世界でも最も厳しいとされるデータ保護規制につながっている。

先月(2018年5月)、GDPRが改正されルールが厳しくなった上に罰則も超ウルトラ厳しいので大きな話題になりました。ただ振り返ると「なぜ厳しいのか?」という観点での報道は無く、「これやってたらヤバそう」とかそういう話ばかりが報道されていました。大きな罰則が規定されていますので、そこに目が行ってしまって、どうすればいいかという話になるのは当たり前ですが。

この改正の裏にどういう背景があるのか報じられていなかったのは、本書の読後に考えるとちょっと残念です。もちろんアメリカ企業への牽制も大きな理由なんでしょうけど。

 

(ベネッセとYahooBBの情報漏えいは)対象者に500円をお詫び金として配布した。

ベネッセ事件の時は、なぜ犯行が起きたのか、どうやって犯行を犯したのか、という観点で報道されていました。こういう事件の決着のところは忘れたころにニュースになるので扱いも小さかったのか、見逃していました。企業側としてはかなり頑張ったんだろうなと思いますが、利用者の立場で考えると安いですね。 

 

JIAA(インターネット広告推進協議会)は2014年11月に「インフォメーションアイコン」の実装を始めると発表した。プライバシー保護を企業競争のツールにしようとする意欲的な試みだ。

こういうものがあることすら知らなかったので勉強になりました。

行動ターゲティング広告に共通のアイコンを表示する「JIAAインフォメーションアイコンプログラム」の認定を開始│JIAA

イコン画像を貼りたいんですが、認定を受けているわけではないのでやめておきます。適当に再現します。Web広告の右上にあるこんな感じのアイコンです。

f:id:kwnflog:20180611164826p:plain

広告上にあるこの菱形に囲まれた ”i” のマークをクリックすると、広告配信企業のページに飛べて、個人情報の取り扱いやオプトアウトの意思表明をすることができました。こういうのが存在することすら意識していなかったので勉強になったんですが、一点残念なことも。上記JIAAのリンク先から引用します。

JIAAが指定する業界共通のアイコンの表示を行います。

色んな広告を見てみると、広告の右上に上記のようなアイコンは確かにあるんですが、何か広告配信企業によって微妙にデザインが違うんですよね。Googleだと〇の中にiの文字があったり、MicroAdだと□の中にiだったり、配信企業によって違う。準拠しているガイドラインが違ったりするのかな(EUアメリカのガイドラインに準拠しているとか)とも思ったのですが、MicroAd社はJIAAのポリシーに準拠していると宣言している。

JIAAは自分たちが指定する業界共通のアイコンと言っていて、実際の広告をよく見ると、JIAAが公開しているアイコンとは異なるものが表示されている。どういう事情なのかはわかりませんが、かえって混乱を生む土壌を作っているように思えます。

しかしながら知っている人にとってはオプトアウトの方法が明確になっていますから良い事なんでしょう。世の中の大半の人はオプトアウトなんて言葉すら知らないでしょうが。

 

さらにJIAAはインフォメーションアイコンの実装と並行して、「プライバシー・バイ・デザイン実施プロセス検討チーム」という組織を発足した。プライバシー・バイ・デザイン(PbD)とはあらかじめシステムを構想する段階で、ユーザが何らかのアクションをとらなくてもプライバシーが守られている状態になるようシステムを設計段階に組み込むという考え方である。

プライバシーバイデザインという言葉も本書を通して知りました。

プライバシーバイデザイン - Wikipedia

Wikiを軽く見てみましたが、オプトイン・オプトアウトの話はもちろん、デフォルトで非公開設定にするなど、断片的に何となく知っている内容もありますが、こういうものが体系的にまとめられているのはいいですね。エンジニア的には最低限守るべきラインというのが示されていると開発に集中できますし。そのうち勉強したいことリストに加えておこう。

 

えー、ちなみにですが、本書を発行しているのは日経BP社です。日本経済新聞社の子会社です。そしてJIAAの副理事長は日本経済新聞社の方です。いや別に何がってことはないですけど。

 

まとめ・おわりに

前述したように、特に後半部分が読みづらい書籍でした。情報が断片的になっている感じがあり、項や節ごとの繋がりが見えなかったことが原因だろうと思います。しかしながら、プライバシーの定義や国内の主要なプライバシー事件のまとめなど面白い内容が割とありました。後半部にいくにつれて読みづらく、総合的に何を言いたいのかわからない感じがでてきますが、断片的な情報としては役に立つ情報もありました。

 

最近はAIやビッグデータ周りで、カメラを設置して人の流れを追うとか、顔認識の仕組みを入れて自動化を図るとか、様々な取り組みが始まっていますが、「個人情報とは何か」ということを考えるきっかけとして本書は無しではないかなと思います。

 

積極的に推したいレベルの本ではないですが、個人情報周りだと、個人情報保護法や個人情報保護士のテキストなどどうしても法律関連の固い書籍が多いので、読みやすさ重視でまず本書を手に取るのはありだと思います。法律寄りというよりもビジネス寄りの書籍として良書に出会えたことがないので(あるのか?)、とりあえずビジネスパーソンとして目を通しておいて損はないかと思います。特に一章と二章は。

 

 おわり

 

【読書感想文】「SEの教科書【完全版】」を読んで

読書感想文です。今回読んだ本はこちら。

 

SEの教科書 【完全版】 (技評SE選書)

SEの教科書 【完全版】 (技評SE選書)

 

 

この本を読もうと思った理由

今回この「SEの教科書」を手に取った理由はネガティブな理由からです。そもそもSEというのは明確な定義が存在しなく、大よそ広義的にはIT業界にいる下っ端全般を指したり、狭義では上流の設計をする人とか、コードを書かなくてマネジメントと称した調整とドキュメントを書く人を指す言葉だと思っています。

業界的に100人に聞いたら100人が同じ答えを出すわけではないSEという仕事に関して教科書という名前で書籍を発行するのはいかがなものか、たぶん著者独自の定義に従った狭い見識の元、たまたまうまくいった成功例をひけらかすしょうもない書籍なんだろうと思いました。つーか日本人が書いたこの手の書籍でロクな本に出会ったことがないので、これもまたしょうもない本なんだろうと見つけた瞬間に考えました。ただそういった文化的ゴミレベルの書籍がいっぱいある中でも、本書タイトルの「教科書」という言葉はやり過ぎだと感じました。特にここ10年くらい、書籍タイトルでの「釣り」が多く、出版業界の何でもやる感に呆れかえっているので、技術評論社もやるのか、いや技術評論社はまだ誇りを捨てていないはず(願望)と思い、その確認をせにゃならんと本書を手に取りました。

 

全体の感想

技術評論社は誇りを捨てていなかった。すいません、良い本でした。

私の中では本書のタイトルと、まえがきに記述してある「本書の方法で仕様変更ゼロを2回実現した実績のある方法」という文言が気になっていて、2回だけかよ、それたまたまだろと思っていました。しかし本書全体を読むと著者が如何に「プロジェクトを成功させるために本気で考えて仕事をしているか」が伝わって来て、地に足を付けたホンモノのエンジニアであると思いました。

書いてある内容は泥臭い内容が多いです。本当に必要なこと、不要なことを著者が自分の頭で考えて、それを実践して得られた最終的な上澄みのノウハウが凝縮された本です。本書はあくまで業務システム開発を対象にしているので、業務システム開発プロジェクトのアプリ設計、調整役としてのSEが主な対象です。しかしながらITにおける開発の本質部分を突いていると感じましたので、インフラ屋やWEB屋の方が読んでも得るものは多いと思います。また技術系の本では無いため、IT業界への就職を考えている学生にもオススメです。

 

個別にビビッときたところ

「コレ来た」と思ったところを紹介します。引用部は間を省略していることもありますが、基本的に全て本書からです。

 

顧客はコンピュータやプログラミングというものの実態をイメージのしようも無い状態ですから、目に見える開発側担当者の言動や出来上がった画面の動きそのものから受ける印象でのみ、物事を判断することになると思います。

ここでは、顧客はプログラムの実態がわからない → 不安になる → 目に見える物でプロジェクトの状態を判断するしかない → 目に見える物がちょっと違うので修正を依頼する → 出来ないとか間に合わないと言われる → 更に不安になる → 開発担当を信じられなくなる、というコミュニケーション上の問題に対して言及しているところです。見える物をさっさと出すのが宜しい、という著者の考えには賛成です。ただ見える物を出すと、顧客側の決断できない承認者にプロジェクトを止められるリスクがあるので、判断が難しいところではありますね。

 

マネジメントを本当の意味で成功させるには、PMよりも上位の管理者から経営者までの人たちは、「成果物を作る」直接的な技術について、長期間にわたって実際に体験していて、実務として行える程度に詳しく理解していることが必要です。

これは正しいと思いますが、現実的には難しいケースがある。SIerに勤めていると、会社レベルの力学が働いて、どうしようもない人間が管理職に収まることが多い。私の上司で3つほど役職が高い人は、某銀行の開発プロジェクト上がりですが、アプリ保守をずっと続けていた人で、インフラやWEBはド素人です。そんな人間が上位の管理職をやっていて、口出ししてくるわけです。私はインフラ屋ですが、何もわからない顧客にシステムの説明をするのと同じくらい疲れる。そしてその割にアドバイスがあるわけでもなし、トラブってもその上司は頭を下げてくれるわけでもなし、結局は無駄な社内儀式に成り下がっているわけです。

 

プロジェクトのスタート時に、目安となるスケジュールを作成していると思いますが、そのスケジュールにはスケジュールの最適化を行うタイミングをスケジュールしておきます。(中略)当初から提示していたスケジュールで進められそうであれば、それはそれで問題ありません。(中略)スタート時のスケジュールにはいろいろと前提としている事柄があるはずです。

これすごい大事。頭の固い顧客にあたると、「営業提案時のスケジュールと違うやないか!正式な説明を求む」って話になることがあるんですよ。「リリース日は動かしてねーんだからいーだろ、つーか何か困るわけ?」というのがこちらの思い。実際は困る事も無く、お客さんは不安になってるだけなので、ビシッと筋の通った説明をすれば理解してもらえますけど、ぶっちゃけ超面倒なので最初のスケジュール提示時に作業環境や制約条件によって別途スケジュール調整しますと話しておくのがベストだと思います。大日程の提示時に隅っこに小さく書いているレベルではだめです。スケジュール表上にプロットしておくくらいが正解と思う。

  

筆者は「要求は徹底的に話してもらう」ようにしてきました。夢のようなことまで全部話してもらって議事録に記録します。要するに抑えよう抑えようとするから、後からちょっとずつ出てきて、仕様変更になるのです。

これも筆者の書いている通りだと思います。私の少ない経験からでも、徹底的に要件を話し合ってから現実的な話で合意できると、後から揉めるパターンは少ないです。お客さん側でも次フェーズの予算確保に動きやすくなるので、皆ハッピーになりますね。また徹底的に拘って要求を聞いていくと、お客さんからの信頼も得られます。そうなると、「あ、この人が無理って言うなら無理なんだな」と思ってもらえる関係性を構築できます。

 

よくありがちな、「だいたいの業務分析を行って、要求定義をそこそこのドキュメントの積み上げで済ませ、次は設計で、開発。設計でもいろいろと新事実が出てくるし、開発して形になってからもいろいろと加えなければならない事が出てくるが、それは当然の事」という考え方は不十分です。「マネジメントの怠慢」「上流工程そのものを理解していない」といえます。

あぁ、その通りだとも思うし、耳も痛い。私は小規模案件でマネジメントやることがありますが、このパターン多いです。やっぱり本書にある通り徹底的に要件ヒアリングをするのが一番いいんだろうなぁ。なぜ出来ないのだろうか?たぶん上流工程のスキルが足りていないのだろうと思います。研修言っても教科書的なことしか教わらないし。あと気持ちの問題(色々な人たち、ごめんなさい)。

 

(SEが)プログラマーより楽をしていていいわけはありません。しかも、ただ大変ならいいわけでもありません。

これも同感&耳痛です。当たり前の話なんですよね。調整役の只のSEモドキといっても外注会社の社員より高い単価であるのは明白だし、給料だって自分の方が高いだろうし、なのに楽しているとか最悪です。IT業界というか産業界全体なのだろうと思いますが、純粋な開発力で単価が決まるわけではなく、会社の格で単価が決まるのは労働者の意欲を削ぐ歪んだ慣行だと思います。もちろん会社の格が高ければ、そこで働く人や組織への信用度が違うのはわかりますが、客の御用聞きYesマンSEが開発者より高単価であることはおかしいと思います。

 

たとえば、急遽開催されることになった会議があったとします。(中略)少なくとも1日から1日半ぐらいは、間違いなく会議のための「それらしく見える資料作り」に費やされることになります。

わかる!これは開発者側の立場で書きますが、顧客との間に中抜き企業のSEモドキがいると、ひどいもんになります。実態がわかっていないのに、顧客に怒られたからという理由で、末端の作業者に報告資料を作らせるやつです。害悪ですね。

 

当初、「簡単なシステムですよ」とか「こんなかんじです」と、お客さんや関係者から言われることがあります。実際にはあまり正確でない場合も多く、それを後でどうこういったところで始まらないということになります。「自分が作るからには、自分が知らなければならない」ということさえ頭にあれば、かなり多くの問題が回避できると思います。

そう、本当にその通りだと思う。小規模チームだと早い段階でこの考えに慣れることができます。「自分でやらないといけない。自分が理解しないといけない」と思うと、会議やプロジェクト進行に対する姿勢が変わります。会議中なんかは頭をフル回転させて、自分のタスクを整理したり、全体の矛盾点が無いかを考えるようになる。自分で言うのは何ですが、そうやって「自分でやらなければいけない」状況になった時が自分的に一皮剥けた時期だったなと思います。逆に大規模チームの一人という立場にあって指示は自社の上司という若人は、注意した方がいい。

 

多くの場合、上流工程で問題は発生しているが、ここに関わっている人々は、それによって直接の影響をあまり受けない。問題に直接影響を受けたり、とくには変更管理的な対処までを行うのは、主としてプログラマーである。したがって原因を作り出したところには、具体的な苦痛は無い場合が多い。

これは本書を読む中で、一番グサっときた文章でした。
中抜き企業のSEモドキはこれが一番わかってない。SEモドキはお客さんに対してYesマンで、開発者に対しては「やっとけ」「何とかしろ」という立ち位置を取る人間が多い。SE側も開発側と同じレベルの品質で上流工程をやる覚悟を持つことが必要だと感じます開発側のバグや不具合と、SE側の仕様不備は同じレベルの罪であると認識すべき。

  

(PMの安易な兼務はダメです。なぜなら)他のどのステークホルダーよりもプロジェクトを知らない状況に陥ったり、スケジュール調整がうまくできないことなどで顰蹙を買ってしまい、交渉前から最も弱い立場になったりしてしまうなど、不必要なトラブルのオンパレードになってしまいがちです。

周りからは「あの人は(優秀なので)忙しい人なのよね」「兼務しているからしょうがない」という雰囲気になりがちですが、ダメですね。結局はPMの配下にいるメンバーにしわ寄せが行ってしまうので、自分がいるプロジェクトのPMがロクにマネジメント出来ないなら声をあげるべきなんだと。ただ問題が発生する前に、「このプロジェクトのPMに兼務させんな」と下っ端から言うのは難しい。またPMを任命したのはそのPMより偉い人です。上で書いたことと似たようなことを書きますが、PMを兼任させた人は、PMが兼任することで現場に発生する負荷を全く負わない形になっています。下の痛みを知れよ。

 

上場企業レベルの担当SEやPMは実質は、「直接ソフトウェアを作るプロジェクトチームのプロジェクトマネージャ」ではなくて、あくまで技術営業兼関連部署調整役、下請け外注先調整役であって、「本質的にソフトウェアを作るという意味で、技術者としての経験をすることはない(場合によっては生涯ない)」(以下略)

耳痛(激痛により昇天)

 

プロジェクト目標の決定

「顧客の得たい利益は何かを定義する」

「××システムの構築」は目標ではない。顧客は「システムが欲しい」わけではなくて、「システムが稼働し続けることによって得られるであろう利益そのものが欲しい」わけです。

これは小規模な特攻隊で動いていると、よくわかる話です。小さい会社の案件なんかだと経営者が乗り出してくることが多いです。そこで話をしていると、正に経営者のマインドというのは、「如何にしてシステムで利益を出すか」に集中していて、考え直させられることがよくあります。UXの考え方に似ているかもしれないですね。と思っていたらCustomer eXperience、CXという考え方が存在する模様。

 

(会議の場でいつも否定的な意見を述べる人は)一度どこかでケチをつけておけば、「トラブルを避けるための活動を何かしら行った」「自分は警告した」というアリバイ作りになる、というわけです。このようなタイプの人には意見を求めずに、決まった活動だけおこなってもらうようにすることで、他のメンバーのモチベーション低下を引き起こさないようにする必要があります。

それなりの規模のプロジェクトだとどこにでも保身に走る輩がいるものです。そして1人が保身に動くと、囚人のジレンマの如く(違うか?)周りも動かざるを得なくなり、プロジェクトチームが機能不全となるケースがあります。また保身のための発言が出ると会議が冷えるんですね。警告を発した事実と余計な発言をしない姿勢から、どんどん会議が冷えていく。結果として、参加者が「如何にして問題を解決するか」ではなく「如何にして責任を負わないようにするか」に向いてしまう。当然、問題は解決しない。

 

あるプロジェクトの元請けは、何となくそれっぽいことを言ったり、檄を飛ばしたりしていますが、どうも中身がなく、いざ決めようとしても、どこか逃げている感じがしました。(中略)そして何かにつけ「それは顧客には言えない」とか「もう言ってしまった」などと、何とかして交渉自体を行わないで済ませようとする意見を口にするというのも、その会社の社員全般に共通していました。(こういうのは会社のクセみたいなものだから気を付けようという話)

同意&耳痛。「それは顧客には言えない」「もう言ってしまった」私が経験したシステム開発プロジェクトでは良く聞いたセリフです。

「もう言ってしまった」→「じゃあ訂正してよ」→「やだ、何で俺が。お前が自分で言えよ」→「それを言うのがSEの仕事だろ」

こんなやり取り。自分でも気づいていない、自社の常識(世間の非常識)に毒されているであろう事実を認め、改善していく清き心を持ち続けることが大事なのだと思う。(自信は無い)

 

(ソフトウェア開発の失敗パターンは根源的な理由は同じ。出来ないものを引き受けて失敗していたということ。)ソフトウェア開発という、作るもの自体が見えにくい物であることによって、「できない根拠」が示せなかったらです。

そうなんですよ、馬鹿な奴は「出来ない根拠が示せない」=「出来る」と考えてしまうんですよね。根拠の示せない”何か”が存在する可能性を考慮できないんですよ。そしてそれが単純に馬鹿なやつがいつもそう考えるというならまだ対策は可能なんですね。しかしこの話、そんな馬鹿な奴ではなくとも、予算未達の営業がやりがちだからタチが悪い。そういう0/1に単純化した思考で、受注を目指すか、撤退するかを考えるものだから、ピンチな時は細かな事は考えずに営業が自分を正当化する武器として、「出来ない根拠が示せないなら出来るってことだよな。うん大丈夫」となって多くの歩兵が昇天していく。

 

 

まとめ・おわりに

超簡単にまとめると本書で著者が書いていることは以下に凝縮される(と思う)。

・要件定義は徹底的に

・PMやSEはちゃんと計画を立てろ

 

本書は二部構成を取っており、元は別の書籍であったものを合体させて1冊にまとめたようですが、一部と二部の繋がりは意識して書き直されているようで、特に違和感なく最後まで読み切れました。ただ第二部のところで記載内容が不明瞭に感じる部分もあり、第一部のクオリティから見ると、若干ですがクオリティが落ちていると感じました。

 

とは言っても、第一部の内容は国内SIerに勤めるリーマンSEなら必読の内容だと感じました。またSIerだけではなく、WEB屋さんやイラスト・コンテンツ屋さんのような企業に勤める人、就活中の学生、マネジメント層にもぜひ読んでほしいなと思う内容でした。

 

日本のIT業界で働くIT戦士が書いた本となると、妙に外国かぶれをしている人だったり、実現性の無い施策を唱える人だったりで、「は?で?」と思うことが多いのですが、本書は珍しく当たりの本でした。

 

気になる方は是非ご一読くださいませ。

 

以上