こんにちは1部3課の田之上です。

本日は、ぼくがこの業界で仕事をするようになり、これ面白いな‼と感じた
自動車で使用されている電子制御ユニット　＝　ECU( Electronic Control Unit )というものについて少し紹介します。

皆さんは普段利用されている自動車がハンドルを操作したら自動車が曲がる、アクセルを踏むと加速するなど動きの仕組みをご存知でしょうか？

人からどのような開発をしているの？？と聞かれ
自動車の開発をしているよ。というと「あー、車を作っているのね？」と
だいたいの人がどのようなものを作っているか自体は、だいたい想像通りです。

しかし、実際に自分たちが生まれる前からある車を数十年も経過している現在でも
開発していると考えると「なにか新しい機能が次々にあるっけ？？」
という疑問が出てくると思います。

新しい機能の話だと最近では自動運転が等の情報が流れていますが、

そうなんです！！

よく考えると基本的な「動く」、「止まる」、「曲がる」という点においてはデザイン変更など除いたイメージ的には、車として大きな見える変化をしていないんですよね。

では、業務としてどのような点を自動車業界の人は、開発しているのかというと
ざっくりいうと昔からある自動車は、すべてが物理的に機械制御していた部分が現代においては電子制御に置き換わってきています。

より簡易に利便性良く快適に変化しているとイメージしていただければと思います。

例えばサイドレバーだと、昔はワイヤーで物理的にワイヤーを巻き取りブレーキがかかっていたが、現在では、電子制御となりボタンを押すだけで電気モータでブレーキがかかるようになっています。

メリットはユーザ力が大きな力が必要なく
簡易にサイドブレーキがかけれるという点です。

このような物理的な仕組みから電気信号で制御するためにECUというものが必要となります。  

ECUは様々な情報を受け取り状況に応じた判断し、結果を次の動作につながるように電気信号を送信します。
図１と「■操作感」を用いてイメージを示してみます。

いかがでしたでしょうか。

簡単な図と操作感でしたが、普段周りにある物理的なものがどのように進化しているのか少しはイメージ出来たのではないでしょうか？？

イメージできたら身近にある物理的なものの仕組みをなぜ？？と考えてみると新たな発見があるかもしれません。

ものの仕組みについて少しでも興味を持ってくれたら幸いです。

🛜アプリ開発を加速する次世代クラウドサービス​

▶️はじめに​

業務でSQLを使用してデータ操作をしているうちに、『NoSQL』とはどういったものか？

どうやってデータを操作するのかとうい好奇心が湧きました。

そこで手軽に『NoSQL』を試せる環境がないかと調べていると、

今回の題目である【Firebase】にたどり着きました。

調べてみると、Googleが提供する「Firebase（ファイアベース）」は、近年のアプリ開発では、

スピードと柔軟性が求められる中、モバイル・Web開発において注目を集める存在のようです。

本記事では、予備知識ゼロの筆者がFirebaseの基本的な機能やメリットに加え、

他のクラウドサービス（AWSやAzure）との違いも含め、自分なりに理解した内容を解説します。

また、弊社箕浦のTechブログでは実際にFirebaseを設定している記事が掲載されていますので、

ご興味のある方は是非ご参照ください。

https://techblog.dearsystem.jp/blog/2024-04-05-01

|

▶️Firebaseの概要​

Firebaseは、Googleが提供するクラウドベースのアプリ開発プラットフォームです。

サーバーの構築や運用を意識せずに、リアルタイム通信・ユーザー認証・データ保存・通知配信などの

機能をアプリに簡単に組み込める、**BaaS（Backend as a Service）**の代表格です。

開発者はFirebaseを使うことで、サーバーレス環境でバックエンドの構築・運用が可能 となり、

フロントエンドやUI開発に集中しやすくなります。

リアルタイムデータベース、認証、クラウドストレージ、分析、通知など、

アプリに必要な多くの機能をワンストップで提供しています。

元々は2011年に独立した企業としてスタートし、2014年にGoogleに買収されて以降、急速に進化を遂げています。

|

▶️Firebaseで実現できること／得意なこと​

1. リアルタイムデータの同期​

Firebase Realtime Database や Cloud Firestore により、複数端末間でデータをリアルタイムに同期。

チャットアプリや出欠管理、ライブ更新系のアプリに最適。

2. 認証機能の実装​

Googleアカウント、メール認証、電話番号など複数の方式を数行のコードで導入可能（Firebase Authentication）。

3. 通知の配信​

Firebase Cloud Messaging（FCM）で、モバイルやブラウザへのプッシュ通知を簡単に実装。

4. クラウドストレージ​

Firebase Storage で、画像やドキュメントなどのファイルをクラウドに安全に保存・共有可能。

5. ユーザー行動の分析​

Firebase Analytics により、ユーザーの操作や行動履歴を可視化し、改善施策に活用。

|

▶️Firebaseのメリットとデメリット​

メリット​

サーバーレスで開発が可能（インフラ管理不要）

リアルタイム通信が得意（双方向の即時同期）

セットアップが簡単（初心者でも扱いやすい）

Googleインフラによる高いスケーラビリティ

Webとモバイル両対応

デメリット​

無料プランには利用制限がある（同時接続数や転送量）

複雑なSQL操作には不向き（NoSQL型）

依存度が高いクラウド設計（オフライン対応が限定的）

データ構造設計次第でコストが予想外に膨らむ可能性

|

▶️Firebaseの課金情報（ 2025年時点）​

Firebaseには無料と有料の主に以下の2プランがあります。

小規模なアプリでかつ、扱うデータ量も少ないならば、無料でも十分使用できます。

Blazeプランの参考料金（USD）

Realtime DB 保存：$5/GB、ダウンロード：$1/GB

Firestore 書込：$0.18/10万件、読込：$0.06/10万件

Storage 保存：$0.026/GB/月、転送：$0.12/GB

※地域・為替によって変動あります。最新の公式サイトで確認を。

|

▶️Firebaseと AWS / Azureの違いは？​

同様の要件で検討対象となるAWSやAzureとは、いったいどういった違いがあるのでしょうか

Firebase、AWS、Azureはそれぞれクラウドベースのサービスですが、目的や設計思想が大きく異なります。

以下にFirebaseとの差異をまとめてみました。

|

▶️Firebaseが向いているケース​

⇒ アジャイル開発・プロトタイプ作成

⇒ リアルタイム性が必要な教育アプリや出欠管理

⇒ サーバー構築の専門知識がない小〜中規模プロジェクト

⇒ AWS/Azureが向いているケース

⇒ 複雑な業務システムや高トラフィックアプリ

⇒ リレーショナルデータベースを多用する場合

⇒ セキュリティやカスタマイズの自由度が求められる場合

|

▶️まとめ​

Firebaseは、スピーディーにアプリ開発を進めたいチームや個人開発者にとって

非常に強力な選択肢となりそうです。

特にリアルタイム性やモバイル/Webの統合開発が必要な場面では、

他のクラウドサービスと比較しても抜群の効率性を発揮すると考えられます。

一方、AWSやAzureはより柔軟で強力なインフラ制御が可能なため、

エンタープライズ向けや大規模サービスに適していると考えられます。

★ Firebaseは**「すぐ作れる」「すぐ動く」**を最重視するプロジェクト向き。

★ AWS/Azureは**「自由に作れる」「複雑なシステムに対応できる」**のが強み。

|

▶️あとがき​

当初の疑問であったはずの『NoSQL』はどこいった？？？

という内容のブログになりましたが、実はFirebaseを使用して、簡単な『出欠確認アプリ』を

試作しているところです。

運よく完成となった暁には、今回触れることができなかったFirebaseの実際の設定方法や

『NoSQL』の使用感もあわせて記事にできればと考えております。

（断念したらすみません。。。）

ただ、この『Firebase』には可能性を感じており、「自前のデータベースやシステムを持ちたいけれど、

AWSやAzureみたいな大がかりの物はちょっと・・・」とDX化に二の足を踏む

中小事業者向けのサービスとして、手軽に扱えかつ、開発工数も抑えられる本環境は

最適かとも思いました。

7 月より開発２部２課に配属されました、濱上です。よろしくお願いいたします。

【合同研修の概要】​

4 月 8 日から 6 月 28 日までの 3 か月間、合同研修に参加いたしました。
研修では、最初に社会人マナーを学びました。その後、各プログラミング言語の講義を受け、個人開発演習、最後の 1 か月でチーム開発演習を行いました。

【社会人スキル】​

社会人としてのマナー、敬語の使い方、名刺交換や電話対応について学びました。
また、毎日日報を記述し週の半分はグループ内で 1 分間スピーチを行い、講師の方へその日の目標の達成度を伝える口頭報告も行いました。
この中で私が最も役に立ったと感じる点は、計 5 回行った口頭報告です。要点を抑え分かりやすく伝えることが苦手なため、最初はとても緊張していました。ですが、何を伝えるか、大事な点を中心にメモすることで自信をもって報告でき、講師の方から簡潔で分かりやすいと褒めていただきました。

【IT スキル】​

主に以下のプログラミング言語について学びました。

• HTML/CSS
• Oracle
• Java
• Spring

講義を受け、練習問題を解き、毎日確認試験を実施しました。各言語を学び終えると、総合試験と演習試験を行いました。
プログラミング未経験で合同研修に参加したため、講義だけで理解を深めることは困難でした。そのため、自宅での予習復習や、研修内で空いた時間を活用し練習問題を解きました。その結果、講義での理解度が上がり、練習問題をスラスラと解けるようになりました。

【チーム開発演習】​

合同研修の最後の 1 か月で、6 人 1 チームとなりチーム開発を行いました。
ネットショッピングサイトを作成する課題があり、私のチームは、野菜や果物などの食べ物を販売するショッピングサイトをテーマにしました。
1 番大変だった点は、仕様書の作成です。実装も難しく大変でしたが、仕様書を作成した経験がなく、仕様書の読み込みや図の作成など慣れないことが多かったです。ですが、チーム内で役割分担をして協力し合うことでスムーズに進められました。
私はレイアウトの編集も担当しましたが、成果報告会ではテーマに沿ったレイアウトになっていると褒めていただき、とても達成感がありました。

【合同研修を通して】​

合同研修で最も成長したと感じる点は、コミュニケーション力です。
最初は積極的に話しかけることができず、コミュニケーションをとるまでに時間がかかってしまい、質問もなかなかできていませんでした。ですが、チーム開発を通して早めに情報を共有することはチーム全体に良い影響を与えることを意識できました。自分から進んでコミュニケーションをとるようにし、必要事項だけでなく雑談などの会話もとり、良い雰囲気で開発を進められました。
IT スキル面では、まだまだ足りない部分が多いですが、合同研修で学んだことを忘れず今後の実務で活用し、また今後も学ぶ意欲を忘れずに頑張ります。

7 月より開発２部１課に配属されました、大野です。よろしくお願いいたします。

3 か月間の外部研修が終了いたしましたので、その具体的な内容と自身の成長や学びについてお話していきます。

外部研修の概要​

研修は 4 月から６月までの３か月間ございました。
初めの一週間は社会人スキルやセキュリティに関して学び、その後は HTML/CSS や Oracle、Java、Spring などの講義を経て、個人開発演習やチーム開発演習に臨みました。

社会人スキルに関する講義​

話題の『７つの習慣』（スティーブン・R・コヴィー著）に関することや、名刺交換、敬語の使い方、電話対応など、社会人として必要な技能に関して学びました。以下にそれらの具体的な内容を掲載します。\

• 『７つの習慣』：物事を重要度と緊急度の２軸もマトリクスでとらえ、緊急でないが重要度が高い（自学自習や運動など）ことをする時間を増やすことが大切などということを学びました。

• 名刺交換：他の受講生の方々と名刺交換のシミュレーションを何度も繰り返し、名刺交換の仕方を体に染み込ませました。

• 敬語の使い方：丁寧語、尊敬語、謙譲語などの基本的な言葉遣いを覚えました。

• 電話対応：様々なシチュエーションで、電話の「受け手」と「かけ手」に別れ電話の応対の練習をしました。

社会人になりたてで、上司の方やお客様とどの様に接すればよいのか分からない状態で、不安を抱えておりました。
しかし、社会人としての立ち振る舞いを学ぶことで、そのような不安が解消されました。
また、学生から社会人になったという自覚ができるようにもなりました。

IT 技術に関する講義​

先ほども挙げさせていただいたように、この講義では HTML/CSS や Oracle、Java、Spring などを主に、開発現場で使用される言語や技術の使い方について関して、基礎的な内容を学習しました。
　私自身、（入社前研修で Linax や SQL に関して、Python に触れていましたが）プログラミング経験がほとんどなく、講義が進むスピードも早いので、講義についていくのに必死でした。そのため、わからない部分が講義が終わるたびに出現し、そのたびにサポーターの方に何度も質問をしました。わからないことだらけで何度も挫けそうになりましたが、サポーターの方のサポートのおかげで大きく成長することができ、他の受講生の方々にコードの書き方を教えられるまでに成長することができました。
　この講義では、ただ単にコードの書き方などを学ぶだけでなく、分からないことを放置せず質問することの大切さも学ぶことができました。

個人開発演習​

これまで学んできた IT 技術（主に Spring）を用いて「社員管理システム」の改修を行いました。
　具体的な内容としては、まず要件定義書やフォルダとファイルの構成を確認し、それを基に機能を追加していくというものです。
　この演習で学んだことは、計画を立てながら作業を進めることの大切さです。個人開発演習は５日間しか期間がなく、のんびりと開発していると納期に間に合わなくなってしまいます。そのためいつまでにどこまで作業を完了させるのかを予め具体的に決めておき、作業を進めました。その結果、納期よりも 2 日間程早く作業を完了させることができ、追加機能を実装できる程の余裕ができました。今後も、実際に現場で作業する際も綿密に計画を立てて作業していきます。

チーム開発演習​

最後の 1 か月間はランダムに５人のチームを組み、「ショッピングサイト」の改修をする開発演習に取り組みました。
　具体的な内容としましては、まず初めに役割分担（リーダーや課題管理者、品質管理者など）をし、要件定義書などを読みこみ、追加するオリジナル機能や画面の構成などを決めました。その後は、チームで決めた内容に基づき、要件定義書や設計書などに項目を追加し、開発に取り掛かりました。開発が完了すると、テスト仕様書の作成やデバックに取り組みました。
　この演習で学んだことは、コミュニケーションをこまめにとることの大切さです。この演習では、Git を用いて開発を行っていたのですが、誰がどの作業を行っていたのか把握していなかったことで、チームメンバーのコードをマージする際に競合が発生することがありました。しかし、コーディングをする前にどのファイルを編集するのかを事前にメンバーに共有することで、競合が発生することがなくなりました。また、誰がどこまで作業が進んでいるか、課題は何かなどを共有することで、円滑に開発を行うこともできました。

終わりに​

3 か月間で多くのことを学び、エンジニアとして、そして社会人として大きく成長することができました。\また、ここまで成長することができたのは、講生 50 名という大所帯の中、受講生一人ひとりに真摯に向き合いサポートしていただいたサポーターの方々、そして気さくに接してくれた受講生の方々のおかげだと感じています。今後も、この研修で学んだことを忘れず、仲間を大切にし、プロとして活躍できるよう励んでまいります。
　ここまで読んでいいただき、ありがとうございました。これから研修を受ける予定の新入社員の方などの参考になれば幸いです。

数年前に購入して、そのまま放置してしまっていた、RaspberryPi B3 と、電子工作キットを使ってプログラミング学習をしていきたいと思います。 今回は、外部装置とデジタル信号のやり取りを行う GPIO について解説します。

GPIO について​

GPIO(General Purpose Input/Output)は、デジタル信号を入力にも出力にも使える汎用 I/O ポートで、設定によって様々なデバイスやセンサーの制御、信号の送受信に利用することができます。

RaspberryPi の GPIO ポートの構成について​

RaspberryPi に基板上に 40 本のピンヘッダがあり、その端子に配線することで GPIO を使用することができます。

RaspberryPi の GPIO

GPIO の制御方法​

仮想ファイルシステムで制御​

Raspberry Pi では仮想ディレクトリ/sys/class/gpio を通して GPIO にアクセス出来ます。 仮想ファイルシステムを読み書きして制御するようになっています。

/sys/class/gpio/export

仮想ファイル「/sys/class/gpio/export」にポート番号を書き込むと「/sys/class/gpio」内に"gpio"にポート番号が付いた仮想ディレクトリが作成されます。

$ echo ポート番号 > /sys/class/gpio/export

例えば、仮想ファイル「/sys/class/gpio/export」にポート番号"2"書き込むと、「/sys/class/gpio/」内に「gpio2」という仮想ディレクトリが作成されます。

この仮想ディレクトリ内に GPIO の入出力方向を設定する仮想ファイル「direction」と、入出力値を読み書きする仮想ファイル「value」が作成されます。

/sys/class/gpio/gpio2/direction
/sys/class/gpio/gpio2/value

仮想ファイル「/sys/class/gpio/gpio2/direction」に"out"を書き込むと出力、"in"を書き込むと入力になります。

$ echo 入出力方向 > /sys/class/gpio/gpio2/direction

ポート GPIO2 を出力に設定した場合は以下のコマンドで仮想ファイル/sys/class/gpio/gpio2/value に出力値を書くと、その値が GPIO2 に出力されます。

$ echo 出力値 > /sys/class/gpio/gpio2/value

ポート GPIO2 を入力に設定した場合、以下のコマンドで仮想ファイル/sys/class/gpio/gpio2/value から GPIO2 の入力値を取得することが出来ます。

$ echo /sys/class/gpio/gpio2/value

プログラムからのアクセス(C 言語)​

C 言語で仮想ファイルシステムで GPIO を制御して、LED 点灯 ⇒ 消灯するプログラムの例です。

#include <fcntl.h>
#include <unistd.h>

int main (void)
{
	int fd;

	fd = open("/sys/class/gpio/export", O_RDWR);
	write(fd, "17", 2);
	close(fd);
	sleep(1);

	fd = open("/sys/class/gpio/gpio2/direction", O_RDWR);
	write(fd, "out", 3);
	close(fd);

	fd = open("/sys/class/gpio/gpio2/value", O_RDWR);
	write(fd, "1", 1);
	close(fd);
	sleep(2);

	fd = open("/sys/class/gpio/gpio2/value", O_RDWR);
	write(fd, "0", 1);
	close(fd);

	fd = open("/sys/class/gpio/unexport", O_RDWR);
	write(fd, "17", 2);
	close(fd);

	return 0;
}

ライブラリで制御​

プログラムからのアクセス(Python)​

Python で GPIO を制御するためのライブラリとして、RPi.GPIO、gpiozero がよく使われています。

RPi.GPIO​

• Raspberry Pi の GPIO ピンを制御するための低レベルライブラリ
• より細かい制御が可能で、高度な設定や特定のハードウェアの制御に適している

Python で RPi.GPIO を使用して、LED 点灯 ⇒ 消灯するプログラムの例です。

import RPi.GPIO as GPIO
import time

GPIO_PORT=17

GPIO.setmode(GPIO.BCM)
GPIO.setup(GPIO_PORT, GPIO.OUT, initial=GPIO.LOW)

GPIO.output(GPIO_PORT, 1)
time.sleep(2)
GPIO.output(GPIO_PORT, 0)

GPIO.cleanup()

gpiozero​

• 初心者向けに設計された、より高レベルな GPIO ライブラリ
• LED やボタンなどの一般的なデバイスを簡単に制御するためのクラスや関数を提供
• 自動的にプルアップ抵抗を設定するなど、使いやすさに重点を置いています

Python で gpiozero を使用して、LED 点灯 ⇒ 消灯するプログラムの例です。

from gpiozero import LED
import time

GPIO_PORT=17

led = LED(GPIO_PORT)

led.on()
time.sleep(2)
led.off()

以上、GPIO とその制御方法（の一部分ですが）について紹介いたしました。

次回は、実際に電子工作キットを使用して、プログラミング学習していきたいと思います。

こんにちは。開発 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リポジトリだけ作ってみるだけでも効果があります。小さな一歩を積み重ねながら、一緒にテストの質を向上させていきましょう！

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