勘と経験と読経

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

Project Management

書籍「インパクトマッピング」を読んだ

出版されてから随分経つけれどと、書籍「インパクトマッピング」を読んだ。マインドマップの文脈で、上位の階層に利害関係者が登場するのが特徴の価値のツリー構造といった印象。面白いけれど使いどころは難しいと思った。 インパクトマップの概略 ひとこと…

設計書からプログラム自動生成してコスト削減云々

雑な感想。「富士通のプログラマー不要ソフト - Togetterまとめ」を読んだ。日本語設計からプログラムを自動生成して、プログラミング作業が不要になるので大幅にコストが削減できると言う記事。案の定、いろいろと批判されているようだが…… 富士通のプログ…

現行システムの分析あるいは考古学

主に自分向けのメモ。ソフトウェア開発で常に悩ましいのがシステムの更改だ。様々な理由で古いシステムを新しいシステムに作り変えるのが簡単そうで難しい。単に同じものを作ればいいというわけではなく、「必要なだけ同等で、さらに良いもの」を作るのが兎…

IT訴訟 徹底解説を読んだ

ソーシャルメディアで流れていた記事を読んだ話。5月から連載されていたようだけど気づいていなかった。ソフトウェア開発における訴訟解説の話である。別に自分はこういった訴訟沙汰に関わったことはないのだけれど、いろいろと勉強になる。 「ジェイコム株…

ソフトウェア開発の性質(PMBOKガイド第5版ソフトウェア拡張に読む)

公開されたのは少し前のようだけど、PMBOKガイド第5版ソフトウェア拡張というものがPMIから公開されたようだ。これを紹介するInfoQの記事に書かれた「ソフトウェア開発の性質」が面白かったので、少し調べてみた。 PMBOK Guide第5版ソフトウェア拡張がリリ…

画面単位の単体テストが云々

「単体テスト(画面単位のテスト)がクソらしいので思ったことを書いてみる - うさぎ組」という記事を読んで考えたこと。割と雑に書く。画面単位の単体テストに関する個人的な考えたかたの整理的なもの。 画面単位の単体テストの是非 まず用語の定義から。「…

テストでExcelにエビデンス貼り付け云々

激しく周回遅れだけれども、「SIerの闇・Excelにエビデンス貼付け - Togetterまとめ」という話を読んで考えた事。あまり整理せずに書く。 photo by Remko van Dokkum ソフトウェアのテスト結果でスクリーンショットをエビデンスとして作成することについて …

「アジャイルソフトウェア要求」を読んだけれど

書籍「アジャイルソフトウェア要求」の読書メモ。いわゆるエンタープライズアジャイルに関する方法論の一つであるSAFe(Scaled Agile Framework)の解説書。ソフトウェア要求の本ではあるが、事業戦略からデリバリーまでの全ての範囲を含んでいるというのが…

IPA「情報システム高信頼化教訓集(ITサービス編)」を読む

IPAが2014年の5月に出した「情報システム高信頼化教訓集(ITサービス編)」を読んだ。けっこうイイ事が書かれている気がするのだけれども、読むべき人に届いているのかはちょっと疑問がある。みんな読んだ? 重要インフラ障害情報の分析に基づく「情報処理シス…

大規模プロジェクトは失敗しやすいのか?

「大規模開発では4割が予算超過、5割が工期遅延」という記事を読んで考えたこと。 早わかり「企業IT動向調査2014」 - 大規模開発では4割が予算超過、5割が工期遅延:ITpro photo by Official U.S. Navy Imagery そもそも定義はあっているか問題 前述の記事で…

似非プロジェクト科学(2) 夢のスケジュール、あるいは「よげんのしょ」

ソフトウェア開発プロジェクトに限ったことではないかもしれないけれど、一見正しいようで不適切なことを求められることがある。疑似科学じゃないけれども、似非プロジェクト科学としていろいろ考えてみている。もちろん、単なる政治の問題なのかもしれない…

後輩に勧める10冊の本(SIer勤務で固めドメイン・受託開発やってるエンジニア向け)

いわゆるエンプラ(笑)技術者向けにお勧めする本をまとめてみた。というか某方面からピックアップの依頼を受けて考えたもの。SIer勤務でお固めのドメインの受託開発に従事しているエンジニア向けになっていると思う。世の中的には「エンタープライズ」とか…

いまさら「ドメイン駆動設計」を読み終えた

今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを…

似非プロジェクト科学(1)

ソフトウェア開発プロジェクトに限ったことではないかもしれないけれど、一見正しいようで不適切なことを求められることがある。疑似科学じゃないけれども、似非プロジェクト科学としていろいろ考えてみている。もちろん、単なる政治の問題なのかもしれない…

我々はこのシステムを完成させていいのだろうか?

医療関係のコミュニティが公開している動画が興味深かったので感想などを書く。電子カルテの導入の現場における失敗パターンのようなお話。15分程だし、見ていて損は無いと思う。 我々はこのシステムを完成させていいのだろうか? 上記の動画の前半では、『…

アジャイルソフトウェア要求の読み方を聞いてきた

書籍「アジャイルソフトウェア要求」を読み始めている。高い!厚い!重い!ということで心折れそうだったので、丁度開催されてた勉強会に参加して読み方を聞いてきたのであった。 「アジャイルソフトウェア要求」を学ぶ。 - DevLOVE | Doorkeeper アジャイル…

錆びた弾丸

プロセスフローダイアグラム(PFD)について書かれた以下の記事を読んで思ったこと。銀の弾丸は売っていないけど、鉛の弾丸は自部門組織などから手に入れることはできる。ただし、それが錆びた弾丸かどうかは自分でチェックしないといけない。 PFDが明確に指摘…

ソフトウェア設計を家の設計に例えると

メモ。InfoQで無料でダウンロードできる(会員登録は必要)「Domain Driven Design(ドメイン駆動設計) Quickly 日本語版」を読んでいたらこんな例えがあった。どこかで使いたい。 ソフトウエアの設計は家を構成するのに似ています。いわば全体的な展望を作…

ソフトウェア開発と設計書の関係

Info-Qの記事「アジャイルにおけるドキュメント:いつどれくらい書くべきか」を読みながら考えたこと。ソフトウェア開発と設計書の関係については、本ブログでも何回か取り上げている。 開発者向けのソフトウェア設計書は必要か? - 勘と経験と読経 保守開発…

企業情報システムのモダナイゼーション

企業情報システムにはモダナイゼーションが必要だ、というInfoQの記事を見て考えたこと。単なる新規アーキテクチャへの移行の事ではなく、ソフトウェアライフサイクル全般のアップグレードについて。 モダナイゼーションは避けがたい道 企業情報システムのモ…

コンテナの物語を読んで、SIerの行く末を想った

読書メモ。「コンテナ物語」はコンテナ輸送(コンテナリゼーション)が現代社会に与えたインパクトについて書かれた本だ。内容自体とても面白いのだが、読みながら別のことを考えていた。 本書はビルゲイツが2013年の本としてピックアップしている ビル・ゲ…

なぜシステム開発は必ずモメるのか?

読書メモ。他人の不幸は蜜の味と言われるが、他人の失敗はノウハウの塊だと思っている。というわけで、ソフトウェア開発の失敗の極みである「IT紛争」に関する本「なぜシステム開発は必ずモメるのか?」を読んだ感想。この本も、ノウハウの塊になっていると…

もし企業の情シスがGoogleだったら

もし企業の情シスがGoogleだったらどうなるのだろうということを考えている。 業務システムは突然ローンチされる 業務システムが常にBeta版 システムの利用状況が低いと、突然、システムは廃止される システムの利用状況が高くても、将来性が無いなどの理由…

テストから見えてくるグーグルのソフトウェア開発

読書メモ。「テストから見えてくるグーグルのソフトウェア開発」を読んだ(Jolt Awards 2012にも選ばれた本ということで遅ればせながら)。タイトルの通り、テストそのものというより、テストの視点からグーグルのソフトウェア開発全体が語られており興味深…

ゴール、質問、メトリクス

学習メモ。未読のまま半年以上放置していたIPAの「組織内のIT戦略の立案および、IT化評価の意思決定支援を行う教材・ツールを更新」という記事をやっと読んだ。GQMというビジネス分析手法(?)について。 IPA/SEC:組織内のIT戦略の立案および、IT化評価の意思…

ITエンジニアの教養としてのモンティ・パイソン

ITエンジニアたるものモンティ・パイソンくらいは教養として押さえておきたいと思っていたのだ。で、年末に読んだ「アドレナリンジャンキー」に以下のモンティ・パイソンネタが出ていたのでいろいろ調べたりしてみた。「死んだ魚」「死んだオウム」について…

プログラマの質、チームの質

ロバート・L・グラスの「ソフトウエア開発 55の真実と10のウソ」では「優秀なプログラマは最悪に比べ28倍優れている」という記述がある。ただしこれはプログラマ個人に関する記述であって、ソフトウェア開発チームの質とはまた違った軸だという事に注意しな…

もしもソフトウェア開発のPMがTRPGのGMだったら

妄想妄言の類い。工程の区切りで正気度チェック!という話ではなく。InfoQで「ロールプレイングゲームのダンジョンマスタとして学んだことをアジャイルコーチングに活用する」という記事を読んで考えたことなど。ちなみに「TRPGのGM」は、「テーブルトークロ…

単体テストフレームワーク(xUnit)に関すること

このブログエントリの言いたいことがわかるようでわからなかったので、整理してみる記事。ドキュメントベースの単体テストとxUnitの類いの単体テストフレームワークの違いに関する私見。ツール(手段)の話ではなく、目的を中心に考えれば良いと思っている。 …

負の生産性のこと

メモ。2013-10-15を読んだ。お説ごもっとも。とはいえ、ソフトウェア開発の世界にはさらに「負の生産性」があるので、そのことについて。 負の生産性について よく、PGの生産性はピンキリであり、倍率は3倍だとか10倍だとか100倍だとかいう人がいる。おおむ…