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

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

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

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

目次

PHP

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. ミニファイ（コードの圧縮）を行う場合のコメントは全て /* */ で記述する
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

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

プログラミングスクールでは教えてくれない「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ページに押し込めて、効率的に把握・理解できる。動画ではできない。

   特に設計書は、紙は十分な情報量を記述できるので理解・説明しやすい。動画では難しい。
   動画で設計書全体が見れるようにすると、文字や図表が小さく見えなくなる。

   紙の設計書なら普通にできることが、動画では全くできなくなる。

6. 操作説明など
   

   動画が本より優れているのは、操作説明など画面の変化を説明する場合だ。動画では画面の状態変化をすべて記録し配信できるが、本は部分的になりがちだ。

   説明したい一連の操作を動画にすると、本より圧倒的にわかりやすい。

   昔の技術書やマニュアルは不親切で不明点が多かった。Solarisの再インストールに関する説明が保守資料にまったくなかったので、SUNの技術者を呼びかSolarisのインストールをビデオ録画した経験がある。完全再現するために動画は特に有効だ。

   書籍で同様のことをすると、画面の状態変化と同じ数のスクリーンショットが必要になる。 文章で説明すると文章量も多くなる。すべて画面変化をスクリーンショットで取り文章化するのは現実的ではない。

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

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

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

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

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

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

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

脳の良し悪しはあるが、コーディング（プログラミング）程度なら早慶レベルの理工学部の現役大学生は、技術書のみで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を使えるように内容を構成した独学向け学習サイト。不要な基礎はバッサリ切り捨て必要な基礎を十分に深堀した・・・  続きを見る