nekoTheShadow’s diary

技術ブログとして始めたはずが、読書&愚痴ブログになりました(´・ω・`)

宇佐美典也 『パチンコ利権: 瀕死の業界に未来はあるのか?』(ワニブックス)を読んだ。

パチンコ利権 - 瀕死の業界に未来はあるのか? -

パチンコ利権 - 瀕死の業界に未来はあるのか? -

正直にいうと、何の気なしに手に取った本なのですが、意外に面白かったです(´・ω・`) 自分の人生を振り返ってみると、パチンコやスロットをしたことはなく、パチンコホールに立ち入ったのも数回程度。それもトイレを借りるためとか、併設されているラーメン屋に行くためとか、パチンコやスロットとはまったく無関係な理由でした。要はパチンコとはまったく縁遠い人生を送ってきたわけですが、そういう人間でも面白く読めたというか、勉強になった1冊でした。

あげだすときりがないので、このあたりでやめておきますが、以上のように、パチンコというのはとにかく話をややこしくさせる要素に満ち満ちていて、冷静な議論が難しくなりがちです。ともすれば「今日にでもパチンコを全廃しろ」というような、極端で現実味の欠いた結論になりがちです。そんななか、本書は現代のパチンコをめぐる諸問題について、歴史的経緯や法律論や社会的動向などを踏まえながら、冷静な議論を展開しています。タイトルがややセンセーショナルではあるのですが、内容はいたってまじめ。カジノ法案が可決されるなど、ギャンブルに対する社会的関心が高まっているなかで、もっとも身近なギャンブルであるパチンコの問題をこれだけわかりやすく、かみ砕いている本は貴重であり、もっと読まれてもよいと思います。

本書の全体の構成としては、パチンコをめぐる問題をいくつかピックアップし、章ごとに解説しています。まず、この問題の設定方法が上手で、読者が普段から疑問に思っているであろうトピックがずばり選択されています。そのため、どの章を読んでも勉強になるのですが、個人的にもっとも関心を抱いたのは第4章『数字から見るパチンコ業界の凋落: 大逆風に見舞われた21世紀』あたり。パチンコ業界自体の衰退はよく知られており、とくにスマートフォンゲームとの競合は要因としてよく挙げられますが、本書はもう少し突っ込んだ議論をしています。とくに近年のパチンコのゲーム性自体に衰退の原因を見ているのは目からうろこ。詳細は本書に譲りますが、最近のパチンコは「少数のユーザから搾り取る」「派手で華美な演出が多いわりに勝てない」という傾向があるらしく、パチンコを全くたしなまない私でも「それは面白くなさそう」と思える内容で、衰退もやむなしかな(´・ω・`)

第5章 『パチンコ業界はこれからどうすべきか: "グレー産業"からの脱却を提言』あたりで議論されていることですが、筆者はパチンコを地方創生のハブとして考えているようです。要するにパチンコホールに催事場機能やサロン機能を持たせようというもので、この妥当性については判断しかねますが、問題意識は次のWeb記事に近いと思われます。やや本題から外れますが、紹介しておきます。

news.denfaminicogamer.jp

最後に--本書には、パチンコホールの現在を肌感覚として知っている人物として、AV女優である紗倉まなと筆者の対談が掲載されています。そこには紗倉まなの写真が掲載されており、白黒で画質もさほどよい写真ではないのですが、それでも紗倉まなの写真写りはかなり良く、かえって紗倉まなの美人度合いがうかがえる内容でした。こんな写真でもきれいに映る紗倉まなは相当美人なんだろうなということですね。紗倉まなはAV業界でも頂点クラスの女優だそうですが、それも納得です(←なんじゃそりゃ)

『Oracleの基本: データベース入門から設計/運用の初歩まで 』(技術評論社)

Oracleの基本 ~データベース入門から設計/運用の初歩まで

Oracleの基本 ~データベース入門から設計/運用の初歩まで

Oracle Databaseの存在はもちろん知っているし、利用したこともある。ただ"利用したことがある"といっても、インフラエンジニアがインストールしてくれたものを使うだけで、利用するのはもっぱらSQL Developer。管理運用はまるっとDBAならびに運用オペレータにお任せ--というのが、この本を読んだときのわたしのスペックでした。要するに「Oracleに触ったことがある」という程度の人間だったのですが、何の因果なのか、新しく入ったプロジェクトで、Oracleを含むミドルウェアのローカル開発環境構築要員に抜擢(´;ω;`)ウゥゥ 割かれた工数もかなり少なめということもあって、Oracle Databaseについて突貫で勉強する必要があり、本書を手に取ったのでした。

本番環境や大規模な運用になると、本書だと物足りないのかもしれませんが、ローカルPCに開発環境を構築する程度であれば、本書で十分すぎるほど。Oracle Databaseに関して最低限知っておくべき知識が過不足なく簡潔に、かつわかりやすくまとめられており、初めてOracle Databaseに触るという人はもちろんのこと、「Oracleをなんとなくで使ってきた」「その場その場のGoogle力で乗り切ってきた」というわたしのような人間にとっても知識を体系的に整理できるよい機会でした。ちなみに自分が構築したのはOracle 18cでした。本書はOracle 12c対応となっていますが、18cでもちゃんと通用する内容になっています。もしバージョン違いで買うことをためらっている人がいるなら、迷わずGO!

本書のおかげでOracleの基礎的な知識を身に着けることができ、ローカル開発環境の構築と手順書の作成を無事終えることができました。感謝! まあそのプロジェクトはなくなったけどね(´・ω・`)

柚月裕子『凶犬の眼』(角川書店)が面白かった

少し前に読んだ『孤狼の血』が面白かったので、その続編である本作を読んだのですが、読みごたえがあって面白かったです。GW帰省の新幹線の車中で一気に読み切ってしまった(´・ω・`)

孤狼の血 (角川文庫)

孤狼の血 (角川文庫)

孤狼の血』は実在のやくざ組織や事件を参考にしたと思われる個所は存在するものの、全体としては映画『県警対組織暴力』や『仁義なき戦い』を下敷きにしていました。両映画、とりわけ『仁義なき戦い』は実在の抗争事件をもとにした映画なので、そういう意味では『孤狼の血』は実際の広島抗争をもとにしているといえなくはないのですが、作品全体の雰囲気としては"実録"感はうすめ。あくまで映画・フィクションのオマージュ感が強い一方、本作はかなり"実録"感は強い印象でした。ありていにいうと、本作はいわゆる山一抗争、および、そのさなかに発生した四代目山口組組長射殺事件が元ねたです。とりわけ国光寛郎という人物。彼は作品中の最重要人物なのですが、このモデルはあきらかに一和会系の有力組織の組長で、四代目山口組組長と若頭を射殺した、とある人物です(あいまいな書き方ですが、山一抗争を多少知っている人であれば、すぐわかるほどの超有名人)。そのほかにも登場するやくざのモデルが明らかすぎるほどだったり、ディティールを彩る事件が実際に山一抗争で発生したものとうりふたつであったりと、現実の山一抗争をかなりにおわせる書き方をしています。誤解をおそれずにいうと、本作の完全なるフィクション部分を除けば、『実話時代』のような実話雑誌に掲載されている実録小説と内実はほとんど変わりません。それほどまでに"実録"色が色濃く出ています。

山一抗争は戦後最大の暴力団抗争、もしかするとやくざ史上最大の暴力団抗争で、民間人を含む多数の死傷者を出し、挙句の果てには山口組の組長と若頭までが同時に殺されるという、まさに「血で血を洗う」というにふさわしい戦争でした。しかし抗争を振り返ってみると、繰り返し述べている四代目山口組組長射殺事件を除くと、終始山口組が一和会を圧倒しており、「弱いものが智謀と度胸をふるって、強いものを倒す」というような映画的カタルシスはほとんどありません。確かに規模は史上最大であり、また部分部分を見れば刺激的なトピックもあるのですが、全体を通してみれば「強い奴が勝つ」という現実的で面白みに欠けるのが山一抗争です。これをどのようにしてエンターテイメント小説とするのか。それも敗軍である一和会側の人物を主軸に添えるとなると、かなり難易度が上がりますが、本作はそれを軽々超えていました。しかも、基本ラインは『孤狼の血』と一緒。『孤狼の血』は「一癖もふた癖もある人物に感化されて、青年が成長していく」というホモソーシャル的なビルドゥングスロマンが主軸でしたが、本作でもそうした構造は取り入れられており、作者の物語作者としての手腕を強く感じました。

このてのやくざものは本作で打ち止めというようなことを作者は述べているようですが(媒体失念)、もっと書いてくれないかしらん(´・ω・`)

曽根壮大『失敗から学ぶRDBの正しい歩き方』(技術評論社) を読んだ。

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

Twitterのタイムラインで話題になっていたので読みました(ミーハー)が、とても良い本でした。「失敗から学ぶ」「RDB」とタイトルにある通り、本書はRDBSQLに関するアンチパターン集で、1章に1個の割合で、合計20個のアンチパターンが紹介されています。「RDBSQLに関するアンチパターン」というと『SQLアンチパターン』という名著があり、本書でもたびたび言及されています。正直なところをいうと、重複している部分もあるのですが、『SQLアンチパターン』はどちらかといえばDBやテーブルの設計に関する記述が多かったのに対し、本書はDBの運用やアプリケーションとの連携といった部分にまで話が及んでおり、『SQLアンチパターン』と比べると、話題のスコープが広いように感じました。

SQLアンチパターン

SQLアンチパターン

タイトルに関連して述べておくと、表紙には大きく「MySQLPostgreSQLの設計・運用を見直す」とありますが、基本的には特定のRDBMSに限定されない記述になっています。「どういう設定をすればよいのか」「どこを確認すればよいのか」など、具体的な部分でMySQLPostgreSQLを例示している部分はありますが、そこはある程度読み流してしまっても、本書の価値を大きく損なわないと思います。事実、こう書いているわたし自身、MySQLPostgreSQLを本番環境で使ったことがありません……。SIer勤務だとどうしても商用DBが中心になるんや(´・ω・`)

個人的に本書を読んでいて感心したのは、各アンチパターンを紹介する前に「そのアンチパターンを採用すると、どういう場面で困るのか」をストーリー形式で示していること。「XXXはアンチパターンなのでやめましょう」するにあたって、そのアンチパターンがもたらすデメリットが具体的に述べられていれば述べられているほど、その主張は説得的になりますし、読者も自分事のように感じて、まじめに読むようになるはずです。また「どういう場面で困るのか」を示したストーリーですが、目を閉じれば情景が浮かんできそうなほど「あるある」な内容になっています。わたしも似たような場面を経験したことがちらほら……。そうした「あるある」なストーリーを描くことができるということは、筆者のRDBに関する経験の豊かさや造詣の深さをうかがわせており、これも本書の説得力を増強していると思いました。

個人的な経験で申し訳ないのですが、DBやテーブルについて奇妙な設計をしてしまっても、開発自体は意外と何とかなったりします。ただし運用は死ぬ。また本書でも言及されていますが、アプリケーションに比べるとデータはずっと長生きで、「新しいシステムを作ったが、データは古いシステムから引き継いで使う」という話はよく聞きます。要はテーブルやDBやSQL関連の考慮不足が問題として爆発するまでにはタイムラグがあって、開発者はその遠い未来の爆発が起きないような手法を身に着ける必要があります。その点で、本書は量も手ごろに、アンチパターンとその対策が説得的にまとめられていると感じました。

『エンジニアリング組織論への招待: 不確実性に向き合う思考と組織のリファクタリング』を読んだ。

「エンジニアリング組織論の招待」というタイトルを見たとき「どこぞの企業の偉い人が自分の武勇伝に基づいた『俺の考えた最強の組織』を披露するのか」という邪推をしたくなるかもしれない。本書は残念ながらそういう本ではない。仮にそのような本であれば、タイトルは「エンジニアリング組織への招待」とするはずだ。つまり「論」が抜けるはずで、本書は「論への招待」であることに着目する必要がある。

副題は「不確実性に向き合う思考と組織のリファクタリング」で、本書を手に取ったときはこれを次のように区切るものだと思っていた: 「不確実性に向き合う思考/と/組織のリファクタリング」。これだと意識高めの自己啓発と「俺の考えた最強の組織」の紹介で終始する本のように感じられるが、本書を読んでいく中で、この副題はこう区切るのが正しいということがわかった:「不確実性に向き合う/思考と組織の/リファクタリング」。すなわち本書は「不確実性に向き合う」ために「思考と組織」を「リファクタリング」する方法論が示された1冊である。

プログラマにはおなじみの概念だが、リファクタリングとは「外部仕様を変更しないで、内部実装を変更し、処理効率を高めたり、保守性を向上させたりする」ことをいう。大事なのは「外部仕様を変更しない」というところで、ではエンジニアリング組織の外部仕様とは何だろうか? あるいはエンジニアリング組織に所属するソフトウェア・エンジニアの外部仕様とは何か? これに明快に答えることは難しいが、本書はひとつの答えを提示している。すなわち「不確実性に向き合う」ということである。すなわち、このでのリファクタリングとは、外部仕様をより効率的に達成するために「思考や組織」をブラッシュアップしていく行為であり、本書はそのブラシュアップに役立つさまざまな手法を紹介している。

もっとも「さまざまな手法を提示している」といっても、たとえば筆者の経験談や武勇伝はまったくといっていいほど紹介されない。さまざまな手法はそこかしこのプラクティスやメソトロジーから引っ張られてきており、経験談や武勇伝に比べると、読んでいて納得感がある。また一般論ばかりが陳列されているというわけでもない。紹介される方法論は有名なものから、さほど知られていないものまでさまざまだが、そのすべてがさまざまな企業で実践されていたり、社会科学的な研究に裏付けられていたりすることが明らかなものである。「論」を紹介するといっても、なんでもかんでも紹介すればよいというものではない。その「論」はそれ自体で説得的な裏付けを有している必要があり、そうした正統性を有した「論」を中心に話を組み立てているからこそ、本書は強い説得力を得ているのである。


ここからは本書の感想というよりは現役SIマンの愚痴に近いのだが、本書が対象にしているような領域はSI系のプロジェクトでは一般に「管理工数」として人月計算に計上される。管理工数というのは見た目にわかりづらいというか、KPIにしづらいというか、少なくとも直接何かを生み出しているわけではないため、たとえばプロジェクトが炎上した場合、管理工数はまっさきに削減の対象になる。しかしもとをただしてみれば、なぜプロジェクトが炎上したのかを考えてみると、多くの場合、それは管理不行き届きである。ただでさえ管理が行き届いていないのに、くわえて管理工数を削減するとなると、炎上がひどくなるだけである。

ただここには重大な示唆が含まれていて、それは「管理」という行為の見えづらさである。本書の内容にやや即すると「組織や思考がよくなったということをどうやって判断するのか」ということである。たとえばKPIやチェックシートのような形で、組織や思考のリファクタリング具合を常日頃からトラッキングしておき、上昇傾向なら採用している手法を継続すべきだし、逆に下降気味なら別の手段を試してみるなどの対策が必要になる。本書はこの部分がややあいまい、というよりそもそも本書が語るべき領域ではないのだが、SIだとこれがシビアに求められるケースがあり、つらい場合がある--というお話でした(´・ω・`)

細川義洋『なぜ、システム開発は必ずモメるのか?: 49のトラブルから学ぶプロジェクト管理術』(日本実業出版社)

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?

「どのようにしてプロジェクトをうまく進めるのか」に関する手法やメソトロジーは世間にさまざまあって、たとえばPMBOKなどはその王道であるし、システムの保守運用フェイズであればITILも有名である。アジャイルスクラムエクストリームプログラミングなどもそれぞれ焦点は違えど、極言すればプロジェクト運営のための方法論だといってよい。

ところで日本のIT業界の保守本流はいわゆるSIであり、わたしもその末席に名前を連ねているが、そうした世界では上記であげたような手法が必ずしも有効活用されているわけではないと感じている。現場のSE、なかでもPMは忙しすぎて、そうした知識を学ぶ時間がないから--というのは冗談。日本のSI業界が特殊--というのは言い過ぎだが、プロジェクトマネジメント系の手法の大半は外国生まれ外国育ちで、それを四角四面に日本のSIプロジェクトに適用するのが難しい場合があるのは確かだと思う。

本書がよいところは視点が極めて日本的というか、日本的商慣習のもと実施されるシステム開発プロジェクトにおいて、はまりやすいポイントが適切に解説されているところにあると思う。とりわけ対顧客折衝や下請け管理など、THE JAPANESE SIにおいて重要とされ、ゆえにおうおうにして火薬庫になりやすいポイントについて、その原因と対策をここまで簡潔に書き出されている書籍は珍しいのではないか?

また筆者が裁判所の調停員のようなことをやっているらしく、その関係で「こういうトラブルのときに裁判所はどのように判断するのか」という視点が盛り込まれているのも本書の長所のひとつである。システム開発プロジェクト炎上の究極系は裁判であり、いってしまえばSIerとしてはトラブったとしても、この裁判に勝ちさえすればよい。裁判所の判断というのは、国家権力という極限の実行力を有した判断基準であり、それに従いつつ仕事を進めていくのは悪いことではないと思う。

本書は小説形式、というよりはネットスラングでいうところのSS形式を採用していて、読みやすいといえば読みやすい。ただキャラクタ類型がやや古いというか、正直なところ「10年ぐらい前の感覚で書いているな」という感想を持ってしまった。物語作品としてまじめに読もうとすると厳しい面はある。そこは本作の大事な部分ではないし、もとがSIのトラブルとその対策集をSS化するという無茶をやっているわけで、まあ許容範囲ではある。

Scala挫折しそう

ここ数年、毎年新しい言語をひとつは学ぶという習慣を続けています。2018年はC#コンパイラの出来がよいのか、雑に書いてもそこそこの性能が出るし、なによりLINQが書いていて気持ちいい。またLINQの存在を知ったあとで、JavaのStream APIをあらためて勉強しなおしてみると、こちらはこちらでなかなかよくできていることに気づくなど、たいへん勉強になりました。これからもC#で遊んでいこうと思います。

さて2018年も年の瀬。来年学ぶべき言語を考え始める時期でもあります。そこでここ1か月は予行演習として、前々から関心があったScalaに触れていたのですが、そうそうに挫折しそう、というか多分挫折すると思います(´・ω・`)

①挫折の最大原因がIntelliJ IDEA。ネットの記事や入門書によると、Scalaを書くにはIntelliJ IDEAが最適、というよりそれ以外の選択肢はほぼないらしい。ならばと使ってみたところ、自分のPCとの相性が悪いのか、自分の使い方が悪いのか、妙にもっさりしていて、コード補完がうまくきかなかったり、コンパイルエラーの検出ができなかったりと、ストレスがたまることが多い。ショートカットや見た目のフィーリングが妙に気に食わない、無償版とはいえ商用製品をただで使うのは気が引けるなども、IntelliJ IDEAから遠ざかる要因になっています。なおPluginを導入すればEclipseでもよいそうですが、自分の環境ではろくに動きませんでした(そのPluginがもともとあまり安定していないらしい)。

②あとは些末なところで、Scalaの文法が自分の好みに合わないというのも挫折の理由にあったりなかったり。

  • Listの添字アクセスが[]ではなく()
    • VBAと同じですが、VBAにトラウマがあるので、それを思い出してつらい(´;ω;`)ウゥゥ
    • []は別の用途で利用されるのだが、これはこれは違和感がぬぐえない。
  • やたらに記号を多用するスタイルで、書くのも読むのも慣れないと厳しそう。少なくともググラビリティは低い。
    • 無名関数ではプレースホルダが使えるのだが、その記号が_。ほかの言語だと変数名_は"無視"を意味することが多いので、違和感がある。
    • :+とか+++とか、ほかのプログラミング言語だとあまり見慣れない記号が妙に出現する。
    • 同じ記号に違う意味がありすぎて、覚えきれる自信がない。
  • def methodName() = {}=はいらなくない? =は束縛の意味なのかなあ?

ここに挙げたのは一部で、ほかにもいくつあるのですが、ただこうした違和感は学習期間が短いゆえの現象、要するに「慣れてないだけ」。とはいえ、ひとたび違和感を持ってしまうとそれをぬぐうのはなかなか難しいのも現実ではあります。

③まあこれは覚悟していたことではあるのですが、Scalaは学習コストが高く、はやくもわたしのIQではついていけなさそうな雰囲気を醸し出しています。1か月触れた程度ではあるのですが、それでもimplicitや型クラスなどなど、抽象度が高い概念がぽんぽん出現し、このペースで難しい概念が現れるとなると、ついていけるのかがとても心配になります。


Scalaからは戦略的撤退を決めるとして、ではどの言語を勉強すべきか。そもそもScalaを選んだ要因のひとつがJVM系言語に興味があったからでした。Scala以外のJVM系言語となると、Groovy/Kotolin/Clojureあたりかしらん。Groovyはグルー言語としての用途はよく聞くのですが、アプリケーション構築にどれだけ利用されているのかわからないので、パス。KotolinはAndroidに関心が薄いのと、前述したようにIntelliJ IDEAがだめ。となると消去法的にClojureが最有力候補になりますね……。ただLISP系ということぐらいしかわかっていないので、環境構築とか入門書とか、周辺の情報を集めることが先ですね。過去にSchemeに取り組んだことがあって、LISP系の文法には抵抗ないので、そこは無問題。ただ万が一はまってしまうと、通常世界にかえってこれなさそうな感じがする(LISPプログラマに対する偏見)。

JVMにこだわらずともPHPPerlでもいいですし、昨今の動向を考えるとフロントエンドに取り組むのもありのような気がします。個人的にはとりわけCSSに苦手意識があって、なんとなくフロントエンドからは逃げ回ってきたのですが、最近はそうもいっていられない雰囲気があり、迷うところではあります。また言語ではなく、何かしらのフレームワークを学ぶ選択肢も考えています。ちなみに学ぶとすればRuby on RailsかSpring Bootですね。ただフレームワークを学ぶとなると、何かしらのアプリケーションを作成することになるのですが、どう頭をひねってみても、特別作りたいものがない。よさげなハンズオンを探してみようかしら。

なかなか迷いは尽きないですね(´・ω・`)