PM

アジャイルソフトウェアマネジメント

アジャイルソフトウェアマネジメント

アジャイルソフトウェアマネジメント

TOCアジャイルを組み合わせたソフトウェア開発マネジメントです。
かなり本格的で、読み応えがあります。

TOCらしく、開発工程の中の制約条件であるとか、
各フェーズのスループットだとか、
財務のメトリクスだとか、
普通のアジャイル本とはかなり趣きが違います。

各工程の生産性を見るということで、
例えばテストフェーズで大量に不具合が見つかって手戻りが発生しているとき、
テストにものすごくコストがかかっていて、コスト面・時間面からは一見、ここが問題になっていて要改善に見えるのですが、
スループットで考えると、実装工程で作ったものがテストではねられるということは、生産してないのと同じであり、正しく作ったものだけをアウトプットとして考えると、
実は実装のスループットがかなり少なく、
ここが製造工程中の制約条件であり、要改善ポイントである、というような考え方ができます。

技術的な面から、あるいは経験から、
品質を上げるためには設計・実装であって、テストではない(テストでは手遅れ)というのはよくわかるのですが、
TOCという別の視点・尺度から見て制約条件を探し改善するというのも、わかりやすいものだと感じました。

スループットを測ろうと思うと、なんらかのメトリクスが必要で、それがソフトウェアの場合、それなりにたいへんではあるのですが)

Software People Vol.8

Software People Vol.8

Software People Vol.8

知識労働とソフトウェア開発」
「コードレビューの勧め」
がよいと思いました。

知的労働のはずなのですが、
けっこう力技で押し切る仕事のやり方してる人が多いですからねぇ。

PM Magazine vol.005

PM Magazine Vol.005

PM Magazine Vol.005

PM Magazineの最新号です。
(まだ手元に来てないのです)

ITアーキテクト Vol.4 (IDGムックシリーズ)のvol.4と合わせて、楽天ブックスで買おうと思ってたのですが、なかなか出てこない。。。
しびれきらして、Amazonで注文しました。
ポイントがつく・使えるので楽天ブックス使ってるのですが、扱い冊数や紹介文、レビューなど、やっぱりAmazonの方が便利は便利。

ITアーキテクト Vol.4 (IDGムックシリーズ)

ITアーキテクト Vol.4 (IDGムックシリーズ)

SE の教科書 ~成功するSEの考え方、仕事の進め方 (技評SE新書001)

SE の教科書 ~成功するSEの考え方、仕事の進め方 (技評SE新書001)

新書ブームを受けてか、技術SE新書なるものが創刊されたようです。
電車の中で気軽に読めるように、新書や文庫の技術書はいいですねぇ。

CCPMのサイト

これまで、Being社の中にあったCCPM関連のコンテンツが独立しました。

http://www.toc-ccpm.net/

まだ細かくは見てませんが、とりあえず、
見た目はキレイですねぇ。

トップページより転載

  1. 私は瀬戸際の魔術師だ・・・・・・」と徹夜明けにつぶやく
  2. 「楽勝っぽいからあとでやろう〜」と先延ばしにする
  3. 「早く終わったから完成度を上げよう♪」と仕事師ぶる
  4. 「仕事が多すぎてわけわからん!」と夜中に叫ぶ
  5. 「いろいろ心配」なのでとりあえず納期をサバ読みする

→どれもプロジェクトの邪魔をしています。

...なんとなくわかる気がします...


CD‐ROM付 目標を突破する 実践プロジェクトマネジメント
CD‐ROM付 目標を突破する 実践プロジェクトマネジメント

ソフトウエアインスペクション

ソフトウェアインスペクション

ソフトウェアインスペクション

ひらたく言えば、レビューの本です。

レビュー、ウォークスルーとの違いは、
厳格なルールがあり、メトリクスを計測し、
不具合を見つけ、改善するための手法である、というところでしょうか。

ソフトウェア開発工程の後半で、変動が大きく先が読めない事態を防ぐためには、
結局不具合を作らないこと、これにつきます。

テスト工程といいつつも、
実際には、不具合があること前提で、不具合発見+修正の時間となるわけで、
手戻りが多ければ多いほど、先が読めない不安なプロジェクトとなります。

設計段階で不具合を作りこまない、
コーディング段階で不具合を作りこまない、
後者のためには、ホワイトボックステストユニットテストテストファースト、TDDという解があるわけですが、
「コードレビュー」というレビューによる品質アップの方法もあります。

設計書、仕様書のレビューによって品質を上げることも大切なのですが、
この段階のレビューのやり方をキチンと勉強したことがある人は、けっこう少ないのではないでしょうか。

(仕様書をレビュー=承認を取る、「レビューしたんだから後で文句言っても知りませんからね!」って予防線だったりとか、レビューといいつつ、ブレストで追加アイデアを盛り込んでるだけだったりとか)

この本の中には、インスペクションを導入することによって実際に効果があった実例なども登場します。
設計段階に時間をかけることは、気持ち的に不安なものです。
(早く動くものが見たい、後半で時間が足らなくなるのではないか?etc.)
しかし、同じことの繰り返しでは、いつまで経っても改善できないのも事実です。
とりあえず、世の中の頭のいい人が考えてくれた手法があるのですから、そのエッセンスだけでもいただいてみて損はないかと思います。

ピアレビュー

ピアレビュー

ITアーキテクト Vol.3

ITアーキテクト Vol.3 (IDGムックシリーズ)

ITアーキテクト Vol.3 (IDGムックシリーズ)

ITアーキテクトの新刊です。

特集1
アーキテクチャ設計における「全体最適」と「個別最適」
全体最適の必要性を学び、個別最適との関係、両者を併存させたアーキテクチャの実現法を探る』

全体最適と個別最適、まるでTOCのようなお話です。
ソフトウェアの仕様・設計において、
「この処理はわかりにくいからこういう風に直して!」
「このUIは不便だからこういう風に変えて!」

「でも、それだと他の画面との整合性が、、、」

そんなシーンがよくあります。
1機能内、1画面内での使いやすさを優先するか、
ソフトウェア全体での統一性を優先するか、
バランスを取るのは難しいですね。

一番いいのは、全部まとめて直しちゃうことなんですが。

このパターンで一番イヤなのが、
Windowsはこうなってるから」
Excelはこうなってるから」
そんなのマネしたくないのに!



さて、いつものキーワードキャンペーンです。

ブラザーのカラーレーザー複合機「MFC-9420CN」欲しい!

カラーレーザー、会社で使ってますが、便利ですね。速いし。
とはいえ、カラーはめったに使わず、黒のトナーばかり減りますが。

一昔前は、カラーレーザーで印刷すると、テカテカの光沢入りになって、かなり安っぽかったのですが、今のプリンタは全くそんなことありません。実に便利な世の中ですねぇ。