システムエンジニアはなぜ、ヒゲをそるべきなのか：あるエンジニア、かく語りき（1）（3/3 ページ）

» 2013年10月30日 00時00分公開

[松坂高嗣，リブセンス]

大規模システムと「元請け」と「下請け」

　何にでもそれなりに理由があるものです。では会社は、どうしてそんな成果物を規定したのでしょうか？悩んだり、いろいろな人に聞いたりして、これは「下請け側がリスクを取れないビジネス構造のために、やむを得ず取っているやり方なのだ」と結論付けました。そう考えると筋道が通ります。

　A社の仕事は、比較的大規模なシステム開発のサブシステム下請けや、業務委託で開発チームを提供するものが中心でした。A社は基本的にシステム開発の会社でした。そして、決して体力のある方ではありませんでした。大規模な案件を引き受けても、失敗した場合のリスクは取れません。従って、大規模案件を直接受けることは難しい。体力のある元請けと体力のない下請けでは、引き受けられるリスクが違います。まずは、ここが出発点です。

　元請けと下請けは「設計書を基に、忠実にプログラミングする」という契約を結びます。これで下請けの責任範囲はかなり限定されました。その上で、元請けは下請けに具体的な設計作業も業務委託として依頼します。全体の設計がほぼ完了してからクライアントとの合意の上、次の製造工程に入るので、下請けは開発が始まるまでの人件費を遊ばせなくても済むようになります。分かりやすい構造です。

　以上を踏まえて、要件定義書や設計書は契約によって定義される公式な文書であることが分かります。通常、電子データだけでなく紙資料での納品が必要であるため、印刷を前提としたものになります。（今でもそうかは分かりません）「プログラミング上の構造やロジックが決定される」程度に詳細な設計が行われる必要があることも明らかです。下請けが開発したものが設計通りかどうかを検収しなければいけないからです。これら2つの性質が異なる文書を作って両方メンテナンスするのは大変なので、「コードに直接対応させられる程度に詳細で、しかも日本語で書かれていて、普通の人でも読めるもの」をまとめて作ることになります。

　合いました！素晴らしい！

　実際に適切な理解かどうかはともかくとして、筋道がつくというのは気持ちのいいことです。とはいえ自分は下請け側だったので、納得はしつつも不満でもありましたが。

　余談ですが、実行して確認ができないために、日本語プログラミングはどうしてもバグが多くなります。そして、たいていの開発プロジェクトでは、仕様変更が後から入ります。仕様変更は仕様書から設計書にかけての変更なので、メンテナンスも大変です。実装側はテストを書いたりプログラム仕様書を別に作ったりして対抗しますが、なかなか凌ぎきることができません。いわゆるデスマーチの太鼓が聞こえてきます。

　この体験から、自分が設計者として関わることになった際は、顧客と仕様の読み合わせ→こっそりテストと実装→仕様Fix→詳細設計書とテストコードまで含めた「サンプル」実装を成果物として提出という荒技を編み出しました。

　ただ、後工程でのテストのエビデンスとバグ密度などを要求された場合は、どうすればよいのかよく分かりません。もちろん、契約と異なるプロセスを踏んではいけないわけですが、コンストラクションと単体テストが同時に行われている場合、個別に設定された「単体テスト」という行程をどうとらえるかは難しい問題です。捏造（ねつぞう）……は、やはりよくないですよねぇ。

立っている場所が変われば、見える世界も変わる

　月並みな話を書いてきましたが、私が以上の経験から学んだことを簡単にまとめます。

計画性という性質は、現在ではなく将来への期待感によって作られる。現在の問題に強く意識を向けていたり、あるいは未来に関してイメージが湧かない状態だと計画性が発達しない。
マナーや規範はその組織の目的や理念から出発すると理解しやすい。営利企業にはビジネスという明快な背景があるため、「社会」とか「日本人」よりもずっとシンプル。
「ヒゲをそれといわれる」のは上司がツルツルの顎が好きだからではない。
大規模なウォーターフォール開発の現場では、しばしば日本語でコードと1対1対応するほどの詳細度の設計書が作成される。それが合理的な判断となるのは契約や責任分解の問題であるため、現場での解消は難しい。

　どれも特別なことではありません。いかにも平凡な教訓です。ただ、私が20歳のころのように大学と家とブックオフを往復する生活しかしていなかったら、こうした認識を持たなかったのではないかと思います。

　立場が変わると、見えるものがガラリと変わります。

　今までの自分について外から考えられますし、1つの出来事について新しい視点で考えられるようになります。

　仕事に慣れてくると、チームや組織の仕事の仕方や効率、教育などにも目がいくようになります。2年目からは後輩の育成やチームのマネジメントなどの、全然違ったミッションが与えられて、またいろいろ悩むことになります。

　そのあたりは次回以降に。