読者です 読者をやめる 読者になる 読者になる

勘と経験と読経

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

週報 / Snippetsのススメ

Project Management

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

新しい会社に入るたびに私がまずしていたのは、何に時間を費やし、その日に何を達成したかを日録に書くことだ。その内容をもとに、毎週金曜日に週間サマリーを書いて上司に送ったのである。私はこれを自分の「週報」と呼んでいた。(中略)この週報は、私の存在をアピールするために役に立っただけでなく、人事考課の時期には自分自身にとっても役立つ資料となった。週報を読み返して、その年の主要な達成を拾い出せばよかったのである。自己評価を書くとき、私はその年にしたことを日付とともに正確に書けたのである。
SOFT SKILLS ソフトウェア開発者の人生マニュアル/第9章 出世階段の上がり方

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

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

週報の習慣

別に自慢するようなことでもないし人に強制するようなことでもないのだけど、個人的には日次の作業ログと、週次のまとめ(いわゆる週報)は随分と昔から書く習慣になっている。指示されてというより、自発的に書いている。

  • 日次の作業ログは、もともとはお客様まわりのトラブル回避を目的に始めたような記憶がある。いわゆる「言った、言わない問題」に抗弁するため(その話は何月何日の会議で言われたと記憶してますが違いますか?と言えるように記録してる)。実際作業ログ何度も救われており、成功体験が習慣化を強化している。
  • 出来るエンジニアはログをつける、というハッカー文化への憧れ(?)
  • GTDブーム以降、始業時にタスクを洗い出して着手するスタイルになったので、これに実績を書き込んで日次ログを作成。
  • 最近はGoogle Calenderと連携してEvernoteに日次作業ログのたたき台を自動作成して若干省力化。
  • 週報はだいたい週末に、その週の日次ログと積み残しのタスクリスト、次週のカレンダー等をインプットに週のふりかえりを行いながら執筆。GTDで言う「週次レビュー」の代替としてやる感じ。
  • 書いた週報をメールで関係者に送付。2レベル上の上司、直上司、関係するグループの同僚を宛先に入れる。
  • プロジェクトによっては計数の報告を定期的に行うこともあるけれど、それとは別扱い。
  • 反応はほとんどないけど、何かあった時などに「ああ、あの話ね」で済むので便利。
  • 体調不良や家庭の事情で休む時も引継ぎが楽なのもメリットである。

週報のフォーマット

自分のよく書くパターンはだいたいこんな目次。

  • ロール別のトピック
  • プロジェクト別のトピック
  • ネタ、雑感(最近読んだ本、技術ブログ紹介やプライベート関連トピックなど)
  • 来週の予定サマリー

それぞれの項目について普通に文章でやったこと、次にやることを書いている。ただ、前週の内容をコピーして追記する形式にしないように気をつけている。たとえばこういう記述にはならないようにしている。

プロジェクトAについて、顧客XからZZZの指摘あり。
(7/29)調査中だが十分な時間が取れず。整理に時間を要する状況
(8/5)顧客Xから確認の連絡あり。

コピペばかりの変化に乏しい文書は読まれなくなる。週報は勝手に送りつけているのだけれども、読んでもらえる文章で出すのが礼儀である。また内容を整理することで頭の整理もできるのではないかと考えている。

7/22、顧客XからプロジェクトAについてZZZの指摘着弾。他作業の兼ね合いで前週に回答出来ず。
当週改めてトレースの連絡を受けるが、どのように回答すべきか悩んでいる状況。次週初最優先で対応予定!

あと、こころがけているのは関係者に対するお礼の表明。もちろん個別適時に本人には「ありがとう」「たいへん助かりました」「よろしくお願いします!」みたいな声かけや連絡はしているのだけれども、週次のタイミングでも改めて感謝を表明するようにしている。もちろん忙しくてスッ飛んでしまうこともあるけれど。

週報を書く習慣の良いところ

個人的に「一定サイクルで何かをやる」ということを重視している。だから、自分のワークスタイルでは「週報」のリズム、ハートビート間隔は非常に重要なイベントである。「週報」を書くタイミングで、一週間前に自分が考えていたこと、計画とのギャップを振り返ることができるし、向こう一週間以上のすごし方を考え、作戦を見直す良いきっかけになっている。

またリズムがあるというのは、自分と仕事上で関係のある人たちにとっても良いことだと思っている。リズムがあれば、同期がしやすいのだ。べつに必要な時に聞いてもらっても良いのだけれども、割とたいていのことは週末私から発信されるメールに(たぶん)書かれている。急がない事柄であれば、週末まで待ってもらえればアップデートは配信されるし、もしくは前週の週報に書いてある。自分が繁忙でアップアップしてる時には「ごめん、いったん先週の俺の週報見て!」とか「今週末の週報にコメントしておくから週末まで待って〜」とか言えるので、便利でもある。

というわけで、今週も自分勝手に週報を書いて皆に送りつけるのである。

Kindle以外で気になる電子技術書籍をまとめてみた

book Kindle

主に自分用のメモ。セール等を活用してKindleではもりもりと技術書籍を購入しているのだけれども、一部の気になる書籍についてはKindle非対応、出版社独自に電子書籍化という場合もある。というわけで現時点で気になるKindle非対応の技術書籍をいったん整理してみた。一種のいつか買う予定リスト。

O'REILLY

カンバン仕事術

www.oreilly.co.jp
PDFのみというのが悩ましい。

マイクロサービスアーキテクチャ

www.oreilly.co.jp
PDF、ePub、mobi対応。というわけで購入すればスムーズにKindleで読める。近日中に購入したい

Serverspec

www.oreilly.co.jp
PDF、ePub、mobi対応。

オーム社(達人出版会)

新装版 リファクタリング

tatsu-zine.com
PDFのみというのが悩ましい。

アジャイルレトロスペクティブズ

tatsu-zine.com
PDFのみ。以前に紙書籍で一度読んでいる。

アジャイルプラクティス

tatsu-zine.com
PDFのみ。以前に紙書籍で一度読んでいる。

情熱プログラマー

tatsu-zine.com
PDFのみ。以前に紙書籍で一度読んでいる。

エクストリームプログラミング(新訳版)

tatsu-zine.com
達人出版会からはPDF販売。Kindle版はAmazonで販売。
旧約版は何度も読んだけれど……

エクストリームプログラミング

エクストリームプログラミング

アジャイルサムライ

tatsu-zine.com
PDFとePub対応。Kindle版はAmazonで販売。自分は紙版を以前読んだ

アジャイルサムライ――達人開発者への道

アジャイルサムライ――達人開発者への道

マイナビ出版(達人出版会)

スクラム現場ガイド

tatsu-zine.com
達人出版会からはPDF販売。Amazonからはリフロー版と固定レイアウト版が出ている。選択が難しい。

アジャイルな見積りと計画づくり

tatsu-zine.com
達人出版会からはPDF販売。Kindle版もある。自分は以前に紙書籍で一度読んでいる。

技術評論者

[改訂新版]Spring入門

gihyo.jp
技術評論社のサイトからはPDFとePub販売。Kindle版もある。

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

book Kindle

本日の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パターン

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

Project Management

ソフトウェア開発の見積もりと納期について言及されたブログ記事を見て違和感があったので掘り下げてみた記事。ソフトウェア開発の「見積もり」というと少なからず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年上半期に読んだ本からお勧め図書を選んでみる(文芸、ビジネス、技術書)

book Kindle

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

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

https://www.instagram.com/p/BAByGFHHEEx/https://www.instagram.com/p/BAXHZZ9HEF4/https://www.instagram.com/p/BAetttTHEBc/https://www.instagram.com/p/BArskrFHELi/https://www.instagram.com/p/BAw2jhWnEHk/https://www.instagram.com/p/BA3HylOnECD/https://www.instagram.com/p/BBMoXwpHEHm/https://www.instagram.com/p/BBpVfXQnEEA/https://www.instagram.com/p/BBph8dFHELE/https://www.instagram.com/p/BBzuTb5HEL2/https://www.instagram.com/p/BB4-MuunEJO/https://www.instagram.com/p/BCBz592HEFY/https://www.instagram.com/p/BCVQxFMHEBW/https://www.instagram.com/p/BCiHTgDHEP_/https://www.instagram.com/p/BCkpo_NnEFn/https://www.instagram.com/p/BCsgHAAHEIQ/https://www.instagram.com/p/BDDhCUanEE7/https://www.instagram.com/p/BDQiUSyHECB/https://www.instagram.com/p/BDlCxSvHEER/https://www.instagram.com/p/BD0qbtoHEIW/https://www.instagram.com/p/BED4_NhHENc/https://www.instagram.com/p/BEGkGjqnEMu/https://www.instagram.com/p/BEONMrWHEDt/https://www.instagram.com/p/BEdr9jqnELG/https://www.instagram.com/p/BEhS7SZHEGV/https://www.instagram.com/p/BE97Jq1HEPP/https://www.instagram.com/p/BE98B4SHEBP/https://www.instagram.com/p/BFMEByPHEIJ/https://www.instagram.com/p/BFgsEExnENh/https://www.instagram.com/p/BFgxg_gHEJH/https://www.instagram.com/p/BFwFz42HEO2/https://www.instagram.com/p/BGJ0SkHHEI0/https://www.instagram.com/p/BGZbxn5HEMb/https://www.instagram.com/p/BGbvJmGnEFQ/https://www.instagram.com/p/BGbvbNLnEGA/https://www.instagram.com/p/BGb4TlBnEJi/https://www.instagram.com/p/BGoxdYhHEKB/https://www.instagram.com/p/BGo6BwynEPs/https://www.instagram.com/p/BGraDOTnEKR/https://www.instagram.com/p/BG4Tw2snEIj/https://www.instagram.com/p/BHChczJDIoq/

オススメ文芸書編

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

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

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

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

火星の人

火星の人

オススメビジネス書編

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


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

オススメ技術書編

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

ソフトウェアシステムアーキテクチャ構築の原理 第2版

ソフトウェアシステムアーキテクチャ構築の原理 第2版

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

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

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

東大教養囲碁講座?ゼロからわかりやすく? (光文社新書)

東大教養囲碁講座?ゼロからわかりやすく? (光文社新書)

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

最近の読書環境について

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

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

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

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

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

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

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

Project Management

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

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

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

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

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

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


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

私たちが仕様書を彼に送ったのがほんの24時間前だったことを考えると、彼は昨夜読んだのに違いなかった。彼が質問をし、私がそれに答えた。簡単な質問だったが、それがどんな質問だったかどうしても思い出せない。彼が仕様書をパラパラとめくる手元に目をひきつけられていたからだ。
彼が私の仕様書をパラパラとめくっていて [落ち着けよ! 小娘みたいじゃないか!] …そして仕様書のすべてのページの欄外に書き込みがあるのを見たのだ。彼はあの分厚い仕様書をすべて読んで、欄外に書き込みをしたのだ。 全部読んだんだ! [ウワーッ、なんてこった!]
はじめてのBillGレビューのこと - The Joel on Software Translation Project

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

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

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

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

More Joel on Software

More Joel on Software

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

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

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

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

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

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

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

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

最低限のレビュアー心得

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

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

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

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

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

Project Management Waterfall Agile

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

pool-jump



こちらも合わせて読んだ

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

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

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

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

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

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

アジャイルと規律 ?ソフトウエア開発を成功させる2つの鍵のバランス?

アジャイルと規律 ?ソフトウエア開発を成功させる2つの鍵のバランス?

近年だとエンタープライズアジャイルのガイドの一つである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サービス事業開発や、自動取引の領域においてはアジャイル開発プロセスの親和性が非常に高いのだろう。ソフトウェアの改修や機能追加を人間系の制約なしに反映させることができるかどうか、人間系のボトルネック無くダイレクトに価値を生み出す事ができる領域なのか、というのが重要なポイントだ。ただ、悲しいかな企業システムの領域でこういった取り組みができる範囲は、割と限られているのではないだろうか。

まとめ / 今後に向けて

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

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

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