nDiki : ソフトウェア開発

• アジャイルソフトウェア開発
• 適応型ソフトウェア開発
• ソフトウェア開発の原則

ソフトウェア 開発 Wiki Subversion 見積もり ソフトウェアプロジェクトマネジメント Windows 見える化 Web 現場 プロジェクトマネジメント 書評 WiKicker 計画 プレゼンテーション 革 ビルド 書き方 Joel on Software ドキュメンテーションガイドライン 仕様書 識別子 ガントチャート 納品 日本語 朝会 ソフトウェアかんばん ミーティング Linux コミットメント

■ はたして仕事に希望をもてたか?

ふれあい職場体験学習として、近くの中学校の中学生2人がお昼を挟んで半日ほどオフィスにやってきた。 直接かかわらなかったので詳しくはわからないけれど、あまり刺激的な経験をさせてあげられなかったんじゃないのかな。

バーチャルリアリティも扱っているとはいえ、中学生が想像するようなゲーム的な要素はあまり無いから、期待したものとは違ったであろう。 それはまあいいとしても、「職場体験」させてあげるのは難しかったのではないか。 「ソフトウェア開発の現場としてコードをちょっとでも書く」、「3Dコンテンツの作成をしてみる」いうのも基礎知識の無い状態で「体験」というところまでもっていってあげるにはどうしたら良いか。

本人達にとって何か得られるものがあったなら幸いだが、どうだったのだろう。 月末納品とかでバタバタしている人も多かったのでタイミングも良くなかったし。

話によると、革鞣を体験グループもあるらしい。 あ、それいいな。自分がいってみたい。

• ドキュメンテーション大全 (2006-02-15)
• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)
• Leatherman juice S2 に注意 (2004-11-11)
• コラボレーションを促進するオフィスレイアウトへ (2006-03-11)
• 見られていることが「報酬」になる (2006-07-01)

■ ソフト契約と見積りの基本がよ～くわかる本

最近契約的な視点での決め事にかかわる事が多くなってきたので先日買ってみた。 見積もりの部分はおまけ程度で、契約・契約書の作り方が中心。 ソフトウェア取引の契約について

• ソフトウェア開発委託契約
• ソフトウェア使用許諾契約
• ソフトウェア保守契約
• 情報処理委託契約

などがあることやそれらの概要を確認できるという点でなかなか良い。

権利的には

• 著作権
• 所有権
• 使用権
• 特許権・実用新案権

などかからんでくるのだが、ソフトウェア特有の複雑さがありすぐ混乱してくる。 やっかい。

面倒な世界であるな。

書籍はわかりやすいが、契約(書)例が少ないのが残念。 著作権等がどちらの権利になるかなどについてもう少し解説があると嬉しい。 第三者ソフトウェアがからんできた時の説明も欲しい。

またソフトウェア開発委託契約例はウォーターフォール的なモデルにもとづいており、現場としてアジャイル的なモデルで進めたいと思っても相容れない部分が多い。

それと「図解入門」シリーズということで図がふんだんに使われている。 図があった方がわかりやすいのだが、わざわざ図にする必要のないものを無理やり図にしたり図が間違っていたりするものがあったりする。ちょっと注意。

• ソフト契約と見積りの基本がよ～くわかる本

委託・受託双方にハッピーな結果(と権利関係)が得られる契約が作れるのが一番いいんだけれど、実際のところ

• 力関係
• 雛型がある場合、組織の方針・風潮として(全く/あまり)変えられない事が往々にしてある
• 面倒。時間がかかる。

などなかなか思うようにいかないものである。

この辺りについてカバーされている書籍があれば、ぜひ読んでみたい。

[ 書評 ]

• Joel on Software - 必読書 (2008-08-14)
• コミットメント・リスト vs ガントチャート (2005-10-19)
• ドキュメンテーション大全 (2006-02-15)
• 自分が個人で開発したフリーソフトウェアを自社製品に組み込むとき (2005-05-16)
• 開発の現場 Vol.004 「上流脳」をつくろう! (2006-04-14)

■ コミットメント・リスト vs ガントチャート

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

@ モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

• 作業時間がある程度精度よく見積もれる
• 作業時間と成果が比例的である

であるような場合はガントチャートで計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

@ ガントチャートを利用したマネジメントの特徴

• マネージャからのトップダウン的なスケジュール向き
• リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
• 比較的多人数のチームでもいける
• リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
• 人月計算/コスト積算できる
• プロジェクト外からの割り込みの発生によって狂いやすい
• 成果がみにくい
• チェックしにくい
  • 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
• ぱっと見、計画できている気がする
• 期間が長いと、チャートが見にくくなる
• 1日単位で見積もりたくなる
• 休日が気になりだす

@ コミットメント・リストを利用したマネジメントの特徴

• 担当の裁量を尊重・重視
• コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
• 期日前にせっぱつまりやすい
• 依存関係が複雑だと把握しにくい
• 専用のソフトウェアがなくても可能
• 他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
• 線表派からみると計画だと思ってくれないかも

@ 自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

• スケジュールの変更があった時に面倒
• 現状とあわなくなってくるとだんだん見なくなった
• 結局だんだんメンテナンスしなくなってしまう
• 進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

@ コミットメント・リストでうまくいっている点

• 成果が達成できているか、そうでないかが明確
• 達成できていないコミットメントのチェック、フォローができている
• 担当自身が忘れていたコミットメントもクロスチェックで再認識できる
• コミットメント一つ達成するたびに「いい気分を味わえる」

@ まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。

• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)
• Joel on Software - 必読書 (2008-08-14)
• すごい会議の正しい手順 (2005-07-04)
• すごいKPT事後評価セッション (2005-10-07)

■ ドキュメンテーション大全

プロジェクトの後半で納品用ドキュメントの整備を始めるのだが、その時はたいがいもう切羽詰りはじめていて構成やら体裁やらマネジメントやらを工夫する余力が無かったりする。 ついつい(次回は改良しようと思っていつも思っている)前回のプロジェクトの手法を踏襲してしまいがちだ。 ともすれば劣化コピーになりかねない。

やはり、忙しくても日頃からの改善は重要である。

最近はアジェンダ・議事録・開発メモなどを、積極的に Wiki や Subversion で共有するようにし、その点では以前より改善してきている。

今後はさらに、出荷ドキュメントのレビュープロセスなどを確立し品質を高めていきたいところである。 現状でもチームメンバでのピアデスクチェックやパスアランドを非形式的に行っているのだが、「チェックの程度」やその後の「修正」および「修正の確認」については、まだなんとなくやったかなという具合。この辺りを工夫したい。

先月発売されていて気になっていた「開発の現場 Vol.003」に、何かヒントがあるかなと思って買ってみた。

• 開発の現場 Vol.003 効率UP&スキルUP ドキュメンテーション大全

パラパラと見た感じではテクニカルライティングの話はあまりなく、主にソフトウェア開発における中間成果物としてのドキュメントや開発者間ドキュメントをどうとりまとめていくかという話が中心のよう。 Wiki による開発資料のライトな共有など、うちのチームでも進めている話など。

「(最初から)完全なドキュメントを書こうとしない」というのはもっとも。 状況はほとんどの場合変わるし、最初の段階では未確定の部分も多い。 だからといって、いつまでたっても手元で温めていてもしょうがない。

技術的な話では Perl の Pod を活用しようという話。 Perl 以外の言語のコメント中に Pod 形式でドキュメントを書こうという提案や、Apache で動的に Pod ドキュメントを整形しようという話とか。

テキストフォーマットとしての Pod は =over / =item / =back によるリスト表現など、最近のフォーマットに比べてすごく読み易いわけではないが、たしかに他の言語のコメントに埋め込んでおいて処理するのは、標準の Pod 関連のモジュールでできるな。

自分も Pod でドキュメントを書くけれど、(Perl 以外は) 個人的には reStructuredText にしたいと考えている。 ただ Pod みたいに他のテキストの一部に埋め込んでその部分のみ処理する記法およびツールがが標準の reStructuredText / Docutils には見当らない。 実はどっかにあるのだろうか。

[ 書評 ]

• 定型書式で内容を記述していくのに便利な形式は? (2005-11-21)
• bundle を作成して Perl モジュールをまとめてインストール。 (2004-10-21)
• Joel on Software - 必読書 (2008-08-14)
• 第1回 社内 Perl 勉強会 (2006-04-21)
• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)

■ ソフトウェア開発プロジェクトで朝会をすることにしてみた

私を含めて3人で進めているソフトウェア開発プロジェクトについて、今日から朝会をしてみることにした。 情報共有の促進や、問題の早期発見・解決、コミュニケーションの緊密化などが主な目的。

しかしまだスタイルが全く確立できていないので、どれぐらいの時間で誰が何をしゃべればいいのか手探り状態。

• ビジネスメールガイドライン案 (2006-05-05)
• メールによる社内コミュニケーションの問題 (2006-04-12)
• ソフトウェア開発プロジェクトにおける朝会をカイゼンする (2007-04-06)
• 早朝会議革命 - 元気企業トリンプの「即断即決」経営 (2005-07-16)
• Joel on Software - 必読書 (2008-08-14)

■ ソフトウェア開発プロジェクトにおける朝会をカイゼンする

Jason Yip 氏による「朝会のパターン:立ってるだけじゃないよ (It's Not Just Standing Up: Patterns of Daily Stand-up Meetings)」という記事の日本語訳を、数日前に kdmsnr 氏が公開された (記事)。

らあるソフトウェア開発プロジェクトで2月から朝会を行ってみているのだが、この記事をみてもっと工夫できそうだということで、良さそうな点を取り入れてみることにした。

一昨日にに新ルールをアナウンスしたのだが、昨日は私は休んでしまったので自分としてはスタートは今日から。

@ ルール

記事を参考に、以下のルールにしてみた。

• 立ってやる。(New!)
• 15分以内でやる。
• 最後に来た人から話す。(New!)
• 時計回りで発表する。(New!)
• 以下のフォーマットで話す。(New!)
  • コミットしたことを達成できたか? (昨日はどうだったか?)
  • 今日コミットできることは何? (今日はどうする?)
  • コミットメントを達成するための問題点は何?
• 話す内容は前日に準備しておく。(New!)
• 見える化する (New!)。
• 講演会にしない。問題解決に集中しない。プロジェクトに関係ある話のみにする。(New!)

見える化については、まずはコミットメントを A3 ホワイトボードに書き出すことにした。

3人のチームなので今日は、10分で終了。 いつもは問題解決をつい始めてしまい長引きがちであったが、こうして明確にルールを共有しておくと、互いに制止しやすくてなかなか良い。

しばらくこのスタイルでやってみて、また改良していくことにしよう。

• すごい会議はじめての全手順(1/2) (2005-06-30)
• 情報カードを使って高速すごい会議 (2005-10-27)
• ソフトウェア開発プロジェクトで朝会をすることにしてみた (2007-02-15)
• すごくない会議 (2005-06-29)
• Rekisa で TortoiseSVN から日本語ファイルの差分表示 (2006-03-23)

■ ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler

ときたまやってくるソフトウェア開発の計画作成、今までは GanttProject を使っていたのだけれども、挙動が安定しないのと印刷機能が貧弱なのとで満足できていなかった。

ということで今回は新しいツールを使ってみることにした。チョイスしたのは TaskJuggler。

Linux 上で動くツールである。 GanttProject は Windows でも Linux でも使えるのが利点だったのだが、ここ数年の中でプロジェクトファイルを共有することも無かったので、まあ Linux だけでしか動かなくてもいいかなと。

@ テキスト形式でのプロジェクト記述

TaskJuggler が特徴的なのは、プロジェクトをテキストファイルで記述するところである。 一般的なプロジェクトマネジメントツールは GUI 上でガントチャートを直接編集したりできるのだが、TaskJuggler はそんな軟弱者向けの機能は用意されていない。

あくまでテキストで書く。プロジェクト・リソース・タスク・レポートをテキストファイルに書く。 でコンパイルするとガントチャート等のレポートが生成される。実績もテキストで入力する。

書き方に問題があればコンパイルエラーになるし、定義したタスクの依存関係等でプロジェクト期間からはみ出てしまうような時もコンパイル時に怒られる。 渋い。

@ TaskJugglerUI

とっつきにくく見えるが、慣れると以外とそんなに難しくない。 effort と length と duration の違いが分かればあとは楽勝。

TaskJugglerUI という GUI ソフトウェアでは、補完機能の優れたエディタが内蔵されているしサイドバーのリストからタスク等を選んで、対応する行に移動することもできる。

さながら Eclipse でコードを書いているような感じ。

下手にガントチャート上でタスクをドラッグアンドドロップして、日にちを動かすよりも思った通りに定義していけるので良い。

@ 印刷

ガントチャートについては、それなりに見やすいフォーマットの印刷物を生成してくれる。 印刷からプリンタとして「Print to File (PDF)」を選択すれば日本語も含めて問題なく PDF 化できるので、でき上がったものも配付しやすい(ここら辺は KDE 側の範疇か)。

GanttProject では PDF 出力がイマイチで結局、画像ファイルにエクスポートしてプリントアウト/配付していたのでこれは便利。

@ 面倒な点といえば

面倒な点があるとしたら、タスクに ID をつけてその ID で依存関係などを指定してあげなければいけない点か。 識別子を考えるのが面倒なのと、タスクの数が増えてきた時にその指定したい ID を探す(思い出す)のが面倒である。

あと、識別子の名前変更リファクタリング機能があればいいな (一括置換だと関係ないところまで置換してしまう可能性がある)。

@ ということで

ソフトウェアエンジニアには使いやすいツールだと思う。

マクロ機能やインクルード機能などもあるのでもう少し使いこんでみたい。

• http://www.taskjuggler.org/

• コミットメント・リスト vs ガントチャート (2005-10-19)
• フォト イメージング エキスポ 2005 (2005-03-18)
• GanttProject で開発スケジュールを作成 (2004-08-26)
• amaroK で Linux 上の iTunes 音楽データを聞く (2006-01-22)
• ロバート・キャパの未公開カラー写真 (2005-02-19)

■ Windows 向けソフトウェア開発者はソースパッケージを作る習慣がない

GNU Autotools や ExtUtils::MakeMaker (とその仲間たち)で make dist するのがあたり前になっている自分には、気持ち悪い。

ビルドの自動化とソースパッケージ作成の自動化・バージョン管理のセットアップは、最初の仕事だと思うのだが。

• Module::Build でソースパッケージング (2005-08-24)
• SCons は GNU Autotools のかわりになるか (2005-04-20)
• nmake で毎回 pl2bat されるのを何とかしたい (2004-11-25)
• ActivePerl で Ming (2005-02-23)
• NSIS 2.22 は Linux でビルドできず (2006-12-20)

■ Google ドキュメントでソフトウェアかんばん

ソフトウェア開発の見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。

今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。

@ 他の検討候補

TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。

• TRICHORD - 本命。使ってみたいが予算が。
• Firefox + Internote (light-board.com ライク) - カード感は十分。しかし共有に難。
• 影舞用に新しくソフトウェアかんばんテンプレートを作る - 影舞を使い慣れているという点では○。ただストリーカードとタスクカードをどう扱うかが課題。
• Wiki - 以前やって失敗した。
• XPlanner - インストールと学習が手間。それと開発止まっている?
• その他 Agile Project Management Tool - カードメタファで良さそうなのはあるが、予算が。
• Google ドキュメント プレゼンテーション - 矩形をカードにしようとしたが文字は別オブジェクトで書かなければならず×。文字の背景を設定するというのも試したが見栄え・操作性が良くなかった。

スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。

@ スプレッドシートの作成

以下のようにスプレッドシートを作る。

• 1シート目はインフォメーションシートにする。ソフトウェア概説・かんばんルール・通信事項などを書くのに使う。
• 2シート名以降をかんばんにする。複数ソフトウェアならシートを分けてもよいかもしれない。
• かんばんシートE列の背景を「条件をに応じて変更」で本日より前だと赤くなるように設定する。
• かんばんシートF・G・H列の背景を「条件に応じて変更」で @ と書くと背景がそれぞれ赤・黄・青くなるようにする。

• ソフトウェアかんばんサンプル rev. 1

@ カードの書き方

• 各行にはストリーカードかタスクカードを書く。
• ストーリーカード行は目立つように罫線をつける。

TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。

@ 運用

• カード番号は重複しないように。
• カードの状態にあわせて @ を書き換えていく。
• DOING から TODO に移る時には、開始日と担当者名を消さないで残しておく。
• 列単位でソートしないこと。
• タスクの粒度はできるだけ揃える(例えば半日～1日にする)。

@ 課題

• カードが増えた時に使いにくくならないか? 終わったカードを別シートに分けるルールなどを考える。
• タイムボックス等にあわせて並び換える時の手間。
• カード番号が手動。
• 集計について考慮していない。

• ソフトウェアかんばん (2005-10-28)
• WiKicker でソフトウェアかんばん (2007-03-01)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• 京大式カード (2005-10-26)
• 今日のさえずり - SO905iCS おそれていたほどは厚く感じなかった (2008-02-08)

■ 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-10-28)
• 仕事のヒント (2005-11-26)
• ナノパーセント日 (2005-10-26)
• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)