勘と経験と読経

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

プライムセール連携でSOFT SKILLS等技術関連本がKindleで50%オフのセール

本日のAmazon プライムセールの関連で、最近発売された「SOFT SKILLS」「リモートチームでうまくいく」などが割引+50%のポイント還元セールになっている模様。3日間限りというと7/15までかー。
【7/16追記】SOFT SKILLS以外の本は引き続きセール中の模様。購入時には価格にご注意ください

割と最近発売された本

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

今読んでいるのだけれども、なかなか面白い。50%オフはかなりお得な印象。
7/16 この本は通常価格に戻ったようです

積読

高額技術書カテゴリ

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 上 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

Code Complete 第2版 下 完全なプログラミングを目指して

最近だとこんなレビュー記事がちょっと気になった。

とにかく長すぎる。名著ではあるのだと思うが、時間に余裕があるか「俺はあの Code Complete を読破したんだぞ!」という満足感を得たいのでもなければ、もはやわざわざこの本を読まなくてもいいと思う。重要なトピックごとに、もっと深く掘り下げていてこれほど長くはない本がある。特に、良いコードを書くための知識については「リーダブルコード」のほうが良いと思う。
Code Complete 第2版 下 - @kyanny's blog

長いのはその通りだけど、とりあえず高すぎるので買うならセールの今がお勧め。定価はきつい。

ソフトウェア要求 第3版

ソフトウェア要求 第3版

上流工程の教科書的に。ちなみにこれは改定されてアジャイル開発プロセスまでフォローされている。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

先の記事でも紹介しているが鉄板的にお勧め

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

積読

その他目に付いたもの

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

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

パーフェクトソフトウエア

パーフェクトソフトウエア

プログラミングの心理学 【25周年記念版】

プログラミングの心理学 【25周年記念版】

The DevOps 逆転だ!究極の継続的デリバリー

The DevOps 逆転だ!究極の継続的デリバリー

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

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

デッドライン

デッドライン

ピープルウエア 第3版

ピープルウエア 第3版

熊とワルツを リスクを愉しむプロジェクト管理

熊とワルツを リスクを愉しむプロジェクト管理

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

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

ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからずSIer臭がする。しかしSIerや日本のソフトウェア開発の現状を憎悪するからといって、見積もりというアクティビティの重要性は変わらないし、軽視してよいものではないというのが個人的な考え。
Brueghel-tower-of-babel

ウソ:ソフトウェアの納期見積もりは、星占いレベルのものである

論点を単純化するための釣りタイトルだと思うのだけれども、ソフトウェア開発における「不確実性のコーン」はスケジュールではなく、スコープ(工数、コスト、機能)の見積もりに関する分析であって、納期、スケジュールに関する分析ではない点には注意が必要である。

この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。
ソフトウェアの納期見積もりは、星占いレベルのものであると思う - メソッド屋のブログ

ソフトウェア開発における「不確実性のコーン」は、初期コンセプトの時点でのソフトウェア規模の予測が困難であることを示すものであって、これはある意味当たり前であろう。物理的な建築物などであれば平均坪単価などである程度の費用工数を見積もることが可能であるが、ソフトウェアはそうではないということを示しているに過ぎない。

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

真実:初期コンセプト段階でのソフトウェアスコープ(工数、コスト、機能)の正確な見積もりは難しい

これは自明な事であるのでことさらと掘り下げるつもりはない。が、一方で初期コンセプト時点での予算確保などを検討する場合、「過去のプロジェクトの実績」掛ける「予想される生産性の向上」などで割り引いた予算確保を行うことは大きなリスクである。これは最近のソフトウェア開発データ分析でも言及されている事である。過去に書いた以下ブログ記事もあわせて参照。

  • 2004年~2012年の間で、SLOC生産性は変化していない(生産性向上も低下もない)

ソフトウェア開発プロジェクトは、低価格と短納期の強いプレッシャーに晒されることが多々ある。また、予算管理や価格交渉等の場面で、年率5%の開発コスト削減や前年度比10%のライン単価低減等が要求されるケースが散見される。しかし、データによる裏付け等の根拠が希薄であると、このような状況は開発プロジェクトのリスク増大や品質低下を招く恐れがある。

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

真実:見積もりとスケジューリングは別の活動であり混同すべきではない

混同されがちなので念のため。またスケジューリングの決定は、政治、交渉の問題でもある点を理解すべきだろう。前述の「ソフトウェア見積もり」本でも、まるまる1章を割いてこれを論じている。

交渉がふさわしい情報もあれば、そうでない状況もある。私たちは太陽の表面温度や五大湖の全容積といった事実について交渉することはない。これらは、調べさえすればわかることだからだ。同様に、ソフトウェア見積もりは分析的なアクティビティの結果である。したがって見積もりについて交渉することは道理に合わない。だが、見積もりに関係のあるコミットメントを交渉することは、理にかなっている。
ソフトウェア見積り 人月の暗黙知を解き明かす /第23章 政治、交渉、問題解決

また、政治的なスケジュールの交渉についてはこの本が詳しくて参考になる(アンチパターン集が含まれている)

Manage It! 現場開発者のための達人式プロジェクトマネジメント

Manage It! 現場開発者のための達人式プロジェクトマネジメント

スケジューリングと見積もりは2つの異なるアクティビティだ。スケジューリングとは各タスクの順序付けであり、相互依存関係が見えるようにすることである。一方、見積もりとは、特定のタスクに必要な工数を推測する作業のことだ。スケジュールを編成する方法はタスクの工数と必要な人材の見積もりに依存するので、両者は密接に関係している。
Manage It! 現場開発者のための達人式プロジェクトマネジメント/第4章 プロジェクトをスケジュールする

見積もり、計画、スケジューリングをどんなにがんばっても、スケジュールをゲームにしてしまうスポンサーや管理者やチームメンバーが現れるものだ。ゲームプレーヤーを現実に連れ戻すのはプロジェクトマネージャの仕事である。でもその前にスケジュールゲームを見極める必要がある。
Manage It! 現場開発者のための達人式プロジェクトマネジメント/ 第6章 スケジュールゲームを見極めて回避する

ちなみに紹介されているスケジュールゲームのアンチパターン(第6章 スケジュールゲームを見極めて回避する)は以下の通りだけれども、タイトル見るだけでワクワクできる。

  • 岩をもってこい
  • 願望が最重要の戦略
  • 現実否認の女王
  • カーペットの下に隠してしまえ
  • ご機嫌な期日
  • 尻に火をつける
  • 焦点の分裂
  • スケジュールは確約に等しい
  • 行き当たりばったり
  • スケジュールツールは常に正しい(スケジュールの夢の時間)
  • 何が何でもやってくれ。でないと黒こげだ
  • ノーとは言えない
  • スケジュールチキンレース
  • 90%完了
  • これからペースが上がっていく
  • スケジュール催眠

ウソ:見積もりが困難だから、計画することには意味はない

そんなことはなく、当然、意味はある。ただし、それはコミットメントをすることにおいてのみではない。

見積もりや計画づくりがそんなにも難しくて、プロジェクトの終わりになるまでは正確に見積もれないのであれば、そもそも見積りや計画づくりをするのはなぜだろうか? わかりやすい理由として、働いている組織から見積りの提出を求められることが挙げられる。その理由はさまざまだが、いずれももっともなものだ。マーケティングキャンペーンの計画を立てるためだったり、プロダクトのリリース作業の予定を立てるためだったり、組織内のユーザをトレーニングするためだったり。いずれの場合にも計画や見積りが欠かせない。見積もるのが難しいので計画やスケジュールは作成しない、という言い訳は通用しない。しかも、見積りや計画づくりという大変な仕事に取り組むべき理由は、こうした消極的なものだけではない。もっと根源的な動機があるのだ。
見積りと計画づくりは、期日やスケジュールを決定するためだけのものではない。計画づくりとは価値の探求なのだ。
アジャイルな見積りと計画づくり ?価値あるソフトウェアを育てる概念と技法?/1章 計画の目的

同書は見積りからいかに価値を生み出すか、という点で非常に示唆に富んでいて、個人的にはマコネルの見積もり本と合わせてオススメしている。ソフトウェアの見積もりの工学的な側面をマコネル本で学び、適切にコントロールするという観点は本書を読むのが良いと思う。

真実:受発注契約の関係において納期は絶対である

ポイントは「契約の関係に於いて」という点である。つまり

  • 自社エンジニアが便宜上「納期」と呼称する単なる作業完了のコミットメント
  • 請負契約の関係に無い利害関係者が便宜上「納期」と呼ぶ完成マイルストーン

についてはこの限りではない。
一方で、いうまでも無く契約上で定義された納期は絶対のものであり、これが遅延した場合契約債務不履行になるので「ソフトウェアの見積もりなんて星占いみたいなものだから、納期なんて守れるはずないし、守らなくて良い」なんて思わないように。
参考:システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance

ただ、実際はソフトウェア開発の不確定性を考慮して契約するのが適切だろう

  • ソフトウェア開発の完了予定日(例えばリリース日)と契約書上の納期は分ける
  • スケジュール上のバッファをきちんと設定して、本番稼動後に改めて納入を図る
  • 超過の可能性がある場合は、相手先と今後の係争に抗弁できるような合意形成を行う

納期を越えて

冒頭で紹介した記事は、「納期なんて考え方はやめてしまえ」という意見を示しているのだけれども、個人的にはちょっと疑問がある。SIer的な「ソフトウェア開発完了のコミットメント=納期」は、単純に外注契約を無くしてしまえば回避できるだろう。しかし、ソフトウェア開発を取り巻くすべての利害関係者が期日やコミットメント無く協働していくビジネスというのはちょっとイメージしにくい。経営やマーケティング、運用などの観点ではやはり大小のコミットメントを拠り所として推進せざるをえないのではないだろうか。
ただし「守ることのできないコミットメント(納期、期日)」や「無意味なコミットメント」などは生産性阻害要因であることに変わりない。いま目の前にある期日が何のコミットメントで、最新の状況においてどういう意味があるのか、そして変化がある場合にどのようにすべきなのかについて考えることが必要であるのだと思う。

2016年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書)

昨年に引続き、2016年1月~6月に読んだ本についてふりかえってみるもの。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あと雑誌コミック類もけっこう読んでいるのだけれども、これは除外。全般的には旬な本をぜんぜん読んでいないな・・・

2016年上半期に読んだ本を並べてみた










































オススメ文芸書編

色々と読み散らかしているけれども、ITエンジニア的に以下スライドを見て手に取った「赤めだか」が面白かったし名著だったので一番のオススメ。教育論としても読めるけれども、単純に内容が面白くて楽しく読める。古典落語にも興味を持ってしまった。

赤めだか (扶桑社BOOKS文庫)

赤めだか (扶桑社BOOKS文庫)

もうひとつ。今年映画化もされた「火星の人」はジャンルとしてはSF小説だけれど万人向けのエンターテイメント作品となっているので強くオススメしたい。逆境に立ち向かうエンジニア魂に震えるし、その経過を面白おかしく日記形式で書くという構成はソーシャルネット時代向きで楽しい。

火星の人

火星の人

オススメビジネス書編

今年前半は割と人類の進歩を実感することが多かった。重力波の検知が報道されたり、日常的に人工知能の話題が聞こえるようになってきた。というわけでレイ・カーツワイル氏の「シンギュラリティは近い―人類が生命を超越するとき」を取り上げたい(なおこの本は2005年の著作である)。現在読んでも非常に刺激的だが、電波な内容も含んでいるので注意(同氏は自身の肉体で実験を行いながら不老不死を目指していたりする)。


とりあえず同書を読んで、自分は2045年まで生存することを優先度の高い目標にしている。

オススメ技術書編

残念ながら最近の旬の技術書をタイムリーに読めていない。「マイクロサービスアーキテクチャ」とか「カンバン仕事術」「スクラム現場ガイド」なども読みたいのだけれども辿り着けていない。2015年の積ん読をこなすので精一杯である。
ソフトウェアシステムアーキテクチャ構築の原理 第2版」は有用度で文句なしの一品。アーキテクト関連の仕事をするのであれば目を通すべき鉄板本。
一方で「ビヨンド ソフトウェア アーキテクチャ Object Oriented Selection Classics」はサービス開発、製品開発に関わるエンジニアにお勧めしたい本。受託開発の人にはあまり響かない気がする。

オススメしないけど面白かった本

今年前半での大きなニュースの一つが「アルファ碁」であることは間違いないと思う。

で、ミーハーではあるものの改めて碁に興味を持ったので、いろいろ調べた結果以下の本で学習を始めてみている。

なんとなくルールと指し方はわかった気になっているが、ブラウザでできる碁ゲームでは9路盤で時々勝利できる程度。まったく上手にはならないけれども頭の体操としては楽しめている感じ。

最近の読書環境について

画像からも見て取れるように、読書の大半はKindle端末で読んでいる。読書時間のほとんどが通勤時ということもあり、物理図書だととても持ち歩けない分厚い技術書などが読めるのは大変に便利である。新型の端末が発売されているけれども2013年に購入したKindle PaperWhite(第5世代)を継続して使用中。バッテリーの持続時間は短くなっているのかもしれないけど1週間以上は持つので、まったく不便はない。

故障などで買いなおす事になったとしても、たぶん同じ機種(PaperWhite 広告なしWi-Fiモデル)を買うだろう。物理ボタンはあったら便利かもしれないけれど故障リスクもあるわけで、あまり興味は無い。

Kindle以外の本はだいたい公立図書館で借りたものを読んでいる。というわけで物理図書を購入するのは現在、または将来子供と共有したい時だけである。

読書の大部分は通勤時間と書いたけれども、最近の本の読み方は具体的にはこんな感じ

  • ビジネス書、技術書、文芸書を並行して読む(気分にあわせて選ぶ)
  • 通勤時間、電車等が混雑していない場合は読書。混雑している場合はPodcastなどを聴いている
  • だいたいKindle端末で本を読んでいるけれども、状況によってはスマートフォンKindleアプリで読むこともある
  • 就寝前も読書。Kindle端末はバックライトがあるので便利
  • 技術書とビジネス書は読了後、カフェか自宅で読書ノートをまとめる習慣を継続中

年齢的にはそろそろ老眼が怖いのだけれども今のところは大丈夫。まぁそうなったらKindleで文字サイズを大きくして読めばいいのだけれど。

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

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

(良い)レビューの想い出

ソフトウェア開発におけるレビューはいろいろと経験しているが、折に触れて思い出す出来事がふたつある。こんなことを書くと老害認定されるかもしれないけど書く。老いててすいません。

ひとつは社会人になったばかりの駆け出し時代(一部脚色しています)。社会インフラ的な基幹系システム(ホスト)の開発に参加したのだけれど、ドキュメントもコードもとても丁寧に厳密にレビューしてもらっていた。もちろん学生時代にレポート類のレビューを受ける経験はあったけれども、段違いの精度でのレビューに衝撃を受け、ソフトウェア開発を仕事にするというのはこういうものなんだと理解していた。具体的にはこのような感じ

  • インプットに対して、アウトプットが完全であることをセルフチェックした上で、有識者が時間をかけてレビューしていた
  • セルフチェックも、有識者レビューも文章、コードともに1行ごとに行い、インプットとクロスチェックをしてブロック単位で余白に印鑑押してた(結果として、印刷物の右側に自分のハンコとレビュアーのハンコがずらっと並んでいた)
  • 指摘事項はしっかりとコメントされ、加えて対面で理由も含めてフィードバック

今思うと、紙とか印鑑が非常に懐かしい感じ。ただ、ここで学んだ「レビューへの姿勢」は今も大切にしている。今でも自分がやるレビューではときどき、句読点やコード行すべてにマーキーで色を塗ってしまうのはこの時の癖である。


もうひとつは割と最近の話。大きな企業さんでの大規模な開発での経験(一部脚色しています)。いわゆるウォーターフォール型開発なのだけれども、上流工程を終了するためには形式的にはお客様の部長承認が必要だった。規模が大きかったので、ドキュメントは分厚いキングジム2冊のボリューム。期限ギリギリ夜遅くに提出物を提出して、翌日のレビューに望んだ時に目を疑った。部長さんが持ってきている文書ほぼ全てのページに付箋や書き込みがされている [ウワーッ、なんてこった!] 。こ、これはもしかして伝説のBillGレビューか・・・

私たちが仕様書を彼に送ったのがほんの24時間前だったことを考えると、彼は昨夜読んだのに違いなかった。彼が質問をし、私がそれに答えた。簡単な質問だったが、それがどんな質問だったかどうしても思い出せない。彼が仕様書をパラパラとめくる手元に目をひきつけられていたからだ。
彼が私の仕様書をパラパラとめくっていて [落ち着けよ! 小娘みたいじゃないか!] …そして仕様書のすべてのページの欄外に書き込みがあるのを見たのだ。彼はあの分厚い仕様書をすべて読んで、欄外に書き込みをしたのだ。 全部読んだんだ! [ウワーッ、なんてこった!]
http://local.joelonsoftware.com/wiki/%E3%81%AF%E3%81%98%E3%82%81%E3%81%A6%E3%81%AEBillG%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC%E3%81%AE%E3%81%93%E3%81%A8

レビューは無事に通ったのだけど、後で確認したらこんな感じ

  • 部長レビューはそもそも形式的ではなかった。ガチだった
  • 提出時間が遅かったが、徹夜で読んでいただいていた、というか全部読むポリシーとのこと
  • 判断(承認)を行うためには、内容をきちんと理解して、納得できるかを確認する

もちろんその方のスケジュールは超多忙。であっても、きちんとレビューする姿勢に恐れ入りました。

上記のような事を書くとSIer的だとかWFだという批判も受けそうだけど、今回書きたいのは「ちゃんと真剣にレビューすることは重要だ」ということ。

More Joel on Software

More Joel on Software

  • 作者:Joel Spolsky
  • 発売日: 2009/04/09
  • メディア: 単行本(ソフトカバー)

ソフトウェア開発の文書レビューによくある問題点

多くの現場において散見されるのはだいたい以下のような状況である。

  • レビューそのものが「技術の必要なプロセス」と認知されていない
  • 適当なレビュー方法が雑にOJTなどで、なんとなーく継承されている
  • 簡易な「読み合わせ」をレビューと勘違いしている

結果として、残念なレビューが後を絶たない。

必要なのは、レビューのやり方を見直すことです。ITエンジニアの方はたいてい、上司や先輩のやり方にならってレビューを実施しています。そのレビューのやり方には、改善の余地が多分にあるのです。
間違いだらけの設計レビュー

「レビューのスキルは、ITエンジニアとして知識を得て開発経験を積み、レビューを担当していくうちに身についていく」――。この誤った考え方がはびこっているため、レビューの改善が妨げられているように思います。
間違いだらけの設計レビュー

特に簡単な「読み合わせ」をレビューと称するのは大きな問題で、たとえば以下のようなレビューはただちに運用を見直したほうが良いだろう。

  • なんとなく、関係者が会議室に集まって始まる
  • 成果物(アウトプット)だけを時間内にざっくりと読み合わせる
  • 参加者がその場でたまたま気がついた問題点についてディスカッションする
  • 時間が来たらレビューは終わり
  • 指摘された事項を修正したらレビュー終わり

最低限のレビュアー心得

細かいレベルではいろいろあるけれども、最低限抑えるべき事項は以下の通りである。

  • レビューの目的を確認し、目的を達成するためにレビューを行う。なんとなくレビューしない
  • 原則としては事前にレビュー対象物を通読し、目的に即した重要度に基づき指摘を行う
  • 作業結果レビューであれば、インプットとなる情報とアウトプットを付き合わせ、感覚、勘と経験でレビューしない

もちろん忙しいとか、兼務で複数プロジェクト見ているとか、見切れないなどといった状況もあると思うけれど、BillGだってちゃんとレビューしているのだから、やるべきだろうと自分を戒めている。

ちなみに細々としたレビュー技法についての詳細も書こうかと思っていたのだけれども、以下の記事が良かったのでリンク紹介してお茶を濁す・・・

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

牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。

pool-jump



こちらも合わせて読んだ

そもそも批判されるようなWF型プロジェクトは実在するのか

本件に限らず批判されがちな「ウォーターフォール開発プロセス(以下WFと記述)」だが、実際のところ皆さんそれぞれに工夫を凝らしているので、実際に批判されるに値する害あるWFというのはあまり存在していないのではないかと考えている。外観をひとことで表現するとWFになるのだけれど、皆が魔改造をしており既にWFではなくなっている気がする。

以下は個人的観測による最近のいわるゆWF的プロジェクトの傾向だが、これが批判されるほどWFなのかは疑問がある。

1.計画駆動・計画重視である

プロジェクトを取り巻く環境や、さらされているリスクに応じて適切に計画駆動・計画重視することは必要に応じてやるべきだし、否定されるものではないと思う。
古くはバリー・ベームが2004に書いた「アジャイルと規律」でもバランスを取ることが重視されているし、

残念ながら、ソフトウェア開発に対するこれら二つのアプローチは、お互いにサポートしあう道を採るのではなく、相手をゼロサムゲームにおける対戦相手のようにみなしている。アジャイル主義者は、伝統主義者を罵倒し、プロセスを崇拝する「テーラー式」還元主義者によってソフトウェア開発の人間性が奪われていると嘆く。すると、主流派はそれに応戦して、ハッキング(ずさんなシステムを適当に作っている)とか、品質が悪いとか、真剣なビジネスの中にお楽しみを持ち込みすぎだと非難する。さらに、それぞれの陣営の真剣な信者がやってきては、ほとんど救世主のように甲高い声で自分の信念を言い立てるので、成功のための真の戦略を見つけ出そうとしているソフトウェア開発者やマネジャーはますます混乱するばかりである。
アジャイルと規律

近年だとエンタープライズアジャイルのガイドの一つであるDADについても、必要に応じた一定の計画重視を論じていたように記憶している。

2.フェーズゲートがある

段階的に計画や見通し、状況をチェックしながら進める(たとえば要件定義→設計などのフェーズ移行時)手法はWF的な特徴ではある。しかし実際には利害関係者が多岐に渡る大規模プロジェクトにおける合意形成や、有識者レビューによるリスク軽減を目的にしているものが多く、純WF的なゲートチェックを行うことは最近は少ない。どういうことかというと

  • ○○フェーズ(例えば要件定義)が完了したか

のチェックをするというよりは、

  • 現段階での分析結果について関係者は合意できるのか(みんなサインできる?)
  • 現時点の未確定事項や、リスクを棚卸して、計画を続行してよいか(コントロールはできてる?)

という実践的な確認が中心であり、忌避すべきようなものでは無くなっている印象。

3.プログラミングの工程で要員数が膨らむ

WFのお家芸として

  • プログラミング能力のないエスイーが大量に設計書を書いて
  • 大量に調達されたプログラマーエスイーを呪いながらコードを大量生産
  • 効率悪ぃ〜

というものが以前にあったことは確かだけれども、これも現代ではかなり少なくなってきている。
短納期、大量開発が求められる場合もコードの自動生成とかフレームワークをうまく活用して、どこも効率良く開発するようになった。
要求されるスケジュールと規模を勘案して途中の要員数が大きく増えることはあるけれども、ゼロ年代のような人海戦術の精神論はイマドキあまり見かけない。

4.長期間の統合テストやシステムテスト期間が終盤に存在する

これもWFあるあるだけれども、あまり意味なく長大なテスト期間を設ける例は少なくなってきたと思っている。それなりの期間をテストに費やすケースは、

  • 関連システムとのスケジュール同期化を目的としたもの
  • 高い信頼性と品質を求められるために実施する

などの理由がきちんとある事が多い。
また、前述のDADでも統合テストの必要性は論じられていたし、アジャイル開発でも必要に応じて統合テストとかシステムテストは必要であろう。

また、世の中にはこんな事例もあるわけで、これらも含めてWFのタグがついているからと言って石を投げるのはあまりに乱暴な気もする。
www.publickey1.jp

亀だ愚鈍だと批判されることも多いSIerと大手企業システム部門ではあるが、経済成長も鈍化した昨今、それぞれが様々な工夫をこらしており、非効率を放置しているようなことはほとんどない。というか進歩しないと死ぬ。もちろん悪手も多いが、向いている方向性は正しいのではないかと思っている。

WFの課題

牛尾さんの記事では主にWikipediaの記事をベースにウォーターフォールの課題をいくつか挙げているのだけれど、同じ論点については過去に以下の記事でも深堀りをしたことがあるので参考に。

改めて「ソフトウェア工学で大切な10の考え方」からウォーターフォールの論点を抜き出すと、

  • ウォーターフォールというコンセプト、そのものについては誤解がある(構想者は1回限りの段階プロセスを想定していなかった)
  • コンセプトの適用は「All of Nothing」ではない。プロジェクトにあわせて最適化せよ
  • 「すべてを先に決定しなければならない」ということはない
  • しかし、慎重に検証しても大規模プロジェクトでは「納品後のソフトウェアの変更は要求フェーズでの変更より100倍も高くつく」
  • この事実を踏まえて、適切なプロジェクトの設計が必要である

ということになるというのが私の見解である。そういう意味では、WFもアジャイルも相互補完的に活用するものであり、要は適材適所であろう。というわけでWFもメリットあると思うよ。

エンタープライズ開発とアジャイル

実は最近の実感としてはエンタープライズ開発の領域におけるアジャイル開発プロセスの相性は割と微妙だと考えている。
というのも、企業システムはシステムと人間系が相互に密に連携したワークフローであることが多いため、システム側の適応性をいかに俊敏にしても、人間系が変更に追いついて来ないのだ。準リアルタイムに業務改善のアイデアをシステムに反映していっても、使うユーザー側が追いつかない。もしくは「慣れた頃に変更しやがって」と石を投げられる。

以前に大きな業務改革のプロジェクトに参画したことがある。そのプロジェクトでは、ある店舗業務を無くして新設する専門部門で一括処理を行うというものだったが、新組織を立ち上げるという性格から構想計画分析には多大な時間を要した(マスタースケジュールはとてもWF風だった)。新組織の役割や、そこでの評価の仕組みもかかわってくるわけで、人事や経営も巻き込んだ意思決定について時間をかけた。また当然組織やファシリティはシステムの完成にあわせて立ち上がるので、テストはビッグバン方式にならざるを得ない。この手のプロジェクトに対して、やれアジャイルだ、DevOpsだと言ってもあまり意味はないだろう。(なお、実はソフトウェアの開発部分はScrum採用してた。当時RUPを強く意識していたのだけれども、これはまた別の話)。

だから、人間系と密に結びついた業務ソフトウェア開発プロジェクトにおけるアジャイル開発プロセスの適用は、最近割と慎重に考えるようにしている。アジャイルでやりたいと言われても、ちょっと待て、と実際に言っている。

逆に言えば「人間系」の制約に縛られないソフトウェア、例えばコンシューマ向けのWebサービス事業開発や、自動取引の領域においてはアジャイル開発プロセスの親和性が非常に高いのだろう。ソフトウェアの改修や機能追加を人間系の制約なしに反映させることができるかどうか、人間系のボトルネック無くダイレクトに価値を生み出す事ができる領域なのか、というのが重要なポイントだ。ただ、悲しいかな企業システムの領域でこういった取り組みができる範囲は、割と限られているのではないだろうか。

まとめ / 今後に向けて

まとまらないのだけれども、言いたい事は次の通りである。

  • 現代的に工夫、改良されたウォーターフォール的プロジェクトには課題も多いがメリットも相応にあり、ステレオタイプとして否定非難すべきものではない
  • ビジネス適応領域に応じて、計画駆動とアジャイル型プロセスを使い分け、最適なプロジェクト設計をすべき

プロジェクト環境と開発プロセスが不適切な組み合わせとなってしまう事が、発注者と受注者(もしくは使用者と開発者)にとって最も不幸な事態である。これを避けるために、個人的には何れの方法論宗教にも組せず、学びを継続し、所属組織の能力向上を図り、顧客に積極的に提言できるポジションに踏み込んでいくことが重要なのではないかと思っている。

Kindleで50%オフ以上セールが始まったけど目新しい技術書が無い

どうやらKindleで50%以上オフのセールが始まっているようなのだけれども、目新しいものがあまり無い印象。とりあえず読んだ事のある中でオススメのものをピックアップしてみた。

高額技術書カテゴリー

技術書としては鉄板本。全員読むべき。今回合本版が新たにリリースされて、こちらはセールになっているがバラ売りは定価のままなので注意が必要。

ソフトウェア要求 第3版

ソフトウェア要求 第3版

要求定義関連のトピックをおさえるのであればオススメ。

レガシーコード改善ガイド

レガシーコード改善ガイド

今年に入って電書化された名著の類。いま読んでいるのだけれども、レガシーコードに悩まされている人は読んだ方が良い印象。

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

C#実践開発手法 デザインパターンとSOLID原則によるアジャイルなコーディング

本書だけは未読。良書だという評判だけれども。

高額じゃないけどオススメ

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア見積り 人月の暗黙知を解き明かす

ソフトウェア開発にかかわる人(技術者だけでなく営業さんも)にオススメ。

デッドライン

デッドライン

小説形式で読みやすいので、技術書が苦手な人にもオススメ。

こちらもドキュメンタリーで読みやすい。Windows NT開発秘話なのだけれども、ソフトウェア開発の難しさの本質について学べると思う。

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

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

グーグルのテスト戦略および品質改善の取り組みに関する本。テストという文脈だけでなく、プロセス改善という観点からも興味深い。

技術書じゃないけれど

HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか

HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか

技術マネジメントの観点でいろいろと学びがある。ベストセラーでもあるので、未読であれば

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

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

というのはちょっと乱暴だと思うけどなー、という話

管理者による部下教育

会社組織における教育には2種類あって、その1つが「管理者による部下教育」である。もう1つは「プロフェッショナルとしての後進教育」なのだけれどもこれは後で書くことにして、管理者による教育についてまず整理したい。

管理者による教育についてはいろいろな論があると思うけれども、アンドリュー・S・グローヴの経営論などを参考にするとだいたいこんな感じである。

  • 教育の目的は部下・チームから最高の業績を引き出すことである
  • メンバーのスキル習熟度に応じて、マイクロマネジメント方式から、関与を最小限にして任せる方法まで、マネジメントスタイルを調整しながら教育する
  • 目標設定に関与することにより、必要とする能力の学習を促進する
  • 査定に関与することにより、不足する技能があれば矯正する方法を考える。また良い成長を促進する
  • 人員配置に関与することにより、アサインに関する期待や不満をコントロールする

実際に、うまくやれているかどうかは別にして自分は上記を強く意識している。管理をしているメンバーを面談するときには、「管理職としてのアドバイス」なのか「技術者としてのアドバイス」なのか極力明確にフィードバックしようとしている。

ただ、この「管理者による教育」を一定年次以上のシニアなエンジニアが必ずやらなきゃいけないかというと、それは違うと思う。そもそもこれを実行するためには必要な職責や権限もあるだろうし、スキルとしても追加で学ばなければいけないことはあるだろう。そういう意味で冒頭の倉貫氏のツイートに戻ると、これは「余分な仕事」として関与しないような組織体制作りはアリなのかなぁと。

技術者としての後進教育

もうひとつが「プロフェッショナルとしての後進教育」である。人によって意見は違うと思うけれども、職業プロフェッショナルを名乗るのであれば「自己研鑽」と「他の技術者の育成支援」は必ず意識すべきであるし、やって当然というのが個人的な見解。
ITエンジニアについては、

  • 米国では一般的と思われる、ACM/IEEE-CSのエンジニア倫理規定でも「他のソフトウェア・エンジニアの専門的能力の開発を援助」することが規定されている
  • 国内では、たとえば情報処理学会 認定情報技術者 倫理要綱・行動規範というものがあるが、ここにも「自己研鑽」「他の育成の支援」は入っている

「自己研鑽」は別として「他の技術者の育成支援」まで本当に必要なのか、という反論はあるかと思うが、

  • 一定レベル以上に自己の能力を高めるためには、教育に関わることは必要だと思う
  • その方法は、部下の教育に限るものではないだろう。論文を書いたり、セミナーで発表したりするということも含まれる。とはいえ一般的には周りのエンジニアの能力向上に寄与するということが、自己能力を高めるひとつの方法だというのが個人的な意見

というわけで、後進教育にも一定関与して初めて一人前であると言えるのではないかと考えている。

以前に書いた以下記事も参考まで。