イー・エルダーが考えるコーディング規約とビジネス進化論【2025年4月】

イー・エルダーが考えるコーディング規約とビジネス進化論【2025年4月】

イー・エルダーが考えるコーディング規約とビジネス進化論 メニュー

• コーディング規約
• ソースコードは英文
• コメントは必ず書く
• コーディング規約とビジネス進化論
  • 進化を続けた恐竜
  • 進化する企業とビジネス
  • GAFAMのコアビジネスは優れた技術によって支えられている
  • GAFAMの巨大資本
  • 中小零細企業やベンチャー企業にとっての資金
• 中小零細企業、ベンチャー企業にとっての資金
• 命名規約
  • プリミティブ型の接頭辞

コーディング規約

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

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

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

大昔、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％使用するツールに沿って記述する必要があり、例外は許してはいけない。

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

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

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

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

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

コーディング規約とビジネス進化論（大恐竜時代とGAFAMのビジネス進化論 恐竜たちの教訓）

大恐竜時代と呼ばれる壮大な時代が地球に存在した。地球はまさに恐竜たちの天下だった。

全長約12メートル、体重6～8トンの屈強なフィジカル、最大時速40キロで走る脚力、立体視が可能な発達した視覚、遠方まで嗅ぎ取る嗅覚、獲物をかみ砕く強靭な顎と最大30センチに及ぶ鋭い歯を武器に、ティラノサウルスは食物連鎖の頂点に君臨した。

最強の捕食者であるティラノサウルスの姿は、現代における「Microsoft」「Google」や「Amazon」「Apple」、GAFAMを彷彿とさせる。

GAFAMも「OSとオフィスソフト」「検索エンジン」「スマートフォン」「モバイルアプリケーション」「クラウドサービス」「イーコマース」などの市場を支配し、圧倒的な競争力を誇る。

GAFAMは強大な技術力と資金、圧倒的なブランド力を武器に、他社の追随を許さず、敵対的買収を繰り返し支配力をさらに拡大し続ける。

進化を続けた恐竜

なぜ恐竜たちは、食物連鎖の頂点に君臨し繁栄できたのか？その秘密は「進化」にある。

恐竜時代初期、地球上には多くの生物が繁栄してた。その中で生き残るためには、ただ大きいだけではダメだった。

環境の変化に応じて、素早さ、強靭さ、視覚、聴覚、嗅覚、触覚などのフィジカルだけでなく、海、陸、空に適応していった。群れで狩りをする恐竜も現れた。

進化のスピードが遅い者もいたが、変化に適応できない者はどの時代も淘汰される。

ブラキオサウルスのように、大きな体で他の動物たちを圧倒していたものの、次第にその力を維持できずに絶滅へと追いやられた。

恐竜の中で最も長く生き残ったのは、トリケラトプスやステゴサウルスなどの草食恐竜たちだ。これらの恐竜は、特に強い武器を持たなくてもニッチな市場で生き延びた。

進化する企業とビジネス

現代ビジネスの世界も同様だ。成功する企業は、ただ資本や規模の大きさだけでなく、迅速に変化を捉え、新たな市場に適応する力を持っている。進化し続けることができなければ淘汰される。

恐竜も「変化に柔軟な者」と「変化を拒む者」がいた。後者は環境の変化に適応できず滅びた。

しかし前者は、変化の中で自らの強みを生かし、新たな形で生き延び、次の世代を築いた。

ブラキオサウルスのように変化できなかった、コダック、ノキア、Kマート、シアーズ、コンパックなどは滅びの道を辿っている。

世界で最初にフィルムを発売し、圧倒的なシェアを誇ったコダックはデジタル化の変化に適応できなかった。デジタルカメラを世界で最初に作っていても、フィルム事業から脱退、変化できなかった。

GAFAMのコアビジネスは優れた技術によって支えられている

グーグルの検索エンジンは、Yahooの人が作業し整備するディレクトリ型検索エンジンから、ロボット型検索エンジンとページランクの算出技術で、他社が追随できない優れた検索エンジンを実現している。

アップルは、音楽を配信するインフラと優れた音楽専用端末のiPodで、CD中心の音楽から音楽配信サービスを実現し、iPhoneで携帯電話からスマートフォンへ携帯通信端末革命を起した。

フェイスブックスは、匿名がデファクトスタンダードのインターネットで世界に、実名で利用するSNSを開発した。

GAFAMの巨大資本

もう1つ、GAFAMが圧倒的な強さを誇るのは、優れた技術力をコアにしたサービスで、業界のデファクトスタンダードになり、圧倒的な資本を手に入れたことで、潤沢な資金を「新たな技術開発」と「買収」に活用していることだ。

特に買収は「事業拡大の買収」「技術補完の買収」「敵対的買収」があるが、資本力がなければできない。

大企業と言っても、GAFAMほどの資本金を持つ企業は少ない。潤沢な経営資金がある企業は一握りだ。

中小零細企業、ベンチャー企業にとっての資金

鳴り物入りのベンチャー企業ならベンチャーキャピタルからの資金調達は可能だろう。多くのベンチャー企業は自己資金で事業を始めているし、運転資金も自己資金だ。

ベンチャー企業と言っても最初は零細企業であり、金融機関は業歴の浅いベンチャー企業への融資などおこなわない。業歴があり、キャッシュフローが健全な中小零細企業の方が銀行融資は受けやすい。

公的支援 信用保証協会

中小零細企業は金融機関から融資を受けるのが比較的難しい。バブル崩壊以降、金融機関は融資に消極的になったためだ。

円滑に融資を受ける最も身近な手段として信用保証協会による信用保証がある。

信用保証協会は信用保証協会法（昭和28年8月10日法律第196号）に基づき設立された公的機関で、全国に51の信用保証協会がある。

中小零細企業が事業に必要な資金を金融機関から借入する際、信用保証協会が保証（信用保証）することで円滑な資金調達を実現している。

信用保証協会の審査

資金使途

信用保証協会の審査では、資金の使用目的が明確である必要がある。事業資金のような大まかな目的では審査に通らない。

引用元 もっと知りたい信用保証 ｜ 一般社団法人 全国信用保証協会連合会

命名規約

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

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

プリミティブ型の接頭辞

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

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

よく使う英単語

よく使う英単語。

おすすめ記事

	コーディング規約 コーディング規約が必要な理由は、だれもが好きなようにコーディングしてしまうと、可読性が極めて低い、読めないソースコードが出来上がってしまうからだ。 大昔、VBで変数に日本語（2バイト）を使ったアホがいたが、こういうアホや、for文のカウンターに、i、j、k、などはよく使用するが、i1、i2、i3・・・・のようなマジで読めないソースコードを書くアホを駆逐する為にコーディング規約は重要だ・・・  続きを見る
	ソースコードは英文 プログラムは英語そのものだ。if、for、switch、do while、public、private、add、get、set、put、trim、claer、remove、などなど。 問題は英語ができない日本人で、英語ができない日本人にとって、forも、ifも、switchも、すべてコマンドとして認識しており、クラス、メソッド、プロパティ、変数もそれぞれ、単なるコード（バーコードようなもの）化してしまう・・・  続きを見る
	コメントは必ず書く どのようなクラス、メソッド、プロパティにもコメントは必ず書く必要がある。コメントの記述ルールもコーディング規約で細かく定義する必要がある。 コメントとは補足と考えているプログラマーもいるが（特に英語ができるプログラマー）、コメントは設計書の一部と考えるべきである・・・  続きを見る
	コーディング規約とビジネス進化論 全長約12メートル、体重6～8トンの屈強なフィジカル、最大時速40キロで走る脚力、立体視が可能な発達した視覚、遠方まで嗅ぎ取る嗅覚、獲物をかみ砕く強靭な顎と最大30センチに及ぶ鋭い歯を武器に、ティラノサウルスは食物連鎖の頂点に君臨した。 最強の捕食者であるティラノサウルスの姿は、現代における「Microsoft」「Google」や「Amazon」、GAFAMを彷彿とさせる・・・  続きを見る
	命名規約 プログラムの製造（開発）における命名規約は、可読性を担保するために必須の規約だ。 たとえば、変数がプリミティブの場合、変数の前に接頭辞をつける・・・  続きを見る