大は小を兼ねるという言葉があります。もしかすると、何かに迷った際に、このことわざを参考に選択している人もいるかもしれません。確かにそうだ、と思われているからこそことわざとして受け継がれているんでしょう。
ただ、私はこのことわざについて懐疑的なんですね。まず前提として言葉のチョイスが抽象的過ぎるし、語源を調べてもやっぱり抽象的なので、どういう事例の時に当てはまることわざなのかが不明瞭です。
小さい皿に乗せられる料理は大きい皿にも乗せられる、とか便器でとりあえず大の方向に流せば小も流せる（汚くてすいません）、とかそんなレベル事例は数多くありますよ。でも反例も結構多くて、大きい車だと通れない道があったり、大きい人だと座れない椅子があったり、大きい消しゴムだと微修正ができません。
まぁたぶん何の制約もない場合にのみ限り成り立つのかな、ぐらいに思っています。それに細かいことを言えば、「小」でできることは「大」でもできるという意味なのでしょうが、目的に応じてどちらが適切であるかは変わってきます。
そんなわけで、別に大が小を兼ねるなんて普段はあんまり考えていないんですが、ことのほか、システム開発に限って言えば、大は小を兼ねている、と言えると思います。
私の担当のプロジェクトは基本的には追加開発がほとんどなので、規模は小さめです。私の言う小規模が一般的な小規模と同じかどうかわからないので、具体的な数値を出しておくと、10kstep程度（システムを構成するプログラムの行数が10000行程度ということ）です。
ちなみに私が去年開発した簡易Webシステムのプログラムはさっき調べたところ、1kstepぐらいでした。正確に開発期間を測ったわけではないですが、完成まで約３ヶ月といったところでしょう。
と言っても平日は仕事をしているので週末ぐらいしかコーディングがしていません。なので、土日をすべて開発作業に費やしたと仮定しても、だいたい24人日の工数です。（１人が１日かけて完了できる仕事量（工数）が１人日です。）つまり、私の生産性では、1kstep＝24人日程度に相当することがわかります。
実際のプロジェクト開発では仕事量の規模見積もりには、人日ではなく人月という単位が使われます。１人月＝20人日と考えられるのが一般的です。よって、私の単独プロジェクトも同様に変換しておくと、1.2人月の工数がかかったことになります。
さて。では私の担当で過去に開発された、10kstepのプロジェクトの工数は一体いくらだったのでしょう。単純計算で考えれば、1kstepで1.2人月なので、12人月ぐらいが妥当になります。12人月とはすなわち、１人で開発しても１年、12人で開発すれば１ヶ月でプロジェクトが終わるということを意味します。
実体がどうだったかと言うと、そのプロジェクトは、8人体制で13ヶ月のプロジェクトでした。つまり、約100人月です。これって結構やばくないですか。決して私の生産性が高いわけではないのにもかかわらず、9倍～10倍近く完成までの時間がかかっているんです。
この差が適正なのかはともかくとして、規模が違えば工数は単純計算では求められないんですね。なぜかというと、規模に応じて、必要となる作業・時間が膨大に膨れ上がるからです。
例えば、大規模なシステムは外部のシステムと連携している場合がほとんどです。そのため、システム間のインタフェースを検討する必要があり、顧客と念入りに調整を行う必要があります。
それに伴い、試験をするのも大変です。外部の（特に既に稼働中の）システムと連携して試験を行うのは容易ではないため、シミュレータなるものを別に開発する必要があったり、ネットワークや試験機器の設置なども作業として必要となります。
また、チームでの開発となるため役割分担・体制が決められます。とはいえ、最終的に一つのシステムになるため、適宜情報共有をする必要があります。そのため、各々の知識をドキュメント化するための工数が別途必要になります。
私の開発は、工程で言えば「製造（コーディング）」と「試験」しかやっていません。そもそもちゃんとしたシステム開発の方法論を知らなかったし、必要がないと思ったからです。また、試験環境の構築も、普段使っているMacに仮想サーバとミドルウェアをインストールしたぐらいです。
何が言いたいのかというと、一人でシステムを作った経験だけでは大規模なプロジェクトを動かすことはできないけれど、大規模なプロジェクトを経験していれば、一人でシステムを作ることは可能だということです。大規模開発のタスクの中から必要のない作業を削ぎ落としていけばいいだけなのですから。
もちろん、能力的に難しいというのはあるのかもしれませんが、大規模開発を知っていれば、一人でシステムを作る際に、少なくとも何をすればいいのかわからない、という状態にはならないはずです。そのためにも各工程におけるタスクの必要性や意味を常に考えていくべきでしょう。
