「ソフトウェア要求　第3版」の著者であるKarl Wiegersの新著が出ていたので、ざっと読んでみる記事（あるいは読んだ記録）。 「私はかつて、過去10年間でベストセラーになった要件エンジニアリングの本を10 冊を読んだことがあります。この1冊には、それらの10冊を合わせたものよりも有益な情報が簡潔に記載されています」-- Mike Cohn ここまで言われたら読むしかない。 Software Requirements Essentials: Core Practices for Successful Business Analysis 作者:Wiegers, Karl,Hokanson, CandaseAddison-Wesley ProfessionalAmazon もくじ もくじ 全体的な感想 ソフトウェア要求　第3版から何が省略されたのか 20のコアプラクティス #1: 解決策を

最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に

最近ネットを見ていると要件定義入門的な記事が目についたので思ったことを書いてみる記事。ITシステム開発における要件定義に関するあれこれ。 【2023/10/10追記】続編の記事を書きました。実践要件定義入門 - 勘と経験と読経 目次 要件定義に関するおすすめ書籍 その要件定義は必要か 要件は決められるのか 要件定義をすることがルールで定められているから要件定義をする必要がある 要件は定義できるのか 現行の業務マニュアルをベースに要件定義をするつもりのあなたへ 現行システムをベースに要件定義をするつもりのあなたへ 外部業者を呼ぶ前に考えるべき事 どこから外注するかを考える 要件定義の作業期間を見積もる 要件定義に関するおすすめ書籍 この後に何度も引用することになると思うので、最初に要件定義のおすすめ書籍を紹介しておく。と言っても紹介するのは1つだけだ。 ユーザのための要件定義ガイド第2版 作

いくつかの書籍に書かれたパフォーマンス分析に関するアンチパターンを整理してみた。ここに無いものでご存知のパターンがあればご教授いただきたい。アーキテクチャや組織のパターンはよく見るけど、対応手法に関するパターンってあんまり多くないのかも（もしくは単にアンテナ感度が悪いだけ？） 詳解 システム・パフォーマンス (Systems Performance: Enterprise and the Cloud)より 詳解 システム・パフォーマンス 作者: Brendan Gregg,西脇靖紘,長尾高弘出版社/メーカー: オライリージャパン発売日: 2017/02/22メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 第2章 メソドロジでいくつかアンチパターンが紹介されている(アンチではないほうのパターンも)。 書籍の内容の一部は、以下の翻訳記事および元ネタ記事と同様と思われる

「ソフトウェア開発プロジェクトの成功確率は3割」「ソフトウェア開発が失敗する原因は、往々にして上流工程（企画とか要件定義）にある」という都市伝説（？）に関して。これを説明する際によく紹介される業界データがやたら古かったり、引用があいまいだと感じることがあるので整理してみた記事。 日経コンピュータによるプロジェクト実態調査（2003、2008） 日経コンピュータ創刊900号記念、ITの過去、現在、未来 - ［プロジェクト実態調査800社 1］測る企業は成功率が2倍に：ITpro 日経コンピュータ創刊900号記念、ITの過去、現在、未来 - ［プロジェクト実態調査800社 2］成功の決め手は「定量管理」：ITpro 日経コンピュータ創刊900号記念、ITの過去、現在、未来 - ［プロジェクト実態調査800社 3］費用追加が増え，品質は向上：ITpro 日経コンピュータ創刊900号記念、ITの過

SEC Journal48号で2016年後半の情報システム障害状況まとめが公開されたので読んでみる記事。いろいろあってすでに2017年も4分の1が過ぎてしまったので今更感もあるのだけれど。 過去に書いた関連記事は以下の通り。 情報システムの障害状況ウォッチ（2016年前半） - 勘と経験と読経 情報システムの障害状況ウォッチ（2015年後半）、ポストモーテム - 勘と経験と読経 情報システムの障害状況（2015年前半）あるいは検死解剖 - 勘と経験と読経 SEC Journal最新号の入手はこちらから。 最新号とバックナンバー：IPA 独立行政法人 情報処理推進機構 情報システムの障害状況ウォッチ（2016年後半） 詳細はSEC Journalを確認いただくとして、掲載されているトラブル事例をいつもどおりニュース記事などとザックリ照らし合わせてみた。例によって調べているとお腹が痛くなる事案

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ

タイムラインで目に付いたこの記事を読んで考えたこと。 システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita そういえば障害発生時の対応フローは、割と標準的なものが無いような気がする(不勉強で知らないだけかもしれないけれど)。共通フレーム2013でも細かい定義は無かったし、他の書籍で読んだ記憶も無い。というわけでいったん経験的な知恵をアウトプットしてみようかと。 基本的な流れ 割と自分のイメージと似た障害対応フローが公共系システムのドキュメントとして公開されてたので流用する。ここから拝借したもの。 図にもあるように、基本的な流れは リカバリー対応（初期対応、一次対応） トラブル復旧作業（本格対応） 再発防止 が一般的だと思っている。 初期対応のフレーム 初期対応で考えることはだいたいこんな感じ。あわててプログラムを修正する前にやることがある。 問題調査のために

時間外学習に関するブログ記事をタイムラインで目にして考えたこと。ちなみに業務時間外に学習するかどうかは趣味の問題だと思っている。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない IT業界は技術の流れに置いていかれるとしんどい思いをする。業務時間外の勉強は必須だ。しかし、おかしな話ではないだろうか。なんで時間外に仕事のための技術を勉強しなければならないのだろうか。 本来であれば、業務に必要なことは業務時間内で教えるべきだと思う。だが、今時そんな余裕のある会社なんて無い。やって当然という雰囲気はあるが、やるだけの理由を説明できる人は少ない。大半が「仕事に必要だからやるんだよ！」としか言わない。 業務時間外で勉強をしなければいけない理由：101回死んだエンジニア：エンジニアライフ 業務時間外の勉強が必須なんてことはない

今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型本 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍（most thoroughly useful book）」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛

いわゆるエンプラ（笑）技術者向けにお勧めする本をまとめてみた。というか某方面からピックアップの依頼を受けて考えたもの。SIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。世の中的には「エンタープライズ」とか言われている領域をイメージしていただければよいかと思う（一部で、「エンプラ（笑）って何だ？」みたいな議論もあるみたいだけど、いまいちピンときていない）。なお、初心者向けにはなってはいない。 ソフトウェア開発ライフサイクル全般 共通フレーム いろいろと批判があることはわかっているけれども、ソフトウェア開発のゆりかごから墓場までに実施すべきタスクを全方位に把握するならまず共通フレームがお勧め。注意を払うべき様々な標準についてのインデックスとしても有用である。ただし、読んでて面白い本ではない。そして分厚い。なおIPAの有償セミナーで参加すると一冊貰える場合が

古い記事になるのだけれど、バージョン管理ツールにコミットログのNGワードを登録するという話が面白かった。ソフトウェアは思考がそのまま品質につながるようなところがある。思考停止に近しいワードを禁止してしまうのも手かもしれない。 コミットログのNGワード 注意するのも疲れるし、大抵の場合は注意しても直りません。 そんなわけで、私が面倒を見ている環境だとpre-commit-hooksを使って、規定のバイト数のコメント書かないとコミット出来ないようにして対応しています。 コミットコメントを意地でも書かせたい - almost nearly dead 単にコメント無しを規制するだけではなく、思考停止してしまうようなワードを禁止しているのが素敵。 また、これに加えて会社名や人名も禁止してしまうのはうまいやり方だと思う。人の名前が出てくるとそこで情報が隠蔽されてしまうし、「問題 VS 我々」のスタンス

ときどき「社内勉強会をやってほしい」という事を言われることがあるのだけれども、基本的には断るようにしている。その理由について。 社内勉強会は言われて始めるものじゃない 「社内勉強会をやってほしい」と人に言われても基本的には断っている。こういったことを言うのは自分の上司や関連部門の偉い人に多い。言う人は、きっとこんな期待をしている。 メンバーの底上げやレベルアップ 生きた知識を現場間で情報共有する メンバー間の交流でより良い結果が得られるようになる でも実際に言われるがままに勉強会を企画しても、 人が集まらない 発表者が偏る 発表者の負担が増えていき、開催されなくなる ということになるのがわかっているから、実施しないのだ。 どうしてこんな事が起こるのかというと、単純にマーケットが小さすぎて、企画が成立しないのだからだと思っている。そもそも、コミュニティ活動を真っ当に実施できているエンジニアは

最近とある人とかわした会話についての考察。ソフトウェア開発のベストプラクティスを組織の内側に求めても効果的ではない、というのが個人的な見解。むしろ害になることもあるのではないかと思っている。 以前に書いたこの記事も関連。 成功事例には興味がない - 勘と経験と読経 「ソフトウェア開発」とベストプラクティス Wikipediaで「ベストプラクティス」を引くと、こうある。 ある結果を得るのに最も効率のよい技法、手法、プロセス、活動などのこと。最善慣行、最良慣行と訳されることもある。また、仕事を行うために最も効率のよい技法、手法などがあるという考え方をいう。すなわち、適切なプロセスを確立し、チェックと検証を行えば、問題の発生や予期しない複雑さを低減させて、望ましい結果が得られると考える。ベストプラクティスは、多くの人々によって反復され、最も効率的で最も効果的であることが時間をかけて証明されてきた

前回公開したエントリ「開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経」へのフィードバックで、保守には設計書が必要なのではないか、というものがあった。その点については思うことがある。というわけで、保守という観点でソフトウェア設計書に関する考えをまとめてみた。ソフトウェア構築時に必要とされる設計書と、保守の際に必要とされるものは異なるのではないかと考えている。 議論の前提：仕様書と設計書 再掲になるけれども、ここでは仕様書と設計書という用語を以下のように定義する。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 そして、改めて説明する必要は無いと思うけれども仕様書は保守

最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日本型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォールで全然ダメで それをアジャイルなら変えられないかと思って」 いったい誰と戦っているんだ・・・・・・ History of WaterFall - Speaker Deck 真の敵はこいつだ！ ソフトウェアファクトリ software factory / ソフトウェア工場 / ソフトウェア生産工場 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、

SIerがオワコンだったり新人SEが絶望する今日この頃。組織を憂う前に自分が技術者として終らないようにするほうがよっぽど建設的だと思っている。ひとこと「勉強しよう」というのは簡単。それよりも先に、職業倫理について考えてみるのはどうだろう。 職業がプロとして成熟した証の一つは、倫理規定または職業上の行為の水準が存在することである。 ソフトウエア開発プロフェッショナル　第20章 専門的職業の倫理規定（P239） マコネルの会社のエンジニアが最初に学ぶこと コンストラックスは、Code Completeで有名なスティーブ・マコネルの会社である。同社の専門技術者育成プログラムがソフトウエア開発プロフェッショナルに紹介されていて興味深い。英語版は以下からダウンロードできるようだ。 Construx Professional Development for Software Organizations

「「データモデルなきアジャイル」の危うさ: 設計者の発言」を読んで考えたこと。業務ソフトウェアの開発において、データベースを進化設計するのは厳しいと思っている。確かに技術的にはDBをリファクタリングしていくアプローチは可能だけれども、今のところは現実的な選択肢としては考えにくい。それではどうするか。 データモデルなしでアジャイルを始めてはいけない。少なくとも、DB全体の設計妥当性に関する何らかの担保がないままでアジャイルを強行してはいけない。DB構造の劣悪さゆえに企業活動の変化や発展に追随できない業務システム――皮肉にもそういうアジリティに欠けたシロモノをまたぞろひり出すことになるからだ。 「データモデルなきアジャイル」の危うさ: 設計者の発言 データモデルは単なるDB構造の話ではない 扱うビジネスの内容や範囲によるけれども、データモデルやDB構造は単なる記憶装置では無く、企業の資産である

時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ

コードと構成管理の取扱いについて。ソフトウェア開発プロジェクトで自分がプログラミングすることは基本的に無いのだけれども、プロジェクトマネージャとしてはかなりコードに触れるほうだと思っている。最近コードにまつわる興味深いブログ記事をいくつか見たので、これに対して自分の考えを少しまとめてみる。 コードレビューについて ここで紹介されている、構成管理システム(VCS)でのレビューコントロールがとてもエレガントだと思う。 レビューのために bug tracker や task management system を使うのはあまり良いとは思いません。 レビューでは非常に細かい点が議論されることがあり、これが仕事のタスクの一チケットに相当するとはとても思えないからです。 例えば、この変数名は短すぎて良くわからない、といったことのために bug tracker をブラウザで開き、チケットを切る、やってら