エンジニアリング業務の分類（01. スクラッチ開発）

最近業界の説明が続いて飽きてきたので、業務の分類について話をしたいと思います。以前 SE の分類について説明しましたが、今回からは SE が実際に依頼される業務の分類に関して何回かに分けて説明します。

分類は大きく以下の通りです。

• スクラッチ開発
• エンハンス開発
• 更改
• リプレース

僕の知る限り、いずれも学術的に明確な定義があるわけではなく、業界の慣習として呼ばれているのでその点はご了承ください。

それぞれの項目がプロジェクトのどの工程に該当するか把握すると理解しやすいと思いますので、プロジェクトのライフサイクル全体をイメージしてください。

システムのライフサイクルについては過去の記事を参照にしてみてください。

それではそれぞれについて詳しく説明していきます。

スクラッチ開発

スクラッチ開発はシステムをゼロから構築、開発することです。上記ライフサイクルのイメージでいうところの、企画フェーズから開発フェーズまでを表しています。但し、SE が大きく関わるところは開発フェーズです。

スクラッチ開発においては、何も構築されていない、まっさらな状態でシステムを開発するため、以下のようなタスクが必要になります。

• 開発ルールの制定
• コーディング規約の制定
• リリースルールの制定

開発ルールの制定

まず開発ルールの制定についてですが、具体的には、

• ローカル PC でどのように開発を進めるか。そのために必要なソフトウェアを洗い出し、インストールする手順を決める。
• GitHub のような構成管理サービス上にリポジトリを作成して、どのような手順でプログラムを管理するかを決める。
• プログラムが設計書などの成果物に対して、どのように作業を進めるかを決まる。

といったところになります。会社によってノウハウがあり、それを適用することもありますが、これまで見てきた限り、中小企業でそのようなノウハウが共有されることは稀です。ほとんどの場合、プロジェクトの実務を推進するプロジェクトリーダ個人の経験に依存します。そしてプロジェクトリーダでこれらをそつなく遂行できる人は貴重です。断っておきたいのですが、基本的にスクラッチの開発は概ね現場が混乱します。炎上するプロジェクトも大半はスクラッチです。原因は色々とありますが、企業の思惑と開発現場で歩調があっていないことがほとんどです。スクラッチの開発に参画する機会があった覚悟しましょう。

尚、複数の会社が統合し、それに伴いシステムも統合され、既存の動作を変えずにゼロからシステムを構築する場合はスクラッチと言わず、後述のリプレースとなりますので、ここでは割愛します。

コーディング規約の制定

続いて、コーディング規約の制定ですが、プログラムには一定の自由が許されています。クラス名、メソッド名、変数名、構文の書き方など、言語ごとに最低限のルールはありますが、その範疇にあるうちは自由に記述可能です。但し、この自由度が意外とやっかいで、特に JavaScript や PHP などのスクリプト言語はその自由度の高さが仇となり、極めて可読性が低いプログラムを量産してきました。そこで近年ではどの言語にも特定の団体が推奨するコーディング規約というものが存在します。例えば、クラス名はアッパーキャメル、変数名はロアキャメルで統一する^[1] … Continue reading、それぞれは英語で記述する、などです。規約に則った簡単なコードの例を以下に記載します。

// PHP での例：
public function getUserName(string $userId): string
{
    $userProfile = array();
    $userProfile = $this->user->find($userId);
    return $userProfile->userName;
}

逆に一切の規約を無視したコードの例は以下の通りです。

public function 関数A($Id): {
    $some_thing = array();
    $some_thing = $this->user->find($Id);
    return $some_thing->userName;
}

もはやカオスですね。これは極端な例ですが、数行であればどう書いてもそれほど支障はありません。ただ、実際に稼働するシステムのプログラムは数万行であることが一般的です。数万行の中に統一性のない記載や、まったく関係ないメソッド名・変数名が定義されていたら混乱を招くのは必至です。そのため立上りの段階で、読みづらいコードを混入させないためにも、コーディング規約を制定、正確にはどのコーディング規約を採用するかを決めることになります。

余談ではありますが、プログラミングの世界では古くから「割れ窓理論」という言葉があります。最近の若い人は耳にしたことない人もいるかもしれませんが、これは「すでに窓が割れている建物は、人々が汚したり破壊することに抵抗を覚えなくなり、大事にされず、加速度的に荒廃する」という意味です。転じてプログラミングにおいては「汚いコードが混入される（＝窓が割れた状態になる）と、プログラマは汚いコードを書くことに抵抗を覚えなくなり、どんどんコードが汚れていく」という意味になります。

東京ディズニーリゾートは利用者がゴミを捨てにくくするためにゴミを迅速に片付けるそうです。予防することが重要なのはコーディングにおいても同様ということです。

リリースルールの制定

最後にリリースルールの制定ですが、この場合のリリースは必ずしも本番環境へのリリースとは限りません。プロジェクトの規模にもよりますが、一般的にシステムには作業工程別に以下の環境が用意されます。

• ローカル環境：個人が開発するための環境。コーディングに必要最低限のソフトウェアを用意する。
• 開発環境：開発者向けの共有環境。ローカル環境にはない外部システムなどが一通り用意される。個人が開発したプログラムを統合して結合試験を実施するのが一般的。
• ステージング環境：運用者向けの環境。本番で利用されるすべてのソフトウェアやサービスが用意される。運用者により実際の運用を想定した総合試験が実施され、合格したものが最終的に本番へリリースされる。
• 本番環境：商用とも呼ばれる。システムが本稼働する環境。

スクラッチの開発ではそれぞれの環境に、どのようにプログラムをリリースするか、CI は導入するか、サーバの設定をどうするかなど、予め規定すべき事項が幾つもあります。そしてプログラムのリリースだけでも、当然本番に近づくほど厳格なルールが必要となります。

---

次回に続きます。