勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

Project Management

エンジニアリングモデルとコントラクタモデルと納期のはなし

牛尾さんの「納期がなぜ生産性をぶち壊しにしているのか?」という記事を読んで考えたこと。あるいはインターネットが屑情報ばかりになってしまう現象への個人的な抵抗。

汎用的なデジタルリーダーシップ本としての「プロダクトマネージャーのしごと第2版」

先日、オライリーのSNSキャンペーンで当選して「プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド」をプレゼントいただいた(皆さんも根気強く申し込みましょう)。自分は普段プロダクトマネジメントを仕事としているわけではない(サポー…

最近読んだフィードバックに関する本を3冊紹介する

先日読み終わった「みんなのフィードバック大全」が面白かったのだけれども、ふりかえってみるとフィードバックというテーマの本は他にも何冊も読んでいた。おそらく深層意識のどこかでフィードバックに関する課題感を感じているのだろう(大げさ)。復習も…

エンジニア目線で「記者ハンドブック(第14版)」をチェック

SNSのタイムラインで「記者ハンドブック 第14版 新聞用字用語集」が話題だったので手に取ってみたら非常に良かった。現代では短文で明確なコミュニケーションをすることの重要性が高まっている。校正ツールに頼れば良いという考え方もあるだろうが、理屈を知…

要件定義ではHowじゃなくてWhatを語れという話

ソフトウェア開発における要件定義では「要件定義ではHowじゃなくWhatを語れ」とか「UIの議論の前にシナリオ/ユースケースを整理しろ」という話を最近何度かすることがあった。この考え方は過去のいろいろな学習経験とプロジェクト経験から来ているのだけれ…

GoogleのSRE本の続編(?)「インシデントの解剖学」を読んだ

最近よく聞いているSRE系のポッドキャスト e34.fmのep17で紹介されてた、GoogleのSRE本シリーズの最新作(?)「Anatomy of an Incident(インシデントの解剖学)」を読んだメモ。ポストモーテム(検死解剖)から展開して、Anatomyは解剖学というわけだ。sre.go…

エンプラ技術者の知識継承がうまくいっていないかも、という話

最近読んだ「Web世代が知らないエンタープライズシステム設計」はとても刺激的で良い本だった。企業の情報システム部門およびエンタープライズシステムを受託開発するSIerの中堅技術者は必読だと思う。ただ、書籍タイトルは中身を分かりにくくしている気がす…

Building successful communities of practice 読んだ

「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」で紹介されていた「Building Successful Communities of Practice: Discover How Connecting People Makes Better Organisations (English Edition)」が気になったので調べてみたら…

ゼネラリスト育成としてのGoogle APM

今、「ブリッツスケーリング」を読んでいるのだけれども、ゼネラリスト育成についての説明でGoogle APM(Associate Product Manager Program)が紹介されていたので、オッと思っていろいろと調べてみた。APMをゼネラリスト育成プログラムとしては見ていなか…

データソース全体の整合性/クレンジングの重要性をNASAの事故に学ぶ

有名なソフトウェアのバグ事例の一つにNASAのマーズ・クライメート・オービターの事故というものがあるのだけれども、これをデータソース全体の整合性やクレンジングの重要性を説明する際に使うというのは良いアイデアだと思ったのでメモ。 マーズ・クライメ…

式年遷宮アーキテクチャに関して(いまさら)

数年前に流行したソフトウェアアーキテクチャのメタファー(?)として「式年遷宮アーキテクチャ」というものがある。最近自分が日本美術史の授業で聞いた話を踏まえると、われわれエンジニアは式年遷宮をちょっと誤解しているような気がする、という話。い…

「エンジニアリングマネージャが知るべき97のこと」を対話的に読む(1)

約10年前にいくつか邦訳されて話題となった「〇〇が知るべき97のこと」という技術書シリーズがある。このシリーズが最近復活したようだ。〇〇には現代的なエンジニアロールが入っているので面白そう。翻訳されるかと思ったけれど、その気配もないので原著で…

「Retrospectives Antipatterns」を読んだ

先日「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」を読んだばかりだけれど、別の調べ物をしていたら「Retrospectives Antipatterns」という本が最近発売されたことを知ってしまったので勢いで読んでみ…

More Effective Agileの後半部分も読んだ #デッドライン読書会

読むのが骨な(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第17回。今回はSteve McConnell氏の「More Effective Agile」後半部分(13章以降)がノルマである。最高にオス…

『他者と働く』を読んで考えたこと #デッドライン読書会

対象を決めたら2週間で読み切り、アウトプットして、感想戦をするという読書会企画の第15回。今回の対象は『他者と働く』である。この本は一度読んでいたので再読になる。良い本なのだけれども、なんだろう、この違和感は。他者と働く──「わかりあえなさ」か…

アフターコロナ時代を想定して分散アジャイル開発について調べてみた(Agile Software Development with Distributed Teams)

ウィズコロナなのかアフターコロナなのかはよくわからないけど、今回の新型コロナ感染拡大の事態を踏まえて分散アジャイルについての勘所について整理しようと思って、いろいろな調べてみた。世の中にはTips集と精神論ばかりが溢れている気がする。知りたい…

『チーム・ジャーニー』第2部を含めて読み終わった #デッドライン読書会

対象を決めたら2週間で読み切り、アウトプットして、感想戦をするという読書会企画の第14回。今回の対象は『チーム・ジャーニー』である。味わい深い本であるため、2回に分けることにしていて、今回は後半である第2部および全体の感想だ。前半の感想はこち…

『みずほ銀行システム統合 苦闘の19年史』読んだ #デッドライン読書会

対象を決めたら2週間で読み切りアウトプットしてから感想戦をするという読書会企画の第12回(意外と続いている)。今回の対象は『みずほ銀行システム統合 苦闘の19年史』である。みずほ銀行システム統合、苦闘の19年史 史上最大のITプロジェクト「3度目の正…

情報システムの障害状況ウォッチ(2019年後半)

趣味の情報システム障害状況ウォッチ。前回に引き続き、今回も駆け足で確認。元ネタはこちら。みんな見たほうが良いよ! www.ipa.go.jp これまでのウォッチ履歴 情報システムの障害状況ウォッチ(2019年前半) - 勘と経験と読経 情報システムの障害状況ウォ…

複雑なシステムはどのようにして失敗するのか(How Complex Systems Fail)

How Complex Systems Fail – Perspectives の記事で紹介されていた「複雑なシステムはどのようにして失敗するのか(How Complex Systems Fail)」という論考が興味深かったので紹介する記事。 How Complex Systems Fail(PDF) 詳細はリンク先のPDF参照だが、紹…

2012年のKnight Capitalのシステムトラブルについて調べた

名前だけは知っていた有名なソフトウェアトラブルの事例。「巨大システム 失敗の本質―「組織の壊滅的失敗」を防ぐたった一つの方法」という本で詳しく語られていたのを見て興味が沸いて、いろいろ調べてみた。今は調べたことを、少し後悔している。 米ナイト…

情報システムの障害状況ウォッチ(2018年後半)

趣味の情報システム障害状況ウォッチ。前回に引き続き、今回も駆け足で確認。元ネタはこちら。みんな見たほうが良いよ! 情報システムの障害状況一覧:IPA 独立行政法人 情報処理推進機構 2018年後半(7~12月)の傾向 2018年前半はかなりハイペースで障害が…

腐ったリンゴ理論/ヒューマンエラーを理解する

DevOps関連の書籍(DevOps HandbookやEffective DevOpsなど)やPostmortem関連の記事でよく引用されている書籍「ヒューマンエラーを理解する―実務者のためのフィールドガイド」について調べたメモ。ヒューマンエラーを理解する―実務者のためのフィールドガイ…

ゲリラでない採用面接ガイド(自分用)

ほぼ自分用メモ。人材の採用面接はいつも悩ましくて、いろいろ調べたり考えたりしている。いっぽうですぐに調べたことを忘れてしまう(だって人間だもの)のでストアしておく記事。定期的に更新していきたい。 現時点の採用面接の基本方針 所属組織のガイド…

紙駆動開発とのつきあい方

開発者向けのPodcastの「しがないラジオ」を聞いていたら、SIer受託開発で「紙駆動開発(Paper Driven Development)」がキツかった的な話が面白かったので、いろいろ思うところを書いてみる。 しがないラジオ sp.19a【ゲスト: Dear_you_cry】楽しい!?PL/…

軽めに情報システムの障害状況ウォッチ(2018年前半)

趣味の情報システム障害状況ウォッチ。2017年後半のウォッチが飛んでいるのは自分自身とか所属組織が巻き込まれたとかではなく、単に忙しくなって忘れていたから。とはいえ現在も忙しいので個別事象のピックアップは省略。過去に書いた関連記事は以下の通り…

PagerDuty Incident Response Documentationが良さそう(Site Reliability Engineering Workbookつまみ食い#1)

前回の記事で紹介した「The Site Reliability Workbook: Practical Ways to Implement SRE」が気になるので、興味があるところから適当に読んでいる。The Site Reliability Workbook: Practical Ways to Implement SRE作者: Betsy Beyer,Niall Richard Murph…

産業安全についての神話(Some myths about industrial safety)について調べた

The DevOps ハンドブック 理論・原則・実践のすべてで紹介されていた「産業安全についての神話」(補章E)が面白そうだったので調べてみた。ソフトウェア開発に限らず、工学全般の話。The DevOps ハンドブック 理論・原則・実践のすべて作者: ジーン・キム,…

「5億ドル?!を吹っ飛ばした、たった1つのバグ!」について調べた

久しぶりのブログ更新。書籍「ZERO BUGS シリコンバレープログラマの教え」を読み終えた。この本の中で紹介されている歴史的なソフトウェア障害が気になったのでいろいろ自分で調べてみたメモ。トラブル好きなもので。 View this post on Instagram A post s…

Incident Command Systemについて調べた

Google SRE本を読み終わった。いや、これはすごい本だ。しかし非常に広範囲なプラクティスの詰め合わせ(というか論文集だ)のため、完全に消化不良である。ゆえに、同書で気になった箇所を少しずつ整理検討しているのだけれども、そのひとつがIncident Comm…