「誰が書いても同じコード」は大事なことなのかで 語られている話は非常に興味深ものです。

SIerの言うところの「仕様書」というものはなんなのでしょうか。私のblogでも 内部仕様書はロジックを書くものではない で仕様書を話題に挙げたわけですが、仕様書の在り方を、システム開発の分業の在り方を今一度考えてみたいと思います。

「誰が書いても同じコード」になるためには

コードとは何でしょうか。プログラミング言語で書かれたアルゴリズムの表記のことです。

プログラムするということはどういうことでしょうか。 ある目的を適える為のアルゴリズムを考え、プログラミング言語でそれを表現する過程を言いいます。

「誰が書いても同じコードになる」ということは、誰もが同じアルゴリズムを採用し、 そして、その表記さえも同じ書式になることです。 書式のブレは瑣末なことです（コード規約の自動チェックツールなどを導入すれば容易に揃う程度の問題）が、 アルゴリズムのブレはコードを根本的に変えてしまうほどの問題ですから、 コードを揃えるためにはアルゴリズムを揃えることが必須です。

これを達成するには、プログラムの過程である「ある目的をかなえるためのアルゴリズムを考え」る部分で、 誰もが同じ方法論を選択する、逆にいえばアルゴリズムの選択の余地がない必要があります。

アルゴリズムの選択を制限するにはどうしたらよいでしょうか？ 仕様書の段階でアルゴリズムを指定してしまえばよいわけです。 ロジックまでがちがちに固めた仕様書を提示して、プログラムではなくコーディングをさせるようにすればよい。

ところで、そういった仕様書を書くためには、仕様書を書く段階でアルゴリズムを指定する必要があります。 そして仕様書に書かれたアルゴリズム通りにコードにしたら動く必要があるわけです。

つまり、ある目的を適える為のアルゴリズムを考え、自然言語でそれを表現した仕様書を作る必要があります。

おや？これはまるでプログラミングですね。

ところで、プログラム言語というのはプログラムをするために設計されています。自然言語は当然ながら日常会話のための言語です。 アルゴリズムの表現を自然言語でするよりも、そのために設計されているプログラム言語でする方が断然効率がよいものです。 なんといっても、実行することで容易にデバッグできます。自然言語で書かれたアルゴリズムのデバッグはとても大変です。 そもそもコンパイルエラーすら分からないのですし、自然言語向けのデバッガなど存在しませんから、ステップ実行もできないわけです。

「誰が書いても同じコードになる」という目的を適える為には、プログラムに適していない自然言語でプログラムをして それを仕様書という形で起こし、それをただただ翻訳させるという作業をやらせる必要があります。

そして、「誰が書いても同じコードになる」ような仕様書を書くには、 「ある目的をかなえるためのアルゴリズムを考え」る必要がありますから、 つまるところプログラムができる人が書く必要があります。

ところで、この仕様書、自然言語で記したプログラムなわけですが、このプログラムのコード、 「誰が書いても同じコードになる」ようにするにはどうしたらいいでしょうか？ 仕様を書くための仕様書でアルゴリズムの選択の余地をなくさないといけませんね。

属人化の場所を移しているに過ぎない

以上をもって分かる通り、「誰が書いても同じコードになる」は単なる幻想です。

仕様書からコードになる部分のブレをなくすために、仕様書を作る部分にしわ寄せがいっているだけです。

「誰が書いても同じコード」というのは、技術が属人化することを嫌い、質を均質化させようとする行為。 ただし、先に述べたように、コーディングを均質化させるための仕様書を作るところに 属人化を移しているだけに過ぎないのが現実なわけです。

コーダーの質を問わなくなったら、今度は仕様書を作るSE(笑)の質が問題になるというわけ。

結局のところ、システム開発というのは属人化した技能によって為されるものですから、 属人化を排除しようとしても無くすことはできない。

スペシャリストってのはどこから生まれ来るのか？

システム開発におけるスペシャリストになるために重要なのは経験だと思います。 とりわけ経験の質が重要だと思うわけです。 自分でシステムをこう組んだらうまくいくのではないか？というのを考え設計し、作りあげ、運用して評価される。 そういう質の高い経験を積む必要があると思います。

しかし、これには失敗というものが付きまとう。 システム設計で常に成功せよというのは無理というもの。 痛い目を見て、「巷で言われるＸＸをしてはいけないというのは、どういう理由に因るのか」というのを ただの知識ではなく体験として真に理解することができる。 先行事例のないことはやってみて評価してなんぼの世界です。 成功した、失敗した、で終わってはだめで、だからこの経験を生かして次はこうする、という形にして受け継がなくてはならない。

でも、そんな失敗ばかりさせていたら、スペシャリストが育つ前に会社が傾いてしまうので、 先達のスペシャリストが適当なところでブレーキをかけ、小さく失敗させるようなセーフティネットを作る必要がある。

「責任は俺がとる。好きにやってみろ」と言える監督者が必要ということです。

業務でこのような待遇にある人は稀でしょう。 それ以外の人の多くは、個人的なプログラム開発での設計の成功・失敗を基に、 業務で最小限の失敗で成果を上げているのが実情でしょう。 つまり、人材は会社のあずかり知らぬところで育つか否かが分かれてしまう。

Googleの20%ルール（業務時間の20%を好きなことの研究に費やしてよい）というのは 会社の管理下で人材育成をするためのコストと捉えるのが適当だと私は思います。 業務の100%の時間を正味作業(直接売上に関わる作業)に当てているようではエンジニアの技能は低水準にとどまってしまう。

会社がこういった人材を望むならば、こうしたコストを覚悟する必要があるわけですね。

プログラマはどういう仕事をするべきだろうか？

「誰が書いても同じコード」は大事なことなのかで

今の大手SIerのやり方の問題は、スキルのあるプログラマの能力を殺してしまっているところにあると思います。だめな人に失敗させないように、がちがちに縛るんだけど、だめな人はやっぱり失敗するし、できる人もがちがちに縛られて力を発揮できない。

「誰でもメンテナンスできるコード」にするために、必要十分なドキュメントとコーディング規約を守る以外は、開発者の自由にさせたほうが、全体の生産性はきっとあがるよね。

と述べている。このエントリでいえば、プログラマを単なる自然言語→プログラミング言語の翻訳家として扱うべきではなく、 ちゃんと「目的を適える為のアルゴリズムを考え、プログラミング言語でそれを表現」させるべきだろう、と。

プログラムするという仕事をSE(笑)に移すべきではない。SEはSEで(笑)などとつけられないように、 要件定義の本文を全うするべき。(SIerではSEとは主に要件定義を行うこととされている)

アルゴリズムの選択と実装の方法論はプログラマの裁量に任せてしまう。 SEはプログラマに仕様を提示するわけだけども、その仕様書にはアルゴリズムというかロジックについての記述はしてはいけない。 それはアルゴリズムを考える専門家であるところのプログラマに任せればよい。 その代わり、業務分析や要件定義といった部分はSEの裁量に任せられるべきだし、 それはそれで高度な技能を必要とする仕事なのだから、専門性を発揮すればよい。

こうした、本来の役割ごとの裁量、権限を考えることで「仕様書」というものに必要な記述は何かが決まってくるわけです。

内部仕様書はロジックを書くものではない

こうした役割分担があった上で、SEとプログラマの間をとりもつ資料としての「内部仕様書」を考えるべきです。

「誰が書いても同じコード」にするためにアルゴリズムを選択させないように仕様書に詳細にロジックを記述する、 というのはナンセンスであることが分かることでしょう。そのような仕事の仕方では質は上がらないし、費用もかかる。 つまるところ、市場での競争力が弱くなる。

このあたりの背景を考慮した上で 内部仕様書はロジックを書くものではない を参照していただけると幸いです。

まさる氏の提示のURLがレイアウトを乱していたのでこちらに提示しておきます。

やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか?