これは私が大学を卒業してソフトウェアを製作する会社で働いて最初に思った疑問でした。
「ただ、プログラムが書ければ良いわけではない」これは今時学生プログラマーであっても百も承知なことでしょう。どんな本にもドキュメントやユーザーマニュアルが大切だということは書いてあります。また、良いオープンソースプロジェクトではこれらが充実している(こともある)ので実践している人も多いでしょう。
しかし、最初に会社に入ったときショックであったのは「良い」ものよりも「形式の整った」ものであることが重視されていた点です。
しかも、形式に関するマニュアルや形式を整えるためのツール類が無く「以前のプロジェクトの形式に合わせて。」というのが唯一のマニュアルになっていたのが何より衝撃でした。
例えばプログラムの詳細設計にあたる関数の説明まで全てwordで書いていました。doxygen等は使いません。また、バージョン管理もバージョン管理システムを一切使わず共有フォルダ上で上書きで更新。リリース事に手作業で番号を振ってzipで固めていました。
それ以前にdiffもpatchも現場から管理職まで通じないのでバージョン管理システムの導入も不可能に近い状態でした。驚くことにプログラムのコメントのフォーマットはdoxygenスタイルなのですが、全員doxygenを使ったことがないのでだれもドキュメントにしたことがなく一部のタグは完全に間違った意味で使われていました。
また、これらの非効率な作業はその非効率性に判して几帳面なまでの厳格さをもって行われていました。そのため、ドキュメントのフォーマットは決まっていないのですが、レビュー時には以前のドキュメントの形式に沿っていない部分をきちんと指摘されました。当然追加作業が発生し、残業が増えます。つまるところ「空気をよめ」で作業が行われていたのです。
なぜこんなことになっているのか、当時理由をいろいろ考えてみました。
- 技術の分からない人がルールを決めている。結果ツールで管理すればいいことを手作業でやっている
- 技術力のある人は会社に失望し転職している。
- そもそも会社にとって良いソフトウェアを作成する動機が無い。
私が最終的な結論として導きだしたのは「そもそも会社にとって良いソフトウェアを作成する動機が無い」ということでした。
上記で挙げていたフォーマットが決まっていないが、前例に沿ったものにする。という方法は「技術の分からない人間が発注し、最終的な評価をする」という場合には極めて重要であることが後に分かったからです。
ソフトウェアに詳しくない会社では、発注者は技術が分かっていないのでルールやフォーマットをうまく作ることができません。また、担当者にそれらができたとしても、さらに何も分かっていない上司や部門の査定を通過する必要があります。
こういったケースにおいて良いソフトウェアを作る努力や工夫の多くは「理解不可能で値段のつけにくいもの」と評価されます。一方で「前例に沿ったものにする」という努力は「理解しやすく値段のつけやすいもの」と評価されます。
技術に詳しい人間がおらず、予算の縛りがきつい会社では管理職は「良いもの」より「値段のつけやすいもの」を好みます。後で説明がつかないものに予算を使うと責任問題に繋がるからです。
ですから私のいた会社も売っていたものはソフトウェアではなく、「前例にそった作業でソフトウェアを作ること」そのものを商品にしていたのです。なぜならお客さんはそれに値段をつけ買ってくれるから。もしかすると「フォーマットに沿った作業でソフトウェアを作ること」よりは難易度が高く、我々の商品にはそれなりの値段がついていたのかもしれません。
今は幸いにも転職し、良いソフトウェアを作ることを重視する職場(すくなくとも自分はそう感じる)で働いています。
技術に無理解な人間が上層部に少ない組織であればそれもまた可能であることを知りました。
社会人になってから勉強することは本当に多いです。
投稿
