どうも、もとやんです。
ちょっとタイトルは煽り入ってるところも否めないです。ゴメンナサイ。
前回の予告をぶった切って、ちょっと違う話をさせてください。
表題の様には言うものの、実際問題として同時にある程度以上の規模の2つ以上のプログラムを、統括的ポジションで作ることは多くのプログラマにとって非常な負担になります。一方、営業さんなんかはマルチタスクで幾つものお客様と対応を進めてナンボ感が漂ってまして、こんなこと言うと「何甘えたこと言ってんだよ、死ねボケ」みたいな事言われんじゃねーの？ とか思いながらも、やっぱこっちも大変なんだよ、ってことを書きたいと思います。自己弁護も兼ねて。
逆に言うと大変じゃなくなればそれはタスクマネジメントがうまく言ってるって事ではないかと。
さて、ではなぜある程度以上の規模(個人的な感覚では凝集度にもよりますがステップベースで数万行ぐらいから)の、プログラムを同時に組むことができないのか、というお話です。正確にはやらざるを得ないことは多いんですが、まぁ効率も結果的には良くないし、心理的にも大変っていうお話です。
大変な理由は単純で、スイッチングコストがメチャクチャデカいからです。
プログラムをちゃんと書こうとすると、だいたいソフトウェア全体の挙動を把握していないと、変更の影響範囲を見誤ったり、すでに作った部品と同じような部品を再生産してしまったりしがちです。これを防ぐにはプログラム全体をある程度、脳の中期記憶にロードすることが絶対に必要です。
なので複数のプロジェクトを横断するたびに、(忘れていた場合は)プログラム全体を見直す必要が出てきてしまいます。仕事で何かのソフトウェアをいじりながら、オフで別のプロジェクトに従事する、ぐらいであればスイッチングは一日一回なのでまぁ大丈夫ですが、一日に何回もスイッチングしていたらそれは大変な負荷が脳にかかります。大体中期記憶にとどめておける量も数万行のプロジェクト2個ぐらいならともかく、10個とかは私には多分無理です。
これが、同時に複数のプロジェクトを進められない理由です。補足しておくと、ソースコードの構造を綺麗に保ち、各モジュールを適切にカプセル化することで影響範囲を小さく抑え、こういう事態の発生を遅らせることはできます。ただしそれはプログラムの規模に応じて右肩上がりになる複雑さのグラフの角度を緩やかにするものであって、根本的解決には現実的に至っていないことも留意してください。
また、上からこの部品のココをこういうふうに動くように直して、みたいなことを言われて対応するだけだったら、まぁスイッチングコストも微々たるもので済むので比較的容易に対応出来ます。ただし、こういう場合はこういう場合で、似たような部品がすでにあることに気づかずに再生産してしまうことを、構造的に防げないんですね。
なぜ無駄作業は防げないのか。これにも理由があり、それはドキュメントの文法にあると私は考えます。
ソフトウェアを作成するなら、Javadocのようなものも含めて、何らかの形でドキュメントの作成もワンセットになります。複数人で共同制作を行うのに、何の共通理解も作らずに一緒に事にあたるのは自殺行為でしょう。
ただし、それらのドキュメントは往々にして「○○という箇所は、△△をするためのコード」という文法で記述されます。私がドキュメントを書くときも、何のための設計・コードなのか、という事を重視して書きますし、ドキュメントのお作法的な書籍でもそのようにすべし（意図を書け）と指示されているでしょう。
ただ、こういうドキュメントしかない場合、「△△する処理を作らないといけないけど、こんな処理ってすでに誰か作ってるのかな？」という逆引きに非常に弱いです。多くの開発現場で「□□する時は(プログラムの)どこ(の部分)見ればいいんですか？」という質問は新入りが先輩にする質問TOP3にまぁ入るでしょう。そしてこういう質問に強いのが、そのシステムのエキスパートと呼ばれる人たちでもあります。
この現象は「言葉の意味は国語辞典を引けば分かるが、意味から単語を探すのは難しい」という問題と全く構造的には同じです。この問題への組織的な対応はまたいずれ書こうかと思います(と言ってネタに困った時用のストックを確保する)。
でわでわ。
コメント