「Docs for Developers」を読んだ - 勘と経験と読経
最近知った興味深いPodcast e34.fm で紹介されていたので興味を持って読んでみた本「Docs for Developers: An Engineer’s Field Guide to Technical Writing」に関するメモ。 2023/3追記：翻訳されたようだ。ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング e34.fmwww.oreilly.com この記事の目次 「Docs for Developers」はどんな本なのか 全般的な感想 各章に関する覚え書き Front Matter Chap 1. Understanding your audience Chap 2. Planning your documentation Chap 3. Drafting documentation Chap 4. Editing docum
腐ったリンゴ理論／ヒューマンエラーを理解する - 勘と経験と読経
DevOps関連の書籍（DevOps HandbookやEffective DevOpsなど）やPostmortem関連の記事でよく引用されている書籍「ヒューマンエラーを理解する―実務者のためのフィールドガイド」について調べたメモ。 ヒューマンエラーを理解する―実務者のためのフィールドガイド 作者: シドニーデッカー,Sidney Dekker,小松原明哲,十亀洋出版社/メーカー: 海文堂出版発売日: 2010/07/01メディア: 単行本この商品を含むブログ (1件) を見るThe Field Guide to Understanding 'Human Error' (English Edition) 作者: Sidney Dekker出版社/メーカー: CRC Press発売日: 2017/11/01メディア: Kindle版この商品を含むブログを見る 安全尊重の文化 DevOps推進
DevOps的な非機能要件（運用要件）リスト - 勘と経験と読経
The DevOps Handbookで紹介されていた The Top Ten DevOps “Operational Requirements” | DevOpsGroup を読んだら面白かったというメモ。国内ではあんまり取り上げられていないような気もする（もしくは私が不勉強で知らないだけ？） The DevOps ハンドブック 理論・原則・実践のすべて 作者: ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス出版社/メーカー: 日経BP社発売日: 2017/07/04メディア: Kindle版この商品を含むブログを見る 開発部門が下流の作業の状況をフォローし、本番インシデントの解決の作業に参加すれば、アプリケーションは次第に運用にとってよい設計になっていく。さらに、スピーディなフリーとデプロイのしやすさを正面から意識してコードやアプリケーションを設計するようになると、
Incident Command Systemについて調べた - 勘と経験と読経
Google SRE本を読み終わった。いや、これはすごい本だ。しかし非常に広範囲なプラクティスの詰め合わせ（というか論文集だ）のため、完全に消化不良である。ゆえに、同書で気になった箇所を少しずつ整理検討しているのだけれども、そのひとつがIncident Command Systemである。これはすぐに使いこなしたいプラクティスだと思っている。まぁ、仕事の規模や質次第かも。 SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司出版社/メーカー: オライリージャパン発売日: 2017/08/12メディア: 単行本（ソフトカバー）この商品を含むブログを見る
チーム内でやる進捗会議はムダ - 勘と経験と読経
ソフトウェア開発プロジェクトでは、顧客への定期的な進捗報告を行うために、当然のことだが進捗を管理しなければいけない。中規模以上のプロジェクトではプロジェクトはいくつかのチームに分かれていて、さらにチームごとに担当する会社が異なることもある。ありがちな事だが、チーム別にプロジェクト内の進捗会議を行うようになってくると、これが壮大なムダになっていく。 チームリーダーはソフトウェア開発プロジェクトのボトルネック ソフトウェア開発プロジェクトは、ウォーターフォール形式であれアジャイル開発プロセス型であれ、膨大なコミュニケーションと意思決定を行うことで進んでいく。ソフトウェアの仕様や構成について決定するのは、たいていはチームリーダーの仕事だ。また、各開発担当者の仕事の結果が正しいのかをレビューやインスペクションによって判定するのもチームリーダーの仕事であることが多い。そして、チームリーダーはチームメ
ソフトウェア見積もりと納期のいくつかの真実とウソ - 勘と経験と読経
ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もりというアクティビティの重要性は変わらないし、軽視してよいものではないというのが個人的な考え。 ウソ:ソフトウェアの納期見積もりは、星占いレベルのものである 論点を単純化するための釣りタイトルだと思うのだけれども、ソフトウェア開発における「不確実性のコーン」はスケジュールではなく、スコープ(工数、コスト、機能)の見積もりに関する分析であって、納期、スケジュールに関する分析ではない点には注意が必要である。 この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と
週報 / Snippetsのススメ - 勘と経験と読経
昔から習慣として「週報」を書くということをしている。最近発売された「 SOFT SKILLS 」という本を読んでいたら週報を書くことについて言及されていて面白かったので、「週報」についての自分の考えなどを整理してまとめてみた。 新しい会社に入るたびに私がまずしていたのは、何に時間を費やし、その日に何を達成したかを日録に書くことだ。その内容をもとに、毎週金曜日に週間サマリーを書いて上司に送ったのである。私はこれを自分の「週報」と呼んでいた。(中略)この週報は、私の存在をアピールするために役に立っただけでなく、人事考課の時期には自分自身にとっても役立つ資料となった。週報を読み返して、その年の主要な達成を拾い出せばよかったのである。自己評価を書くとき、私はその年にしたことを日付とともに正確に書けたのである。 SOFT SKILLS ソフトウェア開発者の人生マニュアル/第9章 出世階段の上がり方
「アジャイルソフトウェア要求」を読んだけれど - 勘と経験と読経
書籍「アジャイルソフトウェア要求」の読書メモ。いわゆるエンタープライズアジャイルに関する方法論の一つであるSAFe（Scaled Agile Framework）の解説書。ソフトウェア要求の本ではあるが、事業戦略からデリバリーまでの全ての範囲を含んでいるというのが肝であり、興味深い点である。 アジャイルソフトウェア要求 (Object Oriented SELECTION) 作者:Dean Leffingwell発売日: 2014/02/11メディア: 大型本 事業会社向け エンタープライズアジャイルというキーワードだと、本書と別にDAD（Disciplined Agile Delivery）もある。こちらも今読んでいるところなのだけれど、本書と比較すると、SAFeは事業会社向けの方法論であり、DADはSIer向けの方法論というように思えてくる。 ディシプリンド・アジャイル・デリバリー エ
ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
中級者でいることの価値が急落していく(むしろ害に？) - 勘と経験と読経
電波妄言の類い。「データによる意思決定」をテーマに三冊の本を読んだ。「グーグル ネット覇者の真実 追われる立場から追う立場へ」「WIRED VOL.5 GQ JAPAN.2012年10月号増刊」「その数学が戦略を決める (文春文庫)」。データによる意思決定の価値が高まるにつれて中途半端な専門家の価値は低下していく。ドレイファスモデルにおける「中級者」がむしろ害になっていくのではないか、ということを考えた。 ドレイファスモデルにおける「中級者」 「データによる意思決定」に対抗する「専門家による意思決定」のことを考えるとき、思い出したのはドレイファスモデルのことだった。ちなみにドレイファスモデルに関しては書籍「リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法」が詳しく興味深いのだが、なんと訳書の該当章(一章)がまるまる出版社サイトでダウンロードできるので興味を持った方には一
要求開発のホームグラウンドについての考察 - 勘と経験と読経
要求開発はソフトウェア開発の企画・要件定義向けの方法論ということになっている。しかしわたしはこれが適用できる領域は限られていると考えている（詳細はこちらのエントリを参照）。では、要求開発が適用できる分野はどこか。 要求開発のおさらい 本論に入る前に、いくつか要求開発のエッセンスをさらっておく。詳しくは以下の書籍やサイトも参考に。 - 要求開発~価値ある要求を導き出すプロセスとモデリング 要求開発のことを一言で言うと「企業の経営者・業務担当者・システム部の３者で、後のソフトウェア開発の結果が予想出来るくらいまでイメージをすり合わせて合意する（工程）」になる。逆にいえばイメージが合意できていないとソフトウェア開発はうまくいかないということだ。要求開発のコンセプト資料は公開されているのでそこから抜粋すると、要求開発が念頭に置いている失敗パターンがわかる。 たとえばトップダウンで強力に推進して失敗
上流工程の失敗カタログ - 勘と経験と読経
他のエントリを書いているところなのだけれど、面白い資料を見つけたので紹介。私は失敗談にこそ学びがあると思っているのだけれども、こんなところに上流工程の失敗カタログがあったのだった。 「要求開発・管理ベストプラクティスとその体系化の調査研究」(PDF) (2019/4/19 リンク切れを修正) 「要求開発・管理ベストプラクティスとその体系化の調査研究」を失敗カタログとして読む 「要求開発・管理ベストプラクティスとその体系化の調査研究」はタイトルの通りベストプラクティス集なのだけれども、それぞれのプラクティス毎に想定しているトラブル事例が興味深く、そして胸が熱くなる。 本来あるはずのレアケース、例外に関する要求が出てこない 顧客から要求が出てこない。実はもっと隠された要求があるのに聞き出せていないのかがはっきりしない 顧客との期待とは異なるシステムを開発してしまうことに対して、事前に調整する手
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
