勘と経験と読経

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

Project Management

情報システムの再構築戦略についての現時点の理解整理

1月に公開されたIPA/SECさんの「システム再構築を成功に導くユーザーガイド」と、最近読んだ「レガシーソフトウェア改善ガイド」を踏まえて情報システムの再構築戦略について再整理してみる記事。再構築における、リファクタリング/リアーキテクティング/…

フォードのエベレストプロジェクト

「ジョイ・インク 役職も部署もない全員主役のマネジメント」で言及されていたシステム開発のトラブルプロジェクト事例「フォードのエベレストプロジェクト」について調べてみたメモ。2004年のシステム開発失敗事例の模様。ジョイ・インク 役職も部署もない…

ソフトウェア開発の失敗確率と、原因が上流工程にあるという根拠データを確認してみた

「ソフトウェア開発プロジェクトの成功確率は3割」「ソフトウェア開発が失敗する原因は、往々にして上流工程(企画とか要件定義)にある」という都市伝説(?)に関して。これを説明する際によく紹介される業界データがやたら古かったり、引用があいまいだと…

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

SEC Journal48号で2016年後半の情報システム障害状況まとめが公開されたので読んでみる記事。いろいろあってすでに2017年も4分の1が過ぎてしまったので今更感もあるのだけれど。過去に書いた関連記事は以下の通り。 情報システムの障害状況ウォッチ(2016年…

ソフトウェアにおけるアンチフラジャイルとレジリエンス

気になったキーワード「アンチフラジャイル」について調べてみた。また類似の概念「レジリエンス」との違いについての現時点の理解とそれについて思ったこと。 アンチフラジャイル 自分がこのキーワードを知ったのはInfoQの記事なのだけれども、Qiitaにも整…

カーゴ・カルト・ソフトウェア工学とか

そもそもソフトウェア工学が死んでいるという議論もあるかもしれないが、これとは別にカーゴ・カルト・ソフトウェア工学的な問題が拡大している実感があるので、それについて考えたことをちょっと整理してみるもの。国内で技術者教育の手法の主力となってい…

DIA(デンバー国際空港)の自動手荷物処理システム

有名なソフトウェア開発の失敗事例(トム・デマルコの「熊とワルツを」では「ろくでもないソフトウェア開発の象徴」とも呼ばれる)である DIA(デンバー国際空港)の自動手荷物処理システムについて、勉強がてら整理してみる記事。名前は知ってたけれど、ちゃ…

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

SEC Journal46号で2016年前半の情報システム障害状況まとめが公開されたので読んでみる記事。2015年度の分については以下のエントリを参照。生々しい話を読むと、自分がトラブルを引き起こす確率が減るんじゃないかと思っている。 情報システムの障害状況ウ…

ITエンジニアと法的要件の考慮

XP祭り2016で発表された「巷にはびこる間違ったUX論へのヘイトをぶつける集い」という発表をめぐる一連の議論を読みながら考えた事。ちなみにUXについては門外漢であるし、そこについての意見は無い。ただ、この中で出てくる「UXデザイナーは法律の考慮も行…

週報 / Snippetsのススメ

昔から習慣として「週報」を書くということをしている。最近発売された「 SOFT SKILLS 」という本を読んでいたら週報を書くことについて言及されていて面白かったので、「週報」についての自分の考えなどを整理してまとめてみた。 新しい会社に入るたびに私…

ソフトウェア見積もりと納期のいくつかの真実とウソ

ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もり…

残念なレビュー、あるいはレビュアー心得

ソフトウェア開発におけるドキュメントレビューについて最近考えていること。漫然としたレビュー、残念なレビューにより生産性が大きく損なわれていることが多い。とはいえ、自部門組織でもうまく改善できているわけではなく、どうしたらよいか悩んでいるの…

ウォーターフォール型開発プロセスの有効性

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から…

後進育成ついて考えたこと

「プロフェッショナルエンジニアは後進の育成よりも、自己の能力向上を優先すべきではないか」という意見を複数方面で見かけて考えたこと。管理者としての教育と、技術者としての後進教育は混ぜないほうがよいという意見。そしてエンジニアとして成長を望む…

最近のSIer論に想うこと

ここ数年、定期的にソフトウェア業界で盛り上がるのがシステムインテグレーター(SIer)のビジネスモデルに対する批判の話題である。いろいろと議論されるのは良いことだと思うのだけれども、自分の周りで不必要に不安を感じている人が多いのでいったん現時点…

IPA/SEC情報処理システム高信頼化教訓の2016/1~3の更新点を読む

IT業界(?)のトラブル情報を収集して、そこから教訓を抽出して公開するという取り組みをIPA/SECが行っている。わりと惰性でやっている感はあるのだけれど、2016年1月から3月までにいくつか教訓が追加されていたので目を通して感想を書いてみた。 情報処理シス…

情報システムの障害状況ウォッチ(2015年後半)、ポストモーテム

SEC Journal44号で2015年前半の情報システム障害状況まとめが公開されたので読んでみる記事。 前回記事はこちら。 情報システムの障害状況(2015年前半)あるいは検死解剖 - 勘と経験と読経 SEC Journal最新号の入手はこちらから。 SEC journal:IPA 独立行…

「ビヨンド ソフトウェア アーキテクチャ」あるいはパッケージソフトウェアの作り方

「ビヨンド ソフトウェア アーキテクチャ」に関する読書メモ。ソフトウェアアーキテクチャ全般に興味があるので手に取ったのだけれども、同書はざっくり言えばパッケージソフトウェアの作り方に関する本である。なんとなく、このタイトルでは必要な人の手に…

デス・マーチ著者Ed Yourdonさんの『ソフトウェア工学で大切な10の考え方』を再読する(後編)

前々回、前回記事の続き。デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが和訳を公開している『ソフトウェア工学で大切な10の考え方』を再読してみた。この後編では「9.一貫性は才…

デス・マーチ著者Ed Yourdonさんの『ソフトウェア工学で大切な10の考え方』を再読する(中編)

前回記事の続き。デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが和訳を公開している『ソフトウェア工学で大切な10の考え方』を再読してみた。今回は「5.欠陥が下流に「漏れる」と…

デス・マーチ著者Ed Yourdonさんの『ソフトウェア工学で大切な10の考え方』を再読する(前編)

デス・マーチ著者のEd Yourdonさんが先日(2016/1/22)亡くなったとのこと。合掌。これを機会に同氏が2009年に公開し平鍋さんが翻訳した『ソフトウェア工学で大切な10の考え方』を再読してみた。同資料のサブタイトルには「この困難な時代だからこそ」である。…

IPA/SEC情報処理システム高信頼化教訓がバージョンアップ

以前にこのブログで紹介したこともあるIPA/SECさんの「情報処理システム高信頼化教訓」がバージョンアップして、都度アップデートされるWebコンテンツになった(以前は分厚い報告書体裁のPDFだった)。これは何ぞと言うと「トラブルの原因や防止策が業界内で共…

デスマーチ対策を妄想する

はじめに書いておくがこの記事は冗談である。某所にてトラブル案件の防止策について議論した事がある。「トラブル案件発生の防止策を出しなさい」「あほか。必ずトラブルは起こる。何度でもな!」「むしろトラブル発生を前提として人間側を適応させたほうが…

障害発生時の対応フロー(初期対応、本格対応、再発防止)

タイムラインで目に付いたこの記事を読んで考えたこと。 障害対応方法 - システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita そういえば障害発生時の対応フローは、割と標準的なものが無いような気がする(不勉強で知らないだけ…

リーダーシップと口の悪さ、罵倒語と兵舎語

リアルで会ったことのある人はご存知の通りだけれども、自慢じゃないが私は口が悪い。というか意図的に乱暴な言葉使いをしていたりする。チームメンバーに的確に情報を伝達し、士気を保ち、コミュニケーションを促進するために乱暴な言葉を意図的に使ってい…

大モルトケ「計画することがすべてだ。立てた計画はどうでもいい」

「計画することがすべてだ。立てた計画はどうでもいい。」というのはドイツの軍人、陸軍元帥ヘルムート・グラフ・フォン・モルトケの言葉である。アジャイルに関係ない人にもお勧めの本「アジャイルな見積もりと計画づくり」で引用されているのが有名だけど…

IPA/SEC「ソフトウェア開発データが語るメッセージ2015」を読む

IPA/SECさんではソフトウェア開発に関するデータ収集を行っており、その結果は毎年公表される「ソフトウェア開発データ白書」に反映されている。ソフトウェア開発プロジェクトの見積りや品質管理でいろいろ活用できて便利なデータ集であるけれども、なかなか…

Visual Basicとドメインモデル貧血症とその他の影響

重い腰を上げて、実践ドメイン駆動設計を読み始めているのだけれども、第1章でVisual BasicがDis(?)られていて面白かったのでそのメモ。なお該当箇所はGoogleブックスで立ち読みできるようなので興味があれば以下リンクから該当箇所を読んでみると良いと思う…

情報システムの障害状況(2015年前半)あるいは検死解剖

SEC Journal42号で2015年前半の情報システム障害状況まとめが公開されたので読んでみる記事。残念ながら多くの障害事例は詳細が不明という残念な状況でもある。メメント・モリ。 SEC journal:IPA 独立行政法人 情報処理推進機構 メメント・モリ作者: 藤原新…

ユーザーストーリーテンプレートゾンビ

書籍「ユーザーストーリーマッピング」を読んでいたら、テンプレートゾンビの話が出てきて面白かった。テンプレートゾンビは、デマルコの「アドレナリンジャンキー」に登場するソフトウェア開発のアンチパターンのひとつだ。というわけでデマルコ本を再読し…

コード行数のインフォグラフィックが面白い

いろいろなソフトウェアに関するコード行数について興味を持っていて、さまざまな書籍やWebから拾い読んだ情報をまとめている。ひょんなことからコード行数のインフォグラフィックを見つけたのでご紹介。 Million Lines of Code | Information Is Beautiful …

Googleマネジメントの元ネタでもあるインテル経営の本を読んだ

ちょっと前に目に付いた「1 on 1 で 何を話すのか? マネージャ/ソフトウェアエンジニアの立場から」というブログ記事で紹介されていた「インテル経営の秘密―世界最強企業を創ったマネジメント哲学」を読んだメモ。かなり以前から気になっていたのだけれども…

ITエンジニアの業務時間外の学習

時間外学習に関するブログ記事がタイムラインで目にして考えたこと。ちなみに業務時間外に学習するかどうかは趣味の問題だと思っている。 101回死んだエンジニア: 業務時間外で勉強をしなければいけない理由 業務時間外の勉強が必須なんてことはない IT業界…

要件定義の工数の見積もり

いつか読もうと思っていた名著「ソフトウェア要求 第3版」をやっと通読し終わった。高価(定価が7000円超)なのがネックだけど要件定義のバイブルとしてはいい感じ。いろいろな論点があるのだけれども、要件定義の工数見積もりについての言及が興味深かったの…

ソフトウェア要求 第3版は何が変わったのか

いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる。割といろんな人から「この本は良い本だ」という話を聞くのだけれども、皆が読んでいるのはだいたい第2版だ。10年を経て更新された第3版は何が変わったのかというのは実は明確ではない…

ユースケースとユーザーストーリー

いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる。ユースケースとユーザーストーリーについての説明がすごい腑に落ちたので勢い余って書き付けるもの。アジャイル開発プロセスとユースケースの関係について。 ソフトウェア要求 第3版に…

ソフトウェア顧客の要求に関する権利宣言と責任宣言

いつか読もうと思っていた名著「ソフトウェア要求 第3版」を読んでゐる(例によってKindleのセールで購入。なお現在はほぼ定価に戻ってるので注意) 以前にこのブログで言及したソフトウェア顧客の権利と義務についての章を読んだのでその雑感と関連思考につ…

分散スクラム実用ガイドについて調べてみた

物理的に離れた拠点でアジャイル開発プロセスを実施すること、についてちょっと調べた際のメモ。なお、本によっては「スクラム オブ スクラムでやれば問題ない」といった乱暴な説明もあったのだが、そういった精神論はとりあえず無視。 ディシプリンド・アジ…

続:金融アプリサンプルでよちよちDDDを学ぶ

オンライントレードのサンプルシステムでDDDを学ぶという海外ブログ記事を読みながら、よちよち学習する話の続き。今回も参考情報をなぞっているだけなので、あまり役に立つ記事にはなっていない。前回記事はこちら。 金融アプリサンプルでよちよちDDDを学ぶ…

金融アプリサンプルでよちよちDDDを学ぶ

InfoQで「ドメイン駆動設計とは - 金融取引アプリケーションを例に」という記事が公開されていたのだけれど、これだけではさっぱり分からない。というわけで元記事をたどっていろいろと学んでみようと思う。学習記録なので、内容についてはまったく自信はご…

システム運用のメトリクスに関する研究報告読んだ

IPAの「情報システム運用時の定量的信頼性向上方法に関する調査報告書」(長いよ!)をナナメ読みした感想。システム運用について議論するときに網羅的で良い気がする。ITIL2011、ISO2000、JISA運用プロセス管理指標、JUASシステムの評価指標、IPA/SEC非機能…

IT人材白書2015ナナメ読み

無料だし、自分が属する業界に関する分析記事なので読んだのだ。「自分の仕事を憎むには、人生はあまりにも短い(ジョエル・スポルスキ)」だからこそ。 プレス発表 「IT人材白書2015」を発行:IPA 独立行政法人 情報処理推進機構 IPAが「IT人材白書2015」を…

WFとアジャイルと超高速開発・・・

ソフトウェアの開発プロセスの比較記事?を読んだ感想というかメモ書き。なお詳細が書かれていると思われる「ユーザー企業ソフトウェアメトリックス調査2015」は未刊行なので、うわべを見ての野次馬コメント。 ウォーターフォールとアジャイル開発はどちらが…

夜間バッチレスシステムに関する中途半端な覚え書き

2014年後半からAWSの事例で、東急ハンズさんが「夜間バッチレス」というキーワードを話されている。このキーワードがアタマに引っかかってモヤモヤするのでいろいろ調べたり整理してみたことを吐き出してみる記事。なお実際に本腰を入れて検討したわけでもな…

ITアーキテクチャの定義

以前「ITアーキテクトとは何か」という生煮えの頭の体操のような記事を公開したのだけれども、いただいた意見の中になるほどというものがあった。『「ITアーキテクト」という職種がエンジニアの上位職種みたいに定義されるからおかしいことになる。ITアーキ…

スケジュールの基本公式

開発スケジュールは人月の立方根に比例するという話。 つまりプロジェクトの全期間の長さは、それにかける必要工数の1/3乗におよそ比例する。この式によれば、たとえば00人月の工数がかかるプロジェクトでは、 2.50 * (100^0.33) = 11.6ヶ月 かかるだろう、…

設計レビューは間違いだらけか?

書籍「間違いだらけの設計レビュー」を読んだ感想と、その後に調べたり整理したことについてのメモ。設計レビューは間違いだらけではないと思うけれども、非効率な作業になっていることが多い。専任レビューアー、専任レビューイーという役割は基本的にない…

ITアーキテクトとは何か

割と身近なところで頻繁に「ITアーキテクト」という単語か飛び交っていて、もやもやしたので情報を整理しながら書く記事。オチはない予定。 photo by SantiMB.Photos ITアーキテクトの定義 例えばIPAの共通キャリア・スキルフレームワークでの(システムアー…

ググルナカス / 仕事とサーチ

もうそうもうそう。書籍「ディシプリンド・アジャイル・デリバリー エンタープライズ・アジャイル実践ガイド」を読んでいたらケーススタディの中で面白い会話があった。ある作業の方法が分からないので検索エンジンでリサーチをするかどうか、チームメンバー…

海賊船のリーダーシップ

リーダーシップに関する話。自分の理想に近いリーダーシップがあって、常にそこに近づきたいと考えている。実際に近づけているのかはわからないけれども。 photo by Joriel "Joz" Jimenezテストから見えてくるグーグルのソフトウェア開発作者: ジェームズ A …