こういう技術書読むのっていつ以来だろう？
データに関する散らかった知識を集約したりアップデートするのに、このように一冊にまとまった本は本当に助かります。
システムの信頼性、スケーラビリティ、メンテナンス性の観点から、データを扱う上での課題、考慮点、解決策（とその限界）が具体的な内容を元に整理されている。（時にはDBMS毎の説明もある）
トランザクションを扱うシステムや、DataLakeのようなデータ基盤でも、データの処理がポイントとなるシステムを構築する開発者には必読の一冊です。
サービスサイエンスという分野。
一言で言うと、「サービスを科学しよう！」ということなのだが、この本によると、サービスの品質には「成果品質」と「プロセス品質」があるとのこと。
例えば飲食店の場合は、美味しい料理が「成果品質」。
でも、どんなに美味しい料理が出てきたとしても、そのお店の雰囲気が悪かったり接客態度が悪かったら、二度とそのお店には行きたくない。
これが「プロセス品質」。
成果品質は論理的満足につながり、プロセス品質は感情的満足につながる。飲食店の例で言うと、感情的満足を得られないとリピーターにはならないということ。
システム開発の仕事で言うと、成果品質はQCDで測れるが、いくらQCDを達成しても感情的満足を得られず、「また○○さん（若しくは△△社）と仕事がしたい！」とはならない。
ではどうすればプロセス品質を高めて感情的満足を得られるか？
サービスを提供するお客様には色々なタイプの人がいる。
ステークホルダーの種類で言っても、新サービスや新システム開発の承認をする偉い人、システムへの要求を出す人、システムを利用するエンドユーザー等々。
更には。その新サービスに前向きな人・後ろ向きな人、プロジェクトの経験がある人・ない人、ITリテラシーの高い人・低い人、その仕事に積極的に関わりたい人・少しでも楽したい人、、、あげればキリがない。
要は、サービス業の基本として、相手に合わせて相手が望むサービスを提供する必要がある。
サービスの品質を評価するのは、「正確性」「迅速性」「柔軟性」「共感性」「安心感」「好印象」の６つの要素とのこと。
それほど正確じゃなくてもいいから早く情報を提供するとか、ちょっと不安がありそうだから安心してもらうようにするとか、相手に合わせてこの６つの要素から最適なものを選んで行動する。
実はSEって接客業なのかもしれない（笑）
ブロックチェーンの調査や研究をやっていると、ついブロックチェーンそのものにばかり目が行ってしまうが、そうじゃなくてアプリケーション全体で考える必要があるという、当たり前のことを思い出させてくれる良書。
例えば、オンチェーンとオフチェーンそれぞれで保持するデータをどう切り分けるか？
オン・オフ間でデータの整合性をどう確保するか？（2フェーズコミットのような下手な手段は使わずに）
というような設計上の考慮点が色々と整理されているので、アプリケーション全体のアーキテクチャを考える際に、最初にざっと目を通して「何を考えなければいけないか？」を見るような使い方がいいと思う。（ちなみに目を通せばいいのは、本の後半部分だけです）
初版2001年の本を、２０年近くぶりに再読。
多分、前に読んだ時は、リーダーシップとかリスク管理に興味を持って読み、今回は、組織の変化・成長とか、ストレスに関する内容から多くを学んでいる。
それだけ幅広い読者に受け入れられる内容だということ。
「ゆとり」とは、会社の業務に追われて余裕のない時間以外の時間。
組織運営をしていると、全員が忙しくて走り回っている状態よりも、ちょっとだけ組織的、時間的に余裕がある方が、何か新しいことに着手する際のスピードが全然違う。
効率を求めるよりも、効果を求めるほうが、より組織の成長とか組織文化の醸成に効果がある。
これまでの経験が積み重なったり、立場が変わることで、また新たな気付きをもらいました。
何年かぶりでの再読。
前に読んだ時は、スクラムのHOW TO本として読んだのでわからなかったが、あらためて、著者（スクラムの開発者）の言う、アジャイルの開発方法論としてではなく、仕事のフレームワークとして捉えると、また違った面白さがある。（以前はそこまでのスキルがなかった・・・）
以下、自分自身への備忘録。
・スクラムの真髄は周期性にある（要はリズム感が重要）
・コミュニケーションを妨げるのは仕事を専門化すること
・（労働時間短縮）バランスのとれた生活をして欲しいから言うのではない。その方が仕事がはかどるから
・人の力を引き出す、自信を持たせる
・大きな成果や成功を得るよりも前に、幸福感が先にある
・幸福度を計測する
・個人のパフォーマンスよりもチーム全体のパフォーマンスを伸ばす
開発プロセスというよりは、完全に組織運営目線になってるけど（笑）
この中で一番面白いと思ったのは、幸福感について。
人は成功しているから幸せなのではなく、幸せだから成功するという内容。
確かにそれはよくわかる。
では、幸福度はどうやって上げるか？
色々なやり方があると思うが、著者が言うのは「主体性、スキルアップ、目的意識」の3つ。
自分の運命をコントロール出来ること、自分が上達しているという実感、何かに力を尽くしているという感覚。
これは、企業文化、組織風土の醸成にも言えること。
同じ本でも、それを読んだ時の状況や立場の違いで、刺さるところが全然違ってきます。
一言で言うと、『ザ・ゴール』の手法を使ったシステム開発版。
前半は、あまりにも酷い開発プロセスと人間関係の改善がテーマなので、全くと言っていいほど参考にならない。
DevOpsの、開発から運用までの流れをシームレスにって、プロセス毎に担当が分断化されていない環境では、その基本的な部分は参考になるところがない。
後半からは、「4つのタイプ」と「３つの道」という概念を中心に語られており、そのあたりからは面白くなってくる。
・ビジネスプロジェクト
・内部プロジェクト
・プログラム変更
・予定外の仕事
という4つの仕事のタイプ毎に、どういう問題や弊害があって、それをどう解決するか？
更には、
・カンバンによるタスクの可視化、適正なタスクサイズ
・ビジネスとITの間のフィードバックループの短縮化
・プロセスの改善（反復と継続）
といった3つの道。
これらを具体的にかなり詳細に踏み込んで説明しており、DevOpsの本質的な部分をわかり易く理解出来るようなストーリー（というか脚本）になっている。
たまにはこういうタイプの本も面白いです。
当然、全ての開発プロセスや、ビジネスとITの関係を改善して、主人公は最後にCIOになります（笑）
タイトルに惹かれて予約して買ったのだが。。。
「ブロックチェーン技術」とは謳っていますが、技術的な面には全く触れず、一般人受けを狙っているが故か、漠然とした内容が書かれているだけ。（しかも内容的に古い）
よく、2000円前後のビジネス本だと、ペラッペラな内容のものがあったりしますが、技術書でそれはやめて欲しいな〜という感じ。（技術書ではないけど）
まだ新しい分野のブロックチェーンでこういう本が出てくるのは残念です。
やっとスマートコントラクトに関するちゃんとした技術書が出た。
前半は一般的なブロックチェーンに関する内容なので読み飛ばして、ポイントはPart4の10章から12章。
ここにセキュリティを考慮したパターンとコードサンプルが出ています。
Reentrancy問題を回避する為のCondition-Effects-Interactionパターン。
pull型で送金を行う為のWithdrawパターン。
問題発生時にシステムを緊急停止する為のCircuit Breakerパターン等々。
対策を施さなかった場合の問題も含めて、具体的に丁寧な解説が続きます。
こういう本が早く欲しかった！
この本を読み終わった翌日に、なんと偶然にも著者の方と打ち合わせをする機会があり、そのご縁で色々と仕事のご協力を頂いています。
技術とは全然関係ないですが、「縁」って面白いですね。
この先、色々な知見がストックされ、さらにいい本が出てくるとは思いますが、現時点（2018年1月）ではスマートコントラクトに関わる技術者には必読の一冊です。
意外なことに、スマートコントラクトにテーマを絞った本って、まだそれ程世の中に出回ってないことを知った。
日々色々なニュースでブロックチェーンを活用したPoCの記事を目にするが、まだまだ「普及した」技術にはなっていないということか？
実際にEthereumとかを使って動くモノを作るのが、技術の習得には一番早いのだが、実践に入るにあたって、スマートコントラクトがブロックチェーン上で動く仕組みを前提知識として理解したり、コード作成からデプロイまでの作業イメージを事前に掴むにはいい本だと思います。
これからスマートコントラクトの開発をしようという方は、ざっと目を通しておくとより理解が早まるかと。
本のタイトルからすると（流行りの、〜の「教科書」）ビジネス寄りの本の印象を受けますが、内容的には技術寄りの本です。
ある程度のシステム開発知識がないと読むのは難しいかと思います。
ビットコインのブロックチェーンプラットフォームを中心にまとめられていて、概要レベルで全体を俯瞰するには向いていますが、ちょっと痒いところに手が届かない、という感じ（笑）
最近のコメント