こんにちは。開発 2 部 箕浦です。
今回は、2025年5月21日（水）から23日（金）までの3日間、インテックス大阪で開催された「DX 総合EXPO 2025 春 大阪」に参加してきたので、その様子を開発者目線でレポートします。

DX 総合EXPOとは？​

DX 総合EXPOは、企業の業務効率化・DX（デジタルトランスフォーメーション）推進をテーマに、
AI、業務自動化、セキュリティ、データ分析、クラウド、マーケティングなど、 幅広いカテゴリのソリューションが一堂に集まる大規模展示会です。

会場の雰囲気​

インテックス大阪の広大な展示スペースに、数多くのブースがひしめき合うように並び、
どこを見渡してもDX・AI・業務効率化に関する展示であふれていました。
来場者も非常に多く、ビジネス関係者や開発者らしき方々の姿が多く見受けられました。

気になったテーマ・技術​

■ 生成AIの業務活用​

AIを活用したOCR、チャットボット、問い合わせ対応の自動化、音声認識システムなどが数多く紹介されていました。
特に大規模言語モデル（LLM）をベースにした社内文書検索や、契約書内容チェックツールなどは目を引きました。

■ ノーコード / ローコード開発​

開発工数を削減するためのノーコード・ローコードプラットフォームも目立ちました。
UI設計からデータ連携までGUIで完結するものや、生成AIと連携することで、
簡単な要件入力だけでアプリが生成されるようなツールもありました。

■ セキュリティソリューション​

生成AI時代のセキュリティ課題に対するアプローチとして、ログ監視ツールや社内チャットの情報流出防止機能など、
内部統制を強化する製品も多く見られました。
また、認証・アクセス管理ツールの紹介もあり、SaaS時代における開発者としての配慮ポイントを再確認する場にもなりました。

開発者としての所感​

今回の展示会では、ひとつひとつの技術に目新しさがあるというよりは、「既存技術をどう業務の現場へ適用するか」
「どこまでノーコードでできるか」といった実用化・運用フェーズの工夫が随所に見られたのが印象的でした。

特に生成AI関連のプロダクトは、「導入しました」で終わらず、どのようなデータを使い、どこまで自動化し、
どこから人が介在するかという設計の粒度が問われているように感じました。

最後に​

最新技術を“見て触れる”ことができるこういった展示会は、日々の開発業務に閉じこもりがちなエンジニアにとっても、非常に刺激的な時間になります。
今後もこのようなイベントに足を運び、実際の業務に役立てていきたいと思います。

各ブースでたくさんのお菓子をいただき、子供も大喜びです。

以上、DX 総合EXPO 2025 春 大阪の参加レポートでした！

こんにちは。開発 2 部 箕浦です。
2025年4月24日に『モダンな開発スタイル』というテーマで社内勉強会を行いました。

当日の様子は下記の弊社のブログに記載しております。
https://dsic.jp/blog/2025/05/seminar250514.html

勉強会の概要​

今回の勉強会は、各部署のエンジニアが集まり、最新の開発手法や技術トレンドについて共有する場として企画しました。
全体では以下の3つのセッションで構成されています：

1. モダンなWEBアプリ開発（フロントエンド）
   SPAやアトミックデザイン、フロント開発における有用なライブラリについて紹介

2. Dockerの紹介
   コンテナ技術の基本とその利点、基本的なDockerコマンドの解説

3. マイクロサービス入門
   モノリシックアーキテクチャからマイクロサービスへの移行メリットや設計パターン、実装上の注意点についての解説

モダンなWEBアプリ開発（フロントエンド）​

私の発表『モダンなWEBアプリ開発（フロントエンド）』では主に以下のトピックについてお話ししました：

1. WEB サイトと WEB アプリの違い
   従来の静的なWEBサイトと動的なWEBアプリケーションの特徴や用途の違いについて解説

2. SPA とは
   Single Page Applicationの概念と従来の多ページアプリケーションとの違い、メリットとデメリット

3. アトミックデザイン
   原子・分子・有機体・テンプレート・ページという5段階の設計手法とコンポーネント開発における有用性

4. Headless UI
   見た目とロジックを分離したUIライブラリの考え方と実装の柔軟性について

5. Tailwind CSS
   ユーティリティファーストCSSフレームワークの効率性と開発スピード向上のメリット

6. shadcn/ui
   美しくカスタマイズ可能なコンポーネントライブラリの紹介と実際の実装例

7. Storybook
   UIコンポーネントの開発・テスト・ドキュメント化のための統合環境と開発フローの改善効果

使用した資料の抜粋です

Dockerの紹介​

Dockerのセッションでは、コンテナ技術の基礎から実践的な使い方まで、以下のトピックが紹介されました：

1. Dockerとは
   コンテナ技術の概要と従来の仮想化技術との違い、Dockerの基本概念

2. ライフサイクル
   Dockerのビルド、配布、実行のライフサイクル

3. イメージのビルド
   Dockerイメージのビルド方法

4. コンテナの実行
   docker runコマンドのオプションと使い方

5. コンテナの中に入る
   実行中のコンテナへの接続方法

6. データの永続化について
   ボリュームとバインドマウントの違いと使い分け、データ永続化の方法

使用した資料の抜粋です

マイクロサービス入門​

マイクロサービスセッションでは、モノリシックからマイクロサービスへの移行とその実践について、以下のトピックが紹介されました：

1. マイクロサービスとは？
   モノリシックアーキテクチャとの比較と、マイクロサービスの基本概念の解説

2. マイクロサービスの原則
   サービス毎のデプロイ、サービス毎のデータベース、サービス毎の実装手段の設計原則

3. マイクロサービスの設計
   マイクロサービスを設計する5つの方法

4. マイクロサービスの実装
   マイクロサービスの実装例の紹介

5. 各論：マイクロサービスのトランザクション
   分散トランザクション管理、Saga パターン等トランザクションについて

6. 各論：マイクロサービスの稼働率
   冗長化による可用性の違い

7. 各論：マイクロサービスのロギング
   ログの一元化

使用した資料の抜粋です

今後の展望​

今回の勉強会を通じて、スピーカー側も改めて自分の知識を振り返り、わかりやすく伝えることの難しさを実感しました。 今後も最新技術のキャッチアップを続け、より良いプロダクト開発に貢献していきたいと思います。

発表資料は社内NIコラボに公開していますので、興味のある方はぜひご覧ください。

次回の勉強会も楽しみにしています！

こんにちは。開発一部　第五課　川又です。
IT業界未経験からディアシステムへ入社し2年が経ちました。

もし同じように未経験の状態からエンジニアの業界へ考えている方がいれば少しでも参考になればと思い、
自分の体験を赤裸々にお話したいと思います。

これまで私は小売業界、宿泊業界、飲食業界などに携わってきました。

転職するきっかけは、前職の業務でIT化を進める機会があり、30代後半でITの面白さに気付き、働きながらHTML、CSSやITパスポート資格勉強を始め、
そこから退職して半年間、職業訓練でJava、PHP、AWS、Linuxなど幅広く学びディアシステムに採用して頂き、現在に至ります。

入社して最初の現場は組み込み開発でした。
組み込み開発では主にC言語というプログラミング言語を使っていたのですが、
これまで全く触れたことのない言語でしたので、入門書を買って独学しつつ、
不明点は先輩方にサポートしてもらいながら何とかC言語での業務を進めれるようになりました。

ちなみにディアシステムでは資格取得報奨制度がありますので、
業務で使うスキル勉強はこういった制度を利用することがおすすめです。
実際私も入社半年目の頃にC言語の資格を取得し、報奨金をいただきました。
自分自身も成長でき、会社からも評価してもらえたので、これまでの業界にない嬉しい制度でした。

入社一年目で一番苦労したことは、わからない問題を自分一人で抱え込み過ぎたことです。
先輩方に聞いたら、すぐに解決できる問題を、一人で考え過ぎて結局、時間だけが経ってしまい、作業自体は全然進まないことが多々ありました。
ある先輩に「わからないことは遠慮せず、即聞いて」と言ってもらってからは、誰かに質問することに、ためらわなくなりました。

色んな方に質問する機会が増えると、自分の不明点を明確に相手に伝えるスキルも上がっていくので、
勇気をもって人に聞くことが一年目に特に大切だと感じました。

二年目で苦労したことはレビューなどで自分の成果物を説明することです。
元々、人に説明するのが得意な方ではなかったので、これは、かなり苦労しました。
ある時、いつも説明がわかりやすく堂々と話されている先輩の方に、説明するコツなどあるのか聞いてみたところ
「とにかく準備は十分念入りにやって、自信を持って話すこと」だと教えていただきました。
いつも堂々と話されている裏では、しっかりと準備を怠らずにやっていると知り、
そこから自分も説明する前には準備をしっかりするように意識したところ、少しずつ改善していきました。
まだまだ苦手意識はありますが、今後も継続してい事前準備を念入りにやっていきたいと思います。

三年目に入り、新しい開発業務に携わることになり、日々、わからないことの連続ですが、
その分、色々な知識、スキルを習得できるので、飽き性の自分には合っている業界だと感じています。

ディアシステムでは、社内全体で交流するイベントが定期的に開催され、
普段、違う現場で働いている色々の方からアドバイスをもらえたり、悩み相談などものっていただけるので、
とても働きやすい環境だと思います。

これから未経験からIT業界で働きたいという方がいれば、少しでも私の経験談がお役に立てれば幸いです。

この度、AWS クラウドプラクティショナー試験に合格しましたので、
合格までの道のりを書きたいと思います。
私自身これまで違う職種の仕事をしていたため、IT 関連の企業に勤めたのは初めてで、IT に関する知識は皆無と言っても過言ではありません。
なのでもちろん AWS なんて単語はこの業界に入って初めて知りました。
何故取ろうかと思ったのは、周りから聞こえる AWS 関連の単語がまるで何を言っているのかわからず、「このままではではまずいっ！」触れずともせめて意味くらいはわからねばと思ったのがきっかけです。

今回主に使用した資料は、

• AWS 認定資格試験テキスト　 AWS 認定 クラウドプラクティショナー　改訂第 3 版 (ぶ厚めな本です。)
• Udemy：【CLF-C02 版】この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（6 回分 390 問）

最初は本で勉強していたのですが、そもそも AWS の知識以前に専門用語がわからず、
３ページ読むごとに眠気が襲ってくる始末。もはや寝るために読んでたような気がします。
さすがに文字からスタートは無理ッと思い、YouTube の解説動画を観て基本を理解することからスタートしました。ハンズオンでしていないため、ほぼ想像で理解を深めながら、動画をある程度観てから再度本で勉強することに。
しかしここで勉強をはばかる大きな宿敵が。。

子供が居ては家で勉強できない！かといってこんなぶ厚い本を通勤時に読むには重すぎる 💦 そこで途中から Udemy の過去問をスマホを使い勉強することにしました。
これなら通勤時間も周りを気にせず勉強ができます。
とりあえず一旦過去問 6 回分の内の 1 回分 60 問解いてみることに。。。
なんと 600 点！合格点が 700 点以上なので「これはいけるぞ」と思い、その後も問題を解いていくと、やる毎に 500 点、400 点と点数が落ちていく、、どうやら最初の 2 回分くらいは優しめの問題を出してくれていたようで、その後はしっかり難しめ、、
完全に出鼻をくじかれました。

とはいえ取ると宣言してしまっていた以上引き下がるわけにもいかず、とりあえず過去問をやりまくり、間違えたところは解説を見返し、を続けました。
ある程度解いてから、あらためて参考書を読むと、最初の方はわからなかった内容が
ある程度理解できるようになりました。昔どこかでアウトプットが大事と聞いたことがあるが確かにただただ本を読むより、問題を解く（アウトプット）をする方が覚えれるような気がしました。
そんなこんなで、勉強内容としては、

• 過去問 6 回分 3 週
• 本 2 週

の 1 か月ほどの時間を費やし無事合格することが出来ました！

試験としては、基礎知識が中心で、やはりあのぶ厚い本の内容が頭にあれば合格できるような内容でした。（あの参考書がやはり原点だったんだな～）
各サービスの名前と内容を概要だけでも良いので抑えておくことが大事だと思います。問題は主に選択 4 択（例外あり）なので、名前と意味を覚えているだけでおおよそ絞ることができます！
合格したことで感じたことが、

• 自分の今している仕事への理解が深められる
• 周りから聞こえる単語が理解できる
• AWS の CM を観るとなんとなくテンションが上がる

仕事で直接的に AWS を使うという機会はまだ無いですが、取って損はないと思いました。勉強して、こんな便利な機能があるのなら使ってみないなと思うようなこともあったので、今後も深堀していきたいと思います。

こんにちは。開発一部の鶴田です。

この記事は前編の続きです。前編ではゴールと大まかな実装方針、用語の解説を紹介しました。今回はその続きとして実際にコードを書いてユニットテストを実施します。

実装：製品マスター​

まずはProduct：製品マスタークラスです。

	public string ProductCode { get; }
	public string Name { get; }
	public decimal Price { get; }
	public string? HaibanDate { get; }

	public Product(string productCode, string name, decimal price, string? haibanDate = null)
	{
		if (string.IsNullOrWhiteSpace(productCode)) throw new ArgumentException("製品CDは必須です");
		if (string.IsNullOrWhiteSpace(name)) throw new ArgumentException("名称は必須です");
		if (price < 0) throw new ArgumentException("製品価格は必須です");
		if (haibanDate != null)
		{
			if (!DateTime.TryParseExact(haibanDate, "yyyyMMdd", null, System.Globalization.DateTimeStyles.None, out _))
				throw new ArgumentException("廃番日が有効な日付ではない");
		}

		ProductCode = productCode;
		Name = name;
		Price = price;
		HaibanDate = haibanDate;
	}

実装：製品マスター向けリポジトリ​

続いて追加するリポジトリです。リポジトリはプロジェクトフォルダー内にRepositoryフォルダーを作成することが一般的です。 リポジトリとして2つ、抽象化するためのインターフェイスとテスト用のスタブを登録します。

public interface IProductRepository
{
	// 今回はFindのみ
	Product? Find(string productCode);
}

InMemoryProductRepository

// sealedとする理由：「このクラスは継承しないでほしい」旨の意思表示
public sealed class InMemoryProductRepository : IProductRepository
{
	private readonly Dictionary<string, Product> _store = new();

	public void Add(Product product)
	{
		_store[product.ProductCode] = product;
	}

	public Product? Find(string productCode)
	{
		return _store.TryGetValue(productCode, out var product) ? product : null;
	}
}

実装：製品マスター向けサービス​

つづいてサービスクラスです。サービスクラスとは、ビジネスロジック（業務を表現したロジック）をまとめたクラスのことです。 製品コードをもとに製品名を返すシンプルなサービスクラスを用意します。 サービスクラスはプロジェクトフォルダー配下のServiceフォルダーに格納するのが一般的です。

public class ProductService
{
	private readonly IProductRepository _repository;

	public ProductService(IProductRepository repository)
	{
		_repository = repository;
	}

	public string? GetProductName(string productCode)
	{
		return _repository.Find(productCode)?.Name;
	}
}

つい、「InMemoryProductRepositoryから直接取得すればいいんじゃね？」 と感じてしまうかもしれませんが・・・いや、それだと差し替えできないでしょ？笑

実装：製品マスター向けユニットテスト​

そして、追加したロジックをテストするユニットテストを追加しましょう。

	[TestMethod]
	public void GetProductName_ValidCode_ReturnsName()
	{
		var repo = new InMemoryProductRepository();
		repo.Add(new Product("001", "商品A", 100));
		// ProductServiceオブジェクトが必要とする依存先を（repo）を外部から注入する
		var service = new ProductService(repo);

		var result = service.GetProductName("001");

		Assert.AreEqual("商品A", result);
	}

	[TestMethod]
	public void GetProductName_InvalidCode_ReturnsNull()
	{
		var repo = new InMemoryProductRepository();
		// ProductServiceオブジェクトが必要とする依存先を（repo）を外部から注入する
		var service = new ProductService(repo);

		var result = service.GetProductName("999");

		Assert.IsNull(result);
	}

ユニットテストを実行し、カバレッジを確認しましょう。

よし、分岐までカバレッジ達成です。

実装：スパイを使ったテスト​

では次にスパイを使ってVerifyをとりましょう。今回はサービスクラスからリポジトリクラスを呼び出された回数を確認します。

スパイを使うテストは、戻り値だけでは担保できないケースをテストする場合に行います。例を挙げると・・・・

• ビジネスロジックの呼び出し順が正しいか
• 重い処理を何度も呼び出していないか
• 不可逆的な処理のチェック（ログ出力、メール送信）

などのケースがあります。

ではスパイオブジェクト：SpyProductRepositoryを作成します。保存場所はテストプロジェクトの配下、TestDoubleに置くのが一般的です。

public class SpyProductRepository : IProductRepository
{
	public int CallCount { get; private set; } = 0;

	public Product? Find(string productCode)
	{
		// メソッドが呼ばれた回数をカウント
		CallCount++;
		return new Product(productCode, "Spy商品", 123);
	}
}

今回はメソッドが呼ばれた回数をカウントしています。 ビジネスロジックの呼び出し順を検証するときは、文字列にメソッド名を追記して、それを検証します。 難しく考えることはないです。こんな感じです。そうです意外と泥臭いモンです笑

	public Product? Find(string productCode)
	{
		// メソッドが呼ばれたときにCalledMethodへ追加
		CalledMethod += @$" SpyProductRepository.Find( productCode:\"{productCode}\" )";
		return new Product(productCode, "Spy商品", 123);
	}

話を戻します。テストコードです。

[TestMethod]
public void GetProductName_RepositoryCalledOnce()
{
	var repo = new SpyProductRepository();
		// ProductServiceオブジェクトが必要とする依存先を（repo）を外部から注入する
	var service = new ProductService(repo);

	service.GetProductName("001");
	Assert.AreEqual(1, repo.CallCount);
}

ここまでできたら、ユニットテストを実行してカバレッジを確認しましょう。

まとめ​

今回はMoqを使わないという制約の中で、スタブとスパイを手書きしながらユニットテストを進めてみました。

• インターフェイス＋リポジトリで依存を切り離すと、実装を差し替えるだけでテスト環境を整えられる

• スパイ＋ Verifyを使うと、戻り値だけでは見落としがちな「振る舞い」も確認できる

• OSSが使えないケースでも工夫次第で十分テストを強化できる

もし「まだ全部を取り入れる余裕がない」と感じても、まずはInMemoryリポジトリだけ作ってみるだけでも効果があります。小さな一歩を積み重ねながら、一緒にテストの質を向上させていきましょう！

※今回作ったプログラムは ここ からダウンロードできます。

こんにちは。開発2課の鶴田です。

この記事は、前回の「ユニットテストを使ってカバレッジを計測、テストの品質を向上させよう」の続編です。前回は、主に「プログラムのロジックが十分にテストされているか（＝カバレッジ）」を確認することで、テストの質を高める方法を紹介しました。

今回はそこから一歩進んで、実際のアプリでよく登場する「データベースアクセス」や「外部データとのやりとり」が入った場面でも、ユニットテストを効果的に行う方法を紹介します。

一般的にはMoqというオープンソースソフトウェア（以下、OSSと呼びます）を使って、データベースの代わりとなる代用オブジェクトを作成、テストします。しかし、実際の業務では開発ルール上、OSSを利用できないケースもあります。

そこで今回は、OSSを使わずに実装する方法を紹介します。 OSSを使わずに手でMoq的なモノを実装することで、Moqの基本的な概念に対する理解が深まる効果もあります♪

いきなり実装に入ると混乱しやすいため、この記事（前編）では今回のゴールと実装方針、用語の解説を先に紹介します。次回の後編で、実際にコードを書いてみましょう。

※後編の実装編ではわたしが書いた記事を流用します。記事はこちらです。

今回のゴールと実装方針​

実際のアプリでは、商品マスター（前回の記事ではProduct）や在庫マスター（前回の記事ではZaiko）の情報は「データベース」や「CSVファイル」などの外部データソースから取得されます。しかしそれをそのままユニットテスト化しようとすると、データベースの準備や接続が必要となり、ユニットテストを実装・実行するためのコストが上がります。

そこで今回は、データ取得の仕組みをインターフェイスをつかって抽象化し、本番環境とテスト環境で差し替えられるようにする方針を取ります。

たとえば、商品マスター（前回の記事ではProduct）の場合は以下の通りとなります。

public interface IProductRepository
{
    // Find は習慣的に決まっている名前
    Product? Find(string productCode);
}

// テスト用の取得・更新用クラスはsealedにすることが一般的
public sealed class InMemoryProductRepository : IProductRepository
{
    // テスト用 Product 向けリポジトリクラス
    Product? Find(string productCode)
    {
        // テスト用の値を返すロジック
        return new Product
        ・
        ・
        ・
    }
}

このように「データの取り出し方」だけを切り離すことで、DBやテスト用CSVがなくてもユニットテストを実行することができ、結果として保守しやすいコードになります。

用語の解説​

Moq（モック）​

Moqは .NET向けに広く使われているOSSです。インターフェイスや仮想メソッドに対して、簡単に「スタブ」や「スパイ」として振る舞うオブジェクトを生成できます。

var mock = new Mock<IProductRepository>();
mock.Setup(x => x.Find("001")).Returns(new Product("001", "商品A", 100));

このように記述することで、Find("001") の戻り値をテストごとに制御できます。また、呼び出し回数の確認（Verify）なども可能です。とても便利なライブラリですが、本記事では使用しない方針で進めます。

リポジトリ (Repository)​

リポジトリとは「データの取得や保存のしくみを隠すためのクラス」です。 実装用とテスト用、2パターンを用意し、共通のインターフェイス経由で実装することで差し替えることができるようになります。

テストダブル (Test Double)​

「テストのときに、本物の代わりに使うオブジェクト」の総称です。今回は以下の2つの機能をつかいます。

スタブ：決まった値を返すだけ。今回の例ではInMemoryProductRepositoryがスタブに該当します スパイ：呼び出されたかどうかを記録します。今回は呼び出された回数を内部で記録、検証します。

依存関係逆転の原則（DIP）と依存性の注入（DI）​

テスト用のリポジトリに差し替えるためには、依存関係逆転の原則（DIP）と依存性の注入（DI）という考え方が重要になります。

依存関係逆転の原則（DIP） は以下の2つのルールからなりたっています。

1. 上位のモジュールは下位のモジュールに依存してはならない。

2. 抽象は詳細に依存してはならない。

   • 上位　・・・・ビジネスロジックやアプリ全体を制御するロジック
   • 下位　・・・・DBやCSV、JSONに対する入出力ロジック
   • 依存する　・・ここでは実装を変更したときに影響を受けることを意味する。具体的な例でいうと、下位モジュールのコードを変更したときに、上位モジュールがエラーになったりすることを言う
   • 抽象　・・・・インターフェィスや抽象クラスが該当する
   • 詳細　・・・・具体的な実装

依存性の注入（DI） はオブジェクトが必要とする依存先（他のオブジェクトやサービス）を、外部から渡してもらうデザインパターンです。

ちなみにですが、私は「依存性の注入」がデザインパターンの名前のことであることに気づきませんでした。（名前って重要や・・・） 当社の土井がアップしたこちらの記事でわかりやすく解説しています。5分程度でサラッと読めるよい記事です。ご一読されることをおススメします。 依存関係逆転の原則とDI（Dependency Injection）

後編の予告​

後編では、実際にInMemoryProductRepositoryやProductServiceを使ってユニットテストを書きます。 前回同様、Fine Code Coverageを使って、テストがしっかり書けているかも確認します。

こんにちは。開発一部の土井です。
普段、業務で C#を使っているのですが、テストから本番に移すときなど、アプリケーション構成ファイル内の設定値を手動で変更しておりましたが、手間だったり、ミスも起こりやすいと思い調べていたところ良さそうな方法を見つけたので、ここに書きたいと思います。

動作環境

• Visual Studio Community 2022
• .NET6.0

今回行いたいことは、ソリューション構成（Debug,Release）の切り替えにより、アプリケーション構成ファイル（app.config）の内容が変更されるようにすることです。

結論から方法を伝えると、プロジェクトの csproj ファイルへ以下の設定情報を追加することで可能です。

<!-- Debug構成時 -->
<Target Name="CopyConfigDebug" Condition="'$(Configuration)' == 'Debug'" BeforeTargets="BeforeBuild">
	<Copy SourceFiles="App.$(Configuration).config" DestinationFiles="app.config" />
</Target>

<!-- Release構成時 -->
<Target Name="CopyConfigRelease" Condition="'$(Configuration)' == 'Release'" BeforeTargets="BeforeBuild">
	<Copy SourceFiles="App.$(Configuration).config" DestinationFiles="app.config" />
</Target>

各要素について、ご説明します。

<Target Name="CopyConfigDebug" Condition="'$(Configuration)' == 'Debug'" BeforeTargets="BeforeBuild">

<Target> はビルド中に実行するタスクを定義します。
Name はこの要素の名前です。
Condition は要素を有効にするかどうかを決めます。 ’$(Configuration)’ がソリューション構成の値です。つまり、今回の場合だとソリューション構成が’Debug’となっている場合に <Target> 内のタスクを有効にするということになります。
BeforeTargets はこの <Target> をどのタイミングで実行するかというものです。今回の場合は ”BeforeBuild” となっており、ビルド前に実行するということになります。

<Copy SourceFiles="App.$(Configuration).config" DestinationFiles="app.config" />

<Copy>はその名前の通りコピーを行う要素です。 SourceFiles がコピー元で、DestinationFiles が貼り付け先となります。

つまり、ソリューション構成が Debug のときは App.Debug.config を、Release のときは App.Release.config を、それぞれ ビルドの前に app.config に上書きコピーします。

以下、設定情報追加後の csproj ファイル

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

	<!-- Debug構成時 -->
	<Target Name="CopyConfigDebug" Condition="'$(Configuration)' == 'Debug'" BeforeTargets="BeforeBuild">
		<Copy SourceFiles="App.$(Configuration).config" DestinationFiles="app.config" />
	</Target>

	<!-- Release構成時 -->
	<Target Name="CopyConfigRelease" Condition="'$(Configuration)' == 'Release'" BeforeTargets="BeforeBuild">
		<Copy SourceFiles="App.$(Configuration).config" DestinationFiles="app.config" />
	</Target>

</Project>

これで、ソリューション構成を切り替えることで App.Config の中身を切り替えることができます。
少し注意点ですが、ビルドを実行することで App.config の中身が切り替わるので、必ずソリューション構成を切り替えた後にビルドを行ってください。

ここからはおまけになりますが、csproj の他の要素についてご説明します。
<Project Sdk="Microsoft.NET.Sdk">
プロジェクト内でどの SDK を使うか定義しています。

<PropertyGroup>
プロジェクトのビルドや振る舞いの基本設定をまとめています。

<OutputType>
出力の種類を決めています。今回だと実行ファイル（.exe）を出力します。

<TargetFramework>
対応する.NET のバージョンを指定します。

<ImplicitUsings>
Using を自動で補完してくれる機能の使用可否を決めます。例えば、using System;と明示しなくても良くなります。

<Nullable>
Null に関しての安全なコードを書くためのチェックが有効になります。

他にも様々な要素が存在しますが、全ては書ききれないので一番初めからある基本的なものだけ説明しました。

ここまで csproj について説明しました。
今回は app.config の内容を丸々上書きするという内容でしたが、一部要素だけ書き換えるという方法もあるようでした。（なぜか上手くできませんでした。）
今後はこの方法で設定値を環境ごとに切り替えようと思います。

こんにちは。開発１部の鈴木です。

2024年の秋期試験(10月)を受験し、無事に合格することができました。これから応用情報技術者資格の取得を目指している方に向けて、私の勉強方法や、勉強時間などをお話ししたいと思います。

■応用情報技術者試験の概要​

応用情報技術者試験のWebページ https://www.ipa.go.jp/shiken/kubun/ap.html

応用情報技術者試験は、独立行政法人情報処理推進機構が実施している試験です。春期(4月)、秋期(10月)の年2回実施しており、各地域の会場に直接赴いての筆記試験となります。

試験は午前、午後と分かれており、午前試験は80問の四肢択一問題、午後試験は必答問題が1問と、10問中4問を選択して回答する記述問題です。

■受験前のスキルレベル​

同じく情報処理推進機構の基本情報技術者試験に合格していました。 エンジニアとしての経験があまりない方は、基本情報技術者をとってから応用に進んだ方が良いと思います。

■勉強方法​

応用情報技術者試験ドットコム https://www.ap-siken.com/

上記のサイトでひたすら問題を解き続けました。それだけです。 前述の基本情報技術者試験受験の際にお世話になり、そのままステップアップしていった形です。

15年以上前から、精力的に更新され続けているサイトで、無料で利用できます。応用情報技術者試験の過去問が網羅されており、解説も充実しております。

●午前試験の勉強​

基本情報技術者試験の問題が一回り難しくなったくらいの難易度なので、基本情報技術者試験に合格していれば、上記サイトの過去問道場の問題を一通り解くのは難しくないと思います。

分からなかった問題は解説を読み、自分で他の人に説明できる、というくらいまで理解度を上げるように心がけました。分野を絞って出題する機能もありますので、苦手な分野はそちらの機能を使って何度も確認しました。

私は一日10～30分くらい取り組んで、2週間程で9割以上正答できるようになったので、午後試験対策に移りました。

こちらに時間をかけるよりは、後述する午後試験の対策にしっかり時間をとった方が良いと感じました。

●午後試験の勉強​

午前試験が楽々解けるようになり、意気揚々と午後試験道場に乗り込んだのですが、一瞬で打ちのめされました。

四肢択一の午前試験と異なり、自分で記述して回答しなければならない午後試験は、情報技術へのより深い理解が必要とされました。最初の内は選択問題だけ当てずっぽうで回答して、記述問題は白紙で解説を読む、なんてこともザラでした。

しかし、応用情報技術者試験ドットコムでは解説が非常に丁寧にされているので、理解できるまで読み込んで、気になるワードで検索をかけて知識を仕入れて、他の年度の過去問に挑戦を繰り返す内に、記述問題も正答できるようになっていきました。

午後試験は必答の問題が1問と、10問の内、4問の選択式ですので、選択する分野を絞った方が、必要な勉強時間は短くなります。私の場合は、選択する分野を完全に4分野に絞って勉強をしました。午前試験の過去問を解く中で、自分で得意だと感じた分野から挑戦するのをオススメします。

ただ、各年でそれぞれの分野の難易度にバラツキがあるので、念のため5、6分野の勉強をしておくのも手だと思います。問題文に目を通して、難易度に当たりをつけられるようになる必要がありますが。。。

午後試験は、各分野を10年度分、ほぼ正答できるようになるまで解いて受験に臨みました。合計で40時間くらいはかけたのではないかと思います。ここは自信がつくまで、じっくり時間をかけて勉強しました。

■応用情報技術者試験の振り返り​

数ある情報系資格試験の中でも、それなりに深く、幅広い知識が求められ、難易度が高めだと言われる応用情報技術者試験ですが、試験勉強を通じて得られるものは大きかったです。特にエンジニアから、チームリーダーやマネージャーへのキャリアアップを目指す人にとっては、一つの指針となってくれるのではと感じました。

私は、今後、応用情報技術者試験の更に上のレベルと目される試験にも挑戦したいと思っています。現在は情報処理安全確保支援士試験の勉強を続けております。

最後になりましたが、ここまでお読みくださり、ありがとうございました。この記事が、これから応用情報技術者試験の受験を目指す方のお役に立てることをお祈りしております。

Scoop を使ったアプリケーション管理を紹介します。

Scoop とは​

Scoopとは、有志により開発されている Windows 用のコマンドラインインストーラーです。
PowerShell 上でコマンドを実行することでアプリケーションのインストール、更新、アンインストールなどが行なえるようになります。
パッケージ管理ツールと呼ばれることもあり、同様のツールに Microsoft の WinGetや Chocolatey Software の Chocolateyがあります。

Scoop のインストール​

さっそく Scoop をインストールします。PowerShell ターミナルを起動し、PS C:\> プロンプトが表示されたら次のコマンド実行します。

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

Scoop was installed successfully! といった表示が出ればインストールは完了です。

アプリケーションのインストール​

Scoop でアプリケーションをインストールするにはアプリケーション名を指定して install コマンドを実行します。

例として、Windows に初期インストールされている Windows PowerShell ではない、PowerShell Core をインストールしてみます。

scoop install pwsh

これだけでインストールは完了です。アプリケーションの設定によってスタートメニューに追加され、環境変数 PATH に設定されているため、 スタートメニューから実行したり、Windows キー + R の「ファイル名を指定して実行」で pwsh と入力し実行すると PowerShell Core が起動するようになります。

インストールしたアプリケーションは ~\scoop ディレクトリ(例: C:\User\user\scoop)に配置されるため、環境を綺麗に保つことができます。

インストールしたアプリケーションのアンインストールは uninstall コマンドで、更新は update コマンドで行ないます。

scoop uninstall pwsh
scoop update pwsh

他にどのようなアプリケーションがあるかは search コマンドで一覧表示し、info コマンドで詳細が確認できます。

scoop search
scoop info pwsh

バケットの追加​

アプリケーションの設定はマニュフェストという JSON 形式のファイルに記述されています。いくつかのマニュフェストを纏めて管理しているものがバケットです。

初期状態では main バケットしか有効になっていません。main バケットに GUI ツールは含まれないため、インストールできるアプリケーションも限られたコマンドラインツールのみになります。

そこでバケット extras を追加して、VSCode をインストールしてみます。

scoop bucket add extras
scoop install vscode

extras 以外にも games nerd-fonts nirsoft sysinternals java nonportable php versions バケットが利用できます。

エクスポートとインストール​

Scoop で管理しているアプリケーションの状態を JSON 形式でエクスポートすることができます。 エクスポートした JSON をインポートすることで管理していた状態を再現することができます。

エクスポートすると次のような内容の scoop.json ファイルができあがります。

scoop export > ~/Desktop/scoop.json

{
    "buckets": [
        {
            "Name": "main",
            "Source": "https://github.com/ScoopInstaller/Main",
            "Updated": "2025-04-19T17:30:20+09:00",
            "Manifests": 1388
        },
        {
            "Name": "extras",
            "Source": "https://github.com/ScoopInstaller/Extras",
            "Updated": "2025-04-19T21:30:52+09:00",
            "Manifests": 2152
        }
    ],
    "apps": [
        {
            "Info": "",
            "Name": "pwsh",
            "Source": "main",
            "Version": "7.5.0",
            "Updated": "2025-04-19T22:49:29.0042927+09:00"
        },
        {
            "Info": "",
            "Name": "vscode",
            "Source": "extras",
            "Version": "1.99.3",
            "Updated": "2025-04-19T22:56:28.5872264+09:00"
        },
    ]
}

インポートするには import コマンドに JSON ファイルのパスを指定します。

scoop import ~/Desktop/scoop.json

これで PowerShell Core と VSCode がインストールされた状態が再現されます。

まとめ​

標準で提供されているもの以外に有志により提供されるバケットも利用すると ある程度のアプリケーションは Scoop で管理できるようになります。

コマンドラインでアプリケーションの管理ができる Scoop を活用してみてはいかがでしょうか。

こんにちは。モバイル開発歴 12 年目の井上です。

業務で Flutter / Dart を扱う事があり、その中で Swift の if let のように書きたい!!

    var fruit: String? = "apple"

    if let apple = fruit {
        print("リンゴ")
    }

と思ったのですが・・・Dart では書けない事が判明

なんとか書けなものかとさらに調べると、switch で Null チェックができることを発見!!

  String? fruit = "apple";

  switch (fruit) {
    case var apple?:
      print("リンゴ");
  }

これだ!! if let では無いものの理想に近い物に出会えました。

Dart 3.0 から使用することができます。ご注意ください

余談になりますが

  String? fruit = "apple";

  switch (fruit) {
    case var apple?:
      print("リンゴ");
    default:
      return;
  }

上記のように default に return を記述すると、switch を終えた後の fruit は Null 非許容として扱うことができます。