nDiki : ソフトウェア開発

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

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

■ 売りたいもの

保険会社から TEL。 「買いたいもの」ではなく「売りたいもの」を執拗に勧めるので、却下。 アンタのノルマ/歩合は知ったこっちゃない。 *1

……ソフトウェア開発でも「欲しがられているもの」ではなく「作りたいもの」に走りすぎないように自戒せねば。

• 歯の定期健診 - 今日はしっかりめ (2008-03-27)
• 退職お疲れさま会 (2005-03-25)
• 退職 (2005-07-29)
• 合格 (2004-11-12)
• FOMA F905i 購入 (2008-05-04)

■ キックオフミーティング2日目

今日は朝から雨。 オーシャンビューを満喫できず残念。

バイキング形式の朝食を終えてから荷物をまとめて会議室へ。

• 09:00 - 13:00 ミーティング (途中チェックアウトタイム)

@ wiki でプレゼン

進行が押せ押せだったので、自分の発表時はあまり時間もなかったのでさらりと。 というか準備もたいしてできていなかったというのもあるが。

ここまで全員 PowerPoint を用いたプレゼンテーションだったのに対し、自分はフォントを大き目にした Mozilla + Wiki (WiKicker) で発表。 さすがにその場でページを書き換えるような時間はなかったけれど、皆にはどのように見えたのだろう。 ちょっとプレゼンテンションツールとしては使えるんじゃないかなぁという感蝕。

@ まとめ

ソフトウェア開発というテーマのプロジェクトであるが研究者の集まりということで、全然話が収束した感じはなし。 それぞれ自分がやりたいことを主張して終わったという感じ。

1回目ということで顔合わせをかねた研究発表会に終始したという感じか。

@ 感想

Blog に注目している研究者が非常に多かったのには驚き。 Blog 群から何か有意な情報が抽出できるのではといった希望を持つ人が多いようだ。 しかしまだ漠然としたレベルがほとんどで、実際に何かBlogまわりで研究成果を出している訳ではないというのも面白い。

また Blog といってもそれぞれ捉え方が違っていて日記サイトを指していたり、個人ニュースサイトを指していたりとバラバラであった。

帰宅して各研究者の大学のページを探してみたが作成していなかったり、あってもほとんど情報が無かったりしてがっかり。 Blog も今のところ見つけたのは一人のみ。

うーんがっかり。

Webページの作成にしても Blog をやってみるにしても、(その人達にとっては)そんなに敷居が高くないはずなのでもっと実際に自分でやってみればいいのになぁと思う。 やってみて分かる事も多いはずだし。

それとももしかしたら私がさっと辿りつけなかっただけで、もっとプライベートにいろいろやっているのかな。

• キックオフミーティング1日目 (2004-10-25)
• LaTeX でプレゼンテーション (2005-06-21)
• 準備委員会キックオフミーティング (2005-11-19)
• Hyper Estraier で社内 Web コンテンツ検索 (2006-06-01)
• 私が情報発信を勧める理由 (2006-07-26)

■ Leatherman juice S2 に注意

いつも通りちょっと遅刻気味に駅から会社へ歩いていたところ、すれ違ったはずの警官2人が戻ってきて声をかけられた。 腰にぶらさげていた革ケースに目が止まったらしい。

「ちょっと見せてもらえますか」と言われたので Leatherman juice S2 を提示。 その場でスチール巻尺でブレードをチェック。 「6cmを越えると銃刀法にひっかかるんですよねぇ」

目的をきかれたので仕事でネットワーク関連作業で使用すると主張。

警官が「自分らでは判断ができないので交番まできてくれませんか」。

白黒微妙だなーと思いつつ、まぁ大丈夫だろうと思い一緒に交番へ。 実はその交番は会社の隣りでどのみちそちらへ向かわなければならないし。

で交番ではもう上司の警官がいてその人を含めて3人。 ちなみに一度も身分証明書の提示はなかった。

「仕事は何をされているんですか?」という質問をまた2度される。 ソフトウェア開発でシステム構築時の作業があって工具を使用すると言っておく。

バッグの中もみたいというので(まずいものもないし)中身を見せる。 「これがコンピュータのそれですか」とビニール袋を指差しながら質問された。 「それ、ただの折り畳み傘です…」

「財布の中も見ていいですか」「いいですよ」。ちらりと中をのぞいていた。

(NEW MEGALOPOLIS を見て)「かたそうなバッグですねぇ」「高いんですか〜?」

Leatherman については、再度スチール巻尺をあてながら「ここが6cmを越えると銃刀法にひっかかるんですよねぇ」「ココからですか?(刃のついているところを指す)」「そう」「一応6cm以下ですね」「うん」。

銃刀法(銃砲刀剣類所持等取締法)だと本来は「刃体の長さ」ではかるので実は juice S2 も 6cm を越えているはず。 警官、わかってない? (しかしまた、銃砲刀剣類等所持取締法施行令の第九条とあわせると、折りたたみ式・8cm以下・刃体の幅が 1.5 cm以下・刃体の厚みが 0.25 cm以下で固定装置なしという点から銃刀法の適用外であるはず)。

いちおう「業務その他正当な理由による場合」としての携帯扱いとされたのか、お咎めは無し。 ただし「工具箱やプラスチックケースに入れた上でカバンに入れてください」という注意。

「最近秋葉原も物騒になってきているので取締りを強化しているんですよ。 秋葉原だと私服がまわっているので、呼び止められちゃいますよ」。 そこまで言っていいんですかね。

特に名前・住所の記録等もなし(交番に行くまでに住まいと会社の場所を聞かれたので口頭で簡単な場所の話をしたぐらい)。

@ さて今後どうしたものか

Leatherman を持ち歩いているのは実際のところもちろん仕事のためだけではなくて何かの時のため(もちろん護身目的ではなく)。実際重宝している。

何かあった時(災害時)に「かばんの中の工具箱」にあったのでは利用不可になる可能性があるし身にしていないと不安なのだが、現行ではそうもいかんのだよなぁ。

Leatherman でプライヤー + ハサミがあるモデルは Juice クラスより小さいのではないし、かりにあって付属のブレードが 6cm 以下でも、どのみち軽犯罪法のしばりがあるし。

ナイフのないモデルがあればいいのだが。 あ、でもハサミですらアウトだっけか。 それに、プライヤーも見方によっては軽犯罪法の「他人の邸宅又は建物に侵入するのに使用されるような器具」該当する?

嫌な日本。

どうするかな。MICRA に戻す? squirt P4?

どちらにしても持ち方を考えねば。

• 2004年11月11日(木)　はわわ…そんなバカナー！
• 2004年11月22日:アキバよもやま アキバでの取締りが「路上看板」から「持ち物チェック」になった感じ
• アキバでの警察の持ち物チェックは管轄外の文京区の本富士署が検挙率アップのために行ったものもあったらしい::[アキバBlog]
• そーいや秋葉原の路上取締
• 2004-11-27 マニアの受難
• ぬるヲタが斬る： 秋葉原での警察の持ち物チェックは管轄外の本富士署が検挙率アップのために行ったものらしい

• GRAPH GEAR セミハードタイプ デジタルカメラケース DGB-01... (2005-02-07)
• ThinkPad X31 交換 HDD として Travelstar 5K... (2006-07-27)
• 無印良品のミニ6穴手帳 (2008-01-20)
• 今日のさえずり - 「ドン吉くんの鳥グッズ展」終了間近 (2008-08-08)
• 靴下にかぶりつく中年男性 (2004-07-23)

■ 国際化識別子IRIのRFC

IRIがRFC3987になった。

WiKicker を含めた WikiEngine など(非ASCII)キーワードからURIを生成するタイプのソフトウェア開発において今後要チェック。

• WiKicker における PageName 最長文字数 (2006-06-10)
• Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
• [ WiKicker ] WiKicker へ脚注機能追加 (2004-02-10)
• [ WiKicker ] 複数のキーワード集合による、AutomaticLink (2004-02-07)
• [ WiKicker ] If-Modified-Since: 関連作業ほぼ済 (2003-09-19)

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

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

真実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)
• ソフトウェアかんばん (2005-10-28)
• ナノパーセント日 (2005-10-26)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)
• スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスク... (2008-06-14)

■ 納得してする仕事と、納得しないでする仕事

前者の方が圧倒的に素晴しい仕事をするし満足度も高いと自分は考えている。 ソフトウェア開発なんてもろに差が出る仕事だ。 だからこそ、メンバが納得して仕事をできるようにマネジメントしたい。

簡単に納得してもらえなさそうならば「どのようにすれば納得してもらえるだろうか。納得して自発的にやりたくなるようにすればどのようにすればよいだろうか」ということを考えたい。 今日のミーティングでもそういう議論に持っていきたかったのだが、結果「会社が決めたことならば納得しなくてもやらなければならない」という風に流されてしまった。

目の前の納得していない人を、「納得しなくてもやらなければならない」と納得させようとしているこの矛盾。

米国の心理学者オーヴァストリート教授の名著『人間の行為を支配する力』に次のようなことばがある。「人間の行動は、心のなかの欲求から生まれる……だから、人を動かす最善の法は、まず、相手の心のなかに強い欲求を起こさせることである。商売においても、家庭、学校においても、あるいは政治においても、人を動かそうとする者は、このことをよく覚えておく必要がある。これをやれる人は、万人の指示を得ることに成功し、やれない人は、一人の支持者を得ることにも失敗する」-- デール・カーネギー、「人を動かす」 p.42

• キックオフミーティング2日目 (2004-10-26)
• 今日のさえずり - 明日のミーティング資料 Google ドキュメントで書いた (2007-10-31)
• 電線燃えてた (2005-08-23)
• 緊急出荷 (2005-02-28)
• ビビンバ丼をデリバリー (2005-02-23)

■ 普通の人向けに svnserve を立ち上げるか

開発チームでは主に svn+ssh で Subversion を利用している。

Windows ユーザは

1. 前準備「PuTTYgen で鍵ペアを生成し」「リポジトリのあるサーバ(Linux)側に公開鍵を登録」
2. 前準備「Pagent を動かして秘密鍵を指定しておく」
3. TortoiseSVN でリポジトリアクセス

という手順をとっている(参考記事)。 しかしこの方法は SSH に詳しくなかったり Linux のオペレーションとかに慣れていなかったりするユーザにはかなり敷居が高い。

最近ソフトウェア開発以外でのチームでも Subversion の利用を検討しているが、この手順だと多分萎えるはず。

SSHで暗号化するほどのセキュリティが必要ない運用なので、svnserve を起動して運用した方が楽そうだ。まだ使ったことがないけれど。

svnserve を実行する権限を気にする必要がある以外は基本的には手間なしのはず。 しかし svnserve の組み込みの認証機能を使う場合には、平文パスワード文字列を含むパスワードファイルを使う必要があるのがちょっと嫌。

• TortoiseSVN 1.0.4 (2004-05-17)
• TortoiseSVN と svn+ssh (2004-07-26)
• Unison + Zebedee (2004-06-11)
• ノート PC を持たずに会社に行きたい (2006-12-21)
• Subversion で大文字・小文字のみ違うファイル名へ変更 (2004-08-02)

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

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

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

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

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

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

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

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

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

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

権利的には

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

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

面倒な世界であるな。

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

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

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

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

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

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

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

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

[ 書評 ]

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

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

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

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

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

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

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

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

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

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

@ モデル

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

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

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

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

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

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

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

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

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

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

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

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

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

@ まとめ

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

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

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

• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• ソフトウェアかんばん「見えない化」 (2006-04-10)
• すごい会議の正しい手順 (2005-07-04)
• すごいKPT事後評価セッション (2005-10-07)
• Joel on Software - 必読書 (2008-08-14)