nDiki : ソフトウェアプロジェクトマネジメント

ソフトウェアプロジェクト管理。 主にソフトウェア開発プロジェクトのプロジェクトマネジメントのこと。

開発 見積もり ソフトウェア Joel on Software ビルド 仕様書 ソフトウェアかんばん コミュニケーション ソースコード エクストリーム・プログラミング アップデート リスク 要求定義 リスク管理 KPT リーダーシップ リファクタリング ソフトウェアテスト 朝会 仕様 社長 見える化 ソフトウエア開発 55の真実と10のウソ 習慣 ピアレビュー Web サイト nDiki コーチング 面接 問題解決

■ どうみても、そのままでは失敗しそうなプロジェクト

欲しい機能と完成予定日とを考えると、どう考えても無理なプロジェクトの話が出ているようだ。

真実10. 見積もりは、上層部か、マーケティング部門が実施する場合がほとんどだ。実際にプログラムを開発したり、開発プロジェクトの直接のマネジャーが見積もることはない。結局適切な人が見積もっていないのだ。-- ソフトウエア開発 55の真実と10のウソ p.51

(Fact 10. Software estimation is usuall done by the wrong people.)

まだきちんと見積もりが行われていない。もちろんきちんと見積もるべきである。 きちんとした見積もりを見れば現状の予定は無理すぎ(というか不可能)で、期間をのばして段階的に機能を提供していくべきだということを理解してもらえるであろう。 ……理解してもらえるよね? 不可能がわかっていて無理やり走っていつか闇に葬られるよりいいよね……。

真実9. ソフトウェア開発の見積もりは、プロジェクトの開発時に実施する場合が非常に多い。これだと、要求定義が固まる前に見積もることになり、どんな問題がどこにあるかを理解する以前に予測するので、意味がない。従って、見積もり時期として適切ではない。-- ソフトウエア開発 55の真実と10のウソ p.48

(Fact 9. Software estimation usually occurs at the wrong time.)

[ ソフトウェアプロジェクトマネジメント ]

• Joel on Software - 必読書 (2008-08-14)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• ナノパーセント日 (2005-10-26)
• ソフトウェアかんばん (2005-10-28)
• ドキュメンテーション大全 (2006-02-15)

■ ナノパーセント日

ミーティングで、あるプロジェクトのスケジュール遅れが議題になった(参加していないプロジェクト)。

リクエスト側と開発側で、仕様の誤解による手戻りが大きな原因のようである。

• リクエスト側と開発側が物理的に離れていたため、顔を合わせたキックオフミーティングを行わなかった。
• その後のコミュニケーションも不足であった。

あたりが問題か。 物理的な距離の壁はデカイ。

それから、β版リリース日がナノパーセント日(あるいはそれよりも前)であった可能性も高いように思えるが、その点はどうか。

(Naney 注:リスク図の)曲線の左側が水平になる地点が、「確率がゼロではない最初の日」である。しかし、限りなくゼロに近い。この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ。-- 熊とワルツを, p.65

自分も「これどれぐらいでできる?」と言われると、つい奇跡的最短期間を口にしがちである。 気をつけねば (もっとも、見積もりとは関係なく期日がセットされていて内容で調整ということも多いが)。

[ ソフトウェアプロジェクトマネジメント ]

• Joel on Software - 必読書 (2008-08-14)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• どうみても、そのままでは失敗しそうなプロジェクト (2005-05-16)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスク... (2008-06-14)

■ ソフトウェアかんばん

先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。

プログラマ間でのコラボレーションが一つの課題になった。 決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。

またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。

ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。

よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。

今回はこれをちょっとアレンジして実践してみることにした。

• B6 情報カードを使う。
  • この大きさだと書くにはちょうど良さそうだが広い壁が必要になりそうだ。
• エクストリーム・プログラミングのように、まずはストーリーカードを作成する。
  • 今回はベースとなる仕様書の機能を実装する形。ビジネスサイドがストーリーカードを作るという体制にはできないので、開発チームでストーリーカードをおこす。
• ストーリーカードからのタスクカードおこし。
  • 時間の関係から、まずは優先度の高いストーリーカードを選んでこれをタスク化する。
  • タスク化済みのストーリーカードは(tなどの)マークをつける。
• タスクカードのカテゴリは「TODO」「DOING」「CHECKING」「DONE」の4つとする。
• 開発者は TODO タスクカードから1枚カードを選んで署名して DOING へ移す。
• タスク作業完了後「DONE」あるいは「CHECKING」へ移す。
  • 「CHECKING」はチームはタスクを受け持った人が作業完了後、チームでチェックをして欲しい時に入れられるカテゴリ。
  • カテゴリ名はこれでいいかな?

まずはこれでスタート。

実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。

今後であるが、以下の点をまだ行っていないので順次実行していきたい。

• イテレーションの設定
• タスクの見積もり
• ストーリーの見積もり
• 全体の見積もり
• 定期的チェックタイムの設定
• 貼りやすいプッシュピンの入手

[ ソフトウェアプロジェクトマネジメント ]

• Google ドキュメントでソフトウェアかんばん (2008-03-30)
• 今日のさえずり - フロスティ食べたい (2009-12-10)
• Joel on Software - 必読書 (2008-08-14)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• WiKicker でソフトウェアかんばん (2007-03-01)

■ 「プロジェクトマネジメント」はどうやって勉強すれば良いですか?

会社の後輩から問われた。

答えがあればこちらが知りたい。

プロジェクトマネージャには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトマネージャは答えの決まっていない問題の解決をしていかなければならないのだから。

もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。 ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が～～で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。

ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。

ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。

• 技は盗むもの - 早朝会議革命

@ とはいえ自分なりに列挙してみる

ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。

• 問題発見力、問題解決力 (思考法)
• 意思決定力
• リーダーシップ力
• コミュニケーション力
  • コーチング
  • ファシリテーション
• プレゼンテーション力
• (リスク管理力)
• 以下に関する知識
  • 開発ガイドライン
  • ソースコード管理 (リビジョン管理)
  • バグトラッキングシステム
  • ビルド管理
  • リリース管理
  • ドキュメンテーション
  • ソフトウェアテスト
  • ソフトウェア見積もり
  • ソフトウェアライセンス
  • ピアレビュー

• ビジネスメールガイドライン案 (2006-05-05)
• 早朝会議革命 - 元気企業トリンプの「即断即決」経営 (2005-07-16)
• 久しぶりに build.xml を書く (2005-11-14)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• ソフトウェアかんばん「見えない化」 (2006-04-10)

■ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

自分がプログラムをスクラッチから書き直したいと思った時、またスクラッチから書き直したいと言われた時のためにまとめておこう。

@ スクラッチから書き直したい理由

スクラッチから書き直したいと思う理由はだいたいこうだ。

• もっと良くできると思うから
  • 「もっと良いやり方がある」「自分ならもっとうまく書ける」
  • 「統一されていない」「もっと汎用的にできる」
  • 「今なら新しい開発環境(・新しい実行環境・新しいライブラリ・新しい言語)を使って簡単によりいいものが素早く作れる」
• よくわからないいから
  • 「何をやっているかわからない」「どう直していいかわからない」
  • 「もう直しようがない」
  • 「作り直した方がはやい」
• あいつのだから
  • 「あいつが書いたコードだから」

どんなプログラムでも開発が進み詳細がわかってくると、こうしておけば良かったと思う点がでてくるものだ。

さらに、他人が書いたプログラムだとよく分からない。

It's harder to read code than to write it. (プログラムというのは書くより読むほうが難しい。) -- Things You Should Never Do, Part I - Joel on Software

いっそ作り直してしまいたいと思うのはどの開発者でもあることだ。

@ スクラッチから書き直してはいけない理由

しかし多くの場合スクラッチから書き直すことはリスクとデメリットだらけだ。

• 今までの投資を失うから
  • 「そのプログラムには検討・不具合修正に膨大なエネルギーが投入されている」
  • 「ユーザは今のプログラムのために学習コストをかけている」
• 時間がかかるから
  • 「その新しいプログラムが今と同じレベルの価値を実現するまでは時間がかかりすぎる」
  • 「スクラッチし直してから投入したのでは、もはや価値を失っている可能性が高い」
• 前轍を踏むから
  • 「どう直していいかわからないと思う時は往々にして目標がわかっていない。目標がわからずに作ったものは結局またスクラッチから書き直したくなる」
  • 「あなたが連続的にプログラムを修正できないというのなら、どちらにせよ新しく作り直したプログラムもあなたは連続的にプログラムを修正できない」(リグレッションテストの習慣はあるの? リファクタリングスキルはあるの?)

ほとんどの場合は、漸進的に今のプログラムを修正・改良していった方が得策なのだ。

@ スクラッチから書き直してもいい場合

そうはいってももちろんスクラッチから書き直した方が合理的な場合もある(書き直してはいけない場合も書き直した方が合理的だと思ってしまうわけではあるが)。

それは次のような場合だろう。

• ソースコードがない場合 (ディスククラッシュした。利用する権利がなくなった)。
• もはや開発環境も実行環境も手に入らず、移植も困難な場合。
• 個人的な趣味のプログラムの場合。
• スクラッチから書き直したプログラムに対して、また「スクラッチから書き直したい」という欲求にかられない自信がある場合。

本当にスクラッチから書き直した方がよい場合は止める理由はない。

さてこの記事をスクラッチから書き直したいと思う時がきませんように。

@ 参考

• Joel on Software
  • Things You Should Never Do, Part I - Joel on Software
• はじめからやり直したい症候群
• 最上の日々 - なぜ最初から作り直したくなるのか
• [を] アホでマヌケな米国(アメリカ)ハイテク企業

[ ソフトウェアプロジェクトマネジメント ]

• Joel on Software - 必読書 (2008-08-14)
• ナノパーセント日 (2005-10-26)
• C++ 用ソースコードフォーマッタ Uncrustify (2009-08-10)
• PPM とか (2003-10-01)
• Linux 上で Flex 2 SDK を使った Flash コンテンツ開... (2007-09-11)

■ Joel on Software - 必読書

「スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。」で参照したのがきっかけで、ジョエルテストで有名な Joel on Software を読んだ。

• Joen on Software

ソフトウェアプロジェクトマネージャ・ソフトウェア開発者必読書の1つだね。

扱っているテーマは幅広くどれも気になる記事ばかり。 ここではメモがてら興味深かった主要な記事をピックアップ。

@ 3章 ジョエルテスト

3分でできるソフトウェアチームの良さを評価する有名なテスト。

@ 5章 やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか?

仕様書の最も重要な役割はプログラムをデザインすることだ。p.51

仕様書についての章が何章か続く。仕様書について実践的なことが書かれているのでとても参考になる。

@ 6章 やさしい機能仕様 パート2: 仕様書とはどんなものか?

サンプル仕様書が用意されている。 何をどのように書くべきかについて参考になる。

@ 8章 やさしい機能仕様 パート4: ヒント

そしてなぜ誰も読まないかといえば、仕様書があまりに退屈でつまらないからだ。p.79

これを読んでからできるだけ話を具体的に書くように心掛けている。 適当に外国人の名前をつけてシナリオを書くとなぜか皆喜んだ(同僚も外注も社長も)。

ルール5: テンプレートは有害である p.86

@ 9章 やさしいソフトウェアスケジュール

ソフトウェアプロジェクトマネジメントでうまくいかない事が多い筆頭がスケジュール。

「そのコードのスケジュールを立てられるのは、それを書くプログラマだけ」「タスクの粒度を細かくすること (それによって、その機能をデザインすることを強いられる)」「スケジュールにデバッグ・結合・バッファ・休暇・祝日その他のことのための項目を入れる」「決してマネージャにプログラマの見積もりを減らさせない」

あたりが参考になる。なおこの記事は Web でアップデートされている。

@ 12章 5つの世界

開発するソフトウェアの種類によって使える開発方法論が異なるのだから、自分のプロジェクトで適用できるかよく考えること。

@ 14章 アーキテクチャ宇宙飛行士たちに脅かされるな

抽象化ばかり考えて意味のないところまでいかないこと。

@ 21章 報奨金有害論

つい最近うちの会社でも表彰式があったばかりなんだけれども……。

マネージャは賞与の提案を上位に送り、それは完全に無視され、ほとんどランダムに賞与が支給される。p.188

多くの人は、自分が非常に良い仕事をしていると思っている (実際はそうでない場合でも)。p.189

@ 23章 人のタスク切り替えは有害であると考えられる

一つのプロジェクトに専念したいね。

人々に同時に1つより多くの作業をさせるべきではない。p.202

@ 24章 あなたが絶対すべきでないこと PART I

→ スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスクラッチから書き直したくなる。

@ 25章 氷山の秘密、明らかに

顧客は自分が何が欲しいか分かっていない。顧客が自分で何が欲しいか分かっていると期待するのはやめることだ。p.210

これを理解していないと何でも言うなりにソフトウェア化しようとして失敗する。

@ 31章 下っ端でも何かを成し遂げる方法

多くの人は自分が下っ端だと思ってモンモンとしている。

• 戦略1 実行あるのみ
• 戦略2 じわじわ広めていく
• 戦略3 優れた人間を作り出す
• 戦略4 間抜けを無力化する
• 戦略5 邪魔を避ける
• 戦略6 かげがえのない存在になる

まずは不満を持つだけでなくて、個人ででも実行しようということ。

[ 書評 ] [ お薦めの本 ] [ ソフトウェアプロジェクトマネジメント ]

• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• 仕事のヒント (2005-11-26)
• ソフトウェアかんばん (2005-10-28)
• すごい会議 - 短期間で会社が劇的に変わる! (2005-05-27)
• どうみても、そのままでは失敗しそうなプロジェクト (2005-05-16)