Freemind to MS-Office XSLT Library

開発方法論の話を続ける前に、ちょっと一休みです。

ちょっと仕事の片手間にFreemindの*.mmファイルをWordやらExcelに変換する
XSLを作りました。よろしければご利用ください。
うまく動かないとか、もっとこうして欲しいなどのご意見は
適宜コメントください。ベストエフォートで対応します。

◆使い方
Freemindのメニューから

ファイル->書き出し

でXSLTを選択、ダイアログが開くので以下の3つのXSLから目的に合ったものを
選択して、出力先を指定してExport。これだけです。
なお、出力形式はすべてXMLなので、拡張子もxmlでお願いします。

◆mm2wordml.xsl
FreemindのMindMapをWordの見出しに変換します。
ルートノードは表題になります。
見出しレベルは4まで対応しており、それ以上深いノードは切り捨てます。

◆mm2msp.xsl
FreemindのMindMapをMS-Projectのタスクに変換します。

◆mm2xls.xsl
FreemindのMindMapをExcelワークシートに変換します。
変換の仕様は我ながらかなり微妙です。

次はPowerPointかな...

作業の分割/分業/工程

前回のエントリにも何人かの方からコメントを頂きました。

頂いたコメントを読んでみて、私の中でも工程というものの
定義自体があいまいだったと思いました。
コメントを下さった方の意見は、工程に対する異なる定義に
基づいていて、そこがどうも議論のかみあわなさにつながって
いるような気がします。

私は、ソフトウェア開発における
・作業の分割
・分業
・工程の分割
の3つを区別して考えたいと思います。

3つのうち、もっとも基本的なものは作業の分割
です。これは単に、開発作業全体を管理可能な部分に分割することです。
これは単に分割するということ以上の何者も意味していません。
この分割は、スコープ管理、進捗管理など、プロジェクト管理の基礎と
なるため、ほぼ どのプロジェクトでも必要と思われます。
前回のエントリに対するhiro345さんの意見は、工程というものを
この最も基本的な意味での作業の分割という意味に捉えていると
想定され、その限りにおいて私はhiro345さんの意見に同意します。

分業は分割した作業を異なる担当者にアサインすることです。

さて、問題の工程です。過去のエントリを
読みなおしてみると、私は工程をほとんど作業の分割
と同じように語ってしまっていましたが、実は私の中では勝手に
もっと純粋にウォーターフォール的な意味での工程をイメージしていました。

私のイメージする「工程」を語るためには、まず「作業の分割」にも
次の2つのやり方があることを示さねばなりません。

1.直列に分割する
2.並列に分割する

1.の直列に分割することは、ある機能を実現する作業を

要件定義->基本設計->詳細設計->プログラム設計->
実装->単体試験->結合試験

といったように上流から下流に向かい、前の作業が終わらなければ次の作業に
移れないように分割することです。

2.の並列に分割することは、
システム全体を実現する作業を並行して行えるように、多くの場合は
機能毎に分割することです。

工程とは、作業を直列に分割し、かつ分割した作業に対し
分業が可能なようにInputとOutputとなる成果物を定義し、生成することです。

tatakahaさんの指摘は、作業を並列に分割し、それを異なる担当者で分業
するというものでした。それによって、コストをかけることで
納期が短縮できる。まったくそのとおりだと思います。
私自身、この後のエントリで作業を分割するなら工程と言う形で直列に
分割するのではなく、並列に分割した方が良いという話を書こうと思っていた
所です。

並列に分割した場合は、ここで定義した意味での工程に分割した場合に
発生する問題は発生しませんが、その代わりに並行して開発した部分を
統合するコストが発生します。
しかし、JUnitの様なテストのためのフレームワークや、Mavenのような
ビルドツールの進歩のおかげで、この統合のコストはあまり問題に
ならなくなっています。だから、作成するソフトウェアの規模が大きく、
かつ納期が限られているため、追加の要員を投入して
分業を行うことが必要なケースでは作業を直列に分割する
より並列に分割することを優先した方がうまく行くと思っています。

言葉の定義を後付けするのはあまりよろしくないとは思いますが、
blogでは最初から体系的に書くことは難しいので、
大目に見て頂ければと思います。

今ちょっと酔ってるので何か言ってること
おかしかったらご指摘ください。

次は、どうしても工程を分けざるを得ない場合に、
その分け方の善し悪しをどう判断したらいいか、という話題を取り上げたいと
思っています。

まだ工程の意義を問う

つづきです。

昨日途中で力尽きて結論を最後まで言っていなかったのが
悪いのですが、実は今回私はソフトウェア開発から工程を
完全に無くすべきだとか、
重量級開発プロセスよりも軽量級開発プロセスの方が
常に優れているとかいうことを
言いたい訳ではありません。
主張したかったことは、もっとシンプルで、単に

工程を分割せずに済むなら、分割しないほうが良い

ということです。

昨日のエントリに対し、tatakahaさんとSaisseさんからコメントを頂きましたが、
注意を促したいのは、開発プロセスを複数の工程に分割すべき
積極的理由、つまり、
「工程に分けるとこんな良いことがある」ということはまだ示されていない、
ということです。

「何でも出来る人でなくても開発が可能になる」

これは積極的理由ではないと思います。
「良いこと」とはソフトウェアプロジェクトにとって良いことです。
ソフトウェアプロジェクトにとって「良いこと」とは
QCD(Quality, Cost, Delivery)にプラスの影響を与えることです。

何でも出来る人でなくても開発が可能になることによって、
品質が向上するでしょうか? 向上する理由は思い付きません。
納期は短縮されるでしょうか? 短縮する理由は思い付きません。

コストはどうでしょう?

確かに何でも出来る人より、限られた事しかできない人の方が人件費は
安いかもしれません。しかし、そのコスト的なメリットは
工程を分割することによって発生する余分な作業、やり直し作業の
コストと見合うものなのでしょうか?定量的なデータはありませんが、
少なくとも、明らかに人件費が安いメリットの方が大きいということは
いえないと思います。

だから、「何でも出来る人でなくても開発が可能になる」が
工程を分割することのデメリットを補ってあまりある程の「良いこと」
であると断定する事はできないと思います。

結局のところ、工程に分割すべき理由の多くは、
消極的理由、つまり、「工程に分けないとこういう場合に
うまく行かない」ことなのです。

工程を分割せずに済むなら、分割しないほうが良い

という主張に反論するためには、消極的理由ではなく、
積極的理由をあげる必要があります。

言葉を変えて、今一度問います。

開発作業を複数の工程に分ける積極的理由はありますか?
工程に分けることによって、品質は向上しますか?納期は短縮されますか?
コストは削減されますか?

まだつづきます。

"工程"の意義を問う

ここ数ヵ月、モチベーション最悪でした。
ストレスで2kgほど太りました。酒の量も増えました。
ホントに身体壊した人もいたので、まだましですが。。。
この業界は病んでるなぁ、とつくづく思う今日この頃です。

何か書くと愚痴しかでて来そうになかったので
書いてなかったのですが、久しぶりに書きます。

最近、業界の病気の根っこにはなにがあるのか、という
ことをよく考えます。
語らねばならぬことは沢山ありますが、今日は、開発プロセスに
おける"工程"というものについて考えてみたいと思います。

伝統的な開発プロセスにおいては、
工程というものによって、開発作業が複数の部分に分割されます。
一般的な考えです。
でもよく考えてみて下さい。
工程に分けることによって何か良いことありますか?

悪いことは3つほど思い付きます。

その1:余計な作業が増える
前工程を担当する人は後工程の人に必要な情報を伝達
するために、文書の作成等の作業をする必要があります。
これは工程に分割しなければ必要無い作業なので、
純粋なオーバーヘッドです。

その2:コミュニケーションロスのリスクが生じる
どんなに緻密な文書を作成しても、常にコミュニケーションロスの
リスクは残ります。

その3:仕様変更に弱くなる
工程間の情報伝達のために作成した文書をメンテナンスするため、
システム全体が仕様変更に弱くなります。

でも良いことは、少なくとも私には思い付きません。
みなさんは思い付きますか?

この件についてはまだまだ言いたいことがあるので、
また続きをかきます。

バリバリの重量級プロセス信奉者の方の反論をお待ちしてます。