コーディングとドキュメンテーション

PCWatch、山田祥平氏のコラムから、ソフトウェア開発に関して。「コーディング」なんて、もう20年以上もやっていないから、最近の手法とか開発環境に開発言語にも全く疎いのだけれど、コラムを読む限りでは開発者の悩みというか苦労は余り変わっていないような気もします。私がソフト開発をしていた頃は、まだコラムの中で書かれているようRCSというソフトは無くて、基本エンジニア一人が担当している部分のソースを、決められたタイミングで決められた場所にコピーして、それをまとめてコンパイルしてコード生成をしていた頃。そのうちにRCSが導入されて、途中途中でテストコードを生成する場合に、自分以外の部分のレベルを管理したり、何か問題があった時に一つ前や二つ前のレベルにロールバックできるような仕組みが出来ましたが、まだ慣れないこともあって余り使われなかったような気がします。

コード開発の時には、そういったRevision Controlとともに、ドキュメンテーションが大きな問題で、例えば仕様書を最初に作ったのは良いけれど、実際にコーディングされたコードとの違いや、仕様変更の吸収、さらには完了時に最終的な仕様確定まで、ドキュメント管理するのが凄く大変。バブル前のまだお金も人も潤沢にあった頃は、一つのプロダクトに一人ドキュメント専任のエンジニアがいて、その人が全てを取り仕切っていたけれど、どんどん効率化が進められると、そんな余裕は無くなり、コーディングするエンジニア自身でドキュメントする必要が出てきます。でも、ソフトエンジニアって、ソースのコーディングは好きだけれど、それの文書化ってやりたくないって言うのが一般的な傾向じゃ無いでしょうか。でも、ソースコードだけで全て解決出来る訳では無いので、例えばポイントポイントで文書化作業を強制的に実行させたり、一番多かったのはソースコードにコメントの形で挿入させて、それを自動的に吸い出して文書化するツールを作ったり、その時にコラムにもあるようなタグを挿入しておいて整形やバージョン管理をしたり、でも結局はどれも善し悪しありその時その時でやり方が違ってきたりしたものだから、ますます混乱に拍車をかける結果になったりして(笑)。

コーディング自体も変わってきて、昔はハードが非力だったことも有り、余り時間取るような処理はしないで、出来るだけ1サイクル2サイクルで実行できるような形にしたり、パフォーマンスも考えながらのコーディングが必要でしたが、今はそんなことは考えなくても良いし、後必要最小限で無くてもある程度ざっくりした処理でも良くなったので、逆にそう言う細かなところを突き詰める故に入り込むバグは少なくなったような。共有ライブリーなどのサブルーチンやプロシージャーに関しても、ベースのハードが変わるとそれらのライブラリーも書き換えが必要になったけれど、今はソースレベルの互換性は大体担保されるので、コンパイルだけで良くなったし。

「成果物」としてはソフトウェア製品があるわけで、それが問題無ければ十分だとは思うけれど、ソフトの場合は「メンテナンス(保守作業)」がありますから、突然ソースコードだけ渡されても困る。一般の商品だと、その物を作ったらそれで完了になるのとは、そこが違うと言えるのでは。強いて言うと、例えば家の設計図なんかも「ドキュメンテーション」なんだろうけど、こちらは作る前に設計図を完成させて、それに合わせて作るわけだから、ちょっとソフトの場合とは立場が違う。それに建築物の場合は、設計から実際の建築までの手順も定められているし、許可認可も必要だし、手順の中に組み込まれていますからね。ソフト開発もそういう感じになれば良いのだけれど、そうすると開発スピードががくんと落ちるから実際に即さない訳で、なかなか悩ましいですよね。仕様書を書いたら、そこからコードを生成するみたいなことも昔やったことがあるけれど、これはこれで仕様書の書き方をコードに合わせると生成しやすいけれど、そうなると仕様書が人が読むには厳しくなり、人に優しい仕様書だとコード生成が難しくなるし。コラムでは「プログラマは楽をしている」と書かれているけれど、真面目な人は結構大変な想いをしている気がする(笑)。