ソフトウェア開発プロジェクトは、たとえ間違った技術を選ばなくても、十分に大変だ。私には、ソフトウェアの選び方について、長年の間に痛みを伴う方法で学んだことがいくつかある。この記事の10の教訓を読めば、わざわざ痛みを感じなくても、私の失敗に学ぶことができるはずだ。
1．特定のツールに特効薬を期待しない
開発プロセスを改善するためにソフトウェアを選択しようとする時、犯しやすい最大の間違いは、技術を使えば問題は魔法のように消えると考えてしまうことだ。これはまったく間違っている。私は、ALMシステムがインストールされてから1カ月か2カ月で、大量の項目が散らかった状態になり、それ以降使われなくなったという例を数え切れないほど見ている。これは、システムが悪かったのだろうか？違う。人間がシステムを使うのに失敗したのだ。もしあなたのチームがツールについて学ぶ時間を取り、それを本当にプロセスの一部に取り込むのでなければ、手を出すべきではない。
2．統合に注意する
システム側の立場からよく目にすることの1つに、統合のための作業が、無料のソフトウェアパッケージでさえ予算のブラックホールに変えてしまうというものがある。これは、ソフトウェア開発ツールについても同じことが言える。統合の「コスト」は、既存のシステムと結びつけるのに必要な資源よりも大きい。開発プロセスの中断、古い習慣を学ぶのにかかる時間などの要素も含まれるためだ。
3．「トータルパッケージ」にだまされない
私がこれまで問題を解決するために「トータルパッケージ」に夢中になった際には、その多くは結局まったくだめだということがわかった。使える場合でさえ、多くのことをやるにはかさばりすぎていた。そのよい例が、「Microsoft SQL Server」だ。Microsoft SQL Serverは非常によいデータベースサーバだが、スイートの一部である数多くのアドオンはさまざまで、私はベースパッケージよりも他のアドオンを使った方がいいと学んだこともあった。
4．試験プログラムを実行する
よく引用される統計によれば、ITプロジェクトの70％は失敗だと考えられるという。自分の経験から見ても、この数字はほぼ正しいと思われる。だとすれば、そもそも失敗する可能性が大きいプロジェクトの開発プロセス全体をリスクにさらすべきだろうか？これが、私が試験プログラムを行うことを学んだ理由だ。新しいツールやテクニックを使ってみて、誠実に評価するために、小さめの、新しい、またはリスクの小さいプロジェクトを選ぶといいだろう。「もしこれがうまくいかなければ、全体がバラバラになる」「もし選び間違えればチーム全体がダメになる」というプレッシャーがなければ、「埋没費用の誤謬」に陥るのを避けることも、だめな製品を無理に動かそうと試みることも、ずっと簡単だ。
