広告です。クリックいただけると励みになります。

人気記事(昨日)

    2025年12月28日

    ドメイン駆動とは、何がどうなっているの?

    charles-forerunner-3fPXt37X6UQ-unsplash.jpg

    質問

    ドメイン駆動とは、何がどうなっているの?


    解答

    「ドメイン駆動設計(Domain-Driven Design、DDD)」は、ソフトウェア開発における複雑な業務システムを効率的に作るための設計手法です。
    ざっくり言うと、

    「業務(ドメイン)の理解を中心に、コード・設計・チームの言語を一貫させることで、複雑さを管理する方法」

    です。


    1. 「ドメイン」とは?

    • ドメイン = ソフトウェアが解決する対象の業務領域

    • 例:

      • ECサイトなら → 注文、在庫、配送、決済

      • 銀行システムなら → 口座、振込、利息計算

    → DDDでは、まずこの「業務の世界」を正しく理解することがスタートです。


    2. ドメイン駆動設計で何がどうなるのか?

    (1) ユビキタス言語で統一される

    • 開発者と業務担当者が共通の言葉で会話・コード化する

    • 例:注文を「Order」、承認済み状態を status = APPROVED と統一

    • → コミュニケーションミスが減る


    (2) コード構造がドメインに沿う

    • 業務の概念がそのままコードに反映される

    • 例:

      • クラス:Order, Customer, Payment

      • メソッド:approve(), cancel(), ship()

    • → コードを見れば業務の仕組みが理解できる


    (3) 複雑なシステムを分割できる

    • **境界づけられたコンテキスト(Bounded Context)**という単位で分割

    • 例:

      • 注文管理コンテキスト

      • 配送管理コンテキスト

      • 支払い管理コンテキスト

    • → 各チームが独立して開発・運用でき、衝突を減らす


    (4) 業務ルールが中心にある

    • ただのデータベース操作やCRUDではなく、業務上の振る舞いをコードに反映

    • 例:

      • 「在庫がない場合は出荷できない」というルールを Order.ship() に実装

    • → バグが減り、仕様変更にも強い


    3. DDDが解決する課題

    • 業務が複雑で、単純なデータ中心設計だと混乱する

    • ビジネスルールが変更されるたびにコードが壊れやすい

    • チーム内・開発者と業務担当者のコミュニケーション齟齬が多い

    → DDDでは、業務中心・言語統一・境界の明確化でこれを解決


    4. 図にすると(簡略版)

    [業務(ドメイン)]       │       ▼[ユビキタス言語で共通化]       │       ▼[ドメインモデル(コード)]       │       ▼[境界づけられたコンテキストでチーム分割]

    まとめ

    • ドメイン駆動設計 = 業務を中心に据えて設計する開発手法

    • メリット:

      1. コミュニケーションが統一される

      2. コードが業務に忠実になる

      3. 複雑なシステムでも変更に強い





    関数型ドメインモデリング ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう【電子書籍】[ Scott Wlaschin ]

    価格:3740円
    (2025/12/9 23:26時点)
    感想(0件)


    プロフェッショナルWebプログラミング Django【電子書籍】[ 田中 潤 ]

    価格:3520円
    (2023/12/6 22:41時点)
    感想(0件)


     



    ブログランキング・にほんブログ村へ
    【下記、広告です。クリックいただけると励みになります。】
    posted by モニー at 18:00| Comment(0) | アプリ開発 | このブログの読者になる | 更新情報をチェックする

    2025年12月13日

    コンウェイの法則とは

    europeana-udSClwyJF9Y-unsplash.jpg

    質問

    コンウェイの法則とは何?


    解答

    「コンウェイの法則(Conway’s Law)」は、1968年にメルヴィン・コンウェイが提唱した、

    組織構造と作られるシステム構造の関係に関する法則です。簡単に言うと、


    「組織が設計するシステムや製品の構造は、その組織のコミュニケーション構造に似る」

    というものです。


    1. 具体例

    • 会社が3つのチームに分かれて開発している場合:

      • フロントエンドチーム

      • バックエンドチーム

      • データベースチーム

    → 作られるシステムも3つの独立したモジュールに分かれる傾向がある。

    • チーム間のコミュニケーションが少なければ:

      • モジュール同士の連携が複雑になったり、統合が遅れやすくなる。


    2. ポイント

    1. 組織構造が設計に反映される

      • 人間のコミュニケーションパターンが、ソフトウェアやシステム構造に自然に影響する。

    2. 間接的な影響が大きい

      • 技術的に最適な設計よりも、組織のチーム分けや責任範囲に従った設計になることが多い。

    3. 組織改善がシステム改善につながる

      • チームの連携や情報共有を改善すると、システム構造も改善されやすい。


    3. 実務上の示唆

    • マイクロサービス設計と関係が深い

      • チームを小規模で独立させると、システムも自然に独立したサービス構造になる。

    • 組織再編の影響を意識する

      • 大規模プロジェクトでチームを分けすぎると、モジュールが増えすぎて複雑になる。

    • 設計とコミュニケーションを同時に考える

      • 技術的に最適な構造を作りたい場合は、組織構造やコミュニケーションも調整が必要。


    まとめ

    • コンウェイの法則 = 「組織のコミュニケーション構造は、作るシステムの構造に反映される」

    • ソフトウェアや組織運営の設計において、人の構造と技術の構造が密接に関連することを示す法則




    読みやすいコードのガイドライン 持続可能なソフトウェア開発のために

    価格:2750円
    (2025/12/9 23:28時点)
    感想(0件)


    ギガ速FX 月の手取り439万円を獲得したゾーントレードの極意【完全無修正】 [ リオン ]

    価格:1980円
    (2023/11/19 13:25時点)
    感想(2件)


     



    ブログランキング・にほんブログ村へ
    【下記、広告です。クリックいただけると励みになります。】
    posted by モニー at 15:00| Comment(0) | アプリ開発 | このブログの読者になる | 更新情報をチェックする

    2025年12月03日

    ミドルウェアとは、どういうものをいいますか?

    elias-maurer-wa-ktwemeT4-unsplash.jpg

    質問

    ミドルウェアとは、どういうものをいいますか?
    ソフトウェアとハードウェアから見て、どのようなものですか?


    解答

    ミドルウェアは、ハードウェアとアプリケーションソフトウェアの中間に位置するソフトウェア層のことを指します。
    簡単に言えば、**「アプリが直接ハードやOSの複雑な部分を扱わなくても動けるようにする仲介役」**です。


    1. 位置づけ(ソフトウェアとハードウェアから見た関係)

    [アプリケーションソフト]    ↑    (ゲーム、業務システム、Webアプリなど)-------------------------------------[ミドルウェア]    ↑    (DB、通信制御、描画エンジンなど)-------------------------------------[OS(基本ソフト)]    ↑[ハードウェア(CPU、メモリ、ディスク、ネットワーク機器...)]
    • ハードウェアは物理的な部品。

    • OSはハードウェアを制御する基本ソフト。

    • ミドルウェアは、OSの上で動き、アプリに便利な機能を提供する。

    • アプリケーションはミドルウェアやOSの機能を利用して目的の処理を行う。


    2. ミドルウェアの役割

    1. 共通機能の提供

      • アプリが一から作らなくていいように、共通の処理(通信、データ保存、描画など)を提供する。

    2. 開発の効率化

      • 複雑なハード制御や低レベル処理を隠蔽し、APIやライブラリとして提供。

    3. 移植性の向上

      • アプリはミドルウェアのAPIに依存し、ハードやOSの差異を吸収できる。


    3. ミドルウェアの例

    分野具体例提供する機能
    データベースMySQL, PostgreSQL, Oracle DBデータの保存・検索
    WebサーバApache, NginxHTTP通信処理
    アプリケーションサーバTomcat, WildFlyWebアプリ実行環境
    メッセージングRabbitMQ, Kafka非同期メッセージ通信
    ゲームエンジンUnity, Unreal Engineグラフィック描画、物理演算
    ミドルレベルAPIOpenGL, DirectXハード依存を隠す描画機能

    4. 例え話

    もしPCシステムをレストランに例えると:

    • ハードウェア → 厨房の設備(コンロ、冷蔵庫、包丁)

    • OS → 厨房の基礎運用ルール(火をつける方法、冷蔵庫の温度設定)

    • ミドルウェア → ソースや半調理済み食材のような、調理を助ける共通素材

    • アプリケーション → 完成された料理(お客様に出すメニュー)


    5. まとめ

    • 定義:OSとアプリケーションの間に位置し、共通機能を提供するソフトウェア。

    • 目的:開発効率化・移植性向上・ハード依存の吸収。

    • :DB、Webサーバ、ゲームエンジン、通信ミドルなど。




    Unityサウンドエキスパート養成講座 あらゆるゲームで使える「サウンド処理」の全貌を完全理解![本/雑誌] / 一條貴彰/著 CRI・ミドルウェア/監修

    価格:4180円
    (2025/11/17 21:09時点)
    感想(0件)


    開発系エンジニアのためのDocker絵とき入門 [ 鈴木亮 ]

    価格:3080円
    (2025/9/6 17:52時点)
    感想(0件)


     



    ブログランキング・にほんブログ村へ
    【下記、広告です。クリックいただけると励みになります。】
    posted by モニー at 18:00| Comment(0) | アプリ開発 | このブログの読者になる | 更新情報をチェックする

    2025年11月12日

    逆ポーランド記法について、A+B*CとA*B+Cでは、それぞれどのような記述になりますか?

    quan-jing-HSoPasiEilQ-unsplash.jpg

    質問

    逆ポーランド記法について、A+B*CとA*B+Cでは、それぞれどのような記述になりますか?


    解答

    逆ポーランド記法(RPN: Reverse Polish Notation)は、演算子をオペランドの後に置く記法です。
    かっこを使わずに演算の順序を明確にできるのが特徴です。


    1. 通常の式

    A + B * C

    通常の数式では、掛け算(*)が足し算(+)より優先されます。
    よって計算順序は「B * C」を先に行い、その結果にAを足します。

    これを逆ポーランド記法にすると:

    A B C * +

    手順

    1. B C * → BとCを掛ける

    2. Aを先に置いておき、結果に+を適用 → A + (B*C)


    2. 通常の式

    A * B + C

    ここでは掛け算が先なので、計算順序は「A * B」を先に行い、その後Cを足します。

    これを逆ポーランド記法にすると:

    A B * C +

    手順

    1. A B * → AとBを掛ける

    2. その結果にCを足す → (A*B) + C


    まとめ

    通常の式逆ポーランド記法計算順序
    A + B * CA B C * +B*C → A+(結果)
    A * B + CA B * C +A*B → (結果)+C

    ちなみに、逆ポーランド記法は**スタック構造(LIFO)**で実装しやすいため、
    古い計算機(HP電卓など)やコンパイラの内部処理でも使われています。





    書くスキルも設計スキルも飛躍的に上がる! プログラムを読む技術【電子書籍】[ 岩松 洋 ]

    価格:2860円
    (2025/10/26 11:36時点)
    感想(0件)


    エキスパートたちのGo言語 一流のコードから応用力を学ぶ【電子書籍】[ 上田 拓也 ]

    価格:3278円
    (2024/2/22 22:20時点)
    感想(0件)


     



    ブログランキング・にほんブログ村へ
    【下記、広告です。クリックいただけると励みになります。】
    posted by モニー at 18:00| Comment(0) | アプリ開発 | このブログの読者になる | 更新情報をチェックする

    2025年10月30日

    共通フレームとは

    gaelle-marcel-YnbJwNXy0YQ-unsplash.jpg

    質問

    共通フレームとはどういうものですか?


    解答

    とても良い質問です。
    「共通フレーム(Common Framework)」とは、システム開発における作業内容・工程・成果物などを共通の言葉で整理した「標準的な枠組み」のことです。
    特に日本では「共通フレーム2013(JIS X 0160)」として規格化されています。


    ■ 共通フレームとは何か

    システム開発の世界では、企業やプロジェクトごとに 「要件定義ってどこまで?」「テスト設計は誰がやるの?」 というように、工程や作業の範囲の認識がずれることがよくあります。
    そのズレを防ぎ、発注者(顧客)と受注者(開発側)が共通理解を持てるようにしたのが 共通フレーム です。
    つまり: > 「システム開発のどの段階で、何を、誰が、どんな成果物を出すか」を > 標準化した“共通言語”のようなものです。


    ■ 共通フレームの目的

    1. 契約や見積もりの明確化 → 「どこまでが業務範囲か」を共通の言葉で定義できる
    2. 品質と責任の明確化 → 各工程の成果物や確認方法を標準化できる
    3. プロジェクトの再現性・比較性 → 異なる会社・組織間でも同じ基準で進められる

    ■ 共通フレームの構成

    共通フレーム2013では、システム開発をプロセス(工程)単位で整理しています。
    大きく次の4つの分類に分かれています。
    区分内容
    上位プロセス群企画・導入・運用・廃棄など、システム全体のライフサイクル管理
    システムライフサイクルプロセス群要求定義、設計、開発、テスト、導入など実際の開発工程
    プロジェクトプロセス群進捗・品質・リスク・構成などのマネジメント
    支援プロセス群文書管理、検証、監査、教育などのサポート業務


    ■ 例で理解する:「共通フレーム」を使った話の通じ方

    共通フレームがない場合:
    > 発注者:「テストはちゃんとやってくださいね」
    > 受注者:「もちろんです!(単体テストのことだろう)」
    > 実際は:受入テストをやっていなかった → トラブル発生

    共通フレームがある場合:
    > 発注者:「共通フレームの『受入テスト』工程までが契約範囲です」
    > 受注者:「了解しました。『システムテスト』までは弊社で実施します」

    このように、「どの段階を指しているか」が明確になります。


    ■ 共通フレームのメリット・デメリット



    ◎ メリット

    * 発注者と開発者の認識を統一できる
    * 作業範囲・責任範囲を明確にできる
    * 他社プロジェクトとの比較・分析が容易
    * 教育や標準化にも利用しやすい

    △ デメリット

    * プロセスが細かく、小規模案件には煩雑
    * 柔軟性が低いため、アジャイル開発などには向きにくい

    * 実運用にはプロジェクト文化への適用力が必要

    ■ まとめ

    観点内容
    正式名称共通フレーム2013(JIS X 0160)
    目的システム開発工程の「共通言語」を作る
    主な対象発注者・受注者・プロジェクトマネージャ
    メリット契約・品質・範囲の明確化
    デメリット硬直的になりやすい
    関連ISO/IEC 12207(国際標準プロセスモデル)に基づく




    【送料無料】管理人室シルバーサインプレート 部屋名札 室名札 扉サイン 部屋プレート ルームプレート アクリルサイン

    価格:1650円
    (2025/10/13 20:16時点)
    感想(0件)


    日本インフラの「技」 [ 土木学会 ]

    価格:1540円
    (2025/8/22 21:08時点)
    感想(1件)


     



    ブログランキング・にほんブログ村へ
    【下記、広告です。クリックいただけると励みになります。】
    posted by モニー at 08:00| Comment(0) | アプリ開発 | このブログの読者になる | 更新情報をチェックする

    2025年08月22日

    CI/CDとは

    peter-thomas-1tqb24t3mAw-unsplash.jpg

    質問

    CI/CDとはつまりなんですか


    解答

    CI/CDとは、ソフトウェア開発における自動化されたビルド・テスト・デプロイのプロセスを指し、以下の2つの概念を組み合わせたものです:


    ✅ CI(Continuous Integration:継続的インテグレーション)

    コードを頻繁に統合(マージ)して、自動でテストすること

    ● 目的:

    • 開発者がこまめにコードを共有(=リポジトリにプッシュ)

    • 毎回の変更に対して自動でビルドやテストを実行

    • バグを早期に発見しやすくする

    ● 主な流れ:

    1. 開発者がコードをプッシュ

    2. CIツール(例:GitHub Actions, Jenkins)が自動でビルド

    3. ユニットテストやLintチェックが自動実行

    4. テスト結果を通知


    ✅ CD(Continuous Delivery/Continuous Deployment)

    自動でデプロイ可能な状態にすること(Delivery)
    または
    本番環境にまで自動で反映すること(Deployment)

    ● CDの2つの意味:

    用語名説明
    Continuous Deliveryテスト済みのコードをステージング環境に自動反映。本番反映は手動
    Continuous Deploymentテストに通ったら本番環境まで自動反映

    ● 主な流れ:

    1. CIでテストに合格

    2. ステージング環境または本番環境に自動デプロイ

    3. 手動承認(Delivery)または即反映(Deployment)


    🧠 CI/CD を導入する理由(メリット)

    効果内容
    開発の高速化手動ビルドや手動テストの手間がなくなり、変更を即時反映できる
    品質の向上毎回自動テストを通すことで、バグやミスを早期発見
    リリースの安定少しずつ本番に反映することで、障害リスクを減らせる
    チーム開発の効率化誰のコードも同じ仕組みで検証されるため、属人性を排除できる

    🛠 使用される主なツール

    分類ツール例
    リポジトリ管理GitHub, GitLab, Bitbucket
    CI/CDツールGitHub Actions, Jenkins, CircleCI, GitLab CI
    ビルド・テストDocker, Gradle, Maven, npm
    デプロイ先AWS, GCP, Heroku, Kubernetes など

    🔁 まとめ:CI/CDとは?

    CI:開発中のコードをこまめに共有 → 自動でビルドとテスト
    CD:CIを通過したコードを自動でリリースできる状態に → 自動 or 手動でデプロイ

    つまり、「開発から公開までの流れを自動化し、速く・安全にソフトウェアを更新する仕組み」です。




    図解! Git & GitHubのツボとコツがゼッタイにわかる本[第2版] [ 株式会社ストーンシステム ]

    価格:2420円
    (2025/7/31 11:41時点)
    感想(0件)


    Docker [ Adrian Mouat ]

    価格:3960円
    (2024/4/27 21:33時点)
    感想(0件)


     



    ブログランキング・にほんブログ村へ
    【下記、広告です。クリックいただけると励みになります。】
    posted by モニー at 08:00| Comment(0) | アプリ開発 | このブログの読者になる | 更新情報をチェックする

    2025年07月20日

    ゲームを作ってみたい。

    arno-senoner-SVO98wCEAME-unsplash.jpg

    質問

    ゲームを作ってみたい。
    どんなゲームがおすすめですか


    解答

    ゲーム開発、素晴らしいチャレンジですね。
    まず前提として、**あなたの技術レベル、目的、好きなジャンル、目指すプラットフォーム(PC、スマホ、Webなど)**によって「おすすめのゲーム」は変わります。
    ここでは、初心者〜中級者を想定して、目的別・ジャンル別におすすめを整理します。


    【1】目的別:どんなゲームを作りたいのか?

    目的おすすめジャンル理由
    プログラミングの練習パズル、テキストアドベンチャーロジック中心で簡単に始められる
    デザインや演出の練習2D横スクロール、ビジュアルノベル画面の見せ方・効果を学べる
    完成させる経験を積みたいブラウザ用シンプルゲーム(HTML5)スケールを抑えて完成しやすい
    公開して遊んでもらいたいカジュアルスマホゲーム幅広い層に遊んでもらえる


    【2】初心者におすすめのゲームジャンル5選(理由付き)

    ジャンル内容の例おすすめ理由
    ① ブロック崩しピンボール風、エフェクト付き当たり判定・スコア管理・反射計算の基本を学べる
    ② テキストADV選択肢式ホラー、恋愛、謎解きプログラム初心者でも始めやすい。
    世界観を重視できる
    ③ 2Dアクション横スクロールやジャンプゲーム物理、アニメーション、当たり判定などを学べる
    ④ シューティングゲーム弾幕、縦スクロール風パターン生成、敵AI、SE・演出の練習に最適
    ⑤ ターン制RPGシンプルなコマンドバトルステータス、セーブ、スクリプトの概念に触れられる


    【3】おすすめ開発ツール(レベル・目的別)

    開発ツール特徴対象者
    Unity + C#2D/3D対応、本格的なゲーム制作向き中級者以上〜学ぶ意欲ある人
    Godot軽量で覚えやすい、オープンソース初心者〜中級者
    RPGツクールコーディング不要、RPG作成特化非エンジニア向け
    PICO-8レトロ風ゲーム制作、コード学習に良い初心者/ミニゲーム志向
    Scratchブロック型で学習向け超初心者(小学生レベルもOK)
    JavaScript + HTML5Webゲーム、手軽に公開できるWeb開発経験者


    【4】始めるときのコツ

    * 最初から「大作」を目指さない(クリアできない)
    * 必ず「完成させること」を最優先にする
    * 既存ゲームの簡易版を作ってみる(例:ぷよぷよ風、インベーダー風など)
    * BGM・素材はフリー素材サイトから活用する
    * 小さな面白さを見つけて「伸ばす」のがゲーム作りの醍醐味

    【5】例:こんなゲームはいかが?

    ● 初心者向け

    * 「電車でGo風」簡易シミュレーター:時間通りに停車できたらクリア
    * 「迷子のネコを探す」テキストADV:選択肢でストーリーが分岐する
    * 「1ボタンでジャンプ」アクション:音ゲーっぽくリズムでジャンプ

    ● あなたの知識を活かす方向(例:ITエンジニア × ゲーム)

    * 「セキュリティ擬似ハッキングRPG」:TryHackMe風のパズルを物語で解いていく
    * 「コードを組み替えて敵を倒すパズル」:Pythonの文法がネタになる

    【6】まとめ

    > “最初のゲーム作り”に必要なのは、完成させる工夫と、自分がワクワクできる題材です。
    > 規模は小さくてOK。





    プライムポーカー ルーレット ジーピー カジノゲーム

    価格:2690円
    (2025/6/2 00:29時点)
    感想(2件)


     



    ブログランキング・にほんブログ村へ
    【下記、広告です。クリックいただけると励みになります。】
    posted by モニー at 13:00| Comment(0) | アプリ開発 | このブログの読者になる | 更新情報をチェックする