Uncategorized

はじめに 開発者なら言わずもがなReactは知っている方がほとんどかと思います。Stateで直感的かつ簡潔に状態管理を行うことができ、その際のDOMの更新もReactがよしなにやってくれます。開発者はdocument.getElementById(xxx)などを使って冗長なHTMLの取得・更新・削除まで気にかける必要はありません。外部APIの呼び出しといった副作用もReactのuseEffectを使えば、開発環境では二回呼び出し(間にクリーンアップ関数実行)までデフォルトで確認できるなど使いやすさも素晴らしいです。しかしながら、なぜNext.jsが登場し、それが多くの開発者に親しまれているのでしょうか?今回はReactとNext.jsを比較し、Next.jsのメリットを簡潔におさらいしようかと思います。 ReactとNext.jsのちがい Reactは基本的にCSR(Client-Side Rendering)のみ ReactはCSRのみです。これはつまりブラウザ側でJavaScriptを実行し、DOMを生成するため その処理はすべてユーザー側(ブラウザ)の負担となり表示速度にも課題が残ります。そして何より、ブラウザでJavaScriptをOFFにしていたら、何も表示されません。。。(あるサイトで調べたところ1%ほどはJavaScript無効でブラウザを利用しているユーザーが居るようです。)また、React単体だとSPAとしては勝手が良いのですがルーティングに課題があります。 Next.jsはルーティング機能にCSR&SSR&SSGにも対応 ルーティング Next.jsはルーティング機能を提供しています。src/app/{xxx}/page.tsx を生成するだけで、http://domain.com/{xxx} へのルーティングの設定は完了します。また、動的ルーティングにも対応しており ブログ記事など 動的コンテンツも簡単に実装することができます。 プリレンダリング Next.jsはReactの速度面でのデメリットを解決するため、基本的にページのプリレンダリングを実行します。これはあらかじめ最小限のHTMLを作っておき、その後JavaScriptが読み込まれて、ボタンの押下や送信といった操作できる状態となります。速度改善だけではなく、SEOにもメリットがあります。 CSR (Client-Side Rendering) Reactと同じ動きです。ユーザーのブラウザでのみ処理が行われ、初回表示は遅いのですがその後は高速に動作します。 SSR (Server-Side Rendering) これはサーバーサイドでHTMLをレンダリングすることです。Nodeが実行できる環境のみ可能です。サーバーサイドで処理してからクライアントへ返すのでオーバーヘッドが発生しますが、それでも最新の情報を常に返すようなページに向いてます。 SSG (Static Site Generation） 静的なページであれば、予めHTMLを生成しておくことで速度をかなり向上させることができます。SSGでビルド後に生成されるのは静的なHTML/CSS/JavaScriptファイルなので、Node.jsが使えないサーバー環境でもそのまま公開できます。例えば、日本で人気のレンタルサーバーであるXserverではnodeがサポートされていません。そのようなケースでも使えるのは大きな強みですね。 SSGとCSRを組み合わせるメリット 上述したSSGとCSRを組み合わせることでページごとに戦略を選べることが大きなメリットになります。例えば、コーポレートサイトを考えたとき TOPページや会社概要のページは静的なページですのでSSGが選択できます。これによって表示速度の恩恵を受けることができ、SEO的な観点でもメリットがあります。そして、コーポレートサイトの管理画面ではSSRを採用することで、記事投稿といった機能において最新の情報の取得や更新処理などを実装できます。このように一つのフレームワークで複数のレンダリング戦略を選択できるのはNext.jsのとても強力なメリットとなってます。 まとめ 今まで紹介した通り、Next.jsには以下のような特徴があります。 興味のある方はぜひご自身でもNext.jsを触ってみてください✨️この記事を読んでなにか皆さんの役に立てると嬉しいです..! では!

はじめに データベースの設計は基本設計の中でもかなり重要な工程です。特にデータの構造によってアプリケーションが決まるため、データベース設計での失敗をアプリケーションで改善することはできません。今回は『達人に学ぶDB設計徹底指南書』で指摘されているアンチパターンをピックアップして紹介します。 アンチパターン 非スカラ値の格納(第一正規形未満) 【症状】第一正規形はデータベースの原則である、テーブルに含まれるすべての値がスカラ値であるという原則を無視した「複数の値」をセルにいれること 【なぜ起こるか?】開発者がRDBに柔軟なデータ型が欲しくなり、実装してしまった…など 【問題点】 【対策】 ダブルミーニング 【症状】value カラムには「身長」と「体重」の両方入っている 【なぜ起こるか?】途中からvalueカラム(身長)が不要となり、「体重」が必要となったため、列の使い回ししたくなった…など 【問題点】 【対策】 単一参照テーブル 【症状】部署や会社といった別の意味を持つものを構造的に似ているということで一つのテーブルにまとめてしまう。 【なぜ起こるか?】数百テーブルがある状況において、同じ構造を持ったテーブルを一つのテーブルにまとめることで効率化を図った…など 【問題点】 【対策】 テーブル分割 水平分割 【症状】レコード単位でテーブルを分割してしまうこと例えば2010年用のテーブルと2011年用のテーブルなど、、、業務系のトランザクションテーブルに多い 【なぜ起こるか?】何百万〜何十億とレコードが積み重なったときI/Oコストの増大が発生し、そのパフォーマンス改善を狙って分割してしまう 【問題点】 【対策】 垂直分割 【症状】列を軸にテーブルを分割してしまうこと例えば、社員テーブルを「社員ID・年齢」と「社員ID・名前・部署コード」といった形で分割してしまう。 【なぜ起こるか?】I/Oがボトルネックになったときのパフォーマンス改善として、実装されてしまう。 【問題点】 【対策】 最後に これまで紹介させていただいたアンチパターンは、自分自身も実際に現場で目にした例も多かったです。そして、バックエンドエンジニアとして業務経験が浅かった頃は、1列に集約関数実行後の値をjson文字列で格納した変なサマリーテーブルを作ったことも有りました。。。そのような実装をしてしまう前にアンチパターンを知っておくことで事故を防ぎ、今後の保守や運用の効率が上がって行くかと思います。この記事が少しでも皆さんの設計のヒントになれば嬉しいです！ 参考文献

はじめに プログラミング言語の中でも、Go言語（Golang）は比較的新しい言語でありながら注目度を高めています。その背景には高い保守性と柔軟なコード設計を支える独特の言語仕様があると考えられます。 本記事では、PHPと比較しながらGo言語の設計思想を解説していきます。メソッドの定義方法、継承と合成の違い、そしてポリモーフィズムの実現方法を具体的なコード例とともに取り上げ、オブジェクト指向経験者でも理解しやすい形でGoの特徴を掘り下げます。 Go言語の最大の特徴とは？ 多くのオブジェクト指向言語では、クラスを定義し、それを継承して機能を拡張します。一方、Goにはクラスや継承の概念がありません。その代わりに「構造体（struct）」と「インターフェース」を組み合わせてプログラムを設計します。 この設計により、以下のような利点があります。 構造体とは？ Goの構造体の説明に入る前に、まず以下のGoで書かれたコードに注目してください。 Go言語では、他の言語と同じようにデータを扱うときは変数を使うことが可能です。ここでは太郎さんの身長と年齢の情報を用意し、年齢を標準出力しています。 ただ、以上のような例では太郎さんの身長と年齢が個別の変数で定義されているため、データをまとめて管理することが難しくなります。このような問題に対して、Goでは「構造体」を使うことでバラバラのデータを1つにまとめることができます。 このように、Goの構造体は「複数の値を1つにまとめる」仕組みです。PHPのクラスに似た役割を果たします。 ここまでを踏まえて、Goの構造体とPHPのクラスの共通点をまとめると以下のようになります。 構造体とクラスの共通点 また、Goの構造体とPHPのクラスの違いをまとめると以下のようになります。 構造体とクラスの相違点 PHPのクラス Goの構造体 メソッドの定義方法 クラスの中で定義する クラスの外で定義する コードの再利用方法 継承 埋め込み(合成) ポリモーフィズムの実現方法 インターフェースを明示的に実装 インターフェースを暗黙的に実装（メソッドが一致すればOK） 次章からは、この「メソッドの定義方法」、「コードの再利用方法」、「ポリモーフィズムの実現方法」それぞれについてより詳しく解説していきます。 PHPとGoのメソッド定義方法の違い PHPではクラス内にメソッドを定義します。一方、Goでは構造体の外でメソッドを定義して紐づけます。 この違いはコードの依存関係や再利用性に大きな影響を与えます。Goの方法は疎結合を実現しやすく、保守性が高まります。以下にPHPのクラスとGoの構造体それぞれのメソッド定義方法を紹介します。 両者とも「名前を持つユーザーを表現」し、greet メソッドで挨拶を返すという共通点があります。ただし、Goでは メソッドを構造体の外に定義して紐づけるのが特徴です。 コードの再利用方法の違い ― 継承と合成 PHPの場合 PHPでは継承によって親クラスの機能を子クラスに引き継ぎます。しかし、継承は親クラスの変更が子クラスに波及しやすいため、保守が難しくなることがあります。 Goの場合 Goでは構造体に別の構造体を埋め込む「合成（埋め込み）」を使って構造体同士を組み合わせます。必要な機能だけを柔軟に取り込めるため、より保守しやすい設計が可能です。 継承は便利な反面、親クラスの変更が子クラスに波及しやすく保守性が下がることがあります。Goの「合成」は必要な機能だけを組み合わせるため、変更の影響範囲を限定でき、保守しやすいのが利点です。 ポリモーフィズムの実現方法の違い ― 明示的 vs. 暗黙的な実装 PHPの場合 PHPではインターフェースを明示的に実装しなければなりません。 Goの場合 Goでは暗黙的にポリモーフィズムを実装できます。構造体のメソッドがインターフェースのメソッドと一致していれば、構造体は自動的にインターフェースを実装したことになるため、コードをシンプルに保ちながら柔軟性を確保できます。 この仕組みにより、開発者は「インターフェースを実装している」ことを明示しなくても自然にポリモーフィズムを実現できます。結果として疎結合なコードが書きやすく、テストや再利用の柔軟性が向上します。 Go言語の最大の特徴 改めてGoの構造体とPHPのクラスの違いをまとめます。 構造体とクラスの相違点 PHPのクラス

オフショア開発は、コスト削減やIT人材不足の解消に有効な手段として注目されています。しかし、言語や文化の壁といった特有の課題もあり、どのような業務を委託すべきか判断に迷うケースも少なくありません。 オフショア開発の効果を最大限に引き出すためには、その特性を理解し、適したプロジェクトを見極めることが重要です。 本記事では、オフショア開発が適しているプロジェクトや分野の具体的な特徴について、詳しく解説します。 オフショア開発とは？ オフショア開発とは、システム開発やソフトウェア開発といった業務を、海外の企業や現地法人へ委託する開発手法です。コスト削減やリソース確保などを目的として、海外の比較的安価な労働力を活用することが特徴です。 国内のIT人材不足が課題となる中で、有効な解決策の一つとして注目されています。主な委託先にはベトナムやフィリピンなどがあり、国内の地方都市へ委託するニアショア開発とは区別されます。 オフショア開発のメリット・デメリット オフショア開発の大きなメリットは、開発コストを削減できる点や、国内で不足するIT人材を確保できる点です。人件費が比較的安い海外のエンジニアに委託することで、プロジェクト全体の費用を抑えることが可能です。 一方で、言語や文化、商習慣の違いからコミュニケーションが円滑に進まず、品質の低下を招くリスクがデメリットとして挙げられます。また、時差によるリアルタイム連携の難しさや、為替変動によるコスト増のリスクも考慮する必要があります。 オフショア開発が適しているプロジェクトとは？ オフショア開発は、どのようなプロジェクトにも適しているわけではなく、その特性を生かせる場合に大きな効果を発揮します。コスト削減効果を大きく引き出すためには、委託するプロジェクトがオフショア開発に向いているかを見極めることが重要です。ここでは、オフショア開発に適したプロジェクトが持つ具体的な特徴を解説します。 大規模なプロジェクト 開発工数が多く、長期間にわたる大規模なプロジェクトは、オフショア開発に適しています。開発規模が大きくなるほど、国内との人件費の差によるコスト削減効果が大きくなるためです。 例えば、大規模なWebシステムや業務システムの開発は、多くのエンジニアを必要とするため、そのメリットを実感しやすいでしょう。継続的に作業が発生するプロジェクトも、コストメリットを享受しやすいためオフショア開発に向いています。 環境に依存しないプロジェクト 特定の物理的な環境に依存しない、ソフトウェア開発などのプロジェクトもオフショア開発に向いています。ソフトウェア開発などの分野は世界的に技術仕様が標準化されているため、海外拠点でも国内と同様の開発環境を構築しやすいためです。 業務で用いるアプリケーションなどが、この種のプロジェクトの代表例です。場所の制約を受けずに、スムーズな開発が期待できるでしょう。 ロジックがシンプルなプロジェクト ロジックがシンプルで、仕様が明確に定まっているプロジェクトもオフショア開発に向いています。要件が複雑でないため、言語や文化の壁を越えても開発者間の認識のズレが起こりにくいためです。仕様の誤解による手戻りのリスクが少なければ、プロジェクトを計画通りに進めやすくなるでしょう。 マニュアル化しやすいデータ入力や、手順が決められたテスト作業といった定型業務も同様の理由で適しています。 現地でも馴染みのあるプロジェクト ECサイトやSNSなど、海外のエンジニアにとっても馴染み深いサービスの開発は、オフショア開発に適しています。ECサイトやSNSなどのサービスは世界的に普及しているため、開発者がビジネスモデルや基本的な機能を理解しやすいからです。プロジェクトの全体像を把握しやすくなることで、仕様の誤解から生じる手戻りのリスクが減少します。文化的な背景に依存する特殊な要件が少ないプロジェクトほど、円滑な開発が期待できるでしょう。 オフショア開発が適している分野 Webシステムやアプリ開発、システムの運用・保守など、オフショア開発の適用範囲は多岐にわたります。ここでは、オフショア開発が特に適しているとされる具体的な分野とその理由を解説します。 Webシステム開発 Webシステム開発は、オフショア開発が活用される代表的な分野の一つです。その背景には、開発に必要な技術仕様が世界的に標準化されており、海外のエンジニアでも開発を進めやすいという特徴があります。 具体的な例としては、ECサイトやマッチングサイト、SNS、業務システムなどの開発が挙げられます。いずれのシステムも基本的な構造がある程度定まっているため、オフショア開発に向いているでしょう。 アプリ開発 モバイルアプリ開発も、オフショア開発で広く活用されている分野です。iOSやAndroidといったプラットフォームは世界共通であり、開発に必要な技術仕様も標準化されているためです。これにより、海外のエンジニアでも国内と遜色ない品質での開発が期待できます。 開発会社によっては、UI/UXデザインの設計段階から開発までを一貫して委託することも可能です。 AI開発 AI開発の分野においても、オフショア開発の活用が進んでいます。特に、AIモデルの学習に不可欠な大量のデータ収集や、画像データに情報を付与するアノテーション作業といった工程がその対象です。データ収集やアノテーション作業は多くの人手を必要とする労働集約的な業務であるため、オフショア開発によるコスト削減効果が期待できます。 また、国内では確保が難しいAI専門のエンジニアを、海外の豊富な人材から見つけ出す手段としても有効です。 システム運用・保守 システムの運用・保守業務は、オフショア開発に適した分野です。運用・保守業務はマニュアル化しやすい定型作業が中心となるため、海外拠点でも品質を維持しながら効率的に進めることができます。また、日本との時差を活用することで、国内よりも低いコストで24時間365日の監視体制を構築できる点も大きな利点です。 継続的に作業が発生する特性上、人件費削減というメリットを長期にわたって享受できるでしょう。 オフショア開発に適したプロジェクトを見極めよう！ オフショア開発は、コスト削減やITリソース確保の有効な手段です。その効果を大きく引き出すには、大規模なプロジェクトや仕様が明確なものなど、オフショア開発に適した案件を見極めることが重要です。Webシステム開発やアプリ開発、システムの運用・保守といった分野は、特にその特性を活かしやすいでしょう。 株式会社SPでは、日本人プロジェクトマネージャーが全工程を管理し、オフショア開発特有の品質やコミュニケーションの課題を解決に導きます。1000件以上の豊富なプロジェクト実績に基づき、要件定義から開発、運用まで一貫してサポートしていますので、オフショア開発を検討している企業の担当者様は、ぜひお気軽にお問い合わせください。