榊原彰のレビュー一覧

雲をつかむような概念であるdevops。これをアメリカの老舗自動車部品メーカーを舞台とした小説で体感させることを狙った小説。
本書ではdevopsが仕事の4つのタイプと3つの道に沿って解説される。その根本には『ザ・ゴール』のTOC理論がありボトルネックになっているものから仕事をはぎ取ること、加えて、...続きを読む3つの道で示されるバッチサイズを小さくすることがある。
TOC理論で示されるように、いくら周りが頑張っていてもボトルネックが解消されない限り、その努力は無駄だし、WIPが積み重なるように無駄が無駄を呼ぶことにもなりかねない。また、バッチサイズが大きいとリリースまでの時間が長期化し、ビジネススピードから遅れていく。そのためにはバッチサイズを小さくする必要があり、だからこそアジャイルとも親和性が高いということなのだろう。またスピードアップのためには1日複数回のデプロイを可能とするための運用の効率化、標準化も必要ということになるけれど、これも小さく始めるということを前提に進める必要がある。
本書の内容をすべて汲み取れたとは言えないけれど、再読する価値のある良書。

ソフトウェアエンジニアの仕事とは何か、そしてなぜそれが重要なのか、どうやって実践するのか、が書かれている本
現代のソフトウェア開発の権化とも言える一冊

ソフトウェア工学を工学たらしめるーー。そんな使命感が充満している。
継続的デリバリー。継続的リリース。TDD。DDD。アジャイル/DevOpsの文脈を解する人であれば、初見の概念やプラクティスに出会う確率はそう高くない。新しい出会いをもたらすのではなく、私達が長年かけて学び実践してきたことを、あらた...続きを読むめて工学としてまとめなおす試みなのだ。
なぜ密結合より疎結合を目指すべきか。なぜテストはコードより前にあるべきか。くどいくらいに反復されるWhyからは、筆者のそれに対する信頼と自信、そして未だにそれらがなされない現場が少なくないことをなんとかしよう、という気概が漲っている。

アジャイル、継続的デリバリー、DevOpsを飲み込んで、その本質を明らかにし、その先を開こうとする一冊。これらのプラクティスだけでなく、DORAのReseach、チームトポロジーといったものを飲み込んで現代のソフトウェアを工学として定義した。クラフトマンシップからソフトウェアエンジニアになるための一...続きを読む冊だ。

この本に書かれている内容は上記の事柄を知る人たちにとって新鮮なものはない。だけど、これらに存在する共通的な工学的であると言える原則を定義した。この原則は時間が経過しても簡単に陳腐するようなものでなく応用が効くものだ。

この本に私に与えた影響は自信だった。私はアジャイルを学んで、その本質はよりよいソフトウェアを作ることだと、考えてきた。この考えにこの本は応えてくれた。おかげで私は自分の考えを漸近的にすすめ、学習を深めていける自信を持つことができそうだ。

この本と合わせてClean CraftmapshipやAcceralate(LeanとDevOpsの科学)など読み進めても面白いだろう。

アーキテクチャをデザインするにあたって、パフォーマンスや柔軟性など多数の観点から考えなければならないことをひたすら体系的にまとめた本でした。

パフォーマンスや組織など多数の観点について、図示の方法、チェックリスト、主な落とし穴などがまとまっているので、じっくり1回読んで終わり、ではなくどんな本かさ...続きを読むらっと目を通した後は、気になったときに辞書的に使うのが良いかと思いました。

実は、例えばある処理を実現する場合には A と B の間にキューを挟むといい、というようなアーキテクチャデザインについて学ぶことを想定して買ったので、失敗したと思いましたが、読んでいくうちにすごい本を見つけたと思うようになりました。

私は、規模は非常に小さいですが、仕事で0からのシステム設計を主導する際に、手探りで行き当たりばったりになりながらも、回数を重ねるうちになんとなく自分なりの型を見つけて、型をブラッシュアップしつつシステム設計を進めていました。

自分なりの型が見え始めた段階でこの本が読めていたら、効率的に自分なりの型がブラッシュアップできたなと思います。

初めてシステム設計をする段階だと書いてあることが抽象的でピンと来ず、読むのも辛いぐらいだと思いますが、自分なりの型が見え始めた段階以降でこの本を読むと学べる部分が多いと思います。

IT業界で働く人は、ひとつの並行宇宙で進行しているような話として読んでみると面白いのではないか。VR転職というか、エアー出向というか。実際にはもっと行きつ戻りつ紆余曲折あると思うが、ひとつのケーススタディとしては申し分ないと思う。でも、アメリカって本当に最初グズグズでも「レジスタンス」よろしく各自の...続きを読む持ち分を相乗効果にしてけっこうとんでもないことを成し遂げてしまったりするんですよね。これは日本になかなかできなくて、最初のグズグズを見てバカにしてると最終的にはすごい成果を見せつけられて愕然とする、とか。

自動車部品メーカーのIT部門を舞台にした小説です。
この組織では以下のような問題を抱えていて、自分の職場状況と照らし合わせても他人事とは思えません。
・５分で済む変更のために20分かけて登録するのはアホ臭いと誰も使わなくなった変更管理システム
　→何かを誰かが変えて何かが起こっても誰も状況を把握でき...続きを読むない
・優秀な生き字引１人しか知らない部分の多いシステム
　→開発でも運用でも生き字引に仕事が集中してボトルネックに
・障害など予定外の割り込み仕事に振り回されるスケジュール
　→忙しさに追われ対処療法を繰り返した結果さらなる障害を引き起こす悪循環
・ただでさえ忙しいところに面倒を持ち込むセキュリティおじさん
　→本当に必要悪なのか
・etcetc

抽象的で不文律な面が多い仕事というものを分割し、並べなおし、再定義することでコントロール可能なものとし、最終的には自動化により効率面でのブレイクスルーを果たす。。

職場では運用しつつ開発しているのでDevOpsと言われてもイマイチピンときませんが、会社の経営目的とITとの関係を整理するシーンを読んでいて、Devを弊社、Opsを顧客に置き換えると出来ることがあるかも…と感じました。（Opsって保守運用ではなくビジネスの方だったのね…って今更ながら）

小説なので小難しいことはなく、純粋に読み物として楽しめます。
年次を問わずお勧めできる(得られるものは異なると思いますが)本でした。

■5つの理想
第１の理想－局所性と単純性
第２の理想－集中、フロー、楽しさ
第３の理想－日常業務の改善
第４の理想－心理的安全性
第５の理想－顧客第一

　エンジニアが現実にいる人ではなく、抽象的な存在として”顧客”を考えると、まず正しい結果を生み出せない。

「ソフトウェアのデリバリーでリードタイ...続きを読むムが重要だってことは、ニコール・フォースグレン博士とジェズ・ハンブルの研究でわかったことだ。コードデプロイのリードタイム、コードデプロイの頻度、問題解決時間を見れば、ソフトウェアのデリバリー、運用の能力、組織の能力がわかる。そして、これらは社員の燃え尽き、社員の士気、その他さまざまなものと相関してる。」
　単純性が大切なのは、単純じゃなきゃ局所性が得られないからだ。システムを疎結合に保ち、機能のデリバリーをスピードアップしたければ、コードの局所性が必要不可欠になる。局所性が実現されていれば、チームはまわりのチームのことを気にせず、お客さんにとって価値のあるものをすばやく開発、テスト、デプロイできる。組織に局所性があれば、チームの外の人々と話し合って調整しなくても決定を下せる。現場の仕事からかけ離れていて、いい判断を下せる基盤がない権威や委員会なんてもんから承認をもらう必要もなくなる」

「…日常の仕事の改善を重視していかなきゃダメなんだ。日常の仕事以上にそっちに力を入れなきゃならないくらいだ。そこまで徹底して局所性の実現に集中しなきゃ、どんなシステムでも時間とともに劣化し、技術的負債のなかに埋もれちまう。…」

「いろんな定義があるけど、私が気に入っているのはウォード・カンニガムが2003年に作った定義だな。彼は、『技術的負債とは、次の機会に書き換えたいと思うもののことだ。』って言ったんだ。人々が技術的負債と呼んでいるもののなかにはいろんなものがあるけど、たいていはクリーンアップしたいもの、単純にしたいものとか単純さを取り戻したいもののことだね。直せば、自信を持って早く安全にシステムを変更できるようになる部分だ」

「技術的負債になるのは、たとえばプログラマーに早くフィードバックを渡せないビルド、テストシステムがそうだし、この手のシステムが動かなくなったときもそうだ。それから、単純なコンポーネントがコンプレクトになって、莫大な労力をかけたり、大事故のリスクを背負ったりしなきゃ何をしてるのかわからず書き換えることもできないときもそうだね。意思決定プロセスや組織構造に局所性がなくなり、小さな決定を下すために、エスカレーションが必要になる、君たちが罵倒する”官僚主義”もそうだ。

　私はこういったものを全部“複雑性負債”って呼ぶことにしている。これは単なる技術的な問題ではなく、ビジネスの問題だからね。で、こういった負債にはあれとこれのどっちを選ぶかって問題がかならずくっついてくる。新しい機能を作るか、複雑性負債を全部返済するかっていうようにね、機能を作ることのために自分の時間を全部使っちゃうバカがいると、簡単な仕事が難しくなり、実行に時間がかかるようになるのは避けられないな。そして、0から始めようとすると、どんなにがんばっても、どんなに部下がいても、最終的には自分の重みのために潰れるだろうね」


「理想は5つある。第1の理想、局所性と単純性についてはもう言ったね。システムとシステムを作る組織に局所性が与えられるように仕事をデザインしていく必要がある。そして何をするにも単純でなきゃならない。コードのなかであれ、組織のなかであれ、プロセスのなかであれ、内部に複雑さがあるのはだめだ。外部はもう十分複雑なんだよ。だから、自分たちでコントロールできるもののなかに複雑さが持ち込んだら大変なことになっちゃう」

「第2の理想は集中、フロー、楽しさだ。これはみな日常の仕事で感じるようにしたいことだよ。退屈して自分のためにほかの人が仕事をしてくれるのを待っていないか？全体を見ないで全体のごく小さな一部の開発とだけ考え、デプロイで全体が吹き飛んでいても自分の作業の結果しか見ず、火消し、懲罰、燃え尽きを招いていないか？それとも､小さなバッチ単位、できればひとつの新機能単位でデプロイし、継続的にスピーディなフィードバックを得ているか？これらは、仕事に集中とフロー、挑戦、学習、発見、担当分野のマスター、そして楽しみを生み出す条件だ。

「…第3の理想は、日常業務の改善だ。日常の仕事自体よりも日常の仕事の改善を大切にしなきゃいけない｡そのことを教えてくれるトヨタのアンドンの紐についてよく考えよう。第4の理想は心理的安全性だ。問題の解決のためには問題の予防が必要で、問題の予防のためには率直さが必要だ。そして、あとでどうなるかわからないという怖さがあれば、率直になどなれない。工場では、身体的な安全と同じくらい心理的安全性、つまり安心感も大切なんだよ。そして第5の理想は、顧客第一、つまり機能などがお客さんにとって本当に必要なものかどうかを徹底的に批判的に考え抜くことだ。お客さんがこの機能のためにお金を出す気になるか、それとも自分たちの職場の都合からくる自己満足に過ぎないのかってことさ」


「…
　技術的負債は、納期と同じ日常のことだ。ビジネスの人々は、納期のことはわかっても、技術的負債もあるということをまったく知らないことが多い。技術的負債は、それ自体ではいいことでも悪いことでもない。技術的負債が生まれるのは、日常の仕事のなかでいつも決断を迫られるからだ。長持ちしないことがわかってても、仕事の都合で近道を通ったり、自動テストを省略したり、特定の条件のためにハードコードしたりすることがあるだろう。日常的に、手作業で環境を作ったり手作業でデプロイをしたりといった次善の方法で我慢する場合もあるよな。こういったことが将来の仕事の進捗にどれぐらい大きな影響を与えるかがわかってないと、大きな問題を起こすわけだ」

「…
　これは従者を引っ張るリーダーシップじゃなくて、変身を促すリーダーシップだ。組織のビジョンを理解し、仕事のやり方についての根本的な前提条件を疑うアグレッシブな知性と人の心を動かすコミュニケーション能力を持ち、メンバーの特徴を把握し、支える指導力がなきゃいけない。…」
「…最高の能力を持たなきゃいけない。とことん完璧を追求し、できる限り早くミッションを達成しようという気概を持ち、現状維持に決して満足せず、組織が奉仕する人々をしっかり支えようという熱意を持たなきゃいけない」

　マキシンは、ミーティングの経験から、心理的安全性を実現する条件がいかに薄弱ではかないものかを強く感じるようになった。心理的安全性は、リーダー、同僚の行動、雰囲気、自尊心、過去から引きずっている心の傷といったものによって左右される。

システム開発プロセスの課題を、工場の見学によって俯瞰して洞察を得て、マネジメントに活かしていく物語。タイトル通りのDevOpsの文脈としてだけでなく、普段の業務プロセスのどこに無駄があるのか、それに対する解決のアプローチは製造業からヒントを得られることが多そうだと気付いた。アジャイルやスクラムを学ぶ...続きを読むのもいいだろうけど、この本の学びを深めるために次はトヨタ・ウェイやザ・ゴールを手に取ろうと思う。

・ITの4種類の仕事―ビジネスプロジェクト、IT運用プロジェクト、プログラム変更、予定外の仕事。技術的負債を放置しておくと、予定外の仕事しかできなくなる
・（過度なセキュリティを追求する担当者に対して）会社にとって最大のリスクは、監査所見を解決できないことではない。会社が生き残れないことだ
・「お前...続きを読むはボブではなく、俺の下にいるこを忘れるなよ。この体制で働けないなら、お前をすぐクビにする必要がある」
・「人は、終わりなく続くホラー映画のように、自分には結果を変える力がないと思うと、不満をためてありがたみを感じなくなる。そのことが人間としての自分の価値を傷つけないわけがない。そういう状況を変えなければならないんだ」

ざっくり言うと生産管理からITが学ぶことは沢山あるよという話。度々引用されるので、ザ・ゴールを読んでから本書を読んだ方がよい。CIO視点のビジネス小説として他に「ビジネスリーダーにＩＴがマネジメントできるか」があるが、そちらより学びが多かった気がする。しかし図があった方がもっとわかりやすかった。

私の知る限りでは、日本のITプロジェクトでは、アーキテクトという役割を専任で行うことはあまりない。大体が、要件定義、設計、コーディング、テスト、運用というフェーズごとに責任者、担当者がアサインされており、PMが全体を見る形である。
本書で説明されるアーキテクトは、主に要件定義から設計につながる部分で...続きを読む、問題空間と解決空間を調整しながら結びつけるのが大きな役割で、プロジェクト全体を通して解決策がユーザーの問題に適切に対処しているかを監視する。確かに、ここの役割をおろそかにすると、特にウォーターフォール型開発では、上流からのインプットを完全に正しいとして突き進み、いつの間にかユーザーの要望から乖離してしまう、ということが起こりがちだろう。
というわけでアーキテクトという役割が大切なのだが、この人が責任を持つソフトウェア・アーキテクチャを正しく構築するには、どのような観点で検討すればよいのかを、ビュー（視点）とパースペクティブ（側面）という分類でうまく整理している。やっぱり、PMBOKなどを生み出すだけあって、欧米は知識を体系的に整理するのが上手だ。こういうフレームを参照すれば、アーキテクチャにおける考慮モレは減り、より良いシステム構築につながると思った。

法改正の度に法外な改修費がかかる状況を何とかしたいと思い手にとった。
自社で開発、運用している状況だからできるのか。ベンダーに開発、運用まで任せている状況で、ユーザ部門まで束ねて情報システム部門で何ができるのか、特に「第2の道」をなんとかしたいなあ。

IT運用における問題や問題に対する対処、
運用改善、最終的には開発・運用の一体化までを
小説として書いた本。

嫌がらせをされるシーンもあったりと、
実際のIT運用に近い話が多かったような気がする。
おかげで面白く読むことが出来ました。

IT運用から改善を実現するには、
①現状をまずは改善する（小...続きを読むさく改善し、時間を作る）
　・運用フローを可視化する
　・運用を管理する
　・ボトルネックを見つける
　・運用フローを見直す
②業務とITの関連を把握する（業務を理解する）
　・どんな業務にITが必要なのか
　・そもそもどんなことにITを使っているのか
　・トラブルが起きて困ることは何か
　※個人的には、ココが極めて重要だと感じた。
③開発チームと一体となった組織を作る（クイックな組織）
　・開発と運用が繋がる箇所を整理する
　・整理した結果、自動化出来る部分を特定する
といった流れになるのだろう。

ザゴールのIT版。

基本的に、システム（ある程度規模がある）開発経験者でなければ、用語の理解や、開発現場の雰囲気の調整に難航しそう。また、加えて登場人物の多さも気になる。

日本のシステム開発従事者も、スキルや契約や何より、DevOpsの先にあるITが何のためにあるのかという視点を主人公率いるユニ...続きを読むコーンチームみたいに持てると、本当に素晴らしいことだと思う。システムを守るため、ではなくビジネスを強化、補強、推進するために、DevOpsでIT頑張ろうという話。


devops（以下、抜粋）
ビジネスニーズに即応するということは、ビジネスの変化に応じてITシステムの機能が追加されたり、変更されたりすること。
換言すると、ビジネスの好機に必要とされる機能が提供できないITシステムはお荷物ということになる。

これを解消するために、IT（システム開発）の様々な仕事をミクロな視点で捉えつつ、マクロな視野を得、本当に有用なものにして行く。本書では、開発と運用の一体化を図り、ビジネスニーズへの即応性をより高めるDevOpsを目指す。

IT部門の開発と運用、延いては全社的なビジネスとITの融合を図るまでの過程を本書でも言及されている「ザ・ゴール」のような小説仕立てで描き、コミュニケーションとコラボレーションの推進を訴え、目的の共有と全体最適を啓蒙する。

トラブルに次ぐトラブル、ビジネス側から突きつけられる厳しい要求、正にデスマー...続きを読むチ、そして急転直下の和解とハッピーエンド、ハラハラドキドキしながら読み進めることができた。ただ、主人公のビル・パーマーが辞意を表明したからステーブ（CEO）が謝るまでの四日間での心変わりと謝罪が良く分からなかった。トップと対立したら辞意を表明すれば事態が好転する程、世の中都合よくできてないと思う。

アジャイル・スクラム、リーンスタートアップなど製造業のの方法論をITに展開したものが多い、本書も「ザ・ゴール」のIT的展開だろう、これからのIT業界は製造業に学ぶべきなのだろうか。

ITのプロジェクトがどんな風に進んでいくのか、
また最近流行りの（？）DevOpsがどんな概念なのかを知りたくて、
まずは小説から入ってみました。

欧米の小説な上に、自分の門外漢な領域でもあるので、
話の内容が完璧には分かりませんでしたが、
「それって情シスの仕事でしょ？」と安易に考えていたことに...続きを読む、
とても広い領域があって、
会社の戦略との繋がりも意識していく必要があるということが
よくよく分かりました。

結構骨太で、読むのがっ大変だったのですが、
読み進めてみると、大好きな本である「ザ・ゴール」のことが言及されていたりと、
どんどんストーリーにのめり込んでいきました。

非ＩＴ人間がこの分野を理解するのは、
ハードルが高いのですが、少しずつ理解を進めていきたいと思います。

序盤は主人公と周囲の人たちが酷い環境で仕事をさせられていたり、それにもかかわらず誰も改善しようとしないことなどに対するいら立ちに、共感を覚えることが多くありました。

中盤以降、主人公たちの尽力で改善が進んでいくのですが、なぜかあまりカタルシスを得られず…… 全編通してわからない用語が頻発していたこ...続きを読むともあってか、特に後半はあまり楽しめてなかったように思います。

前半だけなら☆５くらい楽しめていたような気がします。

思ったより読みやすかった。技術スタック的には、自分もやってきたのが並んでて、納得感あった。あるあるネタも、自分も経験あるやつ並んでた。自分のキャリア的に、大手SIerの経験がないのもあるだろうけど、ここまで官僚主義的手続きに技術レイヤまで縛られてる組織の中の人になったことがないので興味深く読めた。今...続きを読むのお客さんは、そーゆー組織多いので。お客さん全部、パーツ・アンリミテッド社より組織階層が深いので、うーん、とゆー感じではあるけど。大きい組織で、ビルドとかデプロイに無頓着なコーダがいるのは、個人的にゼロ年代後半には意識してたけど、今は減ったのかなあ。最後に出てくるコアとコンテキストの整理は、ちょうど気になってた問題なので、wardley mapsは調べてみる。
最近スライド見た、お金で追いつく話とも、関係を考えたり。