ITプロジェクトは、「ソフトウェア開発」を実行するという特徴を持ったプロジェクトです。ソフトウェア開発という特殊なスキルを持った人を決まった予算内でできるだけ多く集め、全力で作業をこなし、納期に向かって全速で邁進していくためのプロジェクトです。
■「ソフトウェア開発」とは何か？
ソフトウェア開発とは、コンピュータサイエンスとソフトウェアエンジニアリングを駆使する実務のことです。逆に言えば、コンピュータサイエンスとソフトウェアエンジニアリングを知らなければ、ソフトウェア開発を実行できません。
コンピュータサイエンスは、コンピュータを使って情報を扱うための知識と技術を集約したものです。ソフトウェアエンジニアリングは、ソフトウェアをモノとして見た「モノづくり」のための方法論です。
これらは、日々、新しいアイデアが考え出される度に、アップデートされていきます。そういう意味では、しっかり体系化されているとは言い難く、ITエンジニアのスキルと裁量によって、ソフトウェア開発のやり方が変わってきます。
コンピュータサイエンスは、原則、個人の独学によって身につけることができます。一方、ソフトウェアエンジニアリングは、知識として知っているだけでは意味がなく、ソフトウェア開発を実施するプロジェクトや組織を通した経験に意味があります。このように、スキルの質が異なる２つのベースを組み合わせることで、ソフトウェア開発が成り立っています。
ソフトウェア開発の主役は、コンピュータサイエンスであり、ソフトウェアエンジニアリングはそれを補強するわき役です。ソフトウェア開発で必要とされる割合で言えば、コンピュータサイエンスが７に対して、ソフトウェアエンジニアリングが３といったところです。
ソフトウェア開発に必要なコンピュータサイエンスを使う時期を、ソフトウェアエンジニアリングによって計画します。さらに、ソフトウェアの品質（Q）、コスト（C）、納期（D）を確保するため、その結果をソフトウェアエンジニアリングによって確認し、対策を実施します。これが、ソフトウェア開発のマネジメントです。
ビジネスの収益をあげ、業務を効率化する目的で、ITエンジニアに金を払い、ソフトウェアを作らせます。ソフトウェア開発は、ボトムアップでITエンジニアたちが自発的に考えて行われるよりも、組織や会社などのトップダウンによる命令によってつくられることの方が圧倒的に多いです。
ボトムアップでITエンジニアにビジネススキルを身に着けさせるよりも、ビジネスマンがソフトウェア開発について知っておくほうが、これからビジネスをする上で有益であることは間違いないでしょう。
■ソフトウェア開発のインプットとアウトプット
ソフトウェア開発に必要なインプットは、以下の３つです。
１）ニーズ
ソフトウェアが必要な理由であり、「何をつくればいいのか？」という問いの答えです。詳細はわからなくても、売上を上げたい、コストを下げたい、集客をしたい、新しいWebサービスをつくりたいなど、願望がないとソフトウェアは作る意味がありません。
２）時間
何かをつくるには、時間が必要です。特に、作業を人が行う場合、もっとも必要なものは時間です。特に、ソフトウェアをつくるのは人だけなので、常に、時間が足りてないという感覚があります。
時間を短くすればするほど、指数的にソフトウェア開発の難易度が跳ね上がることになります。ソフトウェア開発の難易度を左右するのは、技術的な側面よりも、時間的な制限によるもののほうがずっと大きいと言えます。
ソフトウェア開発に必要十分な時間を与えることで、ソフトウェア開発のリスクを大きく減らすことができます。
３）お金
人を動かすには、お金がいります。たとえエンジニアやプログラマーが毎日、椅子に座って、息をしているだけにしか見えなくとも、昼飯代とは比べものにならないほど高額な費用を支払わなければならなりません。
ソフトウェア開発は、何百万、何千万の単位で湯水のごとくお金を使うことになります。それこそ、金額としては高級車の比ではないでしょう。
そういう意味では、ソフトウェアは高級品です。インターネットにのっているHPを見ながらちょっとプログラミングを勉強する程度ならタダでできます。しかし、業務用にソフトウェアをつくろうと思ったら、一人だけでは到底無理で、たくさんのエンジニアを集めないとできません。そうなると、少なくとも数百万～数千万円の予算が必要になります。
また、ソフトウェア開発のアウトプットとしては、実行モジュール、ソースコード、ドキュメントが作られることになります。ソフトウェアの実態である実行モジュールやソースコードは、データサイズとしては大した量ではありません。一方で、ドキュメントは、設計資料、テスト結果、テストデータなど膨大な量がつくられることになります。
これほどまでにドキュメントをつくる理由は、目に見えないソフトウェアのカタチを文章として言語化するためと、開発したエンジニア以外のエンジニアにもソフトウェア内部の動きがわかるようにするためです。いわば、ソフトウェアの取扱説明書（マニュアル）です。
一度、完成したソフトウェアは、随時、メンテナンス（保守）が必要になります。運用している内に改善すべき点や不具合が見つかるからです。そのような場合、ドキュメントを頼りに、ソフトウェアを修正します。
ソフトウェアが完成するとエンジニアはみな離れ、他の仕事へと移っていきます。開発のノウハウを詳細に記録したドキュメントがないと、誰もソースコードを修正することができません。
ソフトウェア開発において、質の高い有用なドキュメントを作ることは、ソフトウェアの品質を維持することに貢献します。逆に言えば、無用なドキュメントをできるだけなくすことが、予算や納期を守ることにつながります。
