『コンピュータの名著・古典 100冊』で読んだ本、読みたい本

『改訂新版 コンピュータの名著・古典 100冊』を読んだ、というか目を通した。名前の通りコンピュータに関して「これは読むべき」な本の紹介本。なのでこれ自体の書評をしたり、この本からの示唆をまとめるというのは向かない。ということで読んだことあった本と、これを見て読みたいと思った本などをメモしておこうと思う。

読んだことのあった本

なんとたったの2冊！しかもどちらもこのブログで紹介したものだ。まぁこれまで経営・マネジメント系の本ばかり読んでいてIT関連の本を読みだしたのはここ最近なのでしょうがない。

•  『ピープルウエア』トム・デマルコ、ティモシー・リスター
  

  以前書評を書いたこちら。人間は機械のようには動かない、という当たり前だが管理者になると忘れがちなことを思い出させてくれる。

  進捗管理と開発者のやる気：『ピープルウェア（第2版）』を読んで - ぷろまねさん

  ピープルウエア　第3版

• 『人月の神話』フレデリック・P・ブルックス・ジュニア
  当然ながら人月の神話も入っていた。ブルックスの法則はもちろん、外科手術チームなどソフトウェア開発プロジェクトについての金言が散りばめられている。
  

  見積りは慎重に：『人月の神話』を読んで - ぷろまねさん
  

  人月の神話【新装版】

「ほしい物リスト」に入れた本

• 『ゲーデル、エッシャー、バッハ』ダグラス・R・ホフスタッター
  前から書名は知っていて気になっていたが内容を知ってさらに興味が湧いた。哲学者、画家、音楽家という異なる分野の3人を「不思議の環」というキーワードで結びつけて、さらにソフトウェア開発や人工知能に言及するなんて、どんなロジックになっているか気になってしまう。しかし分厚い&高い。

  ゲーデル、エッシャー、バッハ―あるいは不思議の環 20周年記念版

• 『心の社会』マーヴィン・ミンスキー
  「人工知能に心は宿る」側の人の本。この問いは近年新しく発生した唯一の哲学的な最大の問いだと思う（この文章少しおかしい、が良い言い方が思いつかない）ので、宿る派、宿らない派ともに追っていきたい。

  心の社会

• 『コンピュータには何ができないか』ヒューバート・L・ドレイファス
  そして「人工知能に心は宿らない」側の人の本。この本では知性という言葉のほうを使っているようだけれども。

  コンピュータには何ができないか―哲学的人工知能批判

• 『思考する機械 コンピュータ』ダニエル・ヒリス
  コンピュータの基礎的概念から未来のコンピュータの姿についてまで書いてある入門書だとか。

  文庫 思考する機械コンピュータ (草思社文庫)

• 『ビーイング・デジタル』ニコラス・ネグロポンテ
  デジタル化によって様々なものがビットに置き換えられることで何が起こるか、今後人間とコンピュータの間の関係性（インターフェース）はどのようになるかなどについて言及している。

  ビーイング・デジタル - ビットの時代 新装版

• 『いかにして問題をとくか』ジョージ・ポリア
  本書を読む前にすでに積ん読されていた本。いわゆるコンサル本に多い「問題解決」についての古典、という理解。ただし問題解決の対象は数学。

  いかにして問題をとくか

• 『やさしいコンピュータ科学』アラン・W・ピアマン
  

  僕は情報工学系出身ではないので、そういえばちゃんとしたコンピュータサイエンスを学んできていない。普段必要性を感じることはあまりないが、こういった基礎を通っていることはじんわりと効いてくるはずなので、米国で入門書としてスタンダードだというこちらあたりで近々一通り把握しておきたい。

  やさしいコンピュータ科学 (Ascii books)

• 『文芸的プログラミング』ドナルド・E・クヌース
  Texを作った著者による「美しいプログラムとは」の本。新入社員研修の自己紹介のとき、この本の存在も知らずに「美しいプログラムってあると思います」とイメージだけで話したことがあることを思い出した。それを理解して語れるようになるよう、この本にも手をだしてみたい。

  文芸的プログラミング (ASCII SOFTWARE SCIENCE Programming Paradigm)

• 『珠玉のプログラミング』ジョン・ベントリー
  こちらは本日ちょうどあったので買ってきた。なるほど、著者は前述のクヌース教授の弟子なのか。「プログラミングの本質」に焦点を当てアルゴリズムやデータ構造について解説しているとのこと。正直マネジメントばかりしている僕が読むのは骨が折れそうだ、、がたまにはこういう知識や考え方も入れておきたい。
  

  珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

• 『スーパーエンジニアへの道』ジェラルド・M・ワインバーグ
  

   ワインバーグの本はいくつか読んだがこちらは読んでなかった。技術者や管理者に求められるリーダシップについてとのこと。

  スーパーエンジニアへの道―技術リーダーシップの人間学

• 『ソフトウェア工学』シャリ・ローレンス・プリーガー
  いわゆる「コンピュータはなぜ動くのか」的な話ではなく、要求定義、機能仕様、、といった実際の開発について言及している本のようだ。プロマネ視点では既知の内容ではあるが、ソフトウェア工学的な観点から見るとどういうことが書かれているか単純に興味がある。
  

  ソフトウェア工学―理論と実践

以上、かなり気になる本も発掘出来て良かった。読むべき本は多く、それを消費するための時間は少ない。。。

改訂新版　コンピュータの名著・古典 100冊

プロマネが声をかけるとき作業を邪魔してませんか？

プロマネの仕事は（デマルコ先生あたりの教義に沿えば）メンバが気持よく作業に集中出来る環境を整えることだ。当然しっかりと進捗管理などを行ってプロジェクトの最新状態を常に可視化しておくことも重要だが、それをするためにメンバの邪魔をして進捗を遅らせていては本末転倒である。

そのため、「如何にメンバの邪魔をせずに必要な情報を引き出すか」はプロマネにとっての重要な技能の1つ*1だと僕は思う。

ということでこれに役立つテクニックのうち「声をかけるタイミング」についてまとめてみた。プロマネ視点ということで対チームメンバを想定しているが、声をかける相手が顧客だったり上司だったりしてもほとんど同様なので適宜読み替えてほしい。

誰かに話しかけるとはどういうことか

誰かに話しかけるということは、相手の作業を一時中断させるということである。これは直接面と向かって話す場合でもそうだし、電話をかける場合でも同様だ。そして人それぞれだが、話しかけられた相手は通常、会話によって一時中断された作業に戻るにはそのための余計な時間がかかってしまう。

また誰かと話しているところに割って入って声をかけられたり、あるいは会議に出席している人の電話が鳴って会議が中断したりするようなことは経験したことがないだろうか？この場合話しかけられた人のみならず、その2倍〜参加人数倍の人の時間を無駄にしていることになる。これは作業中断時の時間の無駄だけを取っても勿体無い。

誰かに話しかけるということは必ず相手の時間の犠牲を伴う行為である。そのため、誰かに話しかける場合にはその犠牲を最小限にするように意識する必要がある。

話しかけていけないサイン、いいサイン

ではその犠牲を最小限にするために、話しかけるタイミングを見計らおう。そのためには前述のような過ちを犯さないために「誰かと話しているところには極力割り込まない」だとか、「可能であれば電話するときには相手が会議中でないか事前に確認する」といった点に注意すべきだ。

その上で、相手が一人で机に向かっているときに話しかけたいというケースを想定する。そういった場合でもむやみに話しかけてはいけない場合もある。それを判断する以下の様な「サイン」を相手は示しているはずだ。

＜話しかけてはいけないサイン＞

• PCに向かって一生懸命タイプしている
  ⇒ これは資料作成をしていたり、コーディングをしていたり、アウトプットに集中している状態である。アウトプットというのはいつでも気軽に出来るものではない。気分も乗らなければいけないし、閃きも必要になる。そのような状態を中断させるのは非常に非効率的であるので、極力話しかけてはいけない。
• PCに手をつけずにいる、画面をじっと見つけている、変な方向をずっと向いている、（寝ているわけではないが）目をつぶっている
  ⇒ これは頭の中で考え事をしている状態である。無数の暗黙的な情報をつなぎ合わせてアウトプットに結びつけようとしているときであり、このようなときに割り込みが入るとそれまでの思考は霧散してしまう。話しかけやすいように一見見えるが、一番話しかけてはいけない。

＜話しかけていいサイン＞

• マウスに手をかけホイールしている、溜まったメールを読んでいる
  ⇒ これは断片的な情報をインプットをしている状態である。このタイミングで深い思考をしていることは稀であり、このような作業を中断しても大きなインパクトはない。こういったときに話しかければ、相手も比較的愛想よく応対してくれるだろう。

タイミングを見計らうには余裕が必要

しかしこのようなサインを見極め話しかけるタイミングを見計らうのは、あくまでその内容が緊急でないときだ。当然緊急度の高い内容であれば、いくら話しかけてはいけないサインが出ていたり、誰かと話していても割り込んで話しかける必要がある。

だがそもそもそのような緊急のコミュニケーションを要するようなことを発生させないことがプロマネとしての腕の見せどころではないか。常にプロジェクト内外にアンテナ高く周りを見渡し異変を早期に検知・対応することで大抵の急を要するコミュニケーションは不要になるはずだ。その上で話しかける必要ができたら、すぐさま話しかけるでもなく、そのデッドラインギリギリまで待ってしまうでもなく、「話しかけていいタイミング」を見計らって話しかければ良い話だ。

そもそも話しかけることが必須か？を判断する

さらに「話しかけなければならないのか」も見極めたほうがいいだろう。直接の会話によらずとも、相手の都合の良いときに見てもらうことが可能なメールやチャット、あるいはポストイットへのメモ書きで代替出来ないかを考えてみたほうがいい。

出来れば話したい内容であっても、上記の「話しかけてはいけないサイン」がずっと続くようであればコミュニケーション手段を切り替えるというのもひとつの方法である。

とはいえ「なんで近くにいるのに話しかけてこないの？」と思う人も少なからずいることにも注意し、メール等の手段に過度に依存しないことも心がける必要がある。また、特にメールの場合は文面を推敲出来てしまうが故に直接の会話よりも自分の時間を多く使ってしまいがちである。自分の時間と相手の時間のそれぞれを尊重し、適切なコミュニケーション方法を採用することが肝要だ。

気にしすぎ？

ちなみにこの話、僕のプロジェクト内で若手向け勉強会のネタにしようと思っていたのだが、僕の担当分のレビュワーになってくれている先輩マネジャーからは「こんな細かいこと気にしたことないよ」ということでボツにした。その方が特段大雑把なほうでもないし、むしろ非常に信頼のおける方であるので、一般的なマネジャーからするとここまで気を配るようなことでもないのかも知れない。しかし僕の経験上これを意識したことによって、特に偏屈気味な開発者の人々と良い関係に転じることが出来たので、無駄ではなかったと思っている。

ピープルウエア　第3版

マネジャーの実像

*1:ミンツバーグがマネジメントに必要なスキルを「アート」、「クラフト」、「サイエンス」の3つに分けた中で言えば、これはクラフトに分類されるだろう。

SIerの生き残る2つの道：『システムインテグレーション崩壊』を読んで

比較的新刊なこちらを読みました。IBMの営業畑出身で現在独立してIT企業向けコンサル会社をされている著者、さすが書名がキャッチー。

中身はひとつひとつのトピックを取れば目新しさはないものの、「SIは崩壊する」と言い切ったのは日本の書籍としてはおそらく初だろうし、各トピックがうまくまとまっていて良かった。ただこれはITの本ではなくて、ビジネス書、いやむしろ経営書な内容なので注意。1プログラマや、非経営層向けというよりも、SIerの経営者、むしろSIerと呼べないソフト開発会社の経営者向けと理解した。

SIの本質とは何か

僕は7年間SIの現場にいたが、本だったりWeb記事だったり、周りから聞いた話だったりで「SIとは何か」に対して明確な答え、定義を持っていたのは本書が初めてだと思う。

まず、本書ではSIの「本質的な」定義を以下のようにしている。シンプルかつ、的を射た非常に良い定義だと思う。

本来、SIは、テクノロジーやノウハウを組み合わせ、ユーザー企業の求める最適なシステムを構築する請負型ビジネスを意味します。*1

一方で「SIが崩壊する」という文脈で使う場合の「既存の」SIの定義は以下の通り。

ここでいうシステムインテグレーション（SI）とは、「工数積算を前提としたビジネス全般」のことです。

我が国のSIは、工数で見積もりする一方で、納期と完成の責任を負わされるビジネス形態です。

つまり、「提示した見積工数と納期に対して発注者にコミットするようなSI形態は崩壊する」と言っているのだ。これはSIerにいる人々の実感にも近いだろうし、事実その可能性は高い。

アジャイル型請負開発

そしてその崩壊の元凶の1つとされているのがウォーターフォール型開発だ。その理由はそこかしこで議論されていることとそれほど大差ないため割愛するが、それに対するカウンターとして著者は「アジャイル型請負開発」を提唱している。これはアジャイル開発をある程度現実味を持って請負開発に適用しているのでなかなか面白い。要点をまとめると、以下の3点になる。

• 業務を遂行するうえでなくてはならない要件に絞り、それ以外を外した工数・期間を算出し、請負契約を締結
• 各要件に対して優先度に従い開発を進める
• 開発途中に優先度が変わった場合は合意した工数・期間内で未対応の案件と入れ替え可能

さて、これはこれまでの一般的な請負開発とどこが違うのか。

まず「全部作らない」というところだろう。最初に業務遂行に必須な部分に絞っているのでこれまで「使うか分からないけど今入れないと作ってもらえないから入れとこう」といって入っていた要件が省かれる。これは短期的には開発のボリュームを減らすことになるので受託者としてはマイナスだが、要求の純度（必須度合い）は上がるため最終的には双方にとってプラスになるだろう。ただそのためには現場を押さえる力が必要だ。

次に要件定義フェーズ後も要件の入れ替えが可能なところ。これも双方にとってプラスではあるが気をつけなければいけない点がある。新しく優先度の高い要件が発生した場合にはノーコストで入れ替えが可能なわけではないのだ。新しい要件はまだ要件定義が行われていないので追加で要件定義コストが発生するし、既に開発済の機能に対して新しい要件が適合するように影響分析を行う必要がある。得てして要件定義や影響分析が可能な要員と開発要員は異なるので、最初から要件の入れ替えを見越して要件定義・影響分析が可能な要員も残しておかなければならない（そして入れ替えが発生しなければその要員が浮いてしまうリスクを取らなければならない）。

しかしそれよりも大きな問題は、最初の時点で請負契約を締結するためその際の工数・期間の見積もりに誤りは許されない（誤っていた場合はその分受注者＝SIerが瑕疵担保として補償しなければならない）ことだ。これは「（特に初期段階の）見積もりは間違っているもの」というアジャイルの原則を逸脱しているため厳密な意味でのアジャイル開発ではない。純粋なアジャイル開発は請負契約では行えない。だから「アジャイル型請負開発」という別名になっているとも言える。

するとどうなるかというと、誤りのない見積もりが必要になる。そのためには要求仕様に対して精査し、きっちりと要件定義を完了させる必要がある。とすると、本書がいうように「おおよその工数と期間の見通しを立てて金額を決め、請負契約を締結」するというのは現実的ではなく、引き続き長期間の要件定義フェーズが必要となってしまう。もちろん上記は「業務を遂行するうえでなくてはならない」プロセス・機能だけに対して行えばいいわけで、それ以外（必要かどうかわからない、あったほうがいいかもしれない）ものについてはその時点で必要ない。その分だけ早く要件定義を切り上げられた分のスピードアップにはなるが、抜本的解決にはならないと感じる。

そういう意味で、本当は純粋なアジャイル開発を行いたいのだけれどもこれまでの慣習に囚われたこの業界での妥協策として「アジャイル型請負開発」を提唱している、と考えたほうがいいかと思う。契約形態と開発手法でマトリクスを作ると、以下のようになるはず。

生き残る道は2つ？

しかし本書ではアジャイル型請負開発だけを唯一の将来的SIer像として描いているわけではない。もうひとつはクラウドを活用したサービスビジネスだ。*2

これはクラウドを使う、使わないという単純な話ではなく、（そのベースがパッケージ製品かを問わず）1つの顧客に対してしか使えないシステムを開発することと、不特定多数の企業を潜在顧客として先行投資でサービスを開発することという決定的な差が存在する。後者はむしろ製品販売・開発を行う企業に近しい。

そのため筆者は「売り方」がまったく異なると主張する。これまでのように「個人力で売る」やり方から、「仕組みで売る」やり方に転換が必要で、そのためにはマーケティングの方法を変えなければならないという。これはその通りだろう。このあたり、やはり営業出身の著者だと思う。

一方で変えなければならないのは売り方だけではない。作り方も変えていかなければならない。顧客に聞けば要件が出てくるわけではないし、そもそも要件定義・設計・開発といったフェーズ分けもナンセンスになってくる。1度のリリースで完了というわけにもいかなくなり、Ver1.0リリース後の不断の改善が必要になってくるので「ゴール」があいまいになる。この点は1箇所だけ触れていたと記憶しているが（どこだったか思い出せない）、十分と言えるほど言及されていなかったところが惜しまれる。

つまり、SIerがサービスプロバイダに転身するには売り方と作り方、両方のパラダイムシフトが必要になる。これはかなりの障壁であるものの、出来ない話ではないはずだ。個人的にはこの道を是非模索していきたい。

システムインテグレーション崩壊　?これからSIerはどう生き残ればいいか？

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

*1:完全に蛇足だが、本書に敢えて難癖をつけるとすると句点が多いのが気になった。僕も何も考えず文書を書くと句点を多く使いすぎてしまうのだけど、見返せば省けるところは見つかるので、もうちょっと校正しっかりやればもっと良くなると思う。

*2:著者がサービスビジネスのみを行う企業をSIerの範疇に含めているかというと、SIの定義を「請負型ビジネス」としてる通り含めていないと思われる。なので、SIerのひとつの選択肢として、SIerからサービスプロバイダに転換することを示している、といったほうが正確。

アジャイルな見積技法：『アジャイルサムライ』を読んで

読んでからずいぶんと経ってしまったのだけど、アジャイル開発について言わずと知れた『アジャイルサムライ』について書いておく。

本書はアジャイル開発についての思想とそれを支える各種ツールを、かなり平易な言葉で時に面白おかしく、かつ網羅的に解説している。アジャイルについて本格的に学び始めるには非常に良い本だと思う。

構成としては大きく3つ、計画、運営、開発の3部構成になっている。計画部分でアジャイルに適した見積もりの仕方など、運営の部分でイテレーションを単位としたプロジェクトの進め方、開発でTDD、CIなどのアジャイルに親和性の高い各種開発手法を紹介している。今回は計画の中の見積もりに話題を絞ってみる。

アジャイルな見積技法

面白いところは、見積技法として「絶対的な数値として精緻な見積もりを行うことを敢えてせず、何らかの実績のある作業と比較して相対的に（作業Aのx倍）見積もりを行う」という点。これには以下3つの背景が存在する。

1. プロジェクト初期段階の見積もりはあくまで概算（当てずっぽう）であるので、プロジェクトが進むに従って精緻化していけばいい、と顧客などにも割り切らせる
2. 得てして絶対的数値で見積もるよりも、何かと比較しての相対的な見積もりのほうが案外正確
3. 絶対的な数値で出してしまうと、出した途端にそれが「唯一絶対正しい数値」かのように扱われてしまいがち

 1.はアジャイルのそもそもの考え方に通じる。それを見積もりでも体現して、「そもそもアジャイルだとこうなんです、最初から全量が固定する訳じゃないんです」ということを分からせるためにも必要なことだ。これが受け入れられるかがアジャイル採用可否の分かれ道になってしまうとも思う。

2.と3.は人間の性質上陥りがちな過ちを見抜いた素晴らしい洞察だと思う。ウォーターフォール型開発を続けている多くのプロジェクトでもこの2点について苦労をしているプロマネも多いはず。

ウォーターフォール型での対処（苦肉の策）

かくいう僕もこの2点については煮え湯を飲まされつつ、自分なりの対処をしてきた。2.については、今までに自分がリードして見積もったことのない大きな規模の案件に対して、敢えて大中小で見積もり、最後にそれに係数を掛けて工数に換算するという方法を採った。大中小にだいたいの目安の数字（小は1−5人月とか）をつけておけば、実際に見積もり工数を提示する担当者は過去の同規模の案件と比較して大中小どれが妥当かを回答する。これは見積者に対して正確な数字を見積もるという負担を下げるという意味もあった。見積もりのオーダ（単位）を少数の選択肢に絞るという意味では、本書の「ポイントで見積もる」という技法とも整合する。

3.については非常に原始的な方法だが、概算見積時には「これは概算」である旨をとにかく強調することと、詳細見積として自信を持って出せる段階になるまでは書面での工数回答を行わない（口頭でのみ「だいたいこれくらい」と回答する）という回避策を採っている。このあたりは「先ずは見積もり工数を」となってしまうウォーターフォール型の限界だ。

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

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

IT人材白書2014をプロマネ視点で読み解く

IPA（情報処理推進機構）発行のIT人材派遣の2014年版を流し読みしてみたので、このブログのテーマでもあるプロマネの話題中心に気になったポイントをピックアップしておく。

https://www.ipa.go.jp/jinzai/jigyou/about.html

Web企業はIT企業（SIer）よりもPM手法を重視しない

Web企業、IT企業（すなわちSIer）、ユーザ企業の3分類で今後拡大予定の技術力についてのグラフが以下(同書p.44)。

これによるとどの企業分類でも圧倒的なのは顧客や業務の分析力、企画力といった、所謂ビジネスアナリシスの技術。このあたりは当然ではあるが、トレンド的に増加傾向なのかそうでもないのかも見てみたいところ。これまでクラフト（職人芸）的に暗黙知化されていた領域ではあったがだんだんBABOK（PMBOKのビジネスアナリシス版）も知名度が上がってきているので、今後サイエンス化（定型化・体系化）されていくのはないかな。

そしてWeb企業ではIT企業・ユーザ企業に対して半分程度しか重要視されていないのがPM手法。白書によれば「スマートホンアプリなどについて比較的小規模・少人数の体制で開発が実施されている ことの反映だと思われる。」とのことで、確かに小規模開発のほうが大規模開発よりもマネジメントを意識的には行わず、定型化された手法（図や統計値）も使う機会が少ないかも知れない。確かにEVMを使った進捗管理のような、いわゆるPM手法は出る幕が限られるのだろう。しかしスピード感が求められ、市場に近いWeb企業のほうが、リスク管理や、人材のモチベーション管理などについてはSIerと同じか、それ以上に力を入れる必要があると思う。このあたりは実際Web屋さんたちがどのように考えているかはお聞きしてみたいところ。

プロマネに必要な能力

次に、IT人材に対して重視される能力について（pp.98-105）。ここではWeb企業について言及がなく、IT企業、ユーザ企業のみの分析になっているのが母数的に謎。いったんIT企業＝SIerだと思っておこう。

IT企業で最も拡大していきたい職種はプロマネとのこと。 後ろのページ（p.143）にあるが絶対数としても「アプリ技術者よりもプロマネが多い」という結果が出ているが、これはさすがにおかしいんじゃないか。考えられるとすると、技術者は既にオフショアが大半で日本国内だけで見ると管理職＞技術職という可能性だが、さすがにそこまでオフショア化されていないと思うし。いずれにせよ、IT企業としてはプロマネの需要は高いということ。

そのプロマネに対して求められる「人間力」が以下のグラフ。（こういうのを人間力というのか、、いや違う気もするが。）面白いのは「管理能力」については25.1%とそれほど高くなく、アプリ技術者に求められる水準とそれほど変わらず、それよりも「問題解決能力」や「リーダーシップ」が求められているということ。

結局プロマネは専門職であることを求められているわけではなく、問題を見つけてそれを解決するための道筋を示し、それにメンバを引きずり込むようなリーダーとしての能力が求められている。言われたことだけを粛々とこなすなんちゃってプロマネが多いなか、経営層から求められるプロマネ像との間にギャップを感じる。 

IT人材白書2014

ビジネスアナリシス知識体系ガイド (BABOKガイド)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

世界一わかりやすいプロジェクト・マネジメント【第３版】

Redmineカスタマイズ事例：チケットの作成単位

プロジェクトに続いてチケットの作成単位について。

もともと僕のチームで行っている運用保守業務ではチケット管理システムとして自作ツールで以下を管理していた。

1. ユーザからの問合せ
2. ユーザからの作業依頼
3. ユーザ以外（顧客IT部門、自社内）からの問合せ、作業依頼
4. 定常作業（月末締め対応や監視で検知した問題の対応）
5. 障害の対応（バグ等）
6. 仕様変更対応
7. 自主的なシステム改善

つまり、（管理作業などを除き）チームで行うほとんどの作業はチケットとして起票されている、基本的なTiDDなルールには元々従えていたわけだ。（属人化していない運用保守プロジェクトであれば基本的に上記のようになっているのではないかと思われるので、運用保守業務はTiDDとの相性は悪くないと思っている。）

一方、上記の単位（案件と呼んでおく）毎にチケットは起票されているたが、各案件には通常複数のタスクが紐づく。障害対応であれば、設計書の修正、プログラム改修、テスト、レビュー、移送、初回稼働確認等というように。これらのサブタスクの管理は管理ツールの1テキストフィールドにベタ書きしていくというルールにしていた。そのため、以下3つの課題が存在していた。

• 「何をやる必要があるか」を毎回1から記載するため、作業に抜け漏れがないかが分かりにくく、属人化しやすい（初回稼働を忘れる、など）
• 各案件の顛末（どういう理由で何が決定され、何が実施されたか）が長文を読み解かなければ理解出来ず、振り返りに時間がかかる
• 各サブタスクの詳細まで可視化されていない（誰が担当で、いつ完了予定か等）

作業の流れに即したワークフローを設定

まず1点目の課題に対してはワークフローが役立っている。障害対応、仕様変更対応といった案件のカテゴリ毎にワークフローを設定し、必ずすべきことをワークフロー上に乗せた。例えば、チケットをクローズするのは特定のユーザのみに限定しておき、実作業者ユーザはクローズ依頼申請する際に障害対応であれば初回稼働確認を行った結果をRedmineに記載しなければそのステータスに遷移出来ない、など。

どのようなワークフロー設定にしたかの詳細はまた別の機会に説明したい。

顛末を記載するフィールドを用意しておく

次に2点目の課題に対しては、「結局そのチケットで何を行ったか」を記載するフィールドを用意し、先に説明したワークフローと合わせて作業者に記載させるようにした。

Redmineには更新時に注記を記載していく機能があるので、対応の途中段階では注記に随時状況をアップデートしていくことになるが、対応完了時に上記を記載するルールとしている。注記が長くなってくると結局何をしたかが曖昧になってしまうので、サマリ情報を保持させておき、今後の振り返りに役立てたいという意図。

サブタスクは子チケットとして起票する

そして3番目が「チケット作成単位」という意味でこれまで使用してきたツールと大きく変更した点。Redmineにはチケット間に親子関係を設定することが可能なため、サブタスクも子チケットとしてどんどん起票するように促している。起票の粒度に厳密な定義は設定しないが、基本的に以下の粒度になるまで分解している。

• 担当者を1名に限定出来る
• 予定工数が2～16時間（2人日）程度

親チケットには紐づく子チケットが最小限の情報とともに一覧化されるため、毎日のステータス確認はその一覧を見ながら状況の概観を確認、気になるサブタスクの状況を子チケットを表示して確認、という流れで回している。親チケット画面の子チケット一覧は情報は少ないところがネックだが、ここはプラグインでなるかも知れない。

しかし、正直なところRedmineの親子関係設定については課題も多い。少なくともデフォルトでは子チケットから親チケットを設定するには番号を指定しなければならず、もう少し直感的な紐付け方も欲しいところ。また、「関係するチケット」が紐付いているチケットに対して親チケットを新規設定しようとするとエラーになる、おそらくバグも存在しているようだ。

Redmineによるタスクマネジメント実践技法

Redmine超入門（日経BP Next ICT選書）

Redmineカスタマイズ事例：プロジェクト作成単位

Redmine運用が開始出来たので、カスタマイズや運用の事例をまとめておく。まずは「プロジェクト（およびサブプロジェクト）をどういった単位で作成したか？」について。

今回は以下2点のルールとした。

• 運用チーム主体ごとにプロジェクトを作成する
• 大規模な仕様変更の場合はサブプロジェクトを作成する

運用チーム主体ごとにプロジェクトを作成する

ものの本や記事を見ていると、アプリケーション単位でプロジェクトを作成するのが常道っぽい。当初このルールに従って3つのプロジェクトの作成しようと考えていた。（アプリケーションA, B, Cとしよう。）

しかしアプリケーションBは（SAPのERPパッケージなのだが）ユーザに画面を開放しておらず他システムとデータインターフェースに使用する中間システムとして機能している。そのため、このアプリケーション単独で問合せ等が発生することはなく、案件管理はこれまでもアプリケーションAのメンバ（僕を含め）が主体となって実施しており、Bのメンバは実作業者のみで構成していた。

そのため、アプリケーションAとBをプロジェクトとして分けてしまうと進捗確認時にはAプロジェクト、Bプロジェクトの双方を見なければならないため非効率的になってしまう。ということでアプリケーションAとBは同じプロジェクトとした。*1

一方アプリケーションCはアプリケーションの特殊性ゆえ自社メンバではなく外部ベンダが主体となり、僕が進捗管理、品質担保、および顧客との調整を行うのみ（実作業は外部メンバに一任）となっている。そのため、AとBに比べて独立性が高いので別プロジェクトとした。

という風に、「誰が運用の主体になるのか」によってプロジェクトを分割してみたが、今のところ上手くいっている。基幹システム系であれば多くないと思うが、それ以外のシステム領域（税金計算、品質管理など）であれば小粒のシステムが乱立しているという状況もしばしばあると思われるので、そのようなときに愚直にシステムごとにプロジェクトを作成する必要は必ずしもないだろう。

大規模な仕様変更の場合はサブプロジェクトを作成する

上記のようにプロジェクトはいったん2つに絞ったが、大規模な仕様変更が発生した場合はその主体プロジェクト下にサブプロジェクトを作成することとした。サブプロジェクトを作成するか否かの定義は敢えて明確に定義していないが、工数、プログラム本数、担当人員数などで適宜判断することとしている。特にメインで実改修を行う人員が複数になるのであればサブプロジェクトを設けてよいかと思う。

サブプロジェクトを作成することによる利点は以下2点だろう。

• サブプロジェクトのチケット情報を排除して統計情報、一覧を取得しやすい
• サブプロジェクト単独での統計情報を取得しやすい'

特に2点目の意味で、完成率やEVM情報を簡単に取得出来るというのは開発管理としては大きな利点になる。

一方で、デメリットとしては、サブプロジェクト自体はチケットとしてカウントされないため、上記のようにサブプロジェクトのチケット情報を排除して統計情報を取得するとサブプロジェクトにした案件分の情報が欠如してしまい、不正確な情報になってしまうという問題がある。この点はちょっと面倒なのだが、親プロジェクトに別途サブプロジェクトの案件に相当する案件をチケットとしても起票しておき、ステータス項目のみそのチケットで管理するということにしている。そうすればサブプロジェクトの情報は無視して報告しても統計情報として問題ないサマリが手に入る。

Redmineによるタスクマネジメント実践技法

*1:別フィールドでアプリケーションAとBを区別する情報を持たせてもいいと思うが、今のところは用意していない。