勘と経験と読経

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

Project Management

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

SEC Journal50号で2017年後半の情報システム障害状況まとめが公開されたので読んでみる記事。単なる野次馬なんだけれど、勉強になるので続けている。過去に書いた関連記事は以下の通り。 日経コンピュータ2017/8/3号特集「変わるITトラブル」を読んだ - 勘と…

上司・部下間のコミニュケーションのKY問題

最近コミニュケーションに関するいくつかの問題が身近にあって、いろいろと考えたことを書く記事。上司部下間のコミニュケーションの問題には階層があって、いちばん改善すべきなのは部下側ではなく上司側の問題だと思っていることについて。なお、顧客との…

日経コンピュータ2017/8/3号特集「変わるITトラブル」を読んだ

趣味のITトラブルウォッチャー活動として、日経コンピュータ2017/8/3号の特集「変わるITトラブル 実例1096件分析、新事実が明らかに」を読んだ感想。日経コンピュータ創刊の1981年から現在まで「動かないコンピュータ」コーナーなどに掲載された事例を分析し…

ポジティブな客先常駐システム開発を考える

株式会社アクシアさんのブログで、常駐開発バッシング(?)記事が最近掲載されている(http://axia.co.jp/2017-08-01)ことについて考えている。指摘されているような「不適切な常駐開発」というのは確かにあるのだろうけれども(ちなみにあまり目撃したことはな…

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

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 そういえば障害発生時の対応フローは、割と標準的なものが無いような気がする(不勉強で知らないだけかもしれないけれ…

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

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

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

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