プログラマの仕事を端的に表すときに「コードを書く」と言ったりするが、それによって単調な仕事だと勘違いされることがある。その誤解は、カメラマンの仕事を「シャッターを押す」だったり、小説家の仕事を「日本語を書く」と言うようなもの。手を動かしてはいるが、実際は頭を使うことが主な仕事だ。
ソフトウェアは、一つのアプリケーションが一つの作品のようなもので、一部の改変が全体に影響を与えることがあるし、一部に品質の悪さがあると全体の品質を落としかねない。製造業のように同じものを沢山つくる訳 … もっと見る
プログラマの仕事を端的に表すときに「コードを書く」と言ったりするが、それによって単調な仕事だと勘違いされることがある。その誤解は、カメラマンの仕事を「シャッターを押す」だったり、小説家の仕事を「日本語を書く」と言うようなもの。手を動かしてはいるが、実際は頭を使うことが主な仕事だ。
ソフトウェアは、一つのアプリケーションが一つの作品のようなもので、一部の改変が全体に影響を与えることがあるし、一部に品質の悪さがあると全体の品質を落としかねない。製造業のように同じものを沢山つくる訳ではないから、多少の不良品を許容するような作り方はできない。製造でなく設計なのだ。
コードを書くことを単純作業だと誤解した経営者は、より多くのソフトウェアを製作するために人を増やせば良いと考える。しかし、実際には闇雲に人手を増やせば、むしろ全体の生産性を落としてしまうことになる。まさしく『遅れてるプロジェクトへの要員追加は、さらに遅らせるだけである』の言う通り。
沢山の人を入れても混乱せずに生産性と品質を出せるようにと考える勢力と、人を増やさず少人数のままで一人当たりの出来ることを増やして生産性と品質を高めるように考える勢力がある。抽象化や仮想化を重ねるソフトウェア技術の進歩の方向性は後者だと思うし、エンジニアの気持ちとしても後者を望む。
ソフトウェアをチーム開発していくなら、ソースコードの設計に対するポリシーや品質の価値観を揃えること、その上で少人数チームを維持すること、人の増員を単純な足し算で考えないことなど、ソフトウェアの本質とエンジニアのモチベーションについて深く理解した上でマネジメントしていく必要がある。
