プログラミングスクール【社会人におすすめオンラインで学べる】

プログラミングスクール【社会人におすすめオンラインで学べる】2026年2月

更新日 2026年2月4日

10日で使えるPHP | 未経験のサルでも分かるPHPの学習サイト 文系未経験、サルでも10日でPHPを使えるように内容を構成した独学向け学習サイト。不要な基礎はバッサリ切り捨て必要な基礎を十分に深堀した・・・  続きを見る

新卒や現役エンジニアの学習方法（オンライン学習 or 書籍） 「SIerやメーカーに就職した新卒」や「現役エンジニア」で、動画配信で学ぶ技術者はほぼゼロと言ってよい。洗練された書籍で学んだほうが短期間で技術習得できるし高すぎる。・・・  続きを見る

RUNTEQの就職先と就職できた卒業生インタビュー RUNTEQの就職先と就職できた卒業生のインタビュー。 インタビュー対象の卒業生の学歴は不明2名、大学中退1名をを除き全員大卒、前職は派遣社員1名、新卒1名を除き、全員正規雇用の社員または公務員だ。・・・  続きを見る

目次

1. PHPとは？
2. PHPの特徴
3. PHPの書き方
   1. HTMLに直接PHPのコードを記述する
   2. Hello Worldを出力する
   3. HTMLの中でHello Worldを出力する
   4. 非推奨タグの記述方法（short_open_tag, asp_tags）
   5. PHPの文の区切り
   6. PHPで改行の出力する
   7. PHPでHTMLの改行を出力する
   8. nl2br()で\nを<br>に変換する
   9. PHPのコメント
   10. 命名規則（ネーミングコンベンション）
   11. ミニファイ（コードの圧縮）を行う場合のコメントは全て /* */ で記述する
4. 型
   1. 整数（int, integer）
   2. 浮動小数点数（float, double, real）
   3. 論理型（bool, boolean）
   4. 文字列（string）
      1. ダブルクォーテーション内の変数の置き換え
5. 関数 function
   1. 関数 function
   2. return
   3. 引数の参照渡し（リファレンス渡し）
   4. 引数のデフォルト値の設定
6. シンタックスハイライト
   1. highlight.js

1. 新卒や現役エンジニアの学習方法（オンライン学習 or 書籍）
   1. 新卒や現役エンジニアはどのように学んでいるか？
   2. 誰も知らない現場に行くのは当たり前
   3. オンラインプログラミングスクールよりペラ本の方が10倍速い
   4. 動画配信は非効率
   5. オンラインプログラミングスクールは情報弱者狩り＋補助金ビジネス
2. コーディング（プログラミング）は大した技術ではない
3. 日本銀行 FRB ECBの政策金利（30年推移）日米欧政治経済年表【2026年2月】

プログラミングスクールを斬る

PHP

関数 function

関数 function

同名の関数を定義した場合、パースエラーが発生する。

パースエラー（構文エラー）は、PHPがコードをパース（構文解釈）する段階で止まってしまうエラーで、多くの場合、間違った構文 ; の付け忘れ、{} () の閉じ忘れなどを記述して発生する。

パースエラーは致命的なエラーで、コンパイルエラーに相当する。パースエラーが発生した場合、プログラムの実行を停止する。

return

return はプログラムの制御を呼び出し元に戻す。 呼び出し側のモジュールでは、呼び出しの次の式から続行する。戻り値として値を設定できる。

function、method で return を呼び出した場合、function、method の処理を終了し、戻り値があれば戻り値を返す。

グローバルスコープで呼び出されると、現在実行中のスクリプトが終了する。

スクリプトが include もしくは require されたものである場合、制御は呼び出し元のファイルに戻る。return に戻り値が設定されている場合、include の戻り値となる 。

<?php
function add($a, $b) {
	$c = $a + $b;
	return $c;	/* 戻り値 $c を返し、function 終了 */
}

$rtn = add(1, 2);
echo $rtn;		/* 3 表示 */
?>

<?php
function who() {
	echo 'hogehoge';
	return;	/* functionを終了。戻り値は返さない。 */
}

$rtn = who();	/* hogehoge 表示 */
?>

引数の参照渡し（リファレンス渡し）

引数の参照渡し（リファレンス渡し）は、定義する関数の引数の前に & を 付加する。

以下の例では、function set_bono(&$var) の &$var は参照渡しの引数になる。

set_bono($name) で、set_bono(&$var) の &$var は $name の参照渡し（リファレンス渡し）となる。

$name は 'hogehoge' が代入されているが、set_bono 関数の $var = 'bonobono'; で $name の内容は 'bonobono' に書き換わる。

引数の参照渡し（リファレンス渡し）は、変数の参照（リファレンス）と同様の仕組みで、$name と $var は同じメモリ領域を指し示すようになる（エイリアス、別名）。詳しくは 変数の参照（リファレンス）を参照。

<?php
function set_bono(&$var) {
	$var = 'bonobono';
}

$name = 'hogehoge';
echo $name;	/* hogehoge 表示 */

set_bono($name);
echo $name;	/* bonobono 表示 */
?>

引数のデフォルト値の設定

関数は引数に、引数 = デフォルト値 の書式で、デフォルト値を設定できる。

デフォルト値は、呼び出し元のパラメーターに引数が指定されなかった場合に使われる。ただし、null を渡した場合はデフォルト値を代入しないので、注意が必要。

以下の例では、function set_bono($var = 'bonobono') の引数、$var に デフォルト値 'bonobono' を設定している。

<?php
function set_bono($var = 'bonobono') {
	return $var . 'はラッコ' ;
}

echo set_bono();		/* bonobonoはラッコ 表示 */
echo set_bono('hogehoge');	/* hogehogeはラッコ 表示 */
echo set_bono(null);		/* はラッコ 表示 */
?>

型

整数（int, integer）

整数（integer）は、10 進数（基数 10）、16 進数（基数 16）、8 進数（基数 8）あるいは 2 進数（基数 2）表記で指定可能。

正の値（+）負の値（-）を数値の前に付与可能。

<?php
$num = 1234;		// 10進整数
$num = -1234;		// 負の値
$num = 01234;		// 8進整数 (0で始まる数値は8進数とみなされる)
$num = 0xffff;		// 16進整数 (0xで始まる数値は16進数とみなされる)
$num = 0b11000100;	// 2進整数 (0bで始まる数値は2進数とみなされる)(PHP 5.4.0以降)
?>

浮動小数点数（float, double, real）

<?php
$num = 1.234;		/* 浮動小数点数 */
$num = 1.2e3;		/* 浮動小数点数（指数表記） 1.2 × 103 */
$num = 7E-10;		/* 浮動小数点数（指数表記） 7 × 10 - 10 */
$num = 123_456_789;	/* 数値リテラルセパレータ（PHP 7.4.0 以降） */
?>

論理型（bool, boolean）

true、false を指定する。小文字、大文字の区別はない。

<?php
$bool = true;
$bool = false;
$bool = TRUE;
$bool = True;
?>

一般的に、true は整数の 1、false は 整数の 0 として扱わる。
※VBなどの一部言語では true は -1 なので注意が必要。

Javaは boolean型と数値の互換性はない。よって、true は整数の 1、false は 整数の 0 としての扱いはない（コンパイルエラー）

true、false を整数として扱い比較するのは、バグの温床になりやすい。
比較は if ($a === true)、if ($a === false) のような厳密な比較を行うことが、可読性が高く望ましい。

<?php
echo (int)true;		/* 1 表示 */
echo (int)false;	/* 0 表示 */
echo intval(true);	/* 1 表示 */
echo intval(false);	/* 0 表示 */

echo (bool)0;		/* 表示されない */
echo (bool)'0';		/* 表示されない */
echo (bool)"0";		/* 表示されない */
echo (bool)1;		/* 1 表示 */
echo (bool)-1;		/* 1 表示 */
echo (bool)123;		/* 1 表示 */
echo (bool)'1';		/* 1 表示 */
echo (bool)"1";		/* 1 表示 */
?>

文字列（string）

文字列はシングルクオーテーション（'）、ダブルクォーテーション（"）で囲む。ダブルクォーテーションで囲まれた文字列の中ではエスケープシーケンスを使用できる（※シングルクオーテーションでは使用できない）。

<?php
$str = 'Hello';	/* Hello 表示 */
$str = "Hello";	/* Hello 表示 */
?>

シングルクオーテーションで囲まれた文字列の中で、文字としてシングルクオーテーションを使いたい場合は \' を、ダブルクォーテーションで囲まれた文字列の中で、文字としてシングルクオーテーションを使いたい場合は \" を使用する。

<?php
$str = 'Hello \'World\' ';	/* Hello 'World' 表示 */
$str = "Hello \"World\" ";	/* Hello "World" 表示 */
?>

シングルクオーテーションで囲まれた文字列の中でダブルクォーテーションを使用できる。また、ダブルクォーテーションで囲まれた文字列の中でシングルクオーテーションを使用できる。

<?php
$str = 'Hello "World" ';	/* Hello "World" 表示 */
$str = "Hello 'World' ";	/* Hello 'World' 表示 */
?>

PHPの特徴

PHPには以下の特徴がある。

1. インタプリタ言語（コンパイル不要）
   インタプリタ言語なので、記述してすぐに動作確認できるメリットがある。コンパイルしないため実行時にエラーが発生しやすい。
2. PHPは変数宣言時に明示的な型定義を必要としない（動的型付け言語）
   明示的な型定義を必要としない動的型付け言語なので、簡単にプログラムを記述し動かすことができる。変数宣言が必須（静的型付け言語）ではないので、バグの温床になりやすい。
3. HTMLに直接PHPのコードを記述できる
   <?php を開始タグ、 ?> を終了タグとして認識し、タグの内側をPHPのコードとして実行する。
   タグの外側はPHPパーサに無視されるので、HTMLに「開始タグ <?php ～ 終了タグ ?>」を記述し、ファイル名（拡張子）を .php とすることで、HTML内に直接コードを埋め込んで動的なWebページを生成できる。

PHPの書き方

HTMLに直接PHPのコードを記述する

PHPはHTMLに直接PHPのコードを記述できる。

<?php を開始タグ、 ?> を終了タグとして認識し、タグの内側をPHPのコードとして実行する。

タグの外側はPHPパーサに無視されるので、HTMLに「開始タグ <?php ～ 終了タグ ?>」を記述し、ファイル名を .php とすることで、HTML内に直接コードを埋め込んで動的なWebページを生成できる。

※パーサとはソースコードやXML、HTMLなどの言語で記述された構造的なテキストデータを解析し、コンピュータが扱いやすいデータ構造に変換するプログラムの総称。コンパイラとは別物。

<?php タグの後ろ、?>の前には必ず「改行・半角空白・タブ」のいずれかを記述する。「改行・半角空白・タブ」がないとエラーになる。

Hello Worldを出力する

<?php ～ ?>の前後を改行で記述

<?php
echo 'Hello World';
?>

<?php ～ ?>の前後を半角空白で記述

<?php echo 'Hello World' ?>

HTMLの中でHello Worldを出力する

<html>
<head>
<title>HTMLのタイトル</title>
</head>
<body>
<h1>h1タグ</h1>
<?php
	echo 'Hello World';
?>
</body>
</html>

<?= ?> は、echo の代わりに値を画面に出力する。

賛否両論あると思うが、可読性、一貫性の低下と、バグの温床になりやすいため <?= ?> は望ましくない。

<html>
<head>
<title>HTMLのタイトル</title>
</head>
<body>
<h1>h1タグ</h1>
<?= 'Hello World'; ?>
</body>
</html>

非推奨タグの記述方法（short_open_tag, asp_tags）

php.ini で short_open_tag が On に設定されている場合は、<?php ～ ?> の代わりに <? ～ ?> を、<?php echo ～ ?> の代わりに <?= ～ ?> を使用できる。

<? ～ ?>

<? echo 'Hello World'; ?>

<?php= ～ ?>

<?= echo 'Hello World'; ?>

php.ini で asp_tags が On に設定されている場合は、<?php ～ ?> の代わりに <% ～ %> を、<?php echo ～ ?> の代わりに <%= ～ %> を使用できる。

<% ～ %>

<% echo 'Hello World'; %>

<%= ～ %>

<%= echo 'Hello World'; %>

PHPの文の区切り

PHPでは、文はセミコロン「;」で区切る。

<?php
echo 'Hello World';
echo 'hogehoge world';
?>

セミコロン「;」で区切っていれば、1行に複数の文を記述できる。

<?php
echo 'Hello World'; echo 'hogehoge world';
?>

PHPで改行を出力する

PHPでは、改行の出力は \n を記述する。

\n を使用するときは文字列をダブルクォーテーションで囲む必要がある。シングルクォーテーションでは改行されない。

<?php
echo "Hello World \n hogehoge world";
?>

PHPでHTMLの改行を出力する

<?php
echo 'Hello World<br>';
echo 'hogehoge world<br>';
?>

nl2br()で\nを<br>に変換する

<?php
echo nl2br("Hello World \n hogehoge world");
?>

PHPのコメント

PHPのコメントは、/* */、//、# の3つの書き方がある。

一般的には /* */、// の2つを使用する。

1. /* */ は /*をコメント開始タグ、 */ をコメント終了タグとして認識し、タグの内側をコメントとして認識する。
2. // は // から改行までをコメントとして認識する。
3. # は // と同様。

命名規則（ネーミングコンベンション）

PHPの命名規則にデファクトスタンダードは存在しない。キャメルケース、スネークケース いずれも使用している。

PHPの言語上の関数は、スネークケースで命名されており、クラス処理ではキャメルケースが使われている。

現在は PSR-12 という規格が業界標準（モダンな開発のデファクト）として広く普及している。

1. isNull
   キャメルケース（camelCase）。単語の区切りを大文字で表すスタイル。Java、JavaScript、C#などでよく使われる。
2. is_null
   スネークケース（snake_case）。Python、Ruby、C言語などで一般的。

ミニファイ（コードの圧縮）を行う場合のコメントは全て /* */ で記述する

HTMLのミニファイ（コードの圧縮）はファイルサイズを小さくして読み込み速度を向上させる目的の他に、HTMLを読みにくくし無断複製を防ぐ目的でも行われる。

ミニファイを行うファイルにPHPのソースコードがあると改行コードが取り除かれてしまい、//、# でコメントを記述すると正しく機能しなくなる。

ミニファイを行う場合は、コメントは全て /* */ で記述する必要がある。

PHP、Rubyの言語比較

HTMLに直接PHPのコードを記述する

PHPは、HTMLに「開始タグ <?php ～ 終了タグ ?>」を記述し、ファイル名（拡張子）を .php とすることで、HTML内に直接コードを埋め込んで動的なWebページを生成できる。

Rubyは、Embedded Ruby を使用し、<% %> または <%= %> を使用する。

<% %> はRubyの処理のみで、HTMLへの出力はしない場合に使用する。<%= %> はRubyの処理および、HTMLへの出力する場合に使用する。

シンタックスハイライト

highlight.js

シンタックスハイライトをおこなうライブラリは syntaxhighlighter、highlight.js、Prism.js などがある。※syntaxhighlighter は2017年で更新が止まっており、事実上開発が終了している。

当サイトは highlight.js を使用している。

highlight.js は下記のスクリプトを<body>～</body>タグの間に記述するだけで使用できる。

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.10/styles/a11y-dark.min.css">
<script src="https://cdnjs.cloudflare.com/ajax/libs/highlight.js/9.15.10/highlight.min.js"></script>
<script>hljs.initHighlightingOnLoad();</script>

シンタックスハイライトさせたいコードを<pre><code></code></pre>で囲む事でシンタックスハイライトされる。

<pre><code>
<?php
$num = 1;	/* グローバルスコープで変数定義 */
function func() {
	global $num;	/* グローバルスコープの$numを呼び出し */
	echo $num;	/* 1が出力される */
}
func();		/* funcを呼び出し */
?>
</code></pre>

a11y-dark.min.css を別のテーマ（配色）に変えることもできる。おすすめは a11y-dark.min.css、vs2015.min.css、xt256.min.css だ。

ぶった斬り第1号 Ruby大好きRubyしかないプログラミングスクール RUNTEQ（ランテック）

記念すべきぶった斬り第1号プログラミングスクールは「RUNTEQ（ランテック）」だ。

人月単価300万円以上の筆者が、たまたま目に留まったプログラミングスクールの「情弱狩り＆補助金ビジネス」に驚愕し、組織でエンジニアの育成を手掛けてきた経験からプログラミングスクールの評価を試みた。

長年システム業界に従事してきたが、プログラミングスクール RUNTEQ（ランテック）には驚きのあまりあんぐり口を開けたまま、脳みそが毛穴から出そうになった。

卒業できない？就職できない？プログラミングスクール RUNTEQ（ランテック）

卒業できない？就職できない？オンラインプログラミングスクール RUNTEQ（ランテック）とは

キャッチコピーは「何者でもない自分から誇れる自分へ」「超実践型プログラミングスクール」、「専門実践教育訓練給付金制度」の対象だ。

身に付くスキルは「Ruby」「Ruby on Rails」「データベース」「HTML CSS」「JavaScript」「開発工程」「サーバー」「ネットワーク」「クラウド」「Linux」「プロダクト開発」「Git Git-flow」「Docker」。

現役ベテランエンジニアからのRUNTEQ（ランテック）評価は以下のとおりである。

オンラインプログラミングスクール RUNTEQ（ランテック） 運営会社RUNTEQについて

企業情報では資本金が「未記載」であり、入居中のビル「〒150-0042 東京都渋谷区宇田川町36-6 ワールド宇田川ビル5階B室」は1975年竣工の築50年のビルで評価は低い。

「新型コロナ感染拡大防止の観点から全従業員テレワーク（在宅勤務）に移行しております。お電話が繋がりにくい可能性がございますので、お問い合わせの際はお問い合わせページからご連絡を検討頂けますようお願い申し上げます｡」の記述があるが、電話連絡先はRUNTEQの公式サイトのどこにもない。

「お電話が繋がりにくい」ではなく、まったく繋ぐ気はないようだ。

引用元 株式会社RUNTEQ - 企業情報

RUNTEQ経営者はWEB系エンジニア

経営者の経歴とYouTubeの配信を見た率直な感想は、プログラマー的な発想で「要件定義→基本設計→詳細設計→製造→試験→教育→運用」というシステム開発の全行程を俯瞰的にみることができていない。

図）システム開発事業者の全工程

参考資料 人生を救ってくれたエンジニアという生き方 菊本久寿 - Speaker Deck

参考資料 「天才じゃなくても世界を変えられる」。菊本久寿氏が語る、「エンジニア×スタートアップ」のキャリアが最高な理由 | アンドエンジニア

参考資料 株式会社スタートアップテクノロジー代表　菊本 久寿氏－社長の履歴書

卒業できない？就職できない？プログラミングスクール RUNTEQ（ランテック）の詳細説明

卒業できない？就職できない？プログラミングスクール RUNTEQ（ランテック）就職できた卒業生インタビュー

RUNTEQが公式ホームページで紹介している就職できた卒業生のインタビューでは、新卒1名、前職で派遣社員1名を除き、前職は全員正規雇用の社員または公務員で、フリーター、職歴ナシは存在しない。

学歴は不明2名、大学中退1名を除き全員大卒。不明2名の内1名は国家公務員（税関）だったので大卒とみるべきだろう。

残り一名は介護士をしながら社会人野球に取り組んでおり、膝の故障で野球を諦め地元の印刷会社に就職しているので、大卒、高卒どちらの可能性もある。

つまりインタビュー対象が全員大卒の可能性（1名大学中退）があり、新卒1名を除く全員が前職で正規雇用の職歴もあるので転職は十分可能であり、見栄えのよいキャリアの持ち主を選んでインタービューしている。

前職が国家公務員、地方公務員もいるのは驚く。

RUNTEQ（ランテック）に紹介してもらいたいのは、フリーターから中小零細のシステム関連の会社でよいので正規雇用されたレベルのインタビューなのだが、実績があれば掲載すると思うので「実績なし」と考えるのが妥当だろう。

転職が難しい経歴しかない人が、RUNTEQで学んだことで転職に成功し、正規雇用されたストーリーを紹介してほしいが、インタビューがないので成功事例はないのかもしれない。

疑問に思ったのは、もしわたしが知人に「WEB系エンジニアになろうかと考えている」と相談されたら、エンジニアの面白さも説明するが、それ以上にエンジニアの不安定な状況も説明する。

特に大手の上場企業のグループ中核企業であれば「職の寿命」と、上場企業によるレイオフは日本では現状不可能なので安定も担保されるが、非上場、特に中小零細（ベンチャーも大多数は中小零細）では実質的レイオフは普通にあること説明する。

卒業できない？就職できない？プログラミングスクール RUNTEQ（ランテック）の就職先企業

卒業できない？就職できない？プログラミングスクール RUNTEQ（ランテック）専門実践教育訓練給付金制度の利用

専門実践教育訓練給付金制度は厚生労働省が実施する教育訓練を支援する制度だ。

受給対象者は、雇用保険の被保険者または被保険者であった方（離職後1年以内）が対象になる。

簡単に言うと「現在就業中で雇用保険に加入している人」「雇用保険に加入していたが1年以内に離職した人」が対象になる。「再就職のための職業訓練としての利用」と「現在就業中で技能を学びたい人の利用」を対象とした制度設計になっている。

RUNTEQ（ランテック）の場合、資格等の取得は、2 or 3の条件で給付を受けるには「修了認定基準」を満たす必要がある。

専門実践教育訓練給付金制度こそが、オンラインプログラミングスクールが爆発的に増殖した要因の1つだ（もう1つはコロナ）。

くれるものは貰っておきたいと考えるのは当たり前の発想だが、これは税金であり「結果を出さないスクールへの補助」はまさに補助金に群がる「補助金ビジネス」に他ならない。

引用元 教育訓練給付制度｜厚生労働省

引用元 専門実践教育訓練給付金制度（Reスキル講座）対象プログラミングスクールRUNTEQの支給条件と対象者

社会人・未経験におすすめのプログラミングスクールで学べる技術

10日で使えるPHP | 未経験のサルでも分かるPHPの学習サイト 文系未経験、サルでも10日でPHPを使えるように内容を構成した独学向け学習サイト。不要な基礎はバッサリ切り捨て必要な基礎を十分に深堀した・・・  続きを見る

新卒や現役エンジニアの学習方法（オンライン学習 or 書籍） 「SIerやメーカーに就職した新卒」や「現役エンジニア」で、動画配信で学ぶ技術者はほぼゼロと言ってよい。洗練された書籍で学んだほうが短期間で技術習得できるし高すぎる。・・・  続きを見る

RUNTEQの就職先と就職できた卒業生インタビュー RUNTEQの就職先と就職できた卒業生のインタビュー。 インタビュー対象の卒業生の学歴は不明2名、大学中退1名をを除き全員大卒、前職は派遣社員1名、新卒1名を除き、全員正規雇用の社員または公務員だ。・・・  続きを見る

プログラミングスクールでは教えてくれないシステム業界の現実

プログラミングスクールでは教えてくれない「Python、Ruby、PHPの特徴」

Python、Ruby、PHPの特徴

小規模開発ではPython、Rubyを採用するケースもあるが、Python、Ruby、PHPなどの変数宣言を必要としない言語（動的型付け言語）は品質を担保することが困難で、システム開発に向かない言語とされている。

Pythonは生成AIの開発に必要なライブラリが充実しており、生成AI関連では採用されることが多い。

小規模かつアジャイル開発のようなスピード重視の開発に採用されるケースはあるが、決められた「品質」「予算」「納期」を実現する言語としては適切ではない。

Python、Ruby、PHPはいずれもインタプリタ言語であり、処理性能が重要な大規模システムではボトルネックになる。それぞれ非公式なコンパイラもあるが、信頼性が低く採用できない。

プログラミングスクールでは教えてくれない「Cobol、C++、Javaの特徴」

Cobol、C++、Javaの特徴

Cobol、C++、Javaなどの変数宣言が必要な言語（静的型付け言語）は品質管理が容易であり、コンパイル言語なので実行速度も速い（厳密にはJavaは中間言語）。

システム開発で重要なことは「品質」「予算」「納期」だ。変数宣言が不要であったり、スコープが曖昧な言語は、動かすことは簡単だが品質管理は難しい。

変数宣言が必要で言語仕様が明確なコンパイル言語は、正しく記述しなければコンパイルエラーで動かない。

動かすことが面倒な言語だが、システム開発で重要なことは「品質」「予算」「納期」であり、これらの条件に沿った言語だ。

プログラミングスクールでは教えてくれない「Ruby」を教えるのは簡単だが「Javaは難しい」

「Ruby」を教えるのは簡単だが「Javaは難しい」

プログラミングスクールでJavaが学習対象にない理由は明確で「教えるのが難しい」からだ。Javaはオブジェクト指向で変数宣言が必須でありコンパイル言語だ。

書いたプログラムをレンタルサーバーにアップロードすれば動かせるPython、Ruby、PHPとは違い、JVMを起動させる必要があるし、WEBシステムならJVMと連動させる必要もある。

プログラムを書いてもコンパイルしなければ動かない。コンパイルでエラーがあればコンパイルすらできない。

Python、Ruby、PHPはインタプリタなので書けばなんとなく動くが、Cobol、C++、Javaは違う。

つまり、Cobol、C++、Javaを避けて、Python、Ruby、PHPを教えたがるプログラミングスクールは、現実のシステム開発を知りつつ、大多数のエンジニアが従事する業務システム、特に大規模システム（業務システム）ではまったく意味がないことを教えているボッタクリスクールと言える。

プログラミングスクールでは教えてくれない「現役エンジニアや新卒はどのように学んでいるか？」

新卒や現役エンジニアはどのように学んでいるか？

「SIerやメーカーに就職した新卒」や「現役エンジニア」で、動画配信で学ぶ技術者はほぼゼロと言ってよい。洗練された書籍で学んだほうが短期間で技術習得できるし、そもそも高すぎる。

「動画配信でチンタラ学んでいるような人は現場ではやっていけない」というのが率直な意見だと思う。

筆者が新卒・中途の未経験者の教育で使用している書籍が「10日で覚えるシリーズ」だ。新卒未経験者にはこの本で10日間でMVCモデル2（Java Servlet JSP Oracle）の開発の初歩ができるようになってもらう。

中途未経験者の採用試験でも使っており、10日間時給を支払い、複数いる場合は協力し合ってこの課題をおこなわせる。

すべて完璧に理解・実装できる必要はないが、重要な部分は10日間ですべて理解・実装できないと合格できない。

できるか？できないか？グダグダ考える前に「読んで手を動かせ」ば、大卒・専門卒・高卒問わず10日間でできるようになる。

もう1つ、この10日間でやることには意味がある。

知人が誰もいない現場に行くのは当たり前

システム開発は気の知れたチームでおこなえることの方が少ない。多くのプロジェクトは、流動するSE・PG・コーダーを調達し、チームを作りプロジェクトを推進する。

自分が流動する人材を向かい入れる側になることもあれば、1人で誰も知人のいないプロジェクトに放り込まれることもある。

全員知らない人は普通で、物怖じしたりグダグダしている暇はなく、現場に入ったら即順応して仕事を始める必要がある。それが即戦力だ。

フットワークが重い人は戦力にならないので短期間で「ダメなヤツ」という烙印が押されてプロジェクトから放り出される。

未経験者でも課題を10日間でやり切る人は「心も作業もフットワークが軽く」近い将来1人で放り出されてもやっていける。

「オンラインプログラミングスクールよりペラ本の方が10倍速い」

通常の学習や、受験、試験でも同様なことが言えるが「いかに要点を短くわかりやすくまとめた参考書」を見つけられるか？が学習を進めていく上で最も重要な技術の1つだ。

技術習得も同様で、自分にあった「要点を短くわかりやすくまとめた技術書」を見つけられるか？は、システム業界で生きて行く上で必須能力になる。

ひとそれぞれ、好みや、わかりやすいと感じる書籍は違うが「わかりやすさ」とは「クドクド長い説明ではなく、必要な要点を端的に説明する」ことだ。

分厚い参考書では挫折するが、薄っぺらいが重要な要点を網羅した参考書では挫折しない。

特に現役エンジニアは、実業務をこなしつつ余剰時間で新たな技術習得をする必要があり、ほとんどのエンジニアは就業時間中に新たな技術を学ぶ余裕はない。

では、どのように学習しているのか？

ペラッペラで良いので、必要な要件だけ書かれた書籍で学んでいる。もしくは、必要な部分のみ抜粋して学んでいる。

エンジニアは技術書を頭から読まず、目次を見てパラパラめくって必要な情報に辿り着く。速読に近いことを多くのエンジニアはしている（ダメなヤツはできない）。

プログラミングスクールでは教えてくれない「動画配信は非効率」

1. 目次・索引から目的の情報を開く
   

   動画配信に目次はなく、パラパラめくることも出来ない。
   本のようにここら辺じゃない？と当たりをつけて開いて、自分が探したい情報にいち早く辿り着けない。
   本のような物理的UIではないので時間がかかる。

プログラミングスクールでは教えてくれない「オンラインプログラミングスクールは情報弱者狩り＋補助金ビジネス」

「オンラインプログラミングスクール＝動画配信」であるため、スクールは動画と書籍の比較はしない。オンラインプログラミングスクールのメリットが見えてこないからだ。

プログラミングスクールでは教えてくれない「プログラミングは大した技術ではない」

コーディング（プログラミング）は大した技術ではない

受験を思い出してほしい。

毎日コツコツと勉強し積み上げて、自分の知識として定着されるのは絶対条件だが、勉強ができる人は要点をとらえるのが上手く、ノートを綺麗に書き、短期間で詰め込む要領の良さがある。

勉強をやらなかった、もしくは勉強の正しいやり方を知らない結果、できなかった事に問題はないが、勉強をやってもできなかったのは問題がある。

脳の良し悪しはあるが、コーディング（プログラミング）程度なら早慶レベルの理工学部の現役大学生は、技術書のみで1ヶ月でかなり書けるようになる。勉強をやってもできなかった人は、1ヶ月で書けるようにはならない。

高卒でも「学習用の技術書を選択」と「進め方」さえ間違わなければ、フルタイムで学べば1ヶ月でかなり書けるようになる。

難関大学の理工学部卒から、高卒まで幅広い学歴の未経験者の教育をおこない、高卒を上場企業に即戦力として中途採用されるレベルのエンジニアに育成することもおこなってきたが、プログラミングに関して言えば、学歴や理系・文系は関係なく誰でも普通にできようになる。

プログラミングは限りなく奥深く、広い知識が必要だが、ありがちな業務システムや配信型WEBシステム程度なら、難易度の高い実装（複雑なトランザクション処理やビジネスロジック）を除けば、2ヶ月フルタイムで学習すればそこそこ現場の戦力になる。

「UI」や「データベースの参照・更新」程度なら技術力は必要なく、誰でも短期間で出来るようになる。高校の数学、物理、英語の方が遥かに難しい。

プログラミングスクールに何十万円もかけて行くとかオンラインで学ぶという感覚は、システム業界の人間にはまったく理解しがたい感覚だ。

大きな書店で気に入った本を買ってきて読めば十分わかる話だ（※アマゾンでポチる場合は、大人買いして良本を見つける必要がある。良本か？自分に合っているか？などはパラパラめくってみないと判断できないからだ）。

プログラミングとはその程度の話で、手に職を付けるといったレベルのものではない。現場レベルのコーディング（プログラミング）だけで一生食べていける可能性はかなり低い。

システム開発全般に対する理解、最低でも下流工程の設計能力がなくては50歳まで現役で働くことすら難しいだろう。

Rubyで開発している代表的なWebサービス（Cookpad、食べログ、クラウドワークス、freeeなど）

Rubyが採用されるシステムは情報配信型のWEBサービスが多い（Cookpad、食べログなど）。

情報配信型のWEBサービスは、小さなサービス（システム）としてスタートし、PVに比例した広告収入などの収益に応じて機能（システム）を建て増ししていく。

情報配信型のWEBサービスの業務要件は曖昧で、ユーザーニーズに合わせて機能追加、変更が頻繁に発生する。

ウォーターフォール（要件定義→基本設計→詳細設計→製造→単体テスト→結合テスト→総合テスト→運用）のような工程が完璧に終るまで次の工程には進まない管理手法では、頻発する仕様変更に対応するのが難しく、アジャイルのような管理手法が適している。

一般的なシステム開発の工程である、業務要件やユーザー要件を定義し、設計書を書き、設計書に基づき製造（コーディング）し、単体テスト→結合テスト→総合テストと段階を追って試験し、運用に乗せるといった工程の大部分を割愛し、要件と大まかな設計書でコーディングして十分な試験をしないでリリースする。

問題があれば、即ソースコードを修正してリリースするといった運用をしている。

また最初から大きな予算をかけて開発しても、サービスが利益につながるビジネスになるか不明確なので、できるだけ少ない予算でスタートする必要がある。

これはどのような情報配信型のWEBサービスでもほぼ同じだ。

仕様変更が頻発し低予算で開発するケースには、Ruby、Python、PHPが適している（JavaやC++では予算がかかり過ぎるでの選択できない）。

低予算の小規模システムではJavaやC++を採用するよりRuby、Python、PHPの方が安価にあがるが、品質とはトレードオフの関係にある。

リクルート（リクナビ、スーモ、じゃらん、ホットペッパーなど）はJavaを採用

情報配信型のWEBサービスのように見えるが、ビジネスモデルが全く違う業務システムもある。

例えば「リクナビ」や「スーモ」は、情報配信型のWEBサービスのように見えるが、「リクナビは就活産業」であり、「スーモは不動産業」だ。

「リクナビ」や「スーモ」は、情報配信型WEBサービスのように見えるが全く異なる。

業態が元々存在するので「十分な予算」があり「Java」が採用されている。業務システムと同様で、障害は事故扱いで損害が発生する。

古典的なビジネスとして元々成立しており、それをデジタル化しただけである。この場合、最初から大きな予算で堅牢なシステムを開発できる。使用する言語はJavaが主流だ。

フレームワークは、BFF（backend for frontend）には「Spring Boot（Spring Web Flux）/ Kotlin」、Backendには「Spring Boot（Spring MVC）」を採用している。

ミッションクリティカルなシステムではないのでサーバーは「AWS」、ミドルウェアは「Google Cloud BigQuery」「Gatling」「Fluentd」だ。サーバー運用管理は「Datadog」「NewRelic」を採用している。

リクルートではプライベートクラウドを構築しているので、AWSでの運用が上手くいかない場合は、プライベートクラウドに専用環境を構築できる強みがある。

引用元 Javaエンジニア（SUUMO/じゃらん/ホットペッパー等オープンポジション）の募集内容｜キャリア採用｜株式会社リクルート

引用元 Recruit (@recruitengineers) on Speaker Deck

Rubyの大規模システム「freee」

Rubyを採用したサービスで例外もある。会計サービスの「freee」だ。

「freee」は小規模事業者・個人向けのクラウド会計ソフトで2024年時点での導入は54万事業所ある。

会計ソフトなのでミッションクリティカルなシステムとは違い、障害が重大な影響（損害）に繋がりにくいが、会計という業務と規模を考えると、長時間のシステムダウンは許されないシステムと言える。

また、会計は複雑な処理が多く、Rubyを採用した場合、設計方針（ルール）、コーディング規約などの決め事を細部までおこなわないと品質管理が難しい。

素晴らしいサービスであることは間違いなのだが、残念なのは「freee」の公式サイトには利用企業として「MS&AD」「野村証券」「関電」「川崎重工」「伊藤忠」「アイシン精機」「富士通」「三菱重工」など日本を代表する企業がロゴで紹介されている。

これらの企業は、独自の会計システムを構築しているかSAPを導入しており、会計処理に「freee」は利用していない。

サービスを大きく見せたい気持ちはわかるが、ユーザーに誤った認識を与えるような広告行為は節度ある企業のすることではない。

Rubyで開発している代表的なWebサービスの使用言語とフレームワーク、ミドルウェアなどのまとめ

資料 Ruby Association Ruby活用事例 freee株式会社 | Ruby Association
資料 Ruby Association Ruby活用事例 株式会社クラウドワークス | Ruby Association
資料 freee Developers Hub Ruby カテゴリーの記事一覧 - freee Developers Hub
資料 freee Developers Hub Ruby on Rails カテゴリーの記事一覧 - freee Developers Hub
資料 freee Developers Hub Ruby on Rails カテゴリーの記事一覧 - freee Developers Hub
資料 freee Developers Hub AWS カテゴリーの記事一覧 - freee Developers Hub
資料 日経クロステック マイクロサービスとモジュラーモノリスが併存、これがfreeeの最適解 | 日経クロステック（xTECH）
資料 クックパッド開発者ブログ クックパッド開発者ブログ
資料 Tabelog Tech Blog Tabelog Tech Blog

資料 ElasticsearchElasticsearch：公式分散検索および分析エンジン | Elastic
資料 ElasticsearchElasticsearch ＆ 導入支援 | NTTテクノクロス株式会社
資料 ECS（Amazon Elastic Container Service） Amazon ECS（Docker コンテナを実行および管理）| AWS
資料 ALB（Amazon Application Load Balancer） Application Load Balancer | Elastic Load Balancing | Amazon Web Services
資料 ALB（Application Load Balancer） Application Load Balancer とは? - エラスティックロードバランシング | AWS
資料 RDS（Amazon Relational Database Service） Amazon RDS（マネージドリレーショナルデータベース）| AWS
資料 S3（Amazon Simple Storage Service） Amazon S3（拡張性と耐久性を兼ね揃えたクラウドストレージ）｜AWS
資料 Redshift（Amazon Redshift） Amazon Redshift（高速、シンプル、費用対効果の高いデータウェアハウス）| AWS
資料 ElastiCache（Amazon ElastiCache） Amazon ElastiCache（インメモリキャッシングシステム）| AWS
資料 SQS（Amazon Simple Queue Service） Amazon SQS（サーバーレスアプリのためのメッセージキューサービス）| AWS
資料 SNS（Amazon Simple Notification Service） Amazon SNS（サーバーレスアプリのための pub/sub メッセージングサービス）| AWS
資料 SNS（Amazon Kinesis） Amazon Kinesis（ストリーミングデータをリアルタイムで収集、処理、分析）| AWS
資料 SNS（AWS Lambda） AWS Lambda（イベント発生時にコードを実行）| AWS
資料 Google BigQueryGoogle BigQuery データ ウェアハウスから自律型データ AI プラットフォームへ | Google

コーディング規約

コーディング規約が必要な理由は、既にご存知の方がほとんどだと思うが、だれもが好きなようにコーディングしてしまうと、可読性が極めて低い、読めないソースコードが出来上がってしまうからだ。

あらかじめルールを決めておくことで、可読性を担保できる。

特に、変数そのもの、変数の接頭辞は規約を作っておくことで、その変数が何を表しているか、どのプリミティブ型か、一目瞭然になる。

大昔、VBで変数に日本語（2バイト）を使ったアホがいたが、こういうアホや、for文のカウンターに、i、j、k、などはよく使用するが、i1、i2、i3・・・・のようなマジで読めないソースコードを書くアホを駆逐する為にコーディング規約は重要だ。

※個人的には、カウンターはcntI、cntJ、cntKのような接頭辞を付ける方が好きだが、これはソースが好きか醤油が好きか？という議論になると思う。

業務アプリなどでは変数そのものを規定する事も多い。「契約 contract」「検査 inspection」「予算 budget」「支払 payment」「委託事業 project」「補助事業 grant」など予め単語と変数名を決めておくことで可読性を担保できる。

「契約 keiyaku」「検査 kensa」「予算 yosan」「支払 shiharai」「委託事業 itaku」「補助事業 hojo」のようなローマ字での記述も馴染みがあるし、命名規約に定義しておけば可読性は上がるので、ローマ字記述でも良い。

※ローマ字記述がダメというプロジェクトも散見するが、意味不明な英単語を付けられるよりは、ローマ字記述の方が可読性は確実に高いので無理に英語を使用する必要はない。重要な事は可読性を第一に考える事で、英語にこだわって可読性を損ねるのは愚の骨頂だ。

ソースコードは英文

プログラムは英語そのものだ。if、for、switch、do while、public、private、add、get、set、put、trim、claer、remove、などなど。

クラス、メソッド、プロパティ、変数、それぞれ正しい英語表記で命名すれば、英文としてきちんと読めるようになる。

英語圏の人（英語ができる人）にとっては単なる文章なので、普通に読めて当然だ。

問題は英語ができない日本人で、英語ができない日本人にとって、forも、ifも、switchも、すべてコマンドとして認識しており、クラス、メソッド、プロパティ、変数もそれぞれ、単なるコード（バーコードようなもの）化してしまう。

その結果、作成されたソースコードは全く読めないものが出来上がる。

UNIXのソースコードを読んだことがある人は、おおよそソースコードは読み物であると理解している。可読性は高くはないけどね。

※困るのが、英語を普通に読み書きできるが、アホで英語のできない日本人を考慮しないプログラマーだ。彼らは思いつくままソースコードを書いた結果、英語のできない日本人には読めないソースコードになる事があるので、嫌がるが規約で縛りつけるしかない。

日本語しかできないコーダーはとても多いので、コーディング規約、命名規約で縛りつけて、可読性を担保する事が重要だ。

コメントは必ず書く

どのようなクラス、メソッド、プロパティにもコメントは必ず書く必要がある。コメントの記述ルールもコーディング規約で細かく定義する必要がある。

「コメントの始まり、機能、引数、戻り値、コメントの終わり」など、記述方法をキッチリ決める必要がる。

特に「javadoc」や「サードパーティー」のドキュメント出力ツールを使用する場合は、100％使用するツールに沿って記述する必要があり、例外は許してはいけない。

日本語しかできないコーダーは、コメントに関しては従順な有能なコメントを書くのだが、ここで問題なのは、英語ができる有能なプログラマーで、彼らはソースコードそのものが文章なので、コメントなど必要ないという考えを持っている人も多い。

彼らのように有能なプログラマーだけなら、複雑な機能以外コメントを書かないという選択もあるかもしれないが、多くはソースコードは単なるコードそのものにしか見えないコーダーなので、読む人の事を考えないプログラマーは無能だと思い、ここでも規約で縛りつけよう。

そもそも、コメントとは補足と考えているプログラマーもいるが（特に英語ができるプログラマー）、コメントは設計書の一部と考えるべきである。

ソースコードの中に書くコメントは確かに補足だが、クラス、メソッド、プロパティの最初に「機能、引数、戻り値」などを書くコメントは設計書の一部である。

設計書の役割は、後々、仕様変更などのメンテナンスで必須になるので、コメントはソースコードと同様に重要だ。設計書とソースコードが一致しないなど言語道断なのである。

インデント（字下げ）

インデント（字下げ）とはソースコードを読みやすくするため、行を下げる事である。

インデントはタブでおこなう。

タブおこなうメリットは「インデント1つ = タブ1つ」を徹底しやすく、高い可読性と保守性を実現できるためだ。

半角スペースでインデントをおこなうケースもあるが、半角スペースでおこなった場合、プログラマーに「インデント1つ = 半角スペース4つ」などのような、同一数のスペースで字下げするルールを徹底する必要があり、現実的に徹底するのは難しくなる。

特に、深いネストや条件分岐でインデントが連続して続く場合、半角スペースの数を確認するのが難しくなり、ズレが生じる可能性が高い。

また、ヒューマンエラーは必ず起こるので、インデントの半角スペース数を決めても、一定数のズレは生じる。

その点、タブをインデントに使用した場合、深いネストでもインデントを目視で確認しやすく、ズレが生じる可能性は極めて低い。同様にヒューマンエラーによるズレも起きにくい。

プログラマーによっては「インデント1つ = 半角スペース2つ」の方が良い、「インデント1つ = 半角スペース4つ」の方が見やすい、慣れているなどの理由でルールに従わないプログラマーもいるが、タブで統一した場合は「インデント1つ = タブ1つ」がほぼ100％共通認識なので、ルールを遵守させやすい。

エディターの設定で、Tabキーで自動的に決まった半角スペースを自動入力する機能もあるが、ソースコードに半角スペースが埋め込まれている事に代わりはなく、修正を加えるなどした場合にズレは一定数生じてしまい保守性は落ちる。

GitHubなどのソースコードの管理ツールを使用した場合、半角スペースでインデントすると、半角スペース1文字でもズレていれば変更ありと判断され、バージョン違いになる。

可読性、保守性から、タブでおこなうべきで、半角スペースでインデントをおこなうメリットはない。

なぜプログラマーは規約を嫌うのか？

なぜプログラマーは規約を嫌うのか？

答えは単純で、自分の癖を直したくないからだ。

例えば箸を正しく使う事が出来ない人がいる。彼は箸をバッテンで挟むように使う。正しい使い方ではないが、特に困る事もない。直す必要性がないのだ。

恥を書くのは、本格的な日本料亭では恥をかくことになる。彼女の両親と食事に行った時も、ハズカシイ思いをするかもしれない。

ただ、恥をかくのは彼一人の問題だ。

プログラムは違う。癖を直さず書いた結果、他人が読むのに苦労する。もしくは読解不可能なスパゲッティプログラムになる可能性もある。

プログラムの製造では、属人的な要素は全て排除すべきだ。わずかでも残せば、メンテナンスで苦労する事になり、将来のリプレイス時には確実に面倒な事になる。

長期的な視点を持てないエンジニア

癖を押し付けるプログラマーはどういう人種なのか？

プロジェクト・プロダクトに長い間コミットしない短期労働者か、または全く逆で、長期間コミットするが、チームプレイを必要としない労働者だ。

規約とは法律と同じで、日本人なら法治国家である日本の法律は遵守しなければならない。法を犯せば罰せられる。

沢山の人が平和に建設的に生きていく為にはルールが必要で、それが法律だ。

システムの設計・製造も同様で、現在から未来において関わるすべての人が、健全に建設的活動ができるように、統一されたルールに基づき可読性の高いコードを生産する必要がある。

コーディング規約を守らないプログラマー・コーダーがいれば、法律違反と見なし、厳しく罰しなければいけない。妥協してはいけない。妥協が将来のシステムを歪める事になる。

多くのシステム開発は「予算、納期、品質」のいずれかを守れない。日本の全システム開発の80％以上が「予算、納期、品質」のいずれかを守れていないのが現実だ。

プロマネはなんとか納期までに間に合わせようと必死になり、長期的な視点を欠き、目に見えない品質を軽視する。

生産性が高いプログラマーのワガママを許している多くの現場は、炎上か？炎上寸前の現場だ。

その結果システムが出来上がっても中身はボロボロで、メンテナンスもコストも想定外の自体に直面する。

プロジェクトの概念設計段階で「予算、納期、品質」が適切か？十分な調査が成されていれば、プロジェクトに携わる人々の質に問題がなければ、いずれの問題も生じない。

「安く」「早く」を要求されても、それは不可能だ。そのような要求は飲めないし、そのような要求を容認するSIerにお願いするのが良いと苦言できないエンジニアは、毎回炎上していればいい。

優秀なエンジニアなら「予算、納期、品質」を十分に守れる提案をする。お客様の要件に変更があった、または追加されたなら「予算の見直し」「納期の延長」、SIer側に問題が発生したら「品質」を担保するために「納期の延長」を申し出る。

優秀なエンジニアなら、どんなに生産性の高いプログラマーでもルールを守らないなら、生産性の低いプログラマー以下の存在で、注意・警告しても守らないならプロジェクトから追放しなくてはならない。

開発スタイル ジャズのセッションか？オーケストラか？

「我々チームは、ジャズのセッションのようなものだ」と私の恩師は自分のチームを表現した。対局にあるのが「クラシックを演奏するオーケストラだ」とも。

ジャズのセッションは「スタンダード曲（ジャズ・スタンダード 代表的なもので約200曲）」があり、セッションの作法があり、それらの組み合わせやアレンジを即興で演奏する。

何もないところからノリで演奏しているわけは全くない。

オーケストラで演奏するクラシックは楽譜があり、指揮者の裁量によるが楽譜どうりに演奏する。ジャズのセッションのような自由度はない。

ブラジル型のサッカーとイタリア型のサッカーの違いとも言える。ブラジル型のサッカーは大まかなポジションはあるが、パスか？ドリブルか？シュートか？はプレイヤーの裁量に任せられている。

イタリア型のサッカーはフォーメーション（厳密なポジション）があり、プレイスタイルはパスサッカーだ。プレイヤーの裁量という意味がブライジル型とは大きく異なる。

ジャズ型開発

彼が言いたいのは、状況に応じて臨機応変にコンサルタントやエンジニアが、最良の結果を出す為に即興でそれぞれ行動し（ポジショニング・準備）、それぞれ最高のプレイをして（ドリブル・パス）、最終的に最良の結果（ゴール）を決めると言うものだ。

全て暗黙の合意（意思疎通）でおこなってしまう。

全員スーパーマンレベルのエンジニアでないとできない。通常そんなスーパーマンばかりのチームを作れるわけない。

だが、彼のチームは事実そうだった。

例えば年度予算が3兆円越え、ユーザーが1万人越えの組織の予算管理システムを、要件定義から運用まで6ヶ月で実現してしまう。今から20年以上も前なのでローコード開発など存在しないスクラッチの世界だ。

コンサルタントSEが顧客と大まかなシステム要件を洗い出し、要件定義と平行してモデル・ドリブン・アーキテクチャのフレームワークを作成、平行して実装できる機能を実装する。

スパイラルともアジャイルとも、プロトタイピングとも違う。

ウォータフォールで行ける部分は確実にウォータフォールで工程を進め、要件がフワフワしている部分はプロトタイピングで毎週顧客とイメージを擦り合わせ、完成度を高める。

全行程は統一感がなく、属人的に進めているようでありながら、並行して開発している強力なフレームワークに適合できるようにインターフェースを整えていく。

ソースコードは規約に沿って作られていくので、可読性は十分に担保されている。

最終的にフレームワークに乗せた時には、フレームワークの強力な拘束力と明確なインターフェースで、システム全体の可視化が容易になる。

試験は全行程の30％以上が充てられ、完成した機能から順次行われる。単体、結合、総合という工程はあるが、製造工程の品質が高いので、総合に十分なリソースを充てる事ができる。

要件定義→基本設計→詳細設計→製造→環境構築→試験→教育→運用まで、コンサルタントSE、SEは全員、全行程おこなう能力がある。プログラマも要件定義と基本設計の一部、教育を除く全行程できる。

それぞれ得意工程があるが、どの工程も高いレベルでできるので、全ての工程でもミス、モレがない。

オーケストラ型開発

オーケストラ型の開発はウォータフォールだ。

厳密なルールに沿って各工程を完璧に行い、次の工程に進めていく。前の工程に戻す必要があれば現在の工程はストップして前の工程に戻る。問題を完全に解消してから次の工程に進める。

全行程、徹底的にドキュメント化し、ドキュメントに沿って開発を行う。実装段階では考える余地がない程、ドキュメント上で詳細な設計を行う。

必要な修正があっても必ずドキュメントを修正し、レビューし、承認作業を経て実装される。

SEが製造をおこなう事はほぼないし、PGが設計をおこなう事もない。上流から下流まで一直線に進めていく。

ウォータフォールのメリットは各工程を完璧におこなう事で、出戻りが発生しない事だ。工程管理がしっかりできるので、大規模開発はウォータフォール以外の選択肢はないと言っていい。

ウォータフォールで進める場合、工程が予定通りに進まないと「予算、納期」に大きな影響が出る。

予定通りに進まない工程があった場合、他の工程を圧縮して「予算、納期」を計画通りにする事は不可能だ。スパイラルやアジャイルのような自由度はない。

スーパーマンも必要ない。ウォータフォールを採用するメリットは、一般的なSEやPGが粛々と作業をする事でリリースまで進められることだ。

開発規模の大きさに比例してプロジェクトに必要な技術者の数も多くなる。大規模開発では全員が歩調を合わせて進むことが大切だ。

命名規約

プログラムの製造（開発）における命名規約は、可読性を担保するために必須の規約だ。

たとえばJavaの場合、変数がプリミティブの場合、変数の前に接頭辞をつける。

プリミティブ型の接頭辞

メソッドやクラスの機能を表す接頭辞

メソッドやクラスの機能を表す接頭辞をつける。

よく使う英単語

よく使う英単語。

プレス印刷と同じレベルの印刷革命

おすすめ記事

10日で使えるPHP | 未経験のサルでも分かるPHPの学習サイト 文系未経験、サルでも10日でPHPを使えるように内容を構成した独学向け学習サイト。不要な基礎はバッサリ切り捨て必要な基礎を十分に深堀した・・・  続きを見る

Copyright (C) 2001～2026年 e-elder.jp All Rights Reserved. Update 2026年2月4日運営者情報 ご質問はこちらへお願いします info@e-elder.jp