勘と経験と読経

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

ITエンジニアと法的要件の考慮

XP祭り2016で発表された「巷にはびこる間違ったUX論へのヘイトをぶつける集い」という発表をめぐる一連の議論を読みながら考えた事。ちなみにUXについては門外漢であるし、そこについての意見は無い。ただ、この中で出てくる「UXデザイナーは法律の考慮も行うべきなのか」については異論を唱えたいところ。

rosetta

なお一言断っておくと、「巷にはびこる間違ったUX論へのヘイトをぶつける集い」講演者の@takigawa401は知人である。だからと言って擁護するような意図は無いし、多分そういう内容になっていない。
また、もともとの議論はUXデザイナーに関するものなのだけれど、本記事ではより広義な事を書いているつもりなので記事タイトルは意図して「ITエンジニアは〜」というビッグワードを使っている。

プロフェッショナルを名乗るのであれば法規の遵守は第一の要件である

まあこの一言に尽きるのだけど・・・

2016年の現在においては、ユーザーニーズだけでなく(このブログで取り扱っているように)既存の各種法律や慣習もユーザーニーズと同様に機能使用や情報の構造に影響を与えるファクターとして存在しています。確かに16年前ではユーザーニーズを検討しておけば十分だったと思います。しかし現在ではITサービスの社会的需要の拡大により、サービスと既存法制との接点も十分に検討すべき課題として挙がっていると個人的には考えています。このような状況の中で、あくまでUXデザイナーの業務はUXだけに限るのか、よりよいサービス(の仕様書)を作るためにUXだけでなく法律や慣習まで業務範囲に含めていく必要があるのか、その辺りUX界隈の人たちがどのように考えているのか興味があります。

もちろん業務を行う上で、法律や商習慣の知識はあった方がいいでしょうし、その方が物事は早く進みます。ですが、UXデザインはそれ自体が非常に大変で専門的な役割であり、だからこそUXデザイナーはUXデザインに注力すべきでしょう。専門外のところまでフォローしようと思ったら、1日24時間どころか72時間あっても全然足らなくなってしまう。法律や商習慣、業務の細かな内容の確認は、それぞれのスペシャリストに任すべきです。だからこそ我々はチームを組み、協業して製品やサービスを開発するのです。

もちろん法的要件の適格性を最終的に確認するのは専門家の役割であるとは思うのだけれども、「UXデザイナーはUXデザインに注力すべきでしょう」という点には同意しかねるのである。職業プロフェッショナルを名乗るのであれば、当然のように法的要件および政治的・文化的要件に配慮すべきである。UXデザイナーに限った話ではなく。

これは職業倫理の問題なのだけれども、ちょっと長いが「ソフトウェア・エンジニアリングのための倫理ならびに専門職実務綱領(日本語訳)」の序文が素晴らしいのでこれを引用して説明したい。

コンピュータは商取引,産業,行政,医療,教育,娯楽,社会全体において中心的な役割を果たしており,その役割はますます増大しつつある。ソフトウェア・エンジニアはソフトウェア・システムの分析,仕様決定,設計,開発,保証,メンテナンス,テストに,直接的な参加あるいは教育を通じて貢献している。ソフトウェア・エンジニアは,ソフトウェア・システムの開発に対して果たすその役割ゆえに,
・自らが善いことをするのか,害をもたらすのか,
・他者が善いことをするのを可能にするのか,害をもたらすことを可能にするのか,あるいは,
・他者が善いことをするよう影響を与えるのか,害をもたらすよう影響を与えるのか,
を決定づける,重大な機会に直面する。自らの取組みが善いことのために利用されることを可能な限り確実なものにするために,ソフトウェア・エンジニアはソフトウェア・エンジニアリングを有益で尊敬に値する専門職の仕事とするよう最大限の努力を投じなければならない。こうした責務に従い,ソフトウェア・エンジニアは以下の倫理ならびに専門職実務綱領を遵守すべきである。
(中略)
倫理的な対立状況では,詳細な規則を盲目的に信頼するよりもむしろ,基本的な原則について注意深く考えることによって,それに最もよく取り組むことが可能となる。そうした原則とは,ソフトウェア・エンジニアに以下のようなことをするよう促すものである:
・誰が自分達の仕事に影響を受けるのかについて広い視点で考え,
・自分達ソフトウェア・エンジニアが他の人々を,当然払うべき尊敬の念をもって扱っているかどうかについて考察し,
・社会の人々が自分達の決定を,もしその内容がきちんと知らされるならば,どのように思うのかについて考え,
・最も権限・権力のない人達が,自分達の決定によってどのように影響を受けるのかについて検討し,
・自分達の行動がソフトウェア・エンジニアとしての理想的な専門家の仕事であると判断されるに値するものであるかどうかを考える。
これらのすべての判断において,社会の人々の健康,安全,福利への関心・配慮が最も重要である。すなわち「公共の利益」こそが,この綱領の中心に存在するものである。

類似のものとしてはITに限定しないエンジニア全般のものとして「技術士倫理要綱」、ソフトウェア開発については「認定情報技術者 倫理要綱」もあるのだけれども基本的には似たようなことが書かれている。要は「専門外なので知りません」とは言うべきではないのである。

ただ、もちろんこれは姿勢の話であって、最終的には専門家に頼らざるをえないとは思う。それでも取り扱う領域において、配慮すべき論点についてのリサーチは行うべきだし、それをすることが本来の職務の妨げになることは無いだろう。

翔泳社さんの技術書がKindleでセール中の模様

定点観測結果。久しぶりに割と翔泳社さんの大型技術書が50%前後オフのセールになっている模様。
これですね。10/2まで。

めぼしい、既読を中心におすすめのものをピックアップ。

組織パターン

組織パターン

  • いわゆるソフトウェア開発組織改善のタネ本。よくある悩みがパターン化されているので、よく読み返してるな。

エッセンシャル スクラム

エッセンシャル スクラム

  • すいません、実は未読です。

実践ドメイン駆動設計

実践ドメイン駆動設計

  • すいません、実は積読です。

旧書の類

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

  • 最近DDDの話題が盛り返している印象もありますが、原典として。

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

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

  • いつ果てるともないレガシーとの戦い方。

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

  • 再読しているのだけれども、こちらも名著の類ですね。

他に、情報処理技術者試験対策本もセールになっている模様。
受験予定の方はチェックしてみると良いかもしれない。

久しぶりにKindleで20%オフの大規模セールで技術書が買い時かも

昨日くらいから、Kindleで割と大規模にポイント還元が始まっている模様。20%ポイント還元。最近こういったセールの頻度が下がっている印象もあるので、要チェック。個人的な観測では「みんなではじめるデザイン批評」が初めてセール対象になったような気がしてて、購入するか迷っている。

値引きが大きいもの

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

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

残念ながら未読。気にはいるのだけれど・・・
ポイント還元も考慮すると実質半額。

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

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

名著のひとつ。とりあえず「なか見検索」ができるので内容を確認すると良い。
ポイント還元も考慮すると実質半額以下。

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

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

こちらも名著のひとつ。上巻だけだけどポイント還元も考慮すると実質半額以下。
とはいえ、世の中にはこういった意見もあるのでご注意。

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

その他めぼしいもの

みんなではじめるデザイン批評

みんなではじめるデザイン批評

  • 作者: アーロン・イリザリー(Aaron Irizarry);アダム・コナー(Adam Connor)
  • 出版社/メーカー: ビー・エヌ・エヌ新社
  • 発売日: 2016/07/26
  • メディア: Kindle
  • この商品を含むブログを見る
未読。最近出た本。冒頭にも書いたけれど、初めてここまで値段が下がった気がする。
この記事を読んで、購入するか迷っているところ。

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

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

既読。良い本なのだけれども、あまり真新しい事は書かれていない。
他の話題の自己啓発本を読んでいるようであれば、手に取る必要はないかも。
ただ、非常に読みやすいのでこの手の本を読んだ事がなければお勧め。

未読。気になっているのだけれども読む時間が作れない。

こちらも未読。

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

サーチ・インサイド・ユアセルフ ― 仕事と人生を飛躍させるグーグルのマインドフルネス実践法

既読。興味深いのだけれども、タイトル通り瞑想に関する本なので注意。
かなり意識高くないと、ひとりで実践は難しい印象。

既読。これも技術の本ではないのだけれどいろいろ参考にしている。良書。

How Google Works

How Google Works

既読。Googleがすごいってことはわかる。しかし真似できないよ、という感想。

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

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

既読。個人的には、本書をテストの本ではなく組織改革の本だと思っている。
学ぶ事の多いお勧めの一冊。

エンタープライズアプリケーションアーキテクチャパターン

エンタープライズアプリケーションアーキテクチャパターン

いま実は再読している。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

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

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

既読。アーキテクトの教科書としておすすめ。高額なので購入のチャンスかも。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

既読。難しいけれど得るものが多い良書。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

実践ドメイン駆動設計

実践ドメイン駆動設計

積ん読中。まずい。高額なので購入のチャンスかも。
ただ、翔泳社の木曜セールでもっと割引される日が来るかもしれない。

既読。エンタープライズアジャイルといった事を検討しているSIer所属の人におすすめ。
こちらも高額なので購入チャンスなのだけど、翔泳社の木曜セールでさらに割り引かれる可能性はある。

他にもいろいろセール対象になっているみたいなので検討している本があればチェックしてみるのがよいかと。

週報 / Snippetsのススメ

昔から習慣として「週報」を書くということをしている。最近発売された「 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以外で気になる電子技術書籍をまとめてみた

主に自分用のメモ。セール等を活用して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%オフのセール

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