OmniAICreator/Qiita-1.07M huggingface dataset:
【Domo】別サーバにあるWorkbenchのジョブをまとめて実行

# はじめに
Domoの管理を行っているとよきタイミングでデータと取り込んでくれとかわがままが多くなってくる。管理者が楽になる方法を記事として書いてみた。

# 対象者
・Workbenchを使って、jobを実行している人
・ちょっとでも楽したい人

# Workbenchってなあに？
昔、記事にしてましたので、参考にどうぞ

https://qiita.com/hidekazu_higashi/items/459c29bf4581467e552b

# JOBを順番連続で実行したい。
Workbenchには取り込むデータごとにJOBが多くあると思います。
弊社でもそこそこあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798145/e845a144-2fcd-416d-a0ef-9aeff0ed57b0.png)

マスターのJOBを取り込んでから、明細を取り込むという順番にしないとDomo上でいろいろと都合が悪い場合があります。
なので、時間を少しずつずらしながらスケジュール実行するなど考えたり、月に一回であれば、順番を考えながら実行していたのですが、飽きました！

# バッチ処理でできそう。
Workbench は、基本的にはスケジュール実行しか対応していませんが、CLI（コマンドラインインターフェース） での実行も可能です。
例の黒い画面です。

# 実行例
## 1. コマンドプロンプトを起動する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798145/62ba11fb-84e3-4a73-b8df-618186b1fc41.png)

## 2.Workbench がインストールされているディレクトリに移動する
標準だったらここ！

```
cd C:\Program Files\Domo\Workbench
```

## Wb.exeを実行する。

実行する前に、対象のDomoドメインと、動かすジョブIDを調べます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3798145/ecfa5b2e-b3f6-43ef-b014-fd3bed428cd2.png)

今回として、下記の情報だったとして、実行をしてみます。
Domoドメイン：xxxxxxx
ジョブID：12

```
Wb.exe run-job -j 12 -s xxxxxxx.domo.com
```

## バッチ処理を作る
いくつかのジョブIDを連続で実行したい場合、下記のようなバッチ処理を作成して、実行すると
順番に実行してくれて、ラクチンです。

``` bat:renzoku.bat
Wb.exe run-job -j 12 -s xxxxxxx.domo.com
Wb.exe run-job -j 13 -s xxxxxxx.domo.com
Wb.exe run-job -j 14 -s xxxxxxx.domo.com
```

# さらに便利にPsExecを使って
弊社では、24時間稼働しているサーバにWorkbenchを入れて運用しています。
そのためWorkbenchの実行のために、リモートデスクトップで入り、実行するということをやっていました。
それすら手間になったので、リモートでバッチ処理を起動する方法も考えました。


## 1.こちらからダウンロード
標準で入っていませんが、Windows純正のソフトでダウンロードするだけで利用できます。
以下よりPsExecをダウンロードし、適当な場所に展開する。
https://technet.microsoft.com/ja-jp/sysinternals/pxexec.aspx

## ポートは下記を利用
ファイアウォールにて以下を開放しておく必要があります。よくわからない方はネットワーク管理者に聞きましょう。
・135/tcp（RPCエンドポイント・マッパー）
・445/tcp（ダイレクト・ホスティングSMB）
・1025～65535/tcp（RPC動的ポート）

## 実行はこんな感じ
サーバのIPアドレス、ログインできるユーザとパスワード、サーバ上のバッチ処理パスをパラメータとして実行する。
```
PsExec.exe -u <user> -p <pass> \\xxx.xxx.xxx.xxx C:\Remote\run_batch.bat
```

v2.1以降であれば、通信自体も暗号化されているようなので、安心して利用可能です。


# まとめ
スケジュール実行できればラクチンですが、どうしてもタイミングを見計らっての手動実行の運用がある場合に、少しでも楽できるようなやり方です。
良かったらお試しください。
watsonx.governanceを学校になぞらえて解説してみる

## はじめに

AIは私たちの生活にどんどん浸透してきていますが、間違った答えを出したり、不公平な判断をしたりするリスクもあります。そこでIBMが提供する **watsonx.governance** は、AIが安全で正しく使われるように管理する仕組みです。

しかし、watsonx.governanceの役割を理解するのは少し難しいかもしれません。そこで、**学校の仕組みになぞらえて**、AIを管理する3つの重要なポイントをわかりやすく説明していきます！

---

## ① モデルのインベントリ管理（AIをリストにして管理する）

### たとえば…「クラスの生徒名簿」

学校では、先生が**クラスにいる生徒の名前や出席番号を名簿にまとめて管理**していますよね？ これがあることで、「このクラスにはどんな生徒がいるのか」「どんな成績を取っているのか」などを把握できます。

AIも同じで、どんなAIモデルを使っているのか、どういうデータで作られたのかをリストにして整理するのが「モデルのインベントリ管理」です。もし問題が起きたとき、「どのAIが原因か？」をすぐに特定できるようにします。

- **watsonx.governanceの役割**
    - どんなAIがどこで使われているか、生徒名簿のようにリストにする
    - AIが作られたときのルールやデータを記録する
    - 問題が起きたらすぐに調べられるようにする

## ② リスクガバナンス（AIがルールを守るようにする）

### たとえば…「校則（ルール）」

学校には「校則」がありますよね？ 「授業中は静かにする」「遅刻をしない」などのルールが決められていて、みんなが正しく学校生活を送れるようになっています。

AIも同じで、「やってはいけないこと」や「守るべきルール」を決めておくのが「リスクガバナンス」です。AIが不適切な答えを出したり、不公平な判断をしないように、**あらかじめルールを設定し、それを守らせる**ことが重要になります。

- **watsonx.governanceの役割**
    - AIが「やってはいけないこと」をルール化する（校則を決める）
    - AIがルールを守っているかチェックする（生徒が校則を守っているか確認する）
    - 問題があったらすぐに対応する（違反したら指導する）

---

## ③ 評価・モニタリング（AIがちゃんと働いているかチェックする）

### たとえば…「定期テストや通知表」

学校では、先生が**定期的にテストをしたり、通知表をつけたりして、生徒の成長を確認**しますよね？ 「この子は国語が得意だな」「この部分はもう少し勉強したほうがいいな」などを見て、必要があれば指導します。

AIも同じで、「このAIはちゃんと正しく答えられているかな？」と、**ずっと見守って評価する**ことが必要です。watsonx.governanceは、**AIの動きをモニタリング（観察）して、問題がないかをチェックする**役割を持っています。

- **watsonx.governanceの役割**
    - AIが正しく答えているかをチェックする（生徒のテストの成績を確認する）
    - まちがった答えを出していないか記録する（間違いが多い科目をチェックする）
    - もし問題があれば、人が見て直せるようにする（成績が下がったら先生がサポートする）

## まとめ

watsonx.governance は、AIを安全に使うための「学校の仕組み」と同じような役割を果たします。

- **モデルのインベントリ管理** → **「クラスの生徒名簿」**（どんなAIがあるかをリストにする）
- **リスクガバナンス** → **「校則」**（AIがルールを守るようにする）
- **評価・モニタリング** → **「定期テスト・通知表」**（AIの働きを定期的にチェックする）

この3つの仕組みのおかげで、AIがまちがったことをしないように、**安全に、正しく使えるようになる**んですね！

## おわりに

watsonx.governanceは、AIが安全に使われるようにするための重要な仕組みです。しかし、技術的な内容が多く、分かりにくいこともあります。今回のように**学校の仕組みに置き換えると、watsonx.governanceの役割がイメージしやすくなったのではないでしょうか？**

AIの活用が進む中で、AIを安全に使うための技術もどんどん重要になっています。watsonx.governanceを活用して、**より安全で信頼できるAI**を目指していきましょう！

## 参考記事
- [IBM watsonx.governance 公式ページ](https://www.ibm.com/products/watsonx-governance)
- [AIガバナンスとは？ AIのリスク管理の重要性](https://example.com/ai-governance)
- [AIモデルのライフサイクル管理とガバナンスの実践](https://example.com/ai-lifecycle-management)
【Teams電話】代表電話を構成する方法

# はじめに

オフィスに出社している時、会社の代表電話などに着信があったら、各座席に配置されている電話機が一斉に鳴動するかと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2680397/b2197b79-ee5a-4ebb-ba8c-4a5ba2d882c6.png)

Teams 電話を使って、このように着信があった際に複数のユーザーを同時に呼び出すには、いくつかの方法があります。この記事では、それらの方法の違いについてまとめました。

# 構成方法の比較

Teams 電話で着信があった際に複数のユーザーを同時に呼び出すには、以下の 3 つの方法があります。

* 通話グループ
* 代理人
* 通話キュー

これらの違いについて以下の観点で表にまとめました。

| 機能名 | 最大同時呼び出し数 | 代表番号による発信 | 通話履歴の共有 |
|:-:|:-:|:-:|:-:|
| 通話グループ | 25 ユーザー | × | × |
| 代理人  | 25 ユーザー | 〇 | 〇 |
| 通話キュー  | 200 ユーザー | 〇 | △ |

表のとおり、まず同時に呼び出しできる最大ユーザー数に大きな違いがあります。25 人を超えるユーザーを同時に呼び出す必要がある場合、通話キューを使用します。

同時呼び出し数が 25 人以下の場合、ユーザーが代表番号で発信を行ったり、ユーザー間で着信履歴の共有が必要であれば、代理人を使用します。

::: note
通話キューではユーザー間で Teams クライアントの通話履歴を共有することはできませんが、ユーザーが Power BI レポートで通話キューの通話履歴を確認することはできます。
:::

※ 関連記事

https://qiita.com/atsmin77/items/933debde93ca328e55be

::: note warn
これらの同時呼び出し先のユーザーが通話転送 (Forward) を設定していても、通話は転送されません。
:::

※ 関連記事

https://qiita.com/atsmin77/items/830a687a99fe817cb29e

## 通話グループ

通話グループは最もシンプルな方法です。ユーザー A に対して通話グループを構成し、着信があったら通話グループを同時に呼び出すよう設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2680397/46e815aa-f5b1-4bbb-9a75-a309ab51e01f.png)

::: note
通話グループには以下のような特徴があります。
* 各ユーザーは通話グループによる着信を自由にオフにできます
* ユーザー数が 5 人以下であれば、各ユーザーを指定した順番で呼び出すこともできます
:::

※ 関連記事

https://qiita.com/atsmin77/items/156c5bdc038f3b688a96

(参考：通話の共有およびグループ通話ピックアップ)
https://learn.microsoft.com/ja-jp/microsoftteams/call-sharing-and-group-call-pickup

## 代理人

代理人は、委任者となるユーザーが代理人に対して、自身の代わりに通話の受発信を委任することができる機能です。この場合、代表番号を割り当てるユーザーが委任者、同時に呼び出されるユーザーが代理人となります。


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2680397/62366d16-45ad-4c22-b06d-46c00bd501f7.png)

::: note
通話グループと異なり、代理人は代表番号 (委任者の電話番号) から発信することができます。また、代理人には委任者の通話履歴が共有されます。
:::

* 委任者の画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2680397/5a6c7001-64a1-4e03-bc30-73b6b56ad0d7.png)

* 代理人の画面
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2680397/90863bee-33bd-4643-9736-767fe43acd3e.png)

※ 関連記事

https://qiita.com/atsmin77/items/77f869629a2e660cd801

(参考：Microsoft Teams での共有回線の外観)
https://learn.microsoft.com/ja-jp/microsoftteams/shared-line-appearance

## 通話キュー

通話キューは、チームや Microsoft 365 グループなどを指定して、呼び出し先を 200 ユーザーまで設定することが可能です。呼び出し方法は同時呼び出しのほか、順番に呼び出す、プレゼンスが応答可能なユーザーを呼び出す、などの制御が行えます。

通話グループや代理人とは異なり、通話キューでは着信があると実際のユーザーではなく、最初にボットが通話を受話します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2680397/0a7704e3-b839-43b0-b78a-d4d8485cde3c.png)

::: note
通話キューの用語
* リソースアカウント：ボット用の仮想的なユーザーアカウント
* エージェント：通話キューから呼び出されるユーザー
:::

通話キューでは、ボットが通話を受話することで以下のような制御を行うことができます。
* 着信時の挨拶メッセージの再生
* タイムアウトなどの例外処理
  例：
  * エージェントが通話を受話しない場合、別の番号に通話を転送する
  * 許容量を超える着信があった場合、メッセージを再生して通話を終了する

::: note warn
通話キューでは、代理人のようにエージェント間で通話履歴を共有することはできません。
:::

※ 関連記事

https://qiita.com/atsmin77/items/cd0d7f0fa8569d677e6f

(参考：Microsoft Teamsで通話キューを作成する)
https://learn.microsoft.com/ja-jp/microsoftteams/create-a-phone-system-call-queue?tabs=general-info

# おわりに

通話グループ、代理人、通話キューは Teams 電話の異なる機能ですが、複数のユーザーを呼び出すことができる点は同じです。どれを使えばいいか検討するにあたり、ポイントを絞って比較してみました。ご参考になれば幸いです。
【SpringBoot】初めてのSpring Boot

# 初めてのSpring Boot

ツール：Eclipse

## 1. まずSpringBootでHello Worldを出力しましょう。
Eclipse > ファイル > 新規 > Spring スターター・プロジェクト
※名前とパッケージ名は任意のものでOKです。
タイプはMavenを選択してください。

依存関係は、Spring Boot DevTools,  Spring WEB, H2 Database, Spring Data JPA, Thymeleaf, Validation
完了を押下すると、Spring Boot プロジェクトが作成されます。

|  |    |
| :--: | :--: |
| Spring Boot DevTools|開発補助モジュール。自動リロードやブラウザが自動更新 |
| Spring WEB | Spring MVCを使用したWebアプリケーションを作成可能 |
| H2 Database | SQLデータベースエンジン |
| Spring Data JPA | Spring bootでデータベースにアクセス |
| Thymeleaf | テンプレートエンジン。動的なWebページを作成可能 |			
| Validation | 入力チェック |

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3279952/1f97377c-0046-48e8-bb97-68c081b22cdd.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3279952/fa79f198-d0ad-4eec-b057-3e2045146895.png)

作成されたファイルについて説明していきます。

```/demo/src/main/java/com/example/demo/DemoApplication.java
package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication // Spring Bootのアプリケーションクラス
public class DemoApplication {

    public static void main(String[] args) {
// アプリケーション起動メソッド　アプリケーションクラスのインスタンスとパラメータを渡しています。      
        SpringApplication.run(DemoApplication.class, args);
    }
}
```

### @SpringBootApplication
Spring Bootアプリケーションのエントリーポイントに付けるアノテーションです。
このアノテーションは、以下の3つのアノテーションをまとめたものです。
@Configuration
@EnableAutoConfiguration
@ComponentScan
このアノテーションを付けることで、Spring Bootアプリケーションの基本的な設定が自動的に行われます。

### /demo/src/main/resources/application.properties
application.propertiesとはSpring Bootで用意されている
デフォルトの設定ではなく環境独自の設定を行うためのファイルです。

### /demo/src/test/java/com/example/demo/DemoApplicationTests.java
テストクラス


## 2.では、実際にソースコードを以下のように編集して表示させてみましょう。


```diff_java:/demo/src/main/java/com/example/demo/DemoApplication.java
	import org.springframework.boot.SpringApplication;								
	import org.springframework.boot.autoconfigure.SpringBootApplication;
+ 	import org.springframework.web.bind.annotation.GetMapping;								
+	import org.springframework.web.bind.annotation.RestController;								
									
	@SpringBootApplication // Spring Bootのアプリケーションクラス								
+	@RestController // REST APIアノテーション								
	public class DemoApplication {								
									
	    public static void main(String[] args) {								
        // アプリケーション起動メソッド　アプリケーションクラスのインスタンスとパラメータを渡しています。      								
            SpringApplication.run(DemoApplication.class, args);								
        }								
        
+       @GetMapping() // GETリクエストがあった場合の処理 引数が空の場合は / となる				
+       String index() {								
+           return "hello world!";								
+       }																
	}
```

## 3.アプリケーションを実行します。
パッケージ・エクスプローラーのルートディレクトリを右クリック > 実行 > Spring Bootアプリケーション
するとコンソールに以下の出力がされます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3279952/883963e9-c73d-40dd-b274-82f2d8901886.png)

http://localhost:8080/

で動作を確認して終了です。

次回は、MVCモデルの説明とSpringBootにおけるMVCの説明になります。
第6回:リモート環境での品質保証（QA）戦略

## **1. はじめに**

オフショア開発では、地理的な距離や時差の影響により、品質管理が難しくなることがあります。品質保証（QA）を適切に行わないと、リリース後にバグが多発し、追加のコストや納期遅延が発生するリスクが高まります。

本記事では、オフショア開発チームと効果的にQAを進めるための戦略やツールを具体例とともに解説します。

---

## **2. オフショア開発における品質管理の課題**

オフショア開発において、品質保証が難しくなる主な要因は以下の通りです。

1. **仕様理解のズレ**：
   - オフショアチームが要件を正しく理解していない。
   - ドキュメントの不足や変更が適切に共有されていない。
   
2. **テスト環境の不統一**：
   - ローカル環境、本番環境、テスト環境の差異。
   - 環境設定のミスによるバグの発生。
   
3. **コードの品質管理不足**：
   - コードレビューが不十分。
   - 自動テストの導入が遅れ、バグが後工程で発覚。

4. **コミュニケーションの問題**：
   - バグ報告の伝達ミス。
   - テスト結果の共有が適切に行われていない。

---

## **3. 品質保証（QA）を強化するための戦略**

### **(1) コーディングとドキュメントの標準化**

**コードの品質基準を明確化**
- コーディング規約を策定し、統一したルールを適用。
- 例：「すべてのコードに対してESLintやPrettierを適用し、統一されたコードスタイルを維持。」

**詳細なドキュメント作成**
- ConfluenceやNotionを活用し、常に最新の仕様を共有。
- 例：「API仕様書をOpenAPIで作成し、開発チームが容易に参照できるようにする。」

---

### **(2) 効率的なテスト戦略の導入**

**ユニットテストの徹底**
- Jest, Mocha, JUnitを活用し、コードの各部分が期待通りに動作するか検証。
- 例：「すべての新機能に対して80%以上のコードカバレッジを達成することを目標とする。」

**自動化テストの導入**
- Selenium, Cypress, Playwrightを活用し、UIテストを自動化。
- 例：「E2EテストをCI/CDパイプラインに組み込み、新しい変更が本番環境に影響を与えないようにする。」

**APIテストの実施**
- Postman, Newmanを活用し、APIの動作確認を自動化。
- 例：「REST APIのレスポンスが正しく返されるか、定期的に自動テストを実行する。」

**リグレッションテストの強化**
- 以前のバージョンで問題がなかった機能が、新しい変更で壊れていないかを検証。
- 例：「主要なフローに対して回帰テストスイートを実行し、予期しないバグを防ぐ。」

---

### **(3) CI/CDの活用による品質向上**

**自動テストをCI/CDに組み込む**
- GitHub Actions, GitLab CI/CD, Jenkinsを利用し、コードの変更が即座にテストされるようにする。
- 例：「新しいコードがプッシュされるたびに、自動テストが実行され、エラーがあれば開発者に通知される。」

**ステージング環境での事前テスト**
- 本番環境と同じステージング環境を用意し、デプロイ前に最終チェック。
- 例：「オフショアチームがテスト環境を使い、事前に動作検証を行うことで、不具合を未然に防ぐ。」

**エラーログの監視と分析**
- Sentry, Datadogを活用し、本番環境のエラーログをリアルタイムで監視。
- 例：「本番環境でエラーが発生した際に、Slack通知を送ることで迅速に対応できるようにする。」

---

### **(4) バグ管理とフィードバックの徹底**

**バグトラッキングツールの活用**
- Jira, Bugzilla, Redmineを利用し、バグの管理と対応をシステム化。
- 例：「すべてのバグをJiraに登録し、担当者を割り当てて進捗を可視化する。」

**定期的なレビューとフィードバック**
- スプリントごとに品質評価を実施し、改善点を共有。
- 例：「毎月QAレビューを実施し、発見された問題の傾向を分析し、予防策を講じる。」

**テスト結果の可視化**
- Allure, TestRailを利用し、テストの進捗状況をダッシュボードで確認。
- 例：「テストの成功率やバグの発生率をグラフ化し、改善ポイントを特定する。」

---

## **4. 成功事例**

### **成功事例: 日本企業C社とベトナムのオフショア開発チーム**

**課題**:
- 開発スピードは速かったが、リリース後のバグが多発し、修正コストが増加。

**対策**:
- Cypressを導入し、E2Eテストを自動化。
- GitHub Actionsでコードの変更時にユニットテストを実行。
- Jiraでバグ管理を徹底し、定期的なQAレビューを実施。

**結果**:
- バグの発生率が40%削減。
- 修正コストが30%削減。
- 品質の向上により、クライアント満足度が向上。

---

## **5. まとめ**

 **コード品質を向上させるために標準化を徹底**
 **自動テストを導入し、QAの効率を向上**
 **CI/CDを活用して品質管理を強化**
 **バグ管理とフィードバックループを最適化**

適切なQA戦略を導入することで、オフショア開発でも高品質なソフトウェアを提供することが可能になります！
次回は **[第7回:信頼とコミットメントを築く](https://qiita.com/BNR-Satoshi/items/da48408b2b90e2d335e6)** について解説します！
inflearn 人気ゲーム講義

こんばんは、韓国在住sanaです！


it教育プラットフォーム　inflearn（インフラン）の人気ゲーム開発講義を紹介します！

約８年ゲーム開発をしているrookiss講師の講義は受講者７万人を超えるほど大人気:sparkles:

初心者でも始めやすい入門コースからプログラミング基礎が身についている経験者向けの中級コースまで幅広くあります。

インフランの講義からゲーム開発者の道を目指してみませんか？？


https://u.inf.run/3XVTpu9

https://u.inf.run/41zHdAw

https://u.inf.run/4iaNpWK

https://u.inf.run/41x8rb1
"Cannot update a component () while rendering a different component ()."エラー解消法

# はじめに

**`Cannot update a component () while rendering a different component ().`のエラー**が出ました。
```
Cannot update a component (`Router`) while rendering a different component (`Private`). To locate the bad setState() call inside `Private`, follow the stack trace as described in https://react.dev/link/setstate-in-render
```
# 原因
**レンダー中に別コンポーネントの状態変更が発生していることが原因**でした。

以下参照です。

https://ja.legacy.reactjs.org/blog/2020/02/26/react-v16.13.0.html#warnings-for-some-updates-during-render

>React コンポーネントは、レンダー中に他のコンポーネントに副作用を起こしてはいけません。
レンダー中に setState を呼び出すことはサポートされていますが同じコンポーネントに対してのみ可能です。


# 解決方法
**該当部分に`useEffect`を使うことで、レンダリング後に副作用として実行**するようにしました。

**修正前**
レンダー中に`Private`コンポーネントで`router.push`を実行してしまっています。

```tsx:page.tsx
const Private = ({ children }: { children: React.ReactNode }) => {
  const router = useRouter();

    if (!loading) {
      if (isSignedIn) {
        return children;
      } else {
      　//該当部分
        router.push(`/signin`);
      }
    } else {
      return <></>;
    }
  };
  return (
    <AuthContext.Provider
      value={{ currentUser, setCurrentUser, isSignedIn, setIsSignedIn }}
    >
      <Private>
        <p>Homeページです</p>
      </Private>
    </AuthContext.Provider>
  );
```

**修正後**
レンダリング中に `router.push`を実行しないように、`useEffect`でラップしています。依存配列を明示的に指定し、不要なレンダーを防ぎます。
```tsx:page.tsx
const Private = ({ children }: { children: React.ReactNode }) => {
  const router = useRouter();

  useEffect(() => {
    if (!loading && !isSignedIn) {
      router.push("/signin");
    }
  }, [loading, isSignedIn, router]); // 依存配列を明確にする

  if (loading) {
    return <></>; // ローディング中は何も表示しない
  }

  if (!isSignedIn) {
    return null; // リダイレクト中はコンテンツをレンダリングしない
  }

  return <>{children}</>;
  };
  return (
    <AuthContext.Provider
      value={{ currentUser, setCurrentUser, isSignedIn, setIsSignedIn }}
    >
      <Private>
        <p>Homeページです</p>
      </Private>
    </AuthContext.Provider>
  );
```
下記も参考になります。

https://zenn.dev/kingdom0927/articles/bfccfcf272dee9

# おわりに
エラーは解消しましたが、エフェクトの多用はアンチパターンとして取り上げられているので、使うべきかどうかは迷いどころです。
用法に注意したいところです。

https://ja.react.dev/learn/you-might-not-need-an-effect#
Python応用

こんにちは、韓国在住sanaです！

初心者でも扱いやすいシンプルで読みやすいコードが特徴のPython

使い方次第でデータ分析やAI、ウェブ開発など、さまざまな分野で活用できるため、現在でも人気のあるプログラミング言語です:sparkles:

Pythonの基礎を勉強した後は、様々な分野にも挑戦したくなりますよね？？
そこで、今日はパイソンを使って学ぶのに適した分野別のおすすめ講義を紹介します:point_up:

今週も一週間頑張りましょう！　ファイティン～




https://u.inf.run/3XZv2fd

https://u.inf.run/42bTAUE

https://u.inf.run/3FwEW1r

https://u.inf.run/4ivSRDj

https://u.inf.run/4iRo189
RAID構成におけるパリティディスク利用方法の最適解

エンタープライズ向けにストレージ製品を提案する際、どんなタイプのドライブを選んでいただいたとしても基本的にはドライブを複数本買っていただいて、RAID構成による冗長化と性能向上を果たした形で実際に運用をしてもらっている。

今回の投稿では専用ストレージ機器を使用するユーザさんがよく使用されるRAID構成と全く使用しないRAID構成の両方について記述していきたい。そして利用目的ごとの最適解は何なのか、についても自分なりの考えについても触れたい。

## 目次
- RAID技術におけるパリティとは
- パリティディスクを用いるRAIDタイプ
- パリティ専用型方式とパリティ分散型方式の違い
- 最終的な性能比較

## RAID技術におけるパリティとは

まずはパリティという用語について。データの冗長性と信頼性を向上させるために利用される技術である。
このパリティはとっかかりとしてミラーリング(コピー)とまずは比較されるものかもしれない。

実効容量8TBを冗長化させたい。その場合のミラーリング(RAID1)構成ではHDD SATAディスク8TB×2本となる。シンプルな反面、冗長性に必要な容量を食べすぎているきらいがある。

パリティを使ったRAID構成では、ミラーリングと比較して冗長化に使う容量を少なくできる。ミラーリング(RAID1)のデータ領域と冗長化領域が1:1だとすると、パリティはデータ領域と冗長化領域は3:1くらいの比率で構成することも可能だ。


## パリティディスクを用いるRAIDタイプ

- **RAID3**：パリティ情報を専用のパリティディスクに保存する。並行稼働による全ディスクにわたるデータの完全ストライプ方式のため大きなデータ転送に適している。その反面、小さなデータ転送には不向き。
- **RAID4**：RAID3同様にパリティ情報を専用のパリティディスクに保存する。ただデータディスクには個別にアクセスできるため、読み書きのスループットは高い。パリティ専用ディスクに書き込みが集中するリスクがある。
- **RAID5**：パリティ情報を各ディスクに分散して保存する。パリティへの書き込み集中が発生しないためパフォーマンスが上がる。ランダムI/Oに強みが活かせるためRDBMSなどのデータベース関連でよく使われる。
- **RAID6**：RAID5からパリティ情報を2本のディスクに分散して保存する。そのため複数のディスクが同時に故障しても復元が可能となる。ただ書き込みのたびにパリティ構成の調整が走るので、1回のI/Oにかかる負荷は大きい。

現在、エンタープライズ向けシステム用に専用ストレージを使っているユーザさんは基本的にRAID5、RAID6で運用をしている。
専用ストレージではなく、例えばサーバ機器内のディスクを保存領域として使っている際はミラーリング(RAID1)を使うユーザさんもいる。
パリティを使った構成でRAID3、RAID4を使っているユーザさんは、個人的な業務の範囲だとまだ目にしていない。


## パリティ専用型方式とパリティ分散型方式の違い

あくまで私個人の業務範囲の話であるが、なぜこれほどまでにパリティ専用型(RAID3)とパリティ分散型(RAID5)で利用比率に差が出てしまったのか。

より詳細に両者の違いに着目しながら考察していきたい。

パリティ専用型はパリティディスク以外のディスクでまるごとデータの保存領域として使われているので、データだけの抽出はシンプルで速い。そして何より連続データの大容量転送にかなり強みを持っている。

そのためやはりシーケンシャルI/Oで強みを発揮するような使い方では優れたパフォーマンスが期待できる。
その一方でパリティ専用ディスクが故障してしまった場合、全てのデータ消失と隣り合わせである。

パリティ分散型は全てのディスクにデータとパリティが混在して保存されているため全データ消失のリスクは限りなく低い。そして読み取り性能もそこまで悪くない構成でもある。安全性とパフォーマンスのバランスが良いのだ。

デメリットを挙げるとしたら書き込みの度にパリティ計算が発生するため上書き更新が頻繁なシステムだとパフォーマンスが低下する恐れはある。ディスク故障時のデータ再構築に時間がかかりがちである。

どちらの方式もメリット・デメリットは存在するが、汎用的に利用したいのであればパリティ分散型のメリットの方が魅力的である。


## 最終的な性能比較

| RAID | 読み取り性能 | 書き込み性能 |データ保護  |
|:-----------|------------:|:------------:|:------------:|
| 3      | ランダム読み取り：中<br>シーケンシャル読み込み：高| 小ランダムデータ書き込み：低<br>大シーケンシャル書き込み：中         | 高い         |
| 4          |ランダム読み取り：高<br>シーケンシャル読み取り：高|ランダム書き込み：中<br>シーケンシャル書き込み：中| 高い       |
| 5       |ランダム読み取り：高<br>シーケンシャル読み取り：高|ランダム書き込み：中<br>シーケンシャル書き込み：中| 高い         |
| 6         |ランダム読み取り：高<br>シーケンシャル読み取り：高|ランダム書き込み：低い<br>シーケンシャル書き込み：中 |とても高い|

## ひとりごと

3月になったら暖かくなるのかなと思いつつ、雪が降ったり、かと思えば桜が咲き始めたりと脈絡のない季節感に振り回されている。

世間ではロサンゼルス・ドジャースの来日で熱狂している。自分が中学生の時、テレビでの観戦だったがニューヨーク・ヤンキースが東京でMLB開幕戦を行ない、松井秀喜選手がホームランを打ったことを強く記憶している。

20代になってMLBのテレビ観戦にハマったのは、間違いなくあの時、目に焼きつけたことが影響しているはず。
今回の来日も現代の小中学生にとってそういう体験になればと思っている。
CloudShellからAWSCLIでAssumeRoleするには

1. CloudShell起動
1. .awsのconfigを修正
    ```
    vi ~/.aws/config
    ```
1. credential_sourceにEcsContainerを設定すると、CloudShellコンテナの認証情報でAssumeRole可能
    ```
    [default]
    region = ap-northeast-1
    output = json
    
    [profile ARole]
    eole_arn = arn:aws:iam::AAAAAAAAAAAA:role/ARole
    credential_source = EcsContainer
    
    [profile BRole]
    role_arn = arn:aws:iam::BBBBBBBBBBBB:role/BRole
    credential_source = EcsContainer
    ```
1. `--profile`をつけてコマンド実行
    ``` 
    aws s3 ls --profile ARole
    ```
完
第5回:オフショア開発を最適化するための技術とツール

## **1. はじめに**

オフショア開発を成功させるためには、適切なツールと技術の活用が不可欠です。チーム間のコミュニケーションを円滑にし、プロジェクト管理や開発の効率を最大化するために、最新のツールを活用することで、多くの課題を解決できます。

本記事では、オフショアチームと円滑に協力するために役立つ技術やツールを紹介し、具体的な活用事例を交えて解説します。

---

## **2. オフショア開発に適した技術とツール**

### **(1) コラボレーションツール**
オフショアチームとスムーズに情報共有を行うためには、リアルタイムでのコラボレーションが重要です。

**Figma**（デザイン共有）
- デザイナーと開発者がリアルタイムでデザインを確認・修正。
- 例：「UIの変更点を即座に共有し、オフショアチームが素早く対応。」

**Confluence**（ドキュメント管理）
- 仕様書、設計資料、議事録を一元管理。
- 例：「仕様の変更が発生した際、全員が同じページを確認できる。」

**GitHub / GitLab / Bitbucket**（コード管理）
- バージョン管理、ブランチ戦略を明確化し、効率的なコードレビューを実施。
- 例：「Pull Requestごとに自動テストを実行し、バグを未然に防ぐ。」

---

### **(2) プロジェクト管理ツール**
オフショアチームと円滑にプロジェクトを進めるために、タスクの可視化が不可欠です。

**Jira**（アジャイル開発向け）
- スプリント計画、タスク管理、進捗確認を一元管理。
- 例：「オフショアチームのタスク進捗を可視化し、遅延を未然に防ぐ。」

**Trello / Asana**（タスク管理）
- シンプルなカンバン方式でタスクを整理。
- 例：「開発タスクをボードで管理し、どの作業が進行中か一目で分かる。」

**Notion**（ドキュメント & タスク統合管理）
- ドキュメントとタスクを統合管理し、チーム全体で情報を共有。
- 例：「仕様変更をNotionに記録し、チームが常に最新情報を把握。」

---

### **(3) CI/CD（継続的インテグレーション & デリバリー）**
オフショア開発では、品質を維持しながら迅速にデプロイする仕組みが重要です。

**Jenkins / GitHub Actions / GitLab CI/CD**
- 自動ビルド・テスト・デプロイのパイプラインを構築。
- 例：「コードがコミットされるたびに自動テストを実行し、バグを早期発見。」

**Docker / Kubernetes**
- 環境の統一化により、ローカル・開発・本番環境の差異を解消。
- 例：「オフショアチームと同じコンテナ環境を共有し、開発環境のズレを防ぐ。」

**Selenium / Cypress / Postman**（テスト自動化）
- UIテストやAPIテストを自動化し、品質を確保。
- 例：「リグレッションテストを自動化し、デプロイ時の手作業を削減。」

---

### **(4) セキュリティとアクセス管理**
オフショア開発では、データの安全性を確保するために適切なセキュリティ対策が必要です。

**VPN / Zero Trust アクセス**
- 安全なリモートアクセスを提供。
- 例：「開発者がVPN経由で社内リソースにアクセスし、セキュリティリスクを低減。」

**AWS IAM / Google Cloud IAM**（アクセス管理）
- 必要な権限のみ付与し、不要なアクセスを制限。
- 例：「オフショアチームには特定のリソースへのアクセス権のみを付与。」

**Git Secrets / SonarQube**（セキュリティチェック）
- コードのセキュリティスキャンを自動化。
- 例：「機密情報がGitリポジトリに誤ってコミットされるのを防ぐ。」

---

## **3. 成功事例**

### **成功事例: 日本企業B社とインドのオフショア開発チーム**
**課題**: 仕様の変更が頻繁に発生し、オフショアチームが最新情報を把握できず、開発が遅れる。

**対策**:
- Confluenceで最新の仕様を一元管理。
- Jiraでスプリント計画を明確化し、進捗を可視化。
- CI/CDを導入し、開発スピードを向上。

**結果**:
- 仕様変更によるミスが50%減少。
- 開発スピードが30%向上。
- チーム間のコミュニケーションがスムーズになり、開発効率が向上。

---

## **4. まとめ**

- **適切なツールを活用し、オフショア開発を効率化する**
- **コラボレーションツールで情報共有を円滑にする**
- **CI/CDを導入し、品質を維持しながら開発を加速する**
- **セキュリティ対策を徹底し、安全な開発環境を構築する**

適切な技術とツールを活用することで、オフショア開発の課題を克服し、よりスムーズで生産的なチームワークを実現できます！
次回は **[第6回:リモートでの品質保証（QA）](https://qiita.com/BNR-Satoshi/items/56ae9f3325c16023d220)** について解説します！
for か while か？使い分けは目的に合わせて

プログラミングをやっていると、「`for` で書いたほうがいいのか？それとも `while`？」と迷うこと、ありませんか？僕は実際に Paizaの問題で、`for` で書いたら無駄に複雑になりました。

問題概要

最初の状態：
パイザ君 と 霧島京子 は、それぞれ `1` を持っている。

操作ルール：
パイザ君の番: 自分の数を `a` 倍 し、京子の数に足す。
霧島京子の番: 自分の数を `b` で割った余り を、パイザ君の数に足す。

ゲームの終了条件：
京子の数が `n` より大きくなったら 終了！
このときのパイザ君の操作回数を求める。

📥 入力例:
```
6  //n
3 2  //a b
```
📤 出力例:
```
2  
```

## <br>❌ 最初に書いたコード（for を使った）
```js
for (let count = 1; ; count++) { // 条件なしの for
    kyoko += paiza * a;
    if (n < kyoko) { 
        console.log(count);
        break;
    }
    paiza += kyoko % b;
}
```

for なのに「何回回るかわからない」設計
    → 普通 for は 「回数が決まっている」 ときに使うもの。
    
break で無理やりループを抜ける書き方
    → while にすれば break なしでスッキリ書ける。


## <br>✅while を使う
```js
while (kyoko <= n) { // 明確な条件を指定
    count++;
    kyoko += paiza * a;
    paiza += kyoko % b;
}
console.log(count);
```
✅ 「条件が明確」
→ 「京子の数が n 以下の間ループする」 ので break 不要！
✅ カウンタ変数 (count) の管理が自然
→ while 内で count++ すれば OK

## <br>まとめ：for と while の選び方

for → 「回数が決まっている」場合
while → 「条件が続く限りループ」する場合

「とりあえず for で書こう」は危険！ ループの目的を考えて使い分ける のが大事です。

<br>[僕の失敗談と解決話！](https://paizabeginner.wordpress.com/2025/03/17/paiza%e3%81%a7%e5%9f%ba%e6%9c%ac%e3%83%9e%e3%82%b9%e3%82%bf%e3%83%bc-%e3%83%ab%e3%83%bc%e3%83%97%e3%81%ae%e9%81%b8%e6%8a%9e%e3%83%9f%e3%82%b9-for%e3%81%a8while%e3%81%ae%e4%bd%bf%e3%81%84%e5%88%86/)
ONE COMPATH社内におけるAIへの取り組み歴史

# はじめに
株式会社ONE COMPATHのうぃるです。
前身のマピオン時代からジョインして、ITエンジニア歴約20年です。
現在はマネジメント系業務に携わっています。
今回は私が所属している部門や部門外関係者で対応したONE COMPATH社内における
「AIへの取り組み」について時系列で紹介します。


# この記事の対象者
:::note info
- AIに興味があり、社内のAIに関する取り組み概要をざっくり知りたい方
- ONE COMPATH社のエンジニア採用に興味がある方
  [ONE COMPATH エンジニア採用サイト](https://onecompath.com/recruit/engineer/index.html)
- AI経験をこれから積んでいきたい方、応募お待ちしてます！！
:::


# ここでは記載しないこと
- 各社AIの機能、性能、金額等の詳細

# Azure OpenAI Service
2023年4月頃、社内で一番最初に導入したモノです。

- [Azure OpenAI Service](https://azure.microsoft.com/ja-jp/products/ai-services/openai-service)
 
Microsoft様に社内勉強会を開催していただき、セキュリティ、情報統制的なことも考慮して採用しました。

当時は今ほどAI利用が一般的ではなかったため、 **「気軽にAIに触れてみよう」** を導入目的としました。
Slackと連携し、Slack上で質問を投げると回答してくれるという使い方が最も多かったですね。導入初日は結構盛り上がりました(Slack上で)。
スプレッドシートにキーを埋め込んで、質問をスプシ記載して回答してもらい一覧化する、といった情報収集にも活用されました。

今現在(2025年3月)では、弊社提供サービスの画像分析周りでも利用しています。


# GitHub Copilot
こちらも2023年春頃に導入したモノです。
社内で最も生産性向上につながったであろう施策となります。

- [GitHub Copilot](https://docs.github.com/ja/copilot/about-github-copilot)

多くの開発エンジニアが利用しており、社内アンケートの結果からも好評です。
ちなみに「どんな利用している？」という社内アンケート結果はこのような内容でした。
（%は各項目における利用割合）

- コードの自動生成 (95%)
- Chat機能を活用して調査スピード向上（72%）
- コードレビュー（45%）
- テストコード生成（29%）
- ドキュメント作成（10%）
- リファクタ相談(2%)


「もうCopilotなしじゃ仕事できない」「昔に戻れない」という声を聴くとうらやましくもあります。（私も開発経験は2年程ありますが、約15年前のお話しなので）

:::note info
GitHub Copilotは費用対効果や利用ニーズが高く、当社では技術職の全従業員が利用できるよう環境を整備しています。
:::


# GenU(Generative-AI-Use-Cases-JP)
発音はたぶん「じぇんゆー」。
- [Generative AI Use Cases JP](https://github.com/aws-samples/generative-ai-use-cases-jp)

「Azure OpenAI Service」を導入しましたが課題がありました。
それはエンジニア以外では使いづらい面があったところです。
　（我々の「社内提供の仕方」に問題がありました。サービス自体は素晴らしいです）

エンジニアはアクセスキーさえあれば何かと利用シーンがありますが、
全社展開を想定するとエンジニア以外の方にはUI的に使いづらく、社内での浸透がイマイチでした。

そんな話を社内でしていたところ部門内のメンバーが「2024 AWS Summit Japan」 に参加した翌日に「これいいんじゃない？」と共有してくれたことがきっかけです。
爆速で導入しました。

現状(2025年3月)は全社展開前のスモールスタート状態ではありますが、
企画系の方々に使ってもらえる機会が増え、GenUを活用した業務改善プロジェクトも立ち上がり、導入した手ごたえを感じています。近いうちに全社展開としたいです。

# その他AI関連
記事が長くなりそうなので割愛しましたが、2024年夏頃から以下を利用したサービス検証もしています。

- [Amazon Bedrock](https://aws.amazon.com/jp/bedrock/)
- [Gemini](https://gemini.google.com/?hl=ja)

検証していると
- 実現したいことは同じでも利用AI毎に特性が出でる
- もちろん精度も違う
- バージョンアップするだけで精度が上がったり、安くなったり

「バージョンアップについてくだけでも大変」「実現したいことによって、AIを使い分ける仕組みが必要」(社内某エンジニア談)と変化が激しい技術要素ではありますが、サービス実現に向け取り組み最中です。

# 社内展開の仕方
AI活用における「期待できる効果」は多岐に渡ります。そのため社内では

- 新商材創出を目的としたプロジェクト
- 社内業務改善、生産性向上を目的としたプロジェクト

と2軸で 2024年から活動しています。
Copilotネタや活用方法を技術勉強会で共有したり、社内アンケート取ったり、全社員参加の全体会議で事例紹介したり、と活動を続けています。

# おわりに
今回はONE COMPATHにおけるAIの取り組みについて紹介しました。当社では、AI関連の職種だけでなく、アプリエンジニアやサーバサイドエンジニアなど幅広い技術職を積極採用しています。興味のある方はぜひカジュアル面談からでもお話ししましょう！

:::note info
- [ONE COMPATH エンジニア採用サイト](https://onecompath.com/recruit/engineer/index.html)
資格取得支援やUdemy提供など自己研鑽サポートが複数あります。
ぜひご参照ください。
- [求人一覧](https://recruit.jobcan.jp/one-compath/list?category_id=23519)
:::


# 参考
- [Azure OpenAI Service](https://azure.microsoft.com/ja-jp/products/ai-services/openai-service)
- [GitHub Copilot](https://docs.github.com/ja/copilot/about-github-copilot)
- [Generative AI Use Cases JP](https://github.com/aws-samples/generative-ai-use-cases-jp)
- [Amazon Bedrock](https://aws.amazon.com/jp/bedrock/)
- [Gemini](https://gemini.google.com/?hl=ja)
第4回:オフショアチームとの共通文化の構築

## **1. はじめに**

オフショア開発の成功には、技術力だけでなく、文化的な違いを理解し、共通の価値観を築くことが不可欠です。文化の違いを乗り越え、信頼関係を構築することで、チームの生産性やモチベーションが大きく向上します。

本記事では、オフショアチームと共通文化を築くための具体的な方法と成功事例を紹介します。

---

## **2. 文化の違いがもたらす課題**

### **(1) コミュニケーションスタイルの違い**
- **日本**: 暗黙の了解や間接的な表現を重視（「空気を読む」文化）
- **欧米**: はっきりと意見を伝えることが一般的
- **アジア（ベトナム、インドなど）**: 上司の指示を重視し、自発的な提案が少ない傾向

**解決策**:
- **期待値を明確にする**（「わかりました」＝理解ではなく「確認のためにリピートしてもらう」）
- **フィードバックの文化を作る**（定期的な振り返りの場を設ける）

### **(2) 仕事の進め方の違い**
- **日本**: 計画をしっかり立て、細かい部分まで丁寧に作業する。
- **欧米・インド**: スピードを重視し、柔軟な対応を優先する。

**解決策**:
- **「なぜこのプロセスが必要か」背景を説明する**
- **ウォーターフォールではなく、アジャイル的な進め方を取り入れる**

---

## **3. 共通文化を構築する方法**

### **(1) ビジョンと価値観の共有**
- プロジェクトの**目的やゴール**を明確にし、チーム全体で共有する。
- 例：「このプロダクトは日本市場で〇〇を解決するために作られている」

### **(2) オープンなコミュニケーションを促進**
- **週1回の「文化交流ミーティング」** を実施（仕事以外の話をする場を設ける）
- **SlackやChatツールで気軽に話せる環境を作る**（「雑談チャンネル」を設ける）

### **(3) バーチャル・チームビルディング**
- オンラインゲーム、クイズ、リモートランチ会などを実施。
- 例：「毎月1回、オフショアチームとオンラインでゲーム大会を開催」

### **(4) 相互理解を深める研修の実施**
- **クロスカルチャートレーニング** を実施し、文化の違いを学ぶ。
- 例：「日本企業のオフショア開発では、『報告・連絡・相談（ホウレンソウ）』が重要だと説明」

---

## **4. 成功事例**

### **成功事例: 日本企業A社とベトナム開発チーム**
**課題**: 日本側とベトナム側の認識の違いが原因で、プロジェクトの進捗が遅れがち。
**対策**:
- 毎週の「**文化交流ミーティング**」を実施し、相互理解を促進。
- 日本側が「報告・連絡・相談」の重要性を説明し、ベトナム側も積極的に情報共有。
**結果**: プロジェクトの手戻りが減り、開発効率が20%向上。

---

## **5. まとめ**

- **文化の違いを理解し、共通の価値観を作る**
- **ビジョンを共有し、オープンなコミュニケーションを促進**
- **オンラインでのチームビルディングを活用**

オフショアチームとの信頼関係を築き、より強いチームを作りましょう！
次回は **[第5回:サポートするテクノロジーとツール](https://qiita.com/BNR-Satoshi/items/a00797e854fefd5070f2)** について解説します！
AWSが展開するデータベースカテゴリのサービスの一覧

## はじめに
AWSが展開するデータベースカテゴリのサービスの一覧についてまとめてみました。

## データベースカテゴリ
　可用性や保全性などの非機能要件を高めたデータベースサービス群。様々なデータベースが提供されているので、種類や内容を理解し、ワークロードに応じたものを選択できるようにしたい。

 ## Amazon Aurora
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/a628ddfa-b663-49a1-92d2-acaca8e42879.png)
 クラウドで最適化されたストレージデータ配置により、高可用性・高性能を実現したリレーショナルデータベース。

 ## Amazon DocumentDB
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/d5998d10-285a-47dd-bf40-4d714f959be6.png)
 オープンソースデータベース「MongoDB」との互換性を持つドキュメント指向データベース。

 ## Amazon DynamoDB
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/a6f0def0-495f-4d4e-99f3-f18edcdad00a.png)
 スケーラブルな特性を持つ、NoSQLスキーマレスデータベース。

 ## Amazon ElastiCache
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/55e0fa2b-0694-4bd4-857c-1bd0e09f0c2c.png)
 オープンソースソフトウェア「Memcached」および「Redis」を利用したキャッシュ向けデータベース。

 ## Amazon Keyspaces (for Apache Cassandra)
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/733edb0e-de88-48dc-bc17-5e5f750b78ad.png)
 オープンソースデータベース「Apache Cassandra」を利用したスケーラブルNoSQLデータベース。

 ## Amazon MemoryDB for Redis
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/709b8cb1-0f2c-43c0-bd23-c017741f489a.png)
 オープンソースソフトウェア「Redis」を利用した、耐久性をより向上させた永続データベース。

 ## Amazon Neptune
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/5d827496-d382-4b19-82a2-1a83228393de.png)
 複雑な関連データの保存に適したグラフ型データベース。

 ## Amazon QLDB
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/8b81c7f0-60a4-472d-b1ed-63f67da8316f.png)
 データ改ざんが不可能な台帳型データベース。

 ## Amazon RDS
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/426d2ea9-2779-440d-b262-c59b41c786a2.png)
 可用性や保全性を向上させたオープンソースおよびプロプライエタリのマネージドリレーショナルデータベース。RDSは「Relational Database Service」の略。

 ## Amazon Timestream
 ![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/7e1b71b7-449e-49a1-9deb-7bc121a7bf34.png)
 時系列的に発生するデータ分析・保存に適したデータベース。

## おわりに
ここまで読んでいただきありがとうございます！

## 参考文献
・AWSの基本・仕組み・重要用語が全部わかる教科書 (見るだけ図解) 単行本（ソフトカバー） – 2022/8/23
川畑光平 (著), 菊地貴彰 (著), 真中俊輝 (著)
p.49-50
Docker ComposeでVite(Vue.js)のコンテナを起動したらホットリロードができなくなった

# はじめに
今まではViteを`npm run dev`コマンドで起動していたが、Docker ComposeでViteを含めたコンポーネント一式起動するようにしたところVueのホットリロードが動かなくなってしまった。

# 環境
- Docker v27.4.0
- Docker Compose v2.31.0
- Vue.js v3.5.13
- Vite v6.0.3

# 対処方法
- docker-compose.ymlに`volumes`を追加した
  - ローカルのViteディレクトリをボリュームとして、コンテナにマウントする
- `volumes`オプションには[ホスト側のディレクトリの相対パス]:[コンテナ側の絶対パス]という風にホストとコンテナの紐づけるディレクトリをそれぞれ記述する

```
services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: ./app/Dockerfile
    ports:
      - "4040:4040"
    env_file:
      - ./app/.env
    volumes:       
      - ./app:/app <- ★ここ
```

# 原因
自分の解釈ですが...
- `volumes`を指定しないと、ホスト側のvueファイルを変更しても、コンテナ側は検知できずファイルは変更されないのでホットリロードは走らない
- ホスト側のディレクトリをボリュームとしてコンテナにマウントすると、コンテナ側でもvueファイルの変更を検知できるためホットリロードが行われる
Gemini Robotics-ER：ロボット工学における新たなAIモデルの詳細解説

近年、ロボット工学の分野では、人工知能（AI）の進歩がロボットの能力向上に大きく寄与しています。その中でも、Google DeepMindが発表した**Gemini Robotics-ER**は、ロボットの物理的なタスク遂行能力を飛躍的に高める画期的なAIモデルとして注目されています。

## Gemini Robotics-ERとは？

**Gemini Robotics-ER**は、Google DeepMindが開発した最新のAIモデルであり、ロボットが現実世界での複雑なタスクを効果的に遂行するために設計されています。このモデルは、視覚、言語、行動を統合し、ロボットが物理的な行動を新たな出力として追加できるようにすることが特徴です。

**主な特徴：**

- **物体検出**：2Dおよび3D空間での物体の位置とサイズを特定し、ロボットが環境内の物体を効果的に認識・追跡できるようにします。

- **把持予測**：物体を安全かつ効率的に操作するための最適な把持方法を計算し、ロボットが状況に応じて適切なグリップを調整できるようにします。

- **軌道推論**：タスク完了に必要な行動計画を生成し、折り紙を折る、デスクを整理するなどの複雑な操作を可能にします。

- **マルチビュー対応**：異なる視点から物体を認識し、3D空間での物体検出を強化します。

## Gemini Robotics-ERの動作原理

Gemini Robotics-ERは、Googleの最新の生成AI「Gemini 2.0」をベースに構築されており、ロボットが複雑な環境に適応し、視覚と言語の理解を統合して物理的なタスクを遂行する能力を提供します。これにより、ロボットは新しい状況やタスクに迅速に対応し、人間との自然なインタラクションを実現します。

## 実際の応用例

Gemini Robotics-ERの高度な機能は、以下のような多岐にわたる分野での応用が期待されています。

- **製造業**：複雑な組み立て作業を自動化し、生産性と精度を向上させる。

- **医療分野**：手術や患者ケアにおいて、繊細な操作を必要とするタスクを支援する。

- **サービス業**：清掃、整理、顧客対応など、多様なサービス業務を効率化する。

## 他のロボット運動制御に適したモデル

ロボットの手の動きや全身の運動制御に関して、Gemini Robotics-ER以外にも以下のような注目すべきAIモデルや技術が存在します。

- **OpenAIのO3推論モデル**：OpenAIが発表した最新の推論モデルであり、ロボットの器用な手の動きを可能にします。このモデルは、高度なセンサーシステムと視覚システムを組み合わせ、人間の手の複雑な機能を模倣することができます。

- **Agility Roboticsの「Digit」**：倉庫や物流センターでの作業自動化を目指すヒューマノイドロボットであり、生成AIを活用して人間の言語指示を理解し、動作に反映する機能を持ちます。2023年10月からは、Amazonの倉庫で試験運用されています。

- **Figure AIの「Figure 02」**：人間のような5本指の手を持ち、周囲を認識する6つのカメラを備えたヒューマノイドロボットです。画像言語モデル（VLM）を用いて視覚的情報や言語情報からタスクを実行し、自然言語での指示に基づいて複雑な作業を遂行することが可能です。

- **ENGINEAIの「SA01」**：低価格な汎用型ヒューマノイドロボットであり、技術のオープンソース化を進めることで、個人の開発者や研究者がヒューマノイド技術へのアクセスを容易にしています。

これらのモデルや技術は、ロボットの運動制御、特に手の動きにおいて重要な役割を果たしており、今後のロボット工学の発展に寄与することが期待されています。

## まとめ

**Gemini Robotics-ER**は、ロボットの物理的なタスク遂行能力を飛躍的に向上させる革新的なAIモデルであり、製造、医療、サービス業界を含む多くの分野での応用が期待されています。また、OpenAIやAgility Roboticsのような他の先進的なAIモデルと組み合わせることで、より高度なロボット制御が実現可能となるでしょう。

今後もAI技術の進展により、ロボットの知能化が加速し、社会のさまざまな分野で活躍する未来が期待されます。
第3回:オフショアチームとアジャイル開発の管理

## **1. はじめに**

オフショアチームとアジャイル開発を組み合わせることで、開発の柔軟性を高め、効率的にプロジェクトを進めることができます。しかし、タイムゾーンの違いや文化的なギャップがあるため、適切な方法でアジャイルを適用しないと、期待した成果が得られない可能性があります。

本記事では、オフショア開発におけるアジャイルプロジェクト管理のベストプラクティスと具体的な事例を紹介します。

---

## **2. オフショア開発におけるアジャイルの課題**

### **(1) タイムゾーンの違い**
- **問題点**: 日本とインド（3.5時間）、ウクライナ（7時間）のように大きな時差があると、リアルタイムでのやり取りが難しい。
- **解決策**:
  - **非同期コミュニケーション**（Slack、Jiraのコメント機能）を活用する。
  - **重なる勤務時間帯にデイリースクラムを設定** する。

### **(2) コミュニケーションの壁**
- **問題点**: 言語や文化の違いにより、仕様の理解にズレが生じやすい。
- **解決策**:
  - 明確な**ドキュメント化**（ConfluenceやNotion）
  - 仕様の確認ミーティングを実施し、**相互理解をチェック**
  - 例: 「開発要件を英語で伝えるだけでなく、ワイヤーフレームや図を使って視覚的に説明」

### **(3) スクラムの実践が難しい**
- **問題点**: 毎日のデイリースクラムやスプリントレビューが難航しがち。
- **解決策**:
  - 必要に応じて**ハイブリッドアジャイル**（Scrum + Kanban）を採用
  - ミーティングは録画し、後から確認できるようにする。

---

## **3. オフショア開発でのアジャイルのベストプラクティス**

### **(1) 適切な開発フレームワークの選定**

| フレームワーク | 特徴 | どんなチーム向け？ |
|--------------|-----------------|----------------|
| **Scrum** | 短期間のスプリントで開発を進める | 明確なプロセスが必要なチーム |
| **Kanban** | タスクを視覚的に管理し、柔軟な変更が可能 | 継続的なタスクが多いチーム |
| **Scrum+Kanban** | Scrumの計画性とKanbanの柔軟性を組み合わせる | タイムゾーンの違いが大きいチーム |

- 例: **オフショア開発では「Scrum+Kanban」ハイブリッドが有効。**
  - コアチームはScrumで進め、オフショアチームはKanbanでタスクを処理。

### **(2) タスク管理の透明性を確保**
- **Jira / Trello / Asana を活用**し、タスクの進捗を見える化。
- タスクの詳細を **「誰が」「いつまでに」「何をするのか」**明確に定義。
- 例: **「バグ修正」ではなく、「ログイン時のエラー（#123）を修正し、5月10日までにデプロイ」**と具体的に記述。

### **(3) 定期的なミーティングと報告の最適化**

| 頻度 | ミーティングの種類 | 目的 |
|------|-----------------|------|
| 毎日 | デイリースクラム | 進捗確認 & 課題共有 |
| 週1回 | スプリントプランニング | 次の開発タスクの計画 |
| 週1回 | スプリントレビュー | 完了した機能のデモ & フィードバック |
| 週1回 | レトロスペクティブ | 改善点を議論 |

- **ベストプラクティス**:
  - ミーティングは**短く（15~30分）**
  - **録画 & 共有** して時差の影響を最小限に

### **(4) コードレビューと品質管理の強化**
- **GitHub / GitLab でプルリクエストを徹底**し、コードの品質を担保。
- 自動テストを活用し、コードのバグを早期発見。
- 例: **「1人が書いたコードは、必ず別のメンバーがレビューする」ルールを設定。**

---

## **4. 成功事例**

### **成功事例: 日本企業Yのケース**

**課題**:
- オフショアチーム（ベトナム）との開発で、仕様の認識違いによる手戻りが多発。
- アジャイルを採用したが、スプリントごとに目標がずれ、開発効率が低下。

**対応策**:
- Jiraを導入し、タスクの透明性を向上。
- スプリントの開始時に **「キックオフミーティング」** を実施し、要件を明確化。
- 各スプリントの終わりに「**振り返りミーティング（レトロスペクティブ）」を実施。

**結果**:
- 認識ミスが減少し、開発の手戻りが30%削減。
- オフショアチームの自主性が向上し、開発スピードが加速。

---

## **5. まとめ**

オフショア開発にアジャイルを適用するには、

- **適切な開発フレームワーク（Scrum/Kanban）を選ぶ**
- **タスク管理ツールを活用し、透明性を確保する**
- **ミーティングと報告を最適化し、時差の影響を減らす**
- **コードレビューと自動テストで品質を担保する**

次回は **[第4回:共通の文化を築く](https://qiita.com/BNR-Satoshi/items/25ff524667580ed29955)** について解説します！

オフショアチームとのアジャイル開発を成功させるために、ぜひ実践してみてください！
vrm to animated glb ~Generative AI Avatar Chat でそこらへんの VRM を使うまで覚書~

## Summary
このブログを読むと、.vrm ファイルを .glb ファイルに変換して他の glb ファイルからアニメーションをコピーできます。また、好きな vrm ファイルを使ってアバター付きAIエージェントを実装できます。

## やりたかったこと

AWS-SamplesのGenerative AI Avatar Chatは、Amazon Bedrock を使ってアバター付き AI Agent を構築できるサンプルです。

https://github.com/aws-samples/generative-ai-avatar-chat

![sample.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2884991/a515a6a1-7ac1-4aeb-b701-44da5d734fb3.png)


ところでこのサンプルの女の子も可愛いですが、自分の好きなアバターを使いたいですよね。

例として、こちらの商用利用可能のアバター(vrm)を使ってみました。
https://sonovr.booth.pm/items/4252664

## .glb ファイルの用意
まず、VRM ファイルを GLB ファイルに変換します。
https://booth.pm/ja/items/4104649

次に、Blender を使って、アニメーションを移植します。
サンプルの女の子には、 Idle, Thinking, RaiseHand, RaiseToIdle という4つのNLAトラックが収録されていますが、この動きを移植したいです。

1. アニメーションが正しく反映されるようにボーンの名前を参照元アバターと同じになるように変更します。これは手作業でやりました...（大体で良い）
2. こちらのコードを使ってsample-avatar からアニメーションをコピーします　https://blender.stackexchange.com/questions/74183/how-can-i-copy-nla-tracks-from-one-armature-to-another
3. このままだとなぜか後ろを向いてしまうので、z軸に沿って180度回転しましょう（アプリのコードで回転できると思ったら、なぜかできなかった）

最後に、GLBファイルに書き出します。
https://blender.atom-box.net/glb_export/
アニメーションモードは NLA トラックにしてください。

glTF Viewer などで、アニメーションが再生できるか確認してください。
https://gltf-viewer.donmccurdy.com/

## unlit への変更
このままだと、モデルが真っ黒に表示されてしまいます。ライトモードをunlitに変更します。
https://gltf-transform.dev/cli
```
gltf-transform unlit test.glb test-unlit.glb
```

## generative ai avatar chat への反映
あとは、`/packages/web/src/models/sample-avatar.glb`を今作ったファイルで置き換えるだけです。
アバターのサイズが小さかったり大きかったりするとカメラがズレるので、様子を見て`/packages/web/src/hooks/useAvatar.ts` 内の以下の部分を書き換えましょう。
```
      rootMesh?.position.set(0, -2.6, 0);
      rootMesh?.scaling.set(1.8, 1.8, 1.8);
      rootMesh?.rotation.set(0, Math.PI / 2, 0);
```
猫メイドちゃんは身長が低かったのと、後ろ向きだったので、このくらいにするとちょうどよかったです。
```
      rootMesh?.position.set(0, -2.3, 0);
      rootMesh?.scaling.set(2.4, 2.4, 2.4);
      rootMesh?.rotation.set(0, Math.PI / 2, 0);
```

終わったらデプロイしましょう。

## 完成！
以下のようになりました。
![Screenshot 2025-03-17 at 17.22.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2884991/185f10be-c813-4443-a2c8-5e4301f2bd9b.png)
AWSが展開するストレージカテゴリのサービスの一覧

## はじめに
AWSが展開するストレージカテゴリのサービスの一覧についてまとめてみました。

## ストレージカテゴリ
　データを保存するためのストレージ、およびバックアップ、データ転送・移行機能を提供するサービス群。様々な種類のストレージがAWSで利用出来るので、種類や適した用途を押さえておきたい。

## AWS Backup
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/627966d2-c30b-47db-950e-c4098730b0e7.png)
定義したポリシーを元に、EBSボリュームやRDS、EFS、DynamoDB、Storage Gatewayなどのバックアップを実行するサービス。

## Amazon EBS
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/b2ebdebd-7f61-42ec-ad0d-8ee2b1dd80e7.png)
EC2にマウントするブロックストレージ。EBSは「Elastic Block Store」の略。

## Amazon EFS
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/ab170cdd-d743-48d5-adb9-f7c90442c5d6.png)
マルチアベイラビリティゾーンで利用可能なネットワーク共有EC2用マウントストレージ。EFSは「Elastic File System」の略。

## AWS Elastic Disaster Recovery
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/262cc9e5-d993-4328-ab67-44758b5290ad.png)
既存環境に影響を与えることなく、サーバやデータベースなどをレプリケーションする災害対策向けのサービス。

## Amazon FSx
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/dfe6768c-32b5-4e39-9450-b52a2c46de39.png)
ビジネスアプリケーション向けのAmazon FSx for Windows File Serverと、高性能ワークロード向けのAmazon FSx for Lustreファイルシステム。FSxは「File System」の意。

## Amazon S3
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/6ca7e0dd-50e1-4d78-82ba-c689f134f9dd.png)
ログ保存、バックアップ、静的ホスティングなどの多様な用途のオンラインストレージ。S3は「Simple Storage Service」の略。

## Amazon S3 Glacier
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/b0764cb4-3185-416f-9481-178fc415a724.png)
S3でのアーカイブ用途の低コストオンラインストレージ。

## AWS Storage Gateway
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/387980/8056e90a-e62c-44bf-9400-340aaf226702.png)
オンプレミス環境のデータ保存用として、AWSクラウド内のストレージを利用するためのサービス。

## おわりに
ここまで読んでいただきありがとうございます！

## 参考文献
・AWSの基本・仕組み・重要用語が全部わかる教科書 (見るだけ図解) 単行本（ソフトカバー） – 2022/8/23
川畑光平 (著), 菊地貴彰 (著), 真中俊輝 (著)
p.48-49
インスタンス生成時の挙動の違い

Pythonでクラスのインスタンスをリストに格納し、後で削除する際、**「同じインスタンスを複数回追加する場合」と「毎回異なるインスタンスを作成する場合」** では削除時の挙動が変わります。  
この違いを理解していないと、**意図せずすべてのオブジェクトが削除されてしまう** ことがあります。  
本記事では、具体的なコードを使ってこの違いを解説します。

---

## **同じインスタンスを追加すると削除時にすべて消える**
まず、次のコードを考えてみましょう。  
ここでは、`Person` クラスのオブジェクト `p1` をリストに3回追加しています。  

```python
class Person:
    def __init__(self, name):
        self.name = name

p1 = Person("Alice")

people = []
for _ in range(3):
    people.append(p1)  # 🔴 同じ `Person` インスタンスを3回追加

print(len(people))  # 出力: 3

# 1つだけ削除したい
people = [p for p in people if p != p1]

print(len(people))  # 出力: 0 （すべて削除されてしまう！）
```

### **なぜすべて削除されるのか？**
- `p1` は **同じオブジェクト** なので、リストに追加された3つの要素はすべて **同じメモリアドレスを指している**。
- `!= p1` の条件でリストをフィルタリングすると、**すべての `p1` が一致するため、すべて削除される**。

---

## **異なるインスタンスを作成すると1つずつ削除される**
次に、`Person("Alice")` を毎回新しく作成してリストに追加する場合の動作を見てみましょう。

```python
class Person:
    def __init__(self, name):
        self.name = name

people = []
for _ in range(3):
    people.append(Person("Alice"))  # ✅ 毎回新しいインスタンスを作成

print(len(people))  # 出力: 3

p_to_remove = people[0]  # 1つだけ削除したい

people = [p for p in people if p != p_to_remove]

print(len(people))  # 出力: 2 （正しく1つだけ削除された！）
```

### **なぜ意図した動作になるのか？**
- `Person("Alice")` を毎回新しく作成するので、リストの各要素は **異なるオブジェクト（異なるメモリアドレス）**。
- `!= p_to_remove` の条件でリストをフィルタリングすると、**最初に一致した1つだけが削除され、他のインスタンスは残る**。

---

## **`del` を使ったより明確な削除方法**
リスト内包表記で `!=` を使う方法ではなく、`del` を使うと、**リストの最初に見つかった1つだけを削除** できます。

```python
for i, person in enumerate(people):
    if person.name == "Alice":
        del people[i]  # 最初の1つだけ削除
        break

print(len(people))  # 出力: 2
```

### **`del` のメリット**
- **最初に見つかった1つだけ削除できる** ので、意図しない削除を防げる。
- **リストのサイズが大きい場合も効率的**。

---

## **まとめ**
| **インスタンスの追加方法** | **削除時の動作** |
|----------------|----------------|
| **同じインスタンスを複数回追加 (`append(p1)`)** | `!=` の比較で **すべて削除** される ⚠️ |
| **毎回新しいインスタンスを作成 (`append(Person("Alice"))`)** | `!=` の比較で **最初に一致したものだけ削除** ✅ |
| **`del` を使う方法** | **最初に見つかった1つだけ削除できる** ✅ |
第2回:効果的なコミュニケーション戦略

## **1. はじめに**

オフショア開発において、コミュニケーションの課題は最大の障壁の一つです。時差、言語の違い、文化のギャップが原因で、仕様の認識違いやプロジェクトの遅延が発生することが少なくありません。

本記事では、オフショアチームとの円滑なコミュニケーションを実現するための戦略と具体的なツールの活用法について解説します。

---

## **2. コミュニケーションの主な課題**

### **(1) 時差による非同期コミュニケーションの難しさ**

- **問題点**:
  - 日本とベトナムの時差は約2時間で比較的軽微だが、インド（3.5時間）やウクライナ（7時間）の場合、リアルタイムのやり取りが難しくなる。
  - ミーティング時間の調整が困難。

- **解決策**:
  - 事前にスケジュールを固定し、ミーティング時間を確保する。
  - 非同期コミュニケーション（Slack、メール、Confluence）を活用。

### **(2) 言語の壁**

- **問題点**:
  - 日本語と英語の微妙なニュアンスの違い。
  - 技術用語の解釈のズレ。

- **解決策**:
  - シンプルな言葉で説明し、専門用語は共通認識を持つ。
  - 画像・動画・ドキュメントを活用して視覚的に伝える。
  - 例: **FigmaでUI設計を共有し、デザインの認識違いを防ぐ。**

### **(3) 文化の違いによる認識のズレ**

- **問題点**:
  - 日本では「察する文化」があるが、海外では明確な指示が必要。
  - 「No」と言わずに「Yes」と答えてしまうケース。

- **解決策**:
  - 明確な指示を出し、重要な点は繰り返し確認。
  - 確認のための「クエスチョンリスト」を用意。
  - 例: **「この仕様に不明点はありますか？」ではなく、「この3点は理解しましたか？」と具体的に質問。**

---

## **3. 効果的なコミュニケーション戦略**

### **(1) 適切なツールの活用**

| ツール | 用途 |
|--------|------|
| Slack / Microsoft Teams | 日常的なチャット & 非同期コミュニケーション |
| Zoom / Google Meet | 週次ミーティング & スクラム会議 |
| Jira / Trello / Asana | タスク管理 & プロジェクト進捗の可視化 |
| Confluence / Notion | 仕様書 & ナレッジ共有 |

- **ベストプラクティス**:
  - 重要なやり取りはSlackだけでなく、**ドキュメントに残す**。
  - Slackのスレッド機能を活用し、トピックごとに整理。

### **(2) 定期的なミーティングとルールの設定**

| 頻度 | ミーティングの種類 | 目的 |
|------|-----------------|------|
| 毎日 | デイリースタンドアップ | 進捗確認 & 課題の共有 |
| 週1回 | ウィークリーミーティング | 進捗レビュー & 次週の計画 |
| 月1回 | レトロスペクティブ | 振り返り & 改善点の議論 |
| 四半期 | 1on1ミーティング | チームメンバーのモチベーション確認 |

- **ベストプラクティス**:
  - ミーティングは **事前にアジェンダを共有** し、無駄な時間を削減。
  - 記録を取り、次回のアクションアイテムを明確化。

### **(3) 仕様伝達の工夫**

- **問題点**: テキストだけでは意図が伝わりにくい。
- **解決策**:
  - **例を使う**: 「この機能はGoogle Driveの共有機能のような動作をします」
  - **ワイヤーフレームを作る**: UI/UXのイメージを明確化
  - **動画録画を活用**: Loomなどで仕様を録画して説明

---

## **4. 成功事例**

### **成功事例: 日本企業Xのケース**

**課題**: インドのオフショアチームと仕様の理解が合わず、開発の手戻りが発生。

**対応策**:
- 仕様書を **日本語 + 英語** で作成。
- **週1回の仕様確認ミーティング** を実施。
- Slackで「**質問チャンネル**」を作り、随時確認できる環境を整備。

**結果**:
- 認識ミスが大幅に減少し、開発スピードが向上。

---

## **5. まとめ**

効果的なコミュニケーションを実現するには、

- **適切なツールを活用し、情報を整理**
- **定期的なミーティングを設定し、共通認識を持つ**
- **視覚的な説明を取り入れ、誤解を防ぐ**

次回は **[第3回:オフショアチームとのアジャイルプロジェクト管理](https://qiita.com/BNR-Satoshi/items/8dc0ce0ea3cc1d4552d5)** について解説します！

オフショア開発を成功させるために、ぜひ実践してみてください！
ユーザの任意の入力文字列に合わせて動的にメモリを確保する

経緯
mallocでメモリを確保する方法はわかったものの，プログラム実行中に自動でメモリ管理するようにして使わないと意味なくない？と思い，ユーザの任意の入力文字列に合わせて動的にメモリ確保する方法を調べていた．
ChatGPTがgetcharで１文字ずつ受け取る例を出力したためそれに対して以下の質問をした．

質問：「getcharで１文字ずつ読み取らなければreallocによる動的メモリ範囲の拡張はできないのですか？」
以下はChatGPTの回答．

---

`getchar` で1文字ずつ読み取らなくても、`realloc` を使って動的メモリを拡張することは可能です。入力のサイズを事前に把握する必要はなく、例えば `fgets` を使って一度にデータを読み取る場合でも、メモリの不足に応じて動的に拡張できます。


`realloc` による動的メモリの拡張は、文字列を逐次的に受け取る（1文字ずつ、または一括で）方法に依存しません。重要なのは「メモリのサイズが不足した場合に、その都度メモリを再確保する」処理が必要である点です。

以下に、`getchar` を使わず、`fgets` や `scanf` のような方法で、動的にメモリを拡張する実装例を紹介します。

### 例: `fgets` を使って動的メモリを拡張

```c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main() {
    char *input = NULL;
    int buf_size = 10;  // 初期バッファサイズ
    int length = 0;     // 入力文字列の長さ（ヌル文字を含む）
    
    // メモリの動的確保
    input = (char *)malloc(buf_size * sizeof(char));
    if (input == NULL) {
        printf("Memory allocation failed!\n");
        return 1;
    }

    printf("Enter a string: ");
    
    // 入力を一度に読み取るが、バッファが足りない場合には再確保
    while (fgets(input + length, buf_size - length, stdin) != NULL) {
        // 改行文字が含まれているか確認
        length = strlen(input);

        if (input[length - 1] == '\n') {
            input[length - 1] = '\0';  // 改行をヌル文字に変換して終了
            break;  // 改行が含まれていたら入力終了
        }

        // バッファが足りなくなった場合にメモリを再確保
        buf_size *= 2;  // バッファサイズを倍増
        input = (char *)realloc(input, buf_size);
        if (input == NULL) {
            printf("Memory reallocation failed!\n");
            return 1;
        }
    }

    printf("You entered: %s\n", input);

    // 動的に確保したメモリを解放
    free(input);

    return 0;
}
```

### 実装のポイント

1. **`fgets` を使用して入力を一度に受け取る**:
   - `fgets` を使って一度に複数の文字を読み取ります。`fgets` の引数で指定したバッファのサイズに応じて読み取りますが、もしバッファが足りない場合は、再度 `realloc` を使ってバッファを拡張します。

2. **`realloc` による動的メモリ拡張**:
   - `fgets` の呼び出し後、文字列の長さ（`strlen`）をチェックし、改行文字が含まれていなければ、バッファサイズを倍増します。その後、再度 `fgets` を使って、残りの入力を読み取るためにメモリを拡張します。

3. **改行文字の処理**:
   - `fgets` は入力中の改行文字も読み込むため、改行文字を検出して、その場合に入力を終了する処理を加えています。

### 動的メモリ範囲の拡張の理解

`fgets` や `scanf` のような方法でも、入力が増えるたびに `realloc` でメモリを拡張することができます。重要なのは、バッファのサイズが足りなくなった時に、その都度メモリを再確保して範囲を広げていくことです。これにより、固定サイズのバッファを超えた入力を効率的に処理できます。

- **`fgets` を使う**: 一度に複数の文字を入力でき、入力が終わったら改行を取り除く処理を加えます。
- **`scanf` を使う**: `scanf` で入力のフォーマットを指定して処理しますが、`fgets` よりも柔軟性に欠けるため、複雑な入力には不向きです。

### 結論

- **`getchar` を使わずとも、`fgets` や `scanf` を使って動的にメモリを拡張することができます**。重要なのは、入力を逐次的に受け取る（または一度に受け取る）ときに、メモリが不足した場合に `realloc` を使って拡張することです。
- メモリの拡張が必要な場合、`fgets` のような関数で入力を一度に読み取ってから処理する方法が便利で、効率的です。
GithubActionsで、特定のブランチにpushする度に自動でCloudRunにデプロイさせる

## IAMアカウントの作成
```
gcloud iam service-accounts create github-actions-for-cloud-run \
  --display-name "GitHub Actions for Cloud Run"
```

権限を付与する
```
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member "serviceAccount:github-actions-for-cloud-run@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role "roles/run.admin"

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member "serviceAccount:github-actions-for-cloud-run@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role "roles/iam.serviceAccountUser"

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member "serviceAccount:github-actions-for-cloud-run@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role "roles/artifactregistry.writer"
```

認証キーの作成
```
gcloud iam service-accounts keys create key.json \
  --iam-account=github-actions-for-cloud-run@YOUR_PROJECT_ID.iam.gserviceaccount.com
```

これでローカルにkey.jsonが作成されるので大事に取っておく。

## 自動デプロイ用のコード

.github/workflows/deploy-production.yml を作成。
ディレクトリ名は固定だが、ファイル名はお好みで。
```yml
name: Deploy to Cloud Run

on:
  push:
    branches:
      - main

env:
  GCP_PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}
  REPO_NAME: ${{ github.event.repository.name }}
  IMAGE: us-central1-docker.pkg.dev/${{ secrets.GCP_PROJECT_ID }}/${{ github.event.repository.name }}/${{ github.sha }}

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Authenticate with Google Cloud
        uses: google-github-actions/auth@v2
        with:
          credentials_json: ${{ secrets.GOOGLE_CREDENTIALS }}

      - name: Configure Google Cloud SDK
        run: |
          gcloud auth configure-docker us-central1-docker.pkg.dev
          gcloud config set project $GCP_PROJECT_ID

      - name: Build and Push Docker Image
        run: |
          docker build --platform linux/amd64 -t $IMAGE .
          docker push $IMAGE

      - name: Deploy to Cloud Run
        run: |
          gcloud run deploy $REPO_NAME \
            --image $IMAGE \
            --region us-central1 \
            --platform managed \
            --allow-unauthenticated #← これがあると認証なしアクセスを許可する。
```


### GitHubのSecretに登録
Githubのリポジトリを開く。

登録するのは以下。
```
GOOGLE_CREDENTIALS: さっきのkey.jsonの中身を登録する。
GCP_PROJECT_ID: さっきのプロジェクトIDを登録。
```
![](https://storage.googleapis.com/zenn-user-upload/7775ede3198d-20250317.png)


## 試す
早速試してみる。githubのmainブランチに何かしらコミットを積んでpush。

Githubのページを開き、アクションタブにて確認。
下記のようになっていれば成功。やったね。
![](https://storage.googleapis.com/zenn-user-upload/1ef435f9cb00-20250317.png)

今後もmainが更新されれば自動で最新になる。便利。