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

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

更新日 2026年2月14日

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. ヒアドキュメント（<<<）
   6. NULL型（null）
   7. 未定義値
   8. NAN（not a number）
   9. コールバック（callable）
   10. キャスト（型の相互変換）
5. 関数 function
   1. 関数 function
   2. return
   3. 引数の参照渡し（リファレンス渡し）
   4. 引数のデフォルト値の設定
6. クラス
   1. クラスのプロパティ、メソッドのスコープ
   2. インスタンスの生成
   3. クラスのプロパティ、メソッドのスコープ（アクセス修飾子）
   4. private プロパティ
7. 例外処理
   1. try catch finally throw の仕様
   2. throw 意図的に例外を発生する
   3. try catch finally による例外処理
   4. 深い階層で発生したエラーの例外処理
8. シンタックスハイライト
   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' 表示 */
?>

文字列（string）内の変数の置き換え

文字列がダブルクォーテーションで括られるかヒアドキュメントで指定された場合、 その中の変数は置き換えられる。

<?php
$name = 'hogehoge';
echo "私の名前は $name です。";	/* 私の名前は hogehoge です。を表示 */
?>

ヒアドキュメント（<<<）

NULL型（null）

null 型は、PHPの unit 型（意味のある情報を持たないことを示す型）であり、単一の値 null しか持たない。

※PHPでは null 型は unit 型としているが、多言語では異なる。Unit型は「何もしない」ことを表す型、nullは「値がない」ことを表す値（またはその状態）という違いがある。

nullは「値が存在しないこと」を示す特別な値である。大文字・小文字は区別されない。ただし、nullと、未定義値は、is_null() などで判断する際の動作が異なる。

<?php
$var = null;

/* is_null($var) === true であり NULL型 が表示される */
if (is_null($var) === true) {
	echo 'NULL型';
} else {
	echo 'NULL型ではない';
}
?>

<?php
$var = 'hogehoge';
unset($var);

/* is_null($var) === true であり NULL型 が表示される */
if (is_null($var) === true) {
	echo 'NULL型' . '<br>';
} else {
	echo 'NULL型ではない' . '<br>';
}

if (is_null($var) === true) {
	echo 'is_null() は true' . '<br>';
} else {
	echo 'is_null() は false' . '<br>';
}

if (empty($var) === true) {
	echo 'empty() は true' . '<br>';
} else {
	echo 'empty() は false' . '<br>';
}

if (isset($var) === true) {
	echo 'isset() は true' . '<br>';
} else {
	echo 'isset() は false' . '<br>';
}
?>

未定義値

※1 Warningが発生する（PHP Notice: Undefined variable）

<?php
$var = 'hogehoge';
unset($var);

/* is_null($var) === true であり NULL型 が表示される */
if (is_null($var) === true) {
	echo 'NULL型' . '<br>';
} else {
	echo 'NULL型ではない' . '<br>';
}

if (is_null($var) === true) {
	echo 'is_null() は true' . '<br>';
} else {
	echo 'is_null() は false' . '<br>';
}

if (empty($var) === true) {
	echo 'empty() は true' . '<br>';
} else {
	echo 'empty() は false' . '<br>';
}

if (isset($var) === true) {
	echo 'isset() は true' . '<br>';
} else {
	echo 'isset() は false' . '<br>';
}
?>

NAN（not a number）

コールバック（callable）

キャスト（型の相互変換）

PHPは変数宣言時に明示的な型定義を必要としない（動的型付け言語）である。変数の型は保存する値によって決まる。

$var に 文字列を代入すれば $var は String型になり、$var に 整数を代入すれば $var は int型になる。$var に 文字列を代入後、整数を代入すれば $var は int型になる。

変数を強制的に特定の型に変換したい場合は、キャストすることで特定の型に変換できる。

<?php
(int)			整数
(integer)		(int)と同義。非推奨
(bool)			真偽値
(boolean)		(bool)と同義。非推奨
(float)			浮動小数点数
(double)		(float)と同義。非推奨
(real)			(float)と同義。非推奨。PHP 8.0.0で削除
(string)		文字列
(array)			配列
(object)		オブジェクト
(unset)			NULL値
(binary)		バイナリ文字列（PHP5.2.1～）
?>

PHPのクラス

インスタンスの生成

インスタンスは new 命令を使用し生成する。

<?php
class MyClass {
}

$mycls = new MyClass();	/* クラスのインスタンスを生成 */
?>

クラスのプロパティ、メソッドのスコープ（アクセス修飾子）

1. public
   クラス内、クラス外のどこからでもアクセス可能。※アクセス修飾子の省略が可能（アクセス修飾子を記述しない場合は自動的にpublicとして扱われる。「可読性」「メンテナンス性」を担保するため public は必ず記述する）。
2. private
   宣言したクラス内のみアクセス可能。
3. protected
   クラス内と、そのクラスの親クラス、継承した子クラスからのアクセスが可能。
4. static
   クラスのインスタンス化なしでアクセス可能。
5. アクセス修飾子なし
   全て public になる。

private プロパティ

private で宣言したプロパティ、メソッドは、宣言したクラス内のみアクセス可能である。

以下のコードは、クラス内で private $name を宣言し、クラス内のメソッドから $this->name で アクセスしている。

重要なポイントは、クラスのプロパティである $this->name と、クラスのメソッド内（引数）で定義した ローカル変数 $name を使い分けている点だ。

同じ名前の変数（$name）でも、プロパティとメソッド内のローカル変数は別の扱いとなる。

※ $this->name は オブジェクトのプロパティだが、$this->$name は 可変プロパティ になるので注意が必要。

Java、C#などの厳格な言語仕様のプログラミング言語と比較し、PHPは言語仕様書がなく、公式ドキュメント（PHP Manual）や実際の動作（挙動）が事実上の仕様として扱われてきた歴史を持っている。

$this->$name に似たような記述は、バグの温床になるので、厳格な言語仕様のプログラミング言語ではできない（コンパイルエラー）。

<?php
class MyClass {
	private $name;	/* private変数を定義 */

	function setName($name) {
		$this->name = $name;	/* private変数 $name に setNameの引数 $name の内容を代入*/
					/*
					$thisはクラス内のプロパティやメソッドにアクセスできる。

					$this->name = $name の左辺の $this->name は
					クラス冒頭で定義された private $name を指している。

					$this->name = $name の右辺の $name は
					function setName($name) 引数 $name を指している。
					*/
	}
	function getName() {
		return $this->name;	/* private変数 $name の値を返す */
	}
}

$mycls = new MyClass();		/* クラスのインスタンスを作成 */
$mycls->setName('hogehoge');	/* setName()メソッドに値を設定する */
echo $mycls->getName();		/* getName()メソッドで値を取得し出力する */
?>

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. # は // と同様。

Javaのコメント

Javaのコメントは、/* */（複数行）、//（単行） の2つの書き方がある。この他に /** */ とすることで Javadoc 用のコメントを記述できる。

1. /* */ は /*をコメント開始タグ、 */ をコメント終了タグとして認識し、タグの内側をコメントとして認識する。

   単行記述 例
   /* コメントを書く */
   
   複数行記述 例
   /*
   　　コメントを書く
   */
   
   /*
    *　　コメントを書く
    */
   

2. // は // から改行までをコメントとして認識する。

   記述 例
   // コメントを書く
   

Javadocのコメント

/** */ は Javadoc（ジャバドック） と呼ばれ、メソッドの引数や戻り値の意味を記述するために使う。

これを書くことで、HTML形式のAPIドキュメントを生成したり、開発ツール（Eclipseなど）上でマウスを置いた時に説明文がポップアップ表示されるようになる。

基本コマンド
コマンドプロンプトやターミナルで、ソースファイルがあるディレクトリに移動して実行する。

-d doc: 生成されたHTML群を doc というディレクトリに出力する指定（ディレクトリ名は自由に変更可能）。

[ソースファイル名.java]: 対象となるJavaファイルを指定する。*.java とすればカレントディレクトリ内の全ファイルを対象にできる。

javadoc -d doc [ソースファイル名.java]

オプション
パッケージ単位で出力指定する。

-sourcepath でソースのルート（srcなど）を指定し、-subpackages で対象のパッケージ名を指定する。

javadoc -d doc -sourcepath src -subpackages com.example

エンコーディングの指定（文字化け対策）
ソースが UTF-8 で書かれている場合、これを指定しないと文字化けすることがある。

javadoc -d doc -encoding UTF-8 -charset UTF-8 [ファイル名]

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

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

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

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

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

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

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

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

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

例外処理

PHPの例外処理は try catch finally を使用する。

try{} ブロック内でエラー（Exception）を捕捉し、catch{} ブロックで発生したエラーをどのように処理するか記述する。finally{} ブロックはエラーの発生を問わず必ず実行される。

throw は意図的に意図的に例外を発生する。

try catch finally throw の仕様

1. try
   try句は、try{} ブロック内で発生した例外（Exception）を捕捉する。必ず catch か finally（あるいは両方）を伴わなければならない。
2. catch
   try句 で例外（Exception）が発生すると catch句 にスローされる。catch句では例外をどのように処理するか記述する。
   例外の型ごとに複数記述でき、上から順に評価される。
3. finally
   例外（Exception）がスローされたかどうかに関わらず必ず実行される。
   return 命令が try{} または catch{}、あるいはその両方に存在した場合、return 命令は出現したときに評価されるが、finally{} ブロックは return 命令の実行前に実行され、finally{} ブロック実行後に return 命令は実行される。
   return 命令が try{} または catch{}、あるいはその両方に存在し、finally{} にも存在した場合、return 命令は出現したときに評価されるが、finally{} ブロックは try{} または catch{} の return 命令の前に実行され、finally{} ブロックの return 命令が実行される。
4. throw
   意図的に例外を発生（スロー）させる。これ以上処理を継続できない場合や、上位層に例外を報告したい場合に使用する。

例 PHP try catch finally

try {
	// 例外が発生する可能性のある処理
} catch (PDOException $e) {
	// データベース関連（JavaのSQLException相当）のエラー処理
	echo "DBエラーが発生しました。";
} catch (TypeError $e) {
	// 型の不一致など特定のエラー処理
	echo "型エラーが発生しました。";
} catch (Exception $e) {
	// それ以外の予期せぬエラー（JavaのException相当）の共通処理
	echo "予期せぬエラーが発生しました。";
} finally {
	// 最後に必ず実行する処理（PHP 5.5以降で使用可能）
}

例 Java try catch finally

try {
	// 例外が発生する可能性のある処理
} catch (ClassNotFoundException e) {
	System.err.println("JDBCドライバが見つかりません。");
} catch (SQLException e) {
	System.err.println("DB操作エラーが発生しました。");
} catch (Exception e) {
	System.err.println("予期せぬエラーが発生しました。");
} finally {
	// finally句は処理の try句、catch句が実行された後に必ず実行される
}

詳しくは Java try catch finally の仕様 を参照。

throw 意図的に例外を発生する

throw は意図的に例外を発生することができる。

<?php
throw new Exception('意図的にエラーを発生する');
?>

<?php
try {
	throw new Exception('意図的にエラーを発生する');
} catch(Exception $e) {
	echo $e;	/*「意図的にエラーを発生する」が出力される */
}
?>

try catch finally による例外処理

次のサンプルコードでは、try{} ブロック内で function func() を呼び出し、func() で throw 命令を使い意図的にエラーを発生させている。

func() 内で発生したエラーは、呼び出し元の try{} ブロック で捕捉され、catch{} ブロックが実行される。

<?php
function func() {
	try {
		throw new Exception('意図的にエラーを発生する');
	} catch(Exception $e) {
		echo $e;	/*「意図的にエラーを発生する」が出力される */
	}
}

func();		/* funcを呼び出し */
?>

深い階層で発生したエラーの例外処理

次のサンプルコードでは、try{} ブロック内で function func() を呼び出し、func() 内で function sub_func() を呼び出し、sub_func() で throw 命令を使い意図的にエラーを発生させている。

func()、sub_func()には try catch による例外処理は記述しておらず、func() の呼び出し元に try catch による例外処理を記述している。

sub_func() 内で発生したエラーは、呼び出し元の func() に投げられ、最終的に func() の呼び出し元の try{} ブロック で捕捉され、catch{} ブロックが実行される。

PHPにはJavaのような、throws Exception 命令（呼び出し元にエラーを投げる命令）はないが、try catch を書かない事で throws Exception と同様のことができる。

<?php
function func() {
	sub_func();	/* sub_funcを呼び出し */
}

function sub_func() {
	throw new Exception('意図的にエラーを発生する');
}

try {
	func();		/* funcを呼び出し */
} catch(Exception $e) {
	echo $e;	/*「意図的にエラーを発生する」が出力される */
}
?>

try catch finally を使用したデータベース接続サンプル

<?php
/**
* MySQLに接続する
* 
* MySQLに接続する
*
* @version 1.0 
* @author hoge
* @param &$pdo MySQLに接続するコネクションオブジェクト
* @return true：正常　false：異常 （Insert失敗）
* @throws Exception なんてPHPにはねぇよ
*/

/* PHP 7.0.0 以降で使用します。 */
function connectMySql(&$pdo) {

	global $printDebugMode;
	$printDebugMode = false;

	print("");
	print("▼　function MySQL 接続（connectMySql） ------------------------------");

	/* MySql 接続情報 */
	$host = "mysql0000.db.hogehoge.jp";
	$db = "db_name";
	$user = "db_user";
	$pass = "db_pass";
	$dsn = "mysql:host={$host};dbname={$db};charset=utf8mb4";

	/* tryにPDOの処理を記述 */
	try {
		/* PDOインスタンスを生成 */
		$pdo = new PDO($dsn, $user, $pass);
		$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
		$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
		print("データベース {$db} に接続しました。");

	/* エラー（例外）が発生した時の処理を記述 */
	} catch (PDOException $e) {
	 
		/* エラーメッセージを表示する */
		print('データベースの接続に失敗しました　mysql_error = ' . $e->getMessage());
		return false;
	} finally {
		print("▲　function MySQL 接続（connectMySql） ------------------------------
");
	}
	return true;
}

/*
 * MySQLに接続する
 * @param &$connection MySQLに接続するコネクションオブジェクト
 * @return true：正常　false：異常 （Insert失敗）
 * @throws Exception なんてPHPにはねぇよ
 */

/* PHP 7.0.0 で削除されました。 */
function old_connectMySql(&$connection) {

	print("");
	print("▼　MySQL 接続（connectMySql） ------------------------------");

	/* MySql 接続情報 */
	$url = "mysql0000.db.hogehoge.jp";
	$db = "db_name";
	$user = "db_user";
	$pass = "db_pass";

	/* MySQLへ接続 */
	$connection = mysql_connect($url,$user,$pass);
	if ($connection === false) {
		print('データベースの接続に失敗しました　mysql_error = ' . mysql_error());
		print("▲　MySQL 接続（connectMySql） ------------------------------");
		print("");
		return false;
	}
	/*
	こんな書き方もできます。dieはその場で実行をphpの実行を止めます。  ※正直、美しいコードとは言えません。
	$connection = mysql_connect($url,$user,$pass) or die("MySQLへの接続に失敗しました");
	*/

	/* データベースを選択する */
	$rtn = mysql_select_db($db, $connection);
	if ($rtn === false) {
		print('データベースの選択に失敗しました　mysql_error = ' . mysql_error());
		mysql_close($connection);
		print("▲　MySQL 接続（connectMySql） ------------------------------");
		print("");
		return false;
	}
	/*
	 *	こんな書き方もできます。
	 *      　※汚いコードです。なにより、$connectionの開放をしていません。
	 *        ※PHPでは、die実行時に、自動的にデータベースとの接続を切断するそうです。
	 *          が、PHP側で切断しても、DB側で切断を感知して、自動でコネクションを開放する仕組みになってないと、コネクションは掴みっぱなしになります。
	 */
	/* $rtn = mysql_select_db($db, $connection) or die("データベースの選択に失敗しました"); */

	print("データベース接続に成功しました。");
	print("▲　MySQL 接続（connectMySql） ------------------------------");
	print("");
	return true;
}
?>

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 だ。

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

プログラミングスクールでは教えてくれない「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ではないので時間がかかる。

2. 速読
   

   動画でも「早送りで見る」「飛ばしながら見る」こともできるが、紙の本での速度の方が速い。

3. 再読（理解できない場合など）
   

   動画は「聞き洩らし」「一度は理解できない」場合、もう一度戻って見なければならない。
   本でも一度読んでも理解できない場合、再度読み直すが、目線を動かし読むだけ。

4. 説明を読みながら作業
   

   本を開いて内容を確認しながら手を動かすのは簡単。
   動画を見ながら手を動かすのは、本よりやや難しい。動画は勝手に進むため、ここで止めたいと思っても進んでしまう。

5. 1ページの情報量
   

   動画とか紙では一度に入ってくる情報量に大きな差が出る。
   本は図表などを1ページに押し込めて、効率的に把握・理解できる。動画ではできない。

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

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

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

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

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

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

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

脳の良し悪しはあるが、コーディング（プログラミング）程度なら早慶レベルの理工学部の現役大学生は、技術書のみで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月14日運営者情報 ご質問はこちらへお願いします info@e-elder.jp