OmniAICreator/Qiita-1.07M huggingface dataset:
グランメゾン東京8話から学ぶ、価値提供に集中することの難しさ、目標について

# はじめに
Xを眺めていた所、

https://x.com/0_majaya/status/1852951724644000080

最近、グランメゾン東京が配信されていることを知りました。
グランメゾン東京はリアルタイムで見ていたのと、その時の面白かったという記憶があったので、定期的に配信されてないかなと探していました。

配信されていることを知ったときにはすぐにU-NEXTと契約し、2日ほどですべてみてしまいました。

やはり面白かったのですが、特に話題になっている8話が自分の中では学びが大きく、今回はそのことについて書こうと思います。


# グランメゾン東京とはどんなドラマ？
尾花夏樹（木村拓哉）と早見倫子（鈴木京香）が手を組み、一緒に世界一のグランメゾンを作る、3つ星を狙うという物語

（本当はもっと色々あるのですが、長くなりそうなのと、うまくまとめられなさそうなので一旦省略）

# 8話の概要
三つ星を狙うことに夢中になりすぎていて、一人一人のお客さんに向き合うことができていなかった。
そこに対して反省する会。
そしてグランメゾン東京の【お客様一人一人に真摯に向き合って最高の料理とサービスを提供する】というぶれない指針が定まった回。

> 星なんかにこだわるから大事なものが見えなくなるんだよ

by キムタクの師匠

# 8話で出てきたグランメゾン東京の三つ星を取る戦略
> グランメゾン東京はミシュランのために特別なことはしません。
これから全面的にコース料理を変えますがそれはミシュランのためではなく、お客様のためです。
私達は今まで通りお客様一人一人に真摯に向き合って最高の料理とサービスを提供したいと考えています。
当たり前のことをやり続けるのが一番むずかしいですよね。
店が有名になると値段をあげて高級食材を使いたくなる、
星を取るために流行りを取り入れたり。
でも、そんなんじゃない。
そんなことに惑わされないで目の前にいるお客様にただ美味しいといってもらうことが大事なんだって。

# 三つ星を取る戦略について思ったこと
テレビで見ていた当時は何も考えずにぼーっと見ていました。
けど、社会人をやっている今なら、

> 当たり前のことをやり続けるのが一番むずかしいですよね。

この言葉がめちゃくちゃ重たいと思えます。

> 店が有名になると値段をあげて高級食材を使いたくなる、星を取るために流行りを取り入れたり。

これは現実世界でも、普通の会社でも起こり得ると思います。
功名心に負けてしまって、本質的な価値提供よりも有名になるためにお金や労力を使ってしまったり。
目の前の人に対する価値提供ができなくなってしまうパターンです。
功名心等々に負けず、本質的な価値提供にのみフォーカスし続けるのはとても難しいと思います。

> 星なんかにこだわるから大事なものが見えなくなるんだよ 

この言葉にも心当たりがありすぎます。
例えば、
- 早くたくさん機能を作るぞ！
- この日までにこの機能を作らなければいけない！
- ベロシティをあげないといけない！
- この数字をこの日までに達成、もしくは改善しなければならない！
- 生成AI流行ってるから流行りにのろう！

これらのものを実際に追う時に、皆さんは目の前にいる、価値提供するべき対象の
人のことはちゃんと見えていますでしょうか？
（自分は本来はここに上がっているような事柄よりも、価値にフォーカスを当てた目標にするべきだと思っています）

> 着実にビジネス面での指標計測を行い、適宜改善を織り込むサイクルが回せている。
だからこそ生まれるのが、数字を追うのに注意しすぎるあまり「ユーザーの声を聞く」「反応を見る」ことを後回しにしてしまっている状態。
収益指標を中心とした計測の精緻さ、こだわりに比べて、ユーザーのインサイト収集にあまり手が出せていない。

こちらは「アジャイルなプロダクトづくり」より抜粋しています。
こういう状況もあるあるなのではないでしょうか？

> 我々が見るべきは皿ではなくて人なんだって

この言葉も8話で出てくるのですが、Webエンジニアにも置き換えることができるのではないでしょうか。
技術力ももちろん大事ですが、技術を提供する先にいる人が常に見えているエンジニアでいたいなと思わされました。

# 目標についての自分の考え
グランメゾン東京はお客様一人一人に対して最高の料理とサービスの提供することを強く中心に添え、三つ星を目指していました。

三つ星を取るために料理を作ってるのではないのです。

最高の料理とサービスを提供することに集中し、結果的に三つ星を取得することを目指していました。

そこから自分は、

目標の先にある提供できる価値、提供すべき価値にフォーカスをし、そこに対してコミットした結果、目標が達成されている、

もし達成ができなくても、自分の行動をふりかえり、以前の自分よりもより多くの価値提供ができるように改善していくことができる、

というように、目標の達成を直接目指すのではなく、価値提供にフォーカスを当て、全力で価値提供をしていき、その価値提供が順調にいっているのかどうなのかを測るために目標は存在している。

というような考え方で目標と向き合っていこうと思いました。
（グッドハートの法則的にも間違えてはいなさそうだと思っています。）

# 最後に
グランメゾン東京は料理人の話ですが、日頃の仕事の仕方や向き合い方を見直すきっかけになったり、チーム作り、マネジメントで参考になったり、プロダクト開発にも通ずることが学べたり、あとは純粋にとてもおもしろいです。

ぜひ興味が湧いた方は観てみてください。
Terraformと最悪な出会いを果たした私が「もしかするとなんとなく読めるかもしれない」となるまで

## はじめに
本記事ではTerraformと最悪な出会いを果たした私が「もしかするとなんとなく読めるかもしれない」となるまでの軌跡を振り返ります。
なお、本記事に技術的要素はなく、Terraformの名を借りたポエムという位置付けで捉えていただくとよさそうです。

それでは出会いから振り返っていきましょう。

## Terraformと私
### 出会い
数年前に面接で面接官に触ってみるといいよと言われたのが始まりです。
この時の私は見よう見まねでなんとか手動でAWSのVPC/EC2/RDSあたりを立ち上げられるかな？というレベルで、IaCについてはよくわかっていませんでした。
とはいえその会社に入社が決まったこともあり、「ちゃんと触っていかなきゃ」と意気込みます。
ハンズオン形式の記事を読みながらなんとかapplyしてみるものの、「ところで今何をやってたんだっけ？」状態で…
これによって私の中でTerraformは「なんだかよくわからないけど面倒なやつ」という位置付けに昇格してしまいました…南無…

### 再会
ちょっと前に、研修という名目でアプリケーションのインフラ環境を構築する機会があり、ここでTerraformと久しぶりの再会を果たします。
もちろんめちゃくちゃ抵抗がありました、最悪な出会いを果たしていますからね…
しかし、ここまでにネットワークの知識やAWSの知識を幾らか身につけており、かつ社内に潤沢な知識を持った方もいていつでも聞くことができたり、見本とする環境もあったりで、以前ほどの抵抗はないかも…？と思えてきます。

進める中でもさまざまな便利さを感じていきます。

例えば、手動でやっているとどこに何を立ち上げたかわからなくなってきますし、ひとつひとつパラメータをどう設定したか、いちいち管理していられませんが、Terraformではソースコード上でこれらを管理することができます。
ちょっと変更したいという時にも、わざわざAWSのマネジメントコンソールからリソースを探して変更して…というような作業をする必要もありません。
いくつかの環境をまとめて消したり立ち上げたりがコマンド一つでできるのも感動的でした。

そして環境ができた頃にはこう思うのです、次に環境を作る際もTerraformを使いたい…と。

## 反省
久しぶりの再会が素敵なものになってよかったですね。
でもなぜ最悪な出会いとなってしまったのでしょうか？

以下のような反省点が挙げられます。

- そもそもTerraformの前に足りてない知識が色々あった
- どんな構成を作りたくて、それには何が必要なのか、そしてなぜIaCが便利なのかを理解せず触っていた

書くまでもない当たり前のことのような気がしてきましたが、少なくとも私は出会いの時点でこれらを認識できていなかったのです。

## Terraformに触れてみたいあなたへ
触れてみることは素晴らしいと思います、世の中に教材は溢れかえっていますし、好奇心がきっと一番の原動力だと思います。
ですが、理解を深めることが目的なのであれば、まずはネットワークの知識を身につけたり、作りたい環境をそもそも手動で作れる状態を目指す方が良いと思います、少なくとも自分はそうでした。

とはいえ、あえて最悪な出会いを果たしたことでより再会が感動的になったというのも事実です、時に遠回りをすることも悪くないのかもしれません。

## 終わりに
今回、Terraformと私の軌跡と呼ぶには浅すぎる軌跡を辿ってみましたが、これらの気づきはTerraformに限らず全ての学習において言えることなのではないかと思います。

それはすなわち自分の現在地を知ること、何がわかっていて何がわかっていないのか、そしてなぜ学ぶのか、これらを把握することが大事で、これにより学習がより有意義なものになるのではないでしょうか。
編集箇所をハイライトしてくれるgoggles.elの紹介

メリークリスマス！[Emacs Advent Calendar](https://qiita.com/advent-calendar/2024/emacs)です。
本稿では、Emacsのパッケージである[goggles.el](https://github.com/minad/goggles)を紹介します。

## 動作の様子

まずは動作の様子を。
scratchバッファのメッセージをkillして、それをyankしています。
分かりやすいよう、色と時間の設定をいじってあります。

killで消えた箇所を赤にハイライト、yankで追加された箇所を緑にハイライトしてくれていますね。

![output.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42721/f9361031-114c-c5c7-dd00-6bdee47075ed.gif)



## [goggles.el](https://github.com/minad/goggles)の良さ

- 変更箇所をわかりやすくハイライト
  - undo、yank、kill、deleteの4種に対応
- 実装がシンプル
  - 約200行
  - 最近のEmacsに入ったpulseを使って実装している

ちなみに、同じ機能を持つ有名パッケージにvolatile-highlightsがあります。
開発頻度の低さと実装の複雑さから、よりシンプルなパッケージとして誕生したようです。[^vhl]
私も以前はvolatile-highlightsを使っていましたが、モダンなgoggles.elに移行しました。

[^vhl]: 長らく開発が止まっていたようですが、2024年9月ころにv1.16がリリースされています。完全に開発が止まっているわけではないようです。https://github.com/k-talo/volatile-highlights.el/commits/master/

## 私の設定

こんな感じにしています。
デフォルトのハイライトがだいぶ短いため、長めかつスムーズに色が変わるようにしています。

```init.el
(leaf goggles
  :doc "変更箇所を強調する"
  :ensure t
  :diminish t
  :hook prog-mode-hook text-mode-hook
  :custom
  ;; 色を薄くする回数、1で即消える
  (goggles-pulse-iterations . 10)
  ;; 色を薄くする1回ごとの秒数
  (goggles-pulse-delay . 0.2)
  
  ;; 実際のface設定はthemeで設定している
  :custom-face
  (goggles-added ((t (:background "#c3fabb"))))
  (goggles-changed ((t (:background "#fae8bb"))))
  (goggles-removed ((t (:background "#fabfbb")))))
```


## まとめ

- モダンなハイライト実装goggles.elはいいぞ
- Emacsの設定沼は楽しい
【Laravel】－初学者向け Laravelホームページの表示流れ

Laravelをインストール完了後、
コマンドプロンプトで「php artisan serve」とたたき
簡易サーバーが立ち上がり、Laravelの下記のホームページが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3929458/ff8f299d-ff17-8db6-8a1b-d1c42c716aa0.png)

今回の記事は、なぜLaravelのホームページがどういう風に表示されるのか？？説明していきます。
（コントローラーは、経由しないため、後の記事で説明していきます。）

# ルーティングについて

PCやスマホからURLをたたくと、最初に行われるのはルーティングです。
まず、ルーティングについて、説明していきます。

**ルーティング**とは…？
⇒どのアクセスがきて、振り分けるかの役割をする

* ルーティングファイルはどこにある？
⇒下記のパスにあります。
```
routes/web.php
```
■Laravel9の場合
「web.php」のファイルを開くと、
use文で下記ファイルを読み込んでおります。
```
use Illuminate\Support\Facades\Route;
```

ルートにアクセスしたら、view関数を使い、「'welcome'」を表示してねといった流れとなります。
```
Route::get('/', function () {
    return view('welcome');
});
```

# ビューについて
**ビューとは…？**
⇒見た目となります。

* では、viewフォルダはどこにあるでしょうか？
下記パスに「xxx.blade.php」があります。
※「blade」は必ずつけるのが決まりごととなっております。
例：welcome.blade.php
```
resources/views/
```
# まとめ
Laravelのホームページは、下記の流れで表示されます。
クライアント（PCまたはスマホ）からアクセスし、ルーティング（振り分け）され、
ビュー（見た目）が返されクライアントに表示されます。
AWS Certified AI Practitioner（AIF）対策：SageMaker Studio・Canvas・Model Registry

# SageMaker Studio

### <font color="MediumBlue">JupyterLab</font>

高性能な統合開発環境（IDE）です。

拡張機能をサポートしており、ファイル管理やカスタマイズが用意です。

:::note info
JupyterNotebookの次世代版
:::

### <font color="MediumBlue">JupyterNotebook</font>

単一のノートブックファイルで作業を行う従来のスタイルです。

# SageMaker Canvas

***<font color="MediumVioletRed">『コードを書かずに機械学習を活用できる非技術系ユーザー向けのノーコードツール』</font>***

数回クリックするだけで、下記を利用できます。

-  **<font color="MediumBlue">データの自動前処理</font>**
   - モデルをトレーニングし、基盤モデルをファインチューニングできます。  
-  **<font color="MediumBlue">モデルの自動構築</font>**
   - タスクに最適な基盤モデルを簡単に比較して選択できます。   

### サポート機械学習モデル

構造化データに対する予測を得意としています。

- **<font color="MediumBlue">分類</font>**
- **<font color="MediumBlue">回帰</font>**
- **<font color="MediumBlue">時系列予測</font>**

### 対象者

- **<font color="MediumBlue">コーディングスキルがない非エンジニア</font>**
- **<font color="MediumBlue">ビジネスアナリスト</font>**

### データの準備

- Amazon S3
- Redshift
- RDS

などの **<font color="MediumBlue">AWSのデータソース</font>** と統合し、データを直接取得して分析することができます。

### 結果の確認方法

ダッシュボードで

- トレーニングの精度
- 性能指標

を確認できます。

### SageMaker Studioとの連携

**<font color="MediumBlue">高度なカスタマイズ</font>**

SageMaker Canvasでトレーニングされたモデルを、SageMaker Studioに **<font color="Darkcyan">エクスポート</font>** することで、さらに高度なカスタマイズが可能です。

**<font color="MediumBlue">チームメンバーと共有</font>**

SageMaker Canvasで作成したモデルを、SageMaker Studioと連携して、 **<font color="Darkcyan">チームメンバーと簡単に共有</font>** することが可能です。


# SageMaker Model Registry

- **<font color="MediumBlue">モデルのバージョン管理</font>**
- **<font color="MediumBlue">メタデータの関連付け</font>**
- **<font color="MediumBlue">承認ステータス管理</font>**

を一元的に行うためのツールで、モデルのライフサイクル全体を効率的に管理することができます。


### SageMaker Canvas や SageMaker Studio との統合

SageMaker Canvas や SageMaker Studio と統合されているため、ユーザーは登録されたモデルを簡単に使用できます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/a09fa50e-d220-fe35-5f5f-b1b9f470d398.jpeg" width="700">
生成AIの待ち時間ってどうしてる？【生成AIサービスのUIを考える】

みなさん，生成AIサービス作ってますか？

昨今では，生成AIの利活用は文章や画像の生成だけでなく，RAGによる検索システムなど幅広い分野で行われています．

一方で，生成AIをサービスへ組み込む場合にしばしば問題となるのが，生成AIによる待ち時間ではないでしょうか．

RAG等のシステムでは，既存の検索システムと比較すると検索に時間がかかる傾向にあり，ユーザー視点では下手すると単に"今までよりも遅いシステム"になりかねません．

また，待ち時間が数秒〜数十秒に及ぶ場合，適切なフィードバックが無いとユーザー視点では正常に稼働しているか判断が出来ず，待ち時間が非常に苦痛に感じることでしょう．

今回は，こうした問題を解決するために，既存の生成AIサービスにおける**ローディング**の工夫点をまとめてみました．

## 生成AIサービスにおける「良い待機時間」とは

(私はデザイナーではないので持論になりますが...)

従来よく見かけるローディングのUIといえば，やはり**Spinner**タイプのものでしょう．

![画面収録 2024-12-08 19.08.05.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/655545/d89fe184-89cc-8996-8a37-85d5ffcf640f.gif)

参考：[Material UI Progress](https://mui.com/material-ui/react-progress/)

しかし，このUIは**読み込み**(=既存のものを取ってくる)のイメージが強い気がします．

対して，生成AIが行っているのは文字通り**生成**(=新しいものを作り出す)です．

そのため，時間がかかっていることをユーザに納得してもらうためには，如何にこの**生成っぽさ**を伝えるかが鍵になるのでは無いかと考えています．

また，RAGやエージェントのように複数のステップを経由してタスクに取り組むタイプのシステムは，**今何をやっているのか**をユーザーに伝えることが，ユーザの待機に対する不安を和らげることに繋がると考えています．

## Spinnerタイプのサービス

### ELYZA LLM for JP デモ版

ELYZA LLMでは文章生成中にSpinnerのローディング表示が行われています．

![画面収録 2024-12-08 19.14.47.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/655545/764609dc-32dc-107a-50d9-d5b6f37ea895.gif)
参考：[ELYZA LLM for JP デモ版](https://elyza.ai/lp/elyza-llm-for-jp)

Sinnerタイプは読み込みのイメージが強く生成AIに向かないと前述したものの，ELYZA LLMにおいては文章自体の生成速度が早いため，待機に対する不快感は感じません．

一方，昨今の生成AIサービスではアニメーションを多様したモダンなUIが多様されており，それと比較すると若干の物足りなさを感じます．

## 処理を逐次的に見せるタイプのサービス
最近のChatGPTの挙動がこれに該当します．(以下の例はChatGPT o1 Previewでの挙動です．)

![画面収録 2024-12-08 19.34.02.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/655545/8f980fb8-eedc-b0e6-ee87-826a1056860d.gif)
参考：[ChatGPT](https://chatgpt.com)

**Thinking**⇒**Connecting the dots**⇒**Recalling past events**⇒**Tracing daily advancements**の順で処理が遷移していることがわかります．

通常であれば即時に生成が開始されますが，Web上の検索を必要とする場合など，一部の時間のかかる処理に対してはこのようなUIが表示されることがあるようです．

LLMが考えていることを端的に表している，生成AIらしいUIだと言えるでしょう．

(一方で，自分でこのようなUIを実装するのは少々めんどくさいかも...？)


## スケルトンスクリーンタイプのサービス

### perplexity

生成AIを用いた検索サービス**perplexity**では一部スケルトンスクリーンが使われています．

![画面収録 2024-12-08 19.42.04.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/655545/8b666f37-c945-d95f-434c-83e962d6a9f5.gif)
参考：[perplexity](https://www.perplexity.ai/search)

スケルトンスクリーンとは，コンテンツの読み込みや生成が完了するまでの間，仮のフレームだけを表示しておくUIの総称です．

perplexityでも，文字が表示されるであろう場所にあらかじめフレームを表示しておくことで，心理的には待機時間が比較的短く感じられます．

また，perplexityの場合は実際に表示される行の高さとスケルトンスクリーンとして表示される行？の高さが一致していないため，**スケルトンスクリーンっぽいローディングアニメーション**と言うことも出来るでしょう．

生成AIでは生成されるコンテンツの大きさがわからないことも多いので．あえて正確に大きさを一致させるよりも，ユーザから見たときの印象を優先してこのような実装になっているのかもしれません．


### Gemini

Google製のLLMであるGeminiも，生成までの待機時間にスケルトンスクリーンを採用しています．

![画面収録 2024-12-08 19.42.54.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/655545/c3aa30d2-0925-8877-f977-6dedf0a6ceb8.gif)
参考：[Gemini](https://gemini.google.com/app)

こちらはperplexityと違い，スケルトンスクリーンと生成される行の高さが一致しているため，実際に生成している感が強い印象を受けます．

文章の表示も滑らかな表示アニメーションが入っているため，全体として非常に使い心地が良いUIに仕上がっていると思います．

## おわりに

今回は簡単に生成AIサービスのローディングアニメーションを調べてみました．

現状でも様々な工夫が見られるローディングアニメーションですが，まだまだ改善の余地はあると考えています．

近年の生成AIの発展が凄まじいのでつい忘れてしまいがちですが，生成AIを活用したサービスが社会実装され世の中で使われ始めたのもつい最近のことです．

今後，生成AIの発展とともに，生成AIに適した様々なUIが作られることを期待したいですね．
多重化とは

### 多重化によってプロセスを差配する
>例えば、あるホストが一つのネットワーク・アドレスだけを持つ場合、そのマシン上のすべてのトランスポート・コネクションはそのアドレスを利用しなければならない。あるセグメントが到着した際、どのプロセスに渡したら良いかを決めるための仕組みが必要となる。この形は多重化と呼ばれる。

### 逆多重化で複数のネットワークを一本のネットワークのようにして信頼性、帯域を得る
>`ホストは使用することのできる複数のネットワーク経路を持っている`。あるユーザーが一つのネットワーク経路が提供できる以上の帯域とより高い信頼性を必要とする場合は、図6−17(b)のように`ラウンドロビンによって複数のネットワーク経路間でトラフィックを分配`するコネクションを持つ方法がある。この手法は逆多重化と呼ばれる。

### 使用例
>逆多重化の例の一つに、複数ネットワーク・インタフェースを使用してコネクションを張ることができるSCTP
...
対照的にTCPでは単一のネットワーク・エンド・ポイントを使用する。

https://bookplus.nikkei.com/atcl/catalog/23/03/16/00728/

# 感想
SCTP,TCPに関して調べなければならない。
多重化によってセグメントの差配とネットワークの性能を上げることができる
研修開催時の庶務を自動化してくれるPowerAutomateクラウドフローアイデア②資料の収集

[Microsoft Power Automate Advent Calendar 2024](https://qiita.com/advent-calendar/2024/powerautomate)の12日目を書いています。


研修やイベントで使える自動化シリーズ、今回は資料の収集編です。
前回はイベント集客時の自動化アイデアについて記載しました。よかったら見てください。

https://qiita.com/ponponmikankan/items/180fc5fbc787f44b6799

勉強会を開催する中で面倒なのが、登壇者からの資料集め…。
なんとなく大勢いる場合、フォルダを触ってほしくないときとかありますよね…。

そんなときはFormsを使うと自動化することができます。

# Formsでアンケートを作成する
添付を付けられる質問が入った質問フォームをFormsで用意します。
今回はデモ用に添付のみの質問を用意してみました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3629241/fd612d21-d1db-66d0-d3d8-4411cb11e1bb.png)

# Formsから指定のSharePointやOneDriveに保存する
実はFormsで添付されたファイルは自分のOneDrive内＞アプリ＞Microsoft Formsの中に保存されます。

今回はここに保存されたら…というトリガーで指定のOneDriveフォルダやSPOに保存するフローを作成します。

Formsの添付についてのドキュメントはこちら

https://support.microsoft.com/ja-jp/office/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%89%E3%82%92%E8%A8%B1%E5%8F%AF%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E8%B3%AA%E5%95%8F%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B-6a75a658-c02b-450e-b119-d068f3cba4cf

# Formsから指定のSharePointやOneDriveに保存する

トリガーをOneDriveの「ファイルが作成されたとき」にして先ほど作成したFormsを指定します。

その後SharePointコネクタの「ファイルの作成」から
サイトのアドレス：保存先のSharePoint Onlineのサイト
フォルダのパス：保存先のSharePoint Onlineフォルダ等
ファイル名：トリガーで拾ってきた「ファイル名」
ファイルコンテンツ：トリガーで拾ってきた「本文」

こうして保存するとFormsでアップロードされた添付ファイルが自動で指定のフォルダに保存されます♪

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3629241/4611fbe0-6bd7-56dc-c253-0fbdfce38db6.png)

他のアイデア：
・アップロードしたよ通知のアクションも追加すると見逃すこともなさそう！
・登壇資料の名前に指定の項番や名前を付ける等もできそう！

Power Automate、めっちゃ庶務の味方！
NCBI より微生物の塩基配列をDLする

# はじめに
　腸内細菌の研究において、シークエンスで読まれた微生物のDNA配列がどの細菌に由来するのかを分類し、菌叢構成を推定する手法に、[`Taxonomy 推定`](https://www.jstage.jst.go.jp/article/jim/36/3/36_149/_pdf)があります。この Taxonomy 推定の精度は使用する分類器とデータベースの種類に依存します。
 <img src = "https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3230781/afecd368-9f3f-bd4d-3308-d0ac3b980d21.png" width ="500">

　16S アンプリコンシークエンスの解析において、16S の V3-V4 を読むショートリードシークエンスでは、[`QIIME2`](https://qiime2.org/) などのパイプラインがあります。一方でショートリードシークエンスはやや実施するコストが高いため、[Nanopore](https://nanoporetech.com/ja) などの比較的安価なロングリードシークエンスより塩基配列データを取得し、Taxonomy 推定を行いたいです。得られたロングリードデータを用いた Taxonomy 推定については、[`Kraken2`](https://github.com/DerrickWood/kraken2) (https://home.hiroshima-u.ac.jp/~tigawa/?p=2217) や [`Emu`](https://github.com/treangenlab/emu) といった分類手法があります。が、どの分類手法が自身の目的とする細菌叢を最も精度よく分類できるのかについて調べるためには、自身で仮想的な菌叢データを作ってみて分類の性能を確かめる必要があります。
　そのため、自身で仮想的な菌叢構成データを作成するため、[`biopython`](https://biopython.org/) を用いて微生物の16S 配列を [NCBI](https://www.ncbi.nlm.nih.gov/) のデータベースからダウンロードし、適当な割合で混合します。今回は安価に手に入る菌叢カクテルである [NBRCヒト常在菌菌体カクテル (Cell-Mock-003)](https://www.nite.go.jp/nbrc/industry/microbiome/cocktail20220113.html)の菌叢構成を参考に、データをダウンロードし、`.fasta`の形式で保存します。
 
# 実装
```py
# import library
from Bio import Entrez, SeqIO

# set e-mail
Entrez.email = "your_email_address"

# NBRC_coctail 16s seq
id_16s = ["NR_028915.1", "NR_044691.2", "NR_044054.1", "NR_028604.1", "NR_044715.2", "NR_029356.1", "NR_113575", "NR_036800.1", "NR_042817.1", "NR_040866.1", "NR_114042.1", "NR_041342.1", "NR_113641.1", "NR_113028.1", "NR_113957.1", "NR_112629.1", "NR_113651.1"]

# number of downloads for each strain
rep_700=  [22,29,73,29,66,36,36,22,36,51,22,58,36,51,51,44,36]

ids = id_16s
with open(f"NBRC_16s_mock_read_700.fasta", "w") as file:
    for i, seq_id in enumerate(ids):
        # get the genome info
        handle = Entrez.efetch(db="nucleotide", id=seq_id, rettype="fasta", retmode="text")
        data = handle.read()
        handle.close()
        for i in range(rep_700[i]):
            file.write(data)
```

# おわりに
　分類器の精度は PCR の増幅バイアスやデータの品質にも影響されるため、実際に菌叢カクテルから DNA を抽出し、シークエンスを行い実験データを得ることで、実データに対する分類器の精度を評価する必要があります。どなたかのお役に立てば幸いです。
AWSのユーザー管理や認証って初心者には無理ゲーやん？

AWS認定試験の勉強してると、ほんま次から次へと分からんこと出てきよるよな！！

今まで業務で触ってこんかった領域なんかは特にや！

例えばやな⋯、Active Directoryって聞いたことあるか？SSOとSAMLの関係分かるか？

これらは全部、企業やサービスで**ユーザー管理**とか**認証**をどうスムーズに、そして安全にするかに関係してる仕組みやねん。

ほな、1つずつ、優〜しく、分かりやすく解説するで！

---

## **1. Active Directory (AD)**  
- **何やねん？**  
    - Microsoftが作ったユーザーやデバイスの「名簿」みたいなもんや
    - 社員が何人おるか、パソコンやプリンターが何台あるか、とか全部登録されてるデータベースやで
- **何に使う？**  
    - 「この社員だけ会議室のWi-Fi使えるようにしよ！」とか、「退職したらその人のアカウント無効にしよ！」みたいに、一括で管理するんや
- **例**: 
    - 学校で言う「生徒名簿」や
    - 生徒の情報（名前、学年、クラス）を一元管理する感じ

---

## **2. SSO (Single Sign-On)**  
- **何やねん？**  
    - 「一回ログインしたら、他のサービスでもそのまま使える仕組み」のことや！  
- **何に使う？**  
    - 例えば、GoogleアカウントでYouTubeやGmail、Google DriveにログインできるのがSSOやねん
    - 同じパスワードを何回も入れる手間を省けるし、セキュリティも向上するやん？
- **例**:
    - デパートの「共通メンバーズカード」
    - 1枚で食品フロアもファッションフロアも買い物できる感じやな

---

## **3. SAML 2.0 (Security Assertion Markup Language)**  
- **何やねん？**  
    - SSOを実現するための「言語」みたいなもん
    - サービスA（ログイン先）とサービスB（利用するアプリ）が話し合うための共通ルールや
- **何に使う？**
    - たとえば、会社のシステム（Active Directory）でログインしたら、そのまま外部のサービス（SlackやZoom）も使えるようになる仕組みや
- **例**:
    - 「会社の社員証」を提示したら、いろんな提携施設に入れる感じやね

---

## **4. SCIM v2.0 (System for Cross-domain Identity Management)**  
- **何やねん？**
    - 「ユーザーの登録とか削除を自動化する仕組み」のことや！  
- **何に使う？**  
    - たとえば、新しい社員が入ったら、会社のシステムに登録するだけでSlackやZoom、Salesforceにも自動的にアカウントが作られるんや
    - 逆に退職したら全部のアカウントが一気に削除されるやで  
- **例**:
    - 自動で会員登録・退会をしてくれる「魔法の受付係」や

---

## **他にも押さえておきたいポイント**

#### **OAuth 2.0**
- **何やねん？**  
    - 「他のアプリやサービスに自分のデータを見せる許可を与える仕組み」や
- **例**:
    - 「家のカギを預けるけど、リビングだけ入ってええで！」みたいな感じ
    - 銀行アプリに「取引履歴だけ見せてええよ」って許可する時に使う

---

#### **OIDC (OpenID Connect)**
- **何やねん？**  
    - OAuth 2.0の上に乗っかってる認証プロトコルや
    - Googleログインとかに使われとる
- **何に使う？**
    - 「この人が誰か」を確認するためのもんや
    - OAuthは「データにアクセスさせる」仕組みやけど、OIDCは「誰かを確認する」仕組みやで

---

#### **MFA (Multi-Factor Authentication)**  
- **何やねん？**  
    - 「複数の方法で認証する」ことや  
- **例**: 
    - 鍵だけじゃなくて指紋やスマホのコードも必要な、セキュリティの厳しいドアみたいなもんや

---

### **まとめ**
1. **Active Directory (AD)**: ユーザーやデバイスを一括管理
2. **SSO**: 一回のログインでいろんなサービスを使える
3. **SAML 2.0**: SSOを実現するルール・仕組み
4. **SCIM v2.0**: ユーザー情報の自動管理
5. **OAuth 2.0**: データアクセスの許可を与える仕組み
6. **OIDC**: 誰かを確認するプロトコル（認証）
7. **MFA**: 複数の認証方法で安全を強化

---

これで全体像が掴めたんちゃう？  
どれもユーザー管理とかセキュリティを簡単＆安全にするための仕組みやで！
興味あるやつから掘り下げてみたらええと思うで！！
Amazon SESに関するメモ

![27f9211c2883f58d7a95ea54963c59b7-300x300.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3161388/15b4b136-932b-20ab-085e-5746872198f2.png)

## Amazon SESとは

- コスト効率の高いEメール送受信サービス
- メール送信可能
- メール受信可能
  - Amazon S３バケットに自動的に配信可能(他にもSNS,Lambda,workmail)
  - 受信時にLambdaを使用してカスタムコードの実行や特定のキーワードを含むメッセージ時にSNS通知が可能
  - 一般的なメールボックスが設けられているわけではないので注意

## SESによるメール送信

- 以下の3つの方法がある
  - Amazon SESコンソール
    - テストEメールを送信するための最も迅速な方法
    - ユースケース：システムアップ時にテストする場合
  - Amazon SES API
    - SendEmailAPI：From,To,Subject,Bodyのみ用意すれば、SES側がメッセージを生成して送信
    - SendRawEmailAPI：メッセージ全体をアプリケーション側で生成して送信
    - IAMユーザ、グループ、ロールで実行できるSES APIアクションを選択
    - ユースケース：アプリケーションから直接メール送信を行う場合
  - SMTP インターフェース
    - 生成済みEmailメッセージを受け取って送信するSESのSMTPエンドポイント
      - ポート：25 / 465(SMTP over SSl) / 587(Message Submission)
      - 要TLS(Transport Layer Security)
      - 要認証
    - 認証には専用IAMユーザを作成してそのクレデンシャルを使用
    - ユースケース：既存の送信用SMTPサーバからリレーしたり、SMTPを前提としてプログラムから直接利用する場合

# SMTPエンドポイントを利用する際の注意点

- デフォルトではEC2からの外向きTCP25番ポートは制限対象

# 送信制限に関して

- 送信クォータ/送信最大レートに達した後にメールを送信しようと、スロットリングエラーが発生、Eメールは破棄される。その後、再度送信するには必要な送信クォータの量に増えるまで待つ必要がある。
- 上限緩和方法
  - 自動的に引き上げるにはガイドラインに従う
  - サポートセンターに連絡

# アクセスレベル

- サンドボックス(初期状態)
  - 指定されたアドレスのみに送信可能
  - 小さな送信制限
  - 200通/24時間
  - 最大送信レート　1通/秒

- プロダクション(サンドボックスの外)
  - 送信先に制限なし
  - 送信制限は実績によって決定
  - 上限緩和申請をすることで、自動的にこちらに変更

# ドメイン検証

- SESでメールを受信/送信するには、所有するドメインを証明する必要がある
  - SESでのドメイン利用開始処理
  - DNSサーバ上でTXTレコードの公開

- MXレコードの公開
  - SESのメール受信用のエンドポイントをMXレコードに指定可能

# バウンスと苦情

- 通知はフィードバック転送orSNSトピックのいずれかで必ず受け取る。
- 両方を無効化・なしには設定できますが、その場合はフィードバック転送による通知がSESから送られてきます。
  - フィードバック通知
    - SNSトピック
    - 細かい運用が可能
  - フィードバック転送
    - デフォルトで有効、メール転送という形でSESから送付
    - SESによる転送先は、元のメールの送信方法とパラメータによって異なる
      - SMTPインターフェイス
        - MAIL FROMコマンドのアドレス、つまり差出人として設定したアドレス
      - Amazon SES API
        - ReturnPathパラメータ等で通知先のアドレスを指定しておくことができる

# 参考文献

- [AWS Black Belt Online Seminar Amazon Simple Email Service (Amazon SES)](https://xn--slideshare-z04i4dsf1o.net/AmazonWebServicesJapan/20190521-aws-black-belt-online-seminar-amazon-simple-email-service-amazon-ses-148042995)
- [SESを利用するにあたり必要な認識と対策(特にバウンス)](https://temporal.hatenablog.com/entry/2013/01/20/174500)
- [Amazon SES でメール送信するときのベストプラクティスまとめ(2020年10月)](https://dev.classmethod.jp/articles/ses-send-mail-best-practices-summary/)
- [AWS SESとSPFの話(その2)
aws SES SPF](https://cloud-aws-gcp.hateblo.jp/entry/2019/11/05/210314)
- [Amazon SESで学ぶメールのBounce（バウンス）とComplaint（苦情）](https://developers.play.jp/entry/2023/07/07/153543)
Yellowfinでレポートを作成してみよう！

この記事は、NTTテクノクロス Advent Calendar 2024 の14日目になります。

　はじめまして！ NTTテクノクロスの野田と申します。
 普段はBI(ビジネスインテリジェンス)と呼ばれる、お客様が持つさまざまなデータを分析・見える化して、ビジネスの意思決定をサポートする業務を行っています。
 今回は普段業務で活用しているBIツール＝Yellowfin(https://yellowfin.co.jp/) についてご紹介します。


# Yellowfinって何？
引用：BIツール Yellowfinより
「Yellowfinは、2003年に誕生した、WebブラウザベースのBIツールです。
データ分析の専門家でなくても使いやすい操作性で、ダッシュボードを素早く作成して社内で共有できるので、全世界50カ国、300万人を超えるエンドユーザーに利用されています。
NTTテクノクロスは、日本で唯一のYellowfinコンサルティングパートナーです。長年BIに携わってきたメンバーの豊富な知識と経験によって、貴社のBIツール導入を成功に導きます。」

　https://www.ntt-tx.co.jp/products/yellowfin/

Yellowfin社の公式ホームページ
https://yellowfin.co.jp/

# 実現できること
商品の売り上げ分析、在庫管理、勤怠可視化といった様々な活用実績があります。POSシステムや勤怠管理システム等に蓄積されたデータを集計し見える化することで、これまで見えてこなかった問題の早期発見や今後の方針決定に役立ちます。

もし他の活用実績にも興味がある方は以下の活用事例をご参照ください！
https://www.ntt-tx.co.jp/case/denso2021/
https://www.ntt-tx.co.jp/case/nexty-ele/

# 操作方法
ここからは実際にYellowfinを操作してレポートや集計グラフを作成していきます。

1.Yellowfinにログインした後、右上の黄色マークからレポートを選択。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/f52e12d3-9332-6b04-23ec-7af664dcf8e2.png)



2.ビューの選択画面で任意のビューを選択。(今回は売上分析ビューを選択)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/7faf76fd-548e-b063-e174-641a0ac4b391.png)


3.レポート作成画面で左側のマスタから「商品名」、「売上金額」を右側のキャンバスにドラック＆ドロップ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/80ccb94c-86aa-539b-83c4-0777a8199d30.png)


4.商品名と売上金額が表形式で表示されている事を確認
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/cb4358fb-74b1-016a-4121-a1f696b7c995.png)


レポート作成は以上で完了ですが、より見やすいレポートにするべく表をグラフに変換してみます。

5.画面左上のグラフボタンをクリック
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/19de5ea1-8a2c-53d6-418d-c46977223d8c.png)

6.グラフの作成画面で作成したいグラフ形式を選択。今回はYellowfinが自動でデータに適したグラフを選択してくれる「おまかせグラフ」を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/eaa45bbe-2fb8-3754-4e22-5779763134e3.png)

7.横軸に「商品名」、縦軸に「売上金額」を設定。今回は縦棒グラフが選択され商品
毎の売上金額が一目で分かるようになりました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/a71e186b-6ede-721a-29cb-a0684fdd1743.png)

ここまででグラフは完成です。最後にレポートを保存します。

8.左上のタブから公開をクリック。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/5ced6fe9-e4df-09ec-586c-c384de51ae3f.png)

9.レポートの名称、説明、保存先を記入して保存ボタンをクリック。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/d050a7d5-8119-201e-9f3d-73fcebcfdf06.png)

10.レポートが保存された事を確認　※保存に成功した場合は編集モードから閲覧モードに遷移します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3922896/e2820d0a-187e-c81c-d928-86985609727d.png)

以上でレポート作成は完了です。皆さんも是非ご興味がありましたらYellowfinを一度体験してみてください。
以下のURLから申し込みが可能です。
[無料トライアル(評価版)の申し込みページ](https://ntt-tx.smktg.jp/public/application/add/546?__CAMCID=LCcSbVRhqA-830&__CAMI=3.4.0.1.fCqCCGzBgXi.nz4mg8sUz1H7cSaa-63&__CAMSID=nz4mg8sUz1H7cSaa-63&__CAMVID=fCqCCGzBgXi&_c_d=1&_ct=1733736649777&_gl=1*o6a2k*_gcl_au*MTU0MjEyNzA4My4xNzMzNzI2Mjcz*_ga*MTc3NDA0NjI2NC4xNzMzNzI2Mjcz*_ga_Q62FS3FLWY*MTczMzcyNjI3My4xLjEuMTczMzczNjY0OC4zNC4wLjA.)


# 参考URL
第2回：BIツールで分析を始めてみよう！～レポート作成編～
https://www.ntt-tx.co.jp/column/tec/bi_sol/taiken/02/
iPhoneで全角コロンを入力する方法

# iPhoneで全角コロンを入力する方法

iPhoneで全角コロンを入力しようとしたときに、困ったのでメモっておきます。

# やり方

（１）数字入力に切り替える。
（２）7を右に向かってスワイプする。
（３）コロンを選択し、全角のコロンを候補から選ぶ。

# まとめ

何かの役に立てばと。
Berachainの概要　[AI作成記事]

:::note
本記事はBerachain DocsをAIに学習させて作成しました
:::

## Berachainとは

Berachainは、高性能なEVM互換のレイヤー1ブロックチェーンです。独自のProof of Liquidity (PoL)というコンセンサスメカニズムと、BeaconKitと呼ばれるモジュラーなフレームワークを採用しています。

EVMとの完全な互換性を持ちながら、流動性提供者へのインセンティブを組み込んだ新しい形のブロックチェーンとして注目を集めています。

https://www.berachain.com/

## 主要な特徴

### EVM互換性 

Berachainは、Ethereum Virtual Machine (EVM)と完全に互換性があります。これにより:

- Solidityで書かれた既存のスマートコントラクトをそのまま移植できる
- MetaMaskなどの主要なウォレットがサポートされている 
- Hardhat、Foundryなどの開発ツールがそのまま使える

という利点があります。

### Proof of Liquidity (PoL)

PoLは、Berachainの特徴的なコンセンサスメカニズムです。従来のPoSと異なり、流動性提供に対してインセンティブを与える仕組みを持っています。

具体的には:
- 流動性提供者はBGTトークンを獲得できる
- バリデーターはBGT保有者から委任を受けることで報酬を増やせる
- プロトコル全体の流動性が向上する

という効果が期待できます。

### BeaconKitフレームワーク

BeaconKitは、Berachainのコアとなる技術フレームワークです。以下のような特徴があります:

- モジュール式の設計で拡張性が高い
- Cosmos SDKをベースにした高いカスタマイズ性
- 即時ファイナリティのサポート

## ネイティブトークン

### BERA ($BERA)
- チェーンのネイティブガストークン
- トランザクション手数料の支払いに使用
- バリデーターのステーキングに必要

### BGT ($BGT) 
- ガバナンストークンとして機能
- 譲渡不可能なソウルバウンドトークン
- バリデーターへの委任やガバナンス投票に使用
- BERAと1:1で交換可能

### HONEY ($HONEY)
- Berachainのネイティブステーブルコイン
- USDCにペッグ
- DeFiプロトコルで広く使用される

## 主要なDApps

Berachainには以下の主要なネイティブDAppsがあります:

### BEX
- 分散型取引所(DEX)
- 流動性プールの提供
- トークンスワップ機能

### Bend
- レンディングプロトコル
- HONEYを担保としたローンの提供
- 利子収入の獲得機会

### Berps
- 永続先物取引プラットフォーム
- レバレッジ取引が可能
- HONEYを証拠金として使用
ドイツへ研究留学した際に詰められた話

## はじめに
初めまして、tarurikaです！

CA Tech Lounge Advent Calendar 2024の11日目を担当するということで、初めて記事を投稿します。

さて今回は、「ドイツへ研究留学した際に詰められた話」というテーマで、日本とドイツ(ヨーロッパ？)の研究に対する考え方の違いの部分についてお話ししたいと思います！

また、研究留学中のTech Lounge生としての過ごし方についても少し触れようと思います。

## ドイツで取り組もうとしていたこと

教育の専門家が保育所を分析する際のタスクを支援するシステム開発を最終目標としていました。特に、ドイツで所属した研究室がネットワーク可視化に精通した研究室だったため、ネットワークに関連したシステム開発に取り組みました。

当初、私は複数の保育所の比較分析を可能にするために以下のような分析システムの構築を検討していました。
1. 画面左側の[Compare two nursery schools]と記載のトグルボタンを選択する。
2. マップ上の特定のピンを2つ選択する。
3. マップ左側に3D共起ネットワークを可視化して、NurserySchool-1のノードとNuserySchool-2のノードの共通部分をエッジで接続する。
※ノードは各保育所の評価データの単語を抽出したもの

![図3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3948110/4f10286e-612d-fd80-7100-9afa78d03de0.png)


## 研究相談で詰められた話
留学先の教授との初回面談で前章で述べた内容について話すと以下の質問が返ってきました。
### ドイツで聞かれたこと
- 研究は誰のために行うのか。
- 研究は社会的に意義があるのか。
- そもそもこの事象の可視化は役に立つのか。
- 2つの保育所を比較する必要性があるのか。保育所を比較する場面は存在するのか。
- 3次元で可視化する意味はあるのか。エッジの色を保育所ごとに変更させることで2次元の共起ネットワークで可視化することは可能なのではないか。

### 日本とドイツの研究に対する考え方の違い
日本で国内学会に参加した際には、研究に使用している手法についての質問が多く寄せられる場合が多かったのですが、ドイツでは上記のように研究に使用されている技術についてというよりも研究が社会に適用されるまでの過程を意識した質問がメインで、研究のストーリーを重要視しているように感じました。

## アドバイスを活かして実践したこと
- 研究のターゲットを明確にする
教育専門家という漠然としたターゲットから、地方自治体や保育所を運営する団体へとターゲットを細かく絞り込むことによって追加すべきシステムについて考えやすくなりました。

- 共起ネットワークの使用方法を細分化する
場合に分けて共起ネットワーク図の形式を変更しました。
    - ある特定の1つの保育所を共起ネットワークを用いて分析する
    各保育所の評価データを使用して、それぞれ共起ネットワークを作成しました。
    以下の図では、NurserySchool-1とNurserySchool-2のそれぞれの共起ネットワーク図を示しています。次元削減手法のMDSを使用することでノードの位置を固定し、他の保育所との比較分析も可能にしました。
    ![図4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3948110/e66dea0d-a580-0393-19fe-d85454d044e6.png)
    
    - ある特定の2つの保育所を共起ネットワークを用いて比較分析する
    2つの保育所の評価データを用いて1つの共起ネットワークを作成しました。
    赤色のエッジがNurserySchool-1が所持するエッジで、青色のエッジがNurserySchool-2が所持するエッジになります。また、黄色のエッジがNurserySchool-1とNurserySchool-2が共通して所持するエッジになります。
    ![図2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3948110/10bc6dd7-1f62-9aab-036f-f4d97e3dab78.png)

    - ある特定の3つ以上の保育所を共起ネットワークを用いて比較分析する（実装中）
    3つ以上の保育所の比較分析を行う場合は、2Dではグラフの視認性が低くなってしまうため、3D共起ネットワークを検討しています。


## （おまけ）留学中のTech Lounge生としての過ごし方
本来、Tech Loungeでは週に2回の出社が奨励されています。私はTech Loungeでは「自然言語処理技術を使用した研究で多数学会にて発表すること」と「Kaggleでメダルを獲得すること」の2つの大きな目標を掲げており、前者について留学中も支援いただくため、休会という形を取らずにオンラインにて参加していました。
### 留学中に行ったこと
月に2度、エンジニア社員との面談を行いました。
留学中にいただいたアドバイスを参考に以下の作業を行いました。
- 使用するデータの前処理
- マッピング手法の改善
- デモアプリのUIの改善

上記の作業行程については割愛して、またどこかの記事で触れようと思います。

## まとめ
ドイツ（ヨーロッパ）では、研究の社会実装までのストーリーを重視する傾向にあり、「誰に対して何を行うために研究しているのか」についてしっかり話せる必要がありました。
日本では（少なくとも可視化界隈の研究において）、ストーリー性よりもどのように実装しているかなど手法について議論される機会が多いと感じるため、研究の意義を考える必要性を実感することができました。
最後にTech Loungeは、オンラインでもとても自分を成長させてくれる場所だと改めて感じた留学となりました！
Surface と Scaffold どっちを使えばいいの

# はじめに

- 最近、新規プロジェクト作成時に、Android Studioで生成される雛形コードが`Scaffold()`になっていることが多くないですか？
- Codelabsのコースでは`Surface()`を使用していることが多いため違いが気になっていました
- そこで`Surface()`と`Scaffold()`のどちらを使えばいいのか調べました

# 結論
- `Scaffold()`を使うべし
- 理由はGoogleが`Edge-to-edge`を推奨しているため

https://developer.android.com/develop/ui/views/layout/edge-to-edge?hl=en

:::note info
Edge-to-edgeとは
公式ドキュメントによると、Edge-to-edgeを有効にするとステータスバーとナビゲーションバーの背後にコンテンツが配置されるようになる
これによりスクリーンの端から端までアプリが描画され、今まで以上に没入感のあるユーザー体験が可能となる
:::

## Scaffold
- Edge-to-edge対応に伴って必要な、上下のシステムバー・カメラノッチ周りの余白を自動調整してくれる

実装例はこちら↓

https://developer.android.com/develop/ui/compose/components/scaffold

## Surface
- これらの処理を手動で実装する必要がある
- WindowInsetsの管理が必要

# まとめ
- 最新のAndroidバージョンとMaterial Designガイドラインに準拠しているのであれば、Scaffoldを使っていれば間違い無いかなと思います
- 僕はCodeLabのハンズオンをやる時は適宜、Surface → Scaffoldと読み替えています（ちょっとめんどうですが）

# 併せて読んでおきたい記事
https://zenn.dev/kgmyshin/articles/89ed1d35292093

- Surface や Scaffold を使わない場合どうなるのかがわかる
- Surfaceの役割がわかる

# 参考
https://stackoverflow.com/questions/78823208/scaffold-vs-surface

https://developer.android.com/develop/ui/views/layout/edge-to-edge?hl=en

https://developer.android.com/develop/ui/compose/components/scaffold
HULFTのパラメータファイルの互換

この記事は [**セゾンテクノロジー Advent Calendar 2024**](https://qiita.com/advent-calendar/2024/saison-tech) 11日目の記事です。

<h1>はじめに</h1>
HULFTではパラメータファイルという一定の形式に従ったテキストファイルを用意することで、ファイル転送を行う定義である管理情報の登録が行えます。
これにより、管理情報をHULFTの管理画面から操作せず、自動で登録することも可能となります。

<h1>詳細ホスト情報の見直し</h1>
HULFT10では、転送先のOSの種類にあたる詳細ホスト情報のホスト種を見直しました。
ただ、ホスト種を変更しましたが、HULFT8と変わらずHULFT10でも同じ意味で動作します。
<br>

<table>
  <caption>ホスト種の変更</caption>
  <thead>
    <tr>
      <th>HULFT8</th> <th>HULFT10</th>
    </tr>
  </thead>
  <tr>
    <td>AS/400</td> <td>IBMi</td>
  </tr>
  <tr>
    <td>UNIX</td> <td>Linux/UNIX</td>
  </tr>
  <tr>
    <td>WindowsNT<br>Windows</td> <td>Windows※</td>
  </tr>
</table>
<br>
※Windowsに統合となりました

<h1>パラメータファイルの変更</h1>
ホスト種の変更にあたり、パラメータファイルの設定値も変更となり「A(AS400)」は「I(IBMI)」となりました。
<br>

<table>
  <caption>パラメータファイルの設定値変更</caption>
  <thead>
    <tr>
      <th>ホスト種(旧ホスト種)</th> <th>HULFT8</th> <th>HULFT10</th>
    </tr>
  </thead>
  <tr>
    <td>IBMi(AS/400)</td> <td>HOSTTYPE=A</td> <td>HOSTTYPE=I</td>
  </tr>
  <tr>
    <td>Linux/UNIX(UNIX)</td> <td>HOSTTYPE=U</td> <td>HOSTTYPE=L</td>
  </tr>
  <tr>
    <td>Windows(WindowsNT)</td> <td>HOSTTYPE=N</td> <td>HOSTTYPE=W</td>
  </tr>
</table>

<table>
  <caption>詳細ホスト情報パラメータファイル</caption>
  <thead>
    <tr>
      <th>HULFT8</th> <th>HULFT10</th>
    </tr>
  </thead>
  <tr>
    <td>HOST=ホスト名<br>HOSTTYPE=A<br>KCODETYPE=I<br>JISYEAR=1<br>END</td>
    <td>HOST=ホスト名<br>HOSTTYPE=I<br>KCODETYPE=I<br>JISYEAR=1<br>END</td>
</table>

<h1>パラメータファイルの互換</h1>

HULFTでは、従来使用していたパラメータファイルをそのまま使用できる思想で設計を行っています。HULFT8で使用していたパラメータファイルをそのまま使用できます。
「A」「I」どちらでもHULFT10ではホスト種「IBMi」で登録され、HULFT8でのホスト種「AS/400」と同じ通信相手として使用されます。

<table>
  <thead>
    <tr>
      <th>パラメータファイルのHOSTTYPE</th> <th>管理情報に登録されるホスト種</th>
    </tr>
  </thead>
  <tr>
    <td>HOSTTYPE=A<br>HOSTTYPE=I</td> <td>IBMi</td>
  </tr>
  <tr>
    <td>HOSTTYPE=U<br>HOSTTYPE=L</td> <td>Linux/UNIX</td>
  </tr>
  <tr>
    <td>HOSTTYPE=N<br>HOSTTYPE=W</td> <td>Windows</td>
  </tr>
</table>

<h1>まとめ</h1>
設定値は変更されていますが、HULFT8のパラメータファイルはそのまま使用できますので、安心してHULFT10に移行することができます。

:::note warn
一部非互換がありますので、新機能・非互換説明書を確認してください。
:::

:::note info
当記事はHULFT for Windowsの表記で記載しています。
:::
AIF C-01に合格したので勉強方法をシェア

## この記事はなに？

2024年12月8日にAWS認定試験のひとつであるAIプラクティショナー（AIF C-01）を受験し、合格しました🎉

![スクリーンショット 2024-12-09 10.54.36.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2688241/b77b1707-2f23-9d53-756f-161d39061793.png)

2025年2月15日までにこの認定資格を取得したので、アーリーアダプターです👏

本記事は、合格するためにどんな勉強をしたかを共有します。

学習期間は2~3週間ほどです。

### 筆者スペック

- エンジニア歴: 1年半
- AI歴:
  - 生成AI: 詳しいつもり
  - 機械学習歴: ゼロではあるが、理系として興味の範囲でなんとなくの知識はあり
- AWS歴:
  - 実務経験: 1年未満
  - 3か月前にSAA取得（[参考](https://qiita.com/ysk91_engineer/items/76db3634cee2b93c0eb0)）
  - AWSのAIサービスを触った経験なし

### AIF公式

https://aws.amazon.com/jp/certification/certified-ai-practitioner/

## やったこと

### 参考記事を読み漁る

https://zenn.dev/issy/scraps/9fbf4635b8c1b4

### テスト申し込み

先に済ませましょう！

### 勉強！

#### 公式のミニテスト

まずは腕試し。
公式が用意している20問のサンプルテストを解いて、己の知識の無さに一回打ちひしがれましょう。

https://explore.skillbuilder.aws/learn/course/19791/play/142171/official-practice-question-set-aws-certified-ai-practitioner-aif-c01-japanese

全然わからなくても大丈夫。
今は**知らない**だけです。
これから勉強すると、これらが解けるようになります。


#### 全体像を掴む

AWSスキルビルダーには、AIFの試験範囲に準じた学習教材があります。

https://explore.skillbuilder.aws/learn/lp/2193/standard-exam-prep-plan-aws-certified-ai-practitioner-aif-c01

特にこのうちの[Fundamentals of Machine Learning and Artificial Intelligence](https://explore.skillbuilder.aws/learn/course/19578/play/153623/fundamentals-of-machine-learning-and-artificial-intelligence;lp=2193)にはビデオでの説明あるので、全体像の理解にはぴったりです。

:::note
- AWSのテキスト翻訳は精度が低いので、Englishの状態でChromeの自動翻訳で読むほうが分かりやすいです。
- ビデオは英語で喋っていますが、その下にスクリプトがあるので理解できます。
:::

#### 問題を解く

ドキュメントだけでの学習では不安だと思います。
やっぱり問題を解きながら理解を深めたいですよね。
公式の過去問はないので、非公式の問題集を活用しました。

##### Udemy（有料）

以下のUdemy問題集を購入しました。

https://www.udemy.com/course/aws-certified-ai-practitioner-certification-55-4

1つのテストに対して**演習モード**で10~20問ずつを複数回解きました。

解説はちょっと不十分な気がしますが、知識の範囲としては十分だと思います。
内容も更新されているようで、そういう意味でも良い教材だと思います。
**激推し**です。

#### 機能別に理解を深める

問題の解説で理解できない場合は公式ドキュメントを読んで理解しましょう。

特にAmazon SageMakerは試験のコア部分、かつ似たサービスが複数あるので公式ドキュメントで理解するのが良さそうです。
https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html
ChatGPTにURLを渡して解説してもらうのでも良いと思います。
SageMaker CanvasとSageMaker JumpStartの違いを説明してもらうとかね。


##### ping-t SAAのセキュリティ範囲

AIの活用にはセキュリティやガバナンスを遵守する必要があります。
AIF C-01では、`第5分野: AIソリューションのセキュリティ、コンプライアンス、ガバナンス`で知識が必要になります。

公式では[この範囲](https://docs.aws.amazon.com/sagemaker/latest/dg/security.html)で知識が求められます。
もしここに書かれていることが分からない場合は、ping-tで学習しましょう。

https://mondai.ping-t.com/g


#### 機械学習について、知った気にならない

YouTubeで調べると機械学習のアルゴリズムについて解説してくれてる方がいます。

https://youtu.be/O9APb0818Do?si=QR6sp_dOsE0fGBtn

端的で分かりやすい。

### 再度公式のサンプルテストを受ける

最終チェック！

## 試験について

### 当日の注意点

- 持ち物: https://www.pearsonvue.com/jp/ja/test-takers/tutorial/identification-1s.html
- トイレには行き過ぎても行き過ぎることはない

### 所要時間

自分は、残り25分くらいで問題を解き終わりました。
見直しフラグは12個つけており、10分くらいで見直し完了しました。

私は長時間一定の集中力を維持することが難しい気質なのですが、それでも時間が余りました。
急いで解く必要は無いと思います。

## 試験にチャレンジしてどうか？

試験にチャレンジしたことで、AWSのAIサービスについて理解が深まりました。
ちょうどLangChainの学習をしていたのですが、もしかしたらAWSサービスを組み合わせる方が実装も運用も楽なのかも？と思ったりしました。

とにかく、この知識を活かせる仕事ができたら幸せだなと思います。

## まとめ

前回の記事で「もう試験はコリゴリ」と言った3ヶ月後に新たな資格を取得してしまいました。
今度こそ資格勉強はしばらく終わりにして、実装したい気持ちです！
DWHを選定する際に意識しておきたいことをまとめる

# はじめに
私は職務上、お客様のデータ分析基盤のアーキテクチャ選定に関わることがあります。
更改であれば観点が明確だと思いますが、はじめて作る場合は観点出しが難しいですよね。

特に「DWHを選定するのは初めてで…」というケースもあるのではないでしょうか。
業務システムで馴染みのRDBMSは既にあるけど、DWHのラインナップって全然違いますよね。

そこで、本記事ではDWHを選定する際に意識しておきたいことをまとめようと思います。

:::note info
**この記事に書いてあること**
- 選定する際に重要となる考え方

特に、はじめてデータ分析基盤を構想したときに思いつかない観点を伝えたいです
:::
:::note warn
**この記事に書いてないこと**
各DHWサービス/製品の比較
- 使い勝手・機能
- 利用料金

これらは比較表に必ず入る項目ですが、選定が意図ではないので記載しません
:::

# 大事な考え方

まずは機能が、とか、AI対応が、とか始める前に少し引いて考えてみましょう。
現実世界と照らし合わせて考えることが重要です。

おそらく「データ分析基盤」を作りたくてDWHを選ぼうとされていると思います。
「データ」と「分析」に分解して考えてみましょう。

まずは「データ」についてです。

**ヒト・モノ・カネ・情報が４大経営資源だと言われています。**
情報とデータはイコールではなく、データを情報にしていくのにはステップがありますが、
雑に捉えるとデータは経営資源（の源泉）だと言うことが出来ます。

４大経営資源を見たときに、「情報」は総量を分けあう構図でないことに着目してください。
つまり、原則としてみんなに同じものを同じだけ提供できるという特徴があります。

つまり、情報（データ）というのは本質的にも会社の共有資産であるということが言えます。

:::note info
データは会社の共有資産である
:::

「データ」についてはまずこれを忘れないようにしてください。

次に「分析」について考えてみます。

分析を何のためにするかというと、当然ですが事業のためにします。
事業計数あるいはKPIの達成のために分析を活用するので、事業活動の一環になります。

つまり「データ」そのものとは異なり、「分析」は事業(≒事業組織)に紐づくものと捉えられます。

:::note info
分析は事業組織に紐づくものである
:::


これをITという観点に置き換えて考えてみましょう。

「データ」は全社の共有資産であるという話をしました。
これはITの観点で考えると、ストレージと考えることができます。

「分析」については事業組織に紐づくものとしました。
これはコンピューティングリソースと考えることができるでしょう。

つまり、ストレージを共有しながら、コンピューティングリソースを事業ごとに分割できると現実世界と適合できると言えます。

:::note info
ストレージは共有、コンピューティングリソースは事業ごとに分割するのが原則
:::

これをすることで、どの事業がどのくらい分析にリソースを使っているのかがわかります。
実際にそのリソースのコストを配賦するケースは少ないと思いますが、どこがどのくらい分析をしているかという情報はデータ分析の拡大していくためにも必要な情報となってきます。
ある事業の分析が別の事業の分析にとってのノイジーネイバーとなることも防ぐことができます。

基本的にこの原則はどのDWHであっても適用するように設計できるはずです。
ただし、どのように実現するかはバラバラです。複雑になるケースもあります。

ここはサービス選定の大きなポイントになるでしょう。
選定前に実現手段までイメージできていることが望ましいです。

## コストに対する考え方
コストに対して考えるとき、まず目を向けるのはサービスの利用料金だと思います。
最初に載せた通り、利用料金についてはここでは触れません。

利用料金以外で考慮に入れるべきコストは主に基盤の維持に要する労務費です。
労務費については、既にチームにいるエンジニアで対応するので追加で見込む必要はないと考えるケースも多いですね。

データ分析基盤の維持を行うエンジニアは定常的に何をしているのでしょう？
イメージしやすいのは

* 基盤に取り込むデータを増やすための対応（データ種の拡大、接続システムの拡大）
* 基盤を利用するユーザーを増やすための対応

あたりだと思います。

これらは利用がどんどん拡大していることの証左でもありますので、喜ばしいことですね。

一方で、運用を開始して利用が拡大していくと直面する課題があります。
それがデータスキューです。

DWHというのはデータを分散配置した上で、パラレルにデータを取得することで大量データを効率的に処理します。
この分散配置において偏りが生じてしまうことをデータスキューといい、データ処理の効率性が落ちてしまいます。

:::note warn
データスキューが発生すると効率性が落ちるので、データの配置についての見直しが必要になる
:::

正しく設計をしていればデータスキューは発生しづらいですが、正しさは時間の経過とともに変わっていきます。
データスキューに対応するだけの知識やリソースがある場合は無視していいと考えますが、そうでない場合は、設計思想としてデータスキューが起こり辛いDWHを選定するのが良いです。

DWHの２大メンテナンスコストは、以下に係る労務費です。
* **データスキューの最適化**
* **コンピューティングリソースの優先順の調整**

コンピューティングリソースの優先順の調整は、前章で述べた通りうまく分離をしていれば発生しません。
分離がされていない場合は、状況を見ながら優先順位を調整する対応が必要になります。

労務費に関する検討はサービス比較の時点で検討に入れておきたいですね。
データやユーザーの拡大に従事してもらうはずのエンジニアが、他の対応で手いっぱいになってしまいます。

# さいごに
この記事は選定をテーマに意識するポイントを書いてきました。
原則を書いていますので、それはすなわち設計をする際にも意識したいポイントになります。

選定や設計など目の前のタスクに追われるとついついミクロなポイントに目が行くと思いますが、
時々マクロな観点に目をやることは大事だと考えています。

この記事が何かの役に立てば幸いです。最後までお読みいただきありがとうございます。
PGroongaを使って類義語辞書を実装する

最近、個人開発しているサービスに類義語辞書を実装したいなと思ったところ、PGroongaで実現できそうだったので、その方法についてまとめます。

# 1. PGroongaとは
PGroongaとは、PostgresのExtensionで日本語の全文検索(※)を可能にしてくれます。


:::note info
全文検索とは、テキスト内の任意の文字列を検索キーワードとして使用できる検索機能です。例えば、"あー。今日もいい天気だな。"というテキストがあった場合、"天気"と検索するとこのテキストがヒットします。
:::

今回は、PGroongaを使って類義語辞書を実装していきます。


# 2. 今回のゴール
以下の検索が可能になることをゴールとします。


- 同じ意味を持つ単語を検索結果に含める
例えば、「ミルク」と検索した場合に、「牛乳」がヒットする。
- カタカナ、ひらがな、ローマ字の入力に対応
例えば、「gyu」と検索しても「牛乳」がヒットする。

この機能を実現するために、PGroongaの類義語辞書として使える仕組みを構築していきます。

# 3.実装
今回の実装は、[PGroongaの公式サイト](https://pgroonga.github.io/how-to/auto-complete.html)通りに進めていきます。

### 3.1 類義語テーブルの作成
まずは類義語を格納するテーブルを作成します。
このテーブルは、以下の2つのカラムを持ちます。

- term: 検索対象の単語
- readings: 類義語や読み仮名のリスト（配列形式）
```sql
CREATE TABLE terms (
  term text,
  readings text[]
);
```

### 3.2 インデックスの作成
次に類義語検索に使用するインデックスを作成します。

```sql
CREATE INDEX pgroonga_terms_prefix_search ON terms USING pgroonga
  (readings pgroonga_text_array_term_search_ops_v2);
```


### 3.3 類義語の登録

さきほど作成したテーブルに類義語を登録します。
```sql
INSERT INTO terms (term, readings) 
VALUES ('牛乳', ARRAY['ギュウニュウ', 'ミルク']);
```

これで実装は完了です！


# 4. 動作確認

今回の同義語を検索する際は以下のようなSELECT文を実行します。
```sql
SELECT term FROM terms WHERE readings &^~ '任意の文字';
```

では、実際にSELECT文で動作確認してみたいと思います。

```sql
SELECT term FROM terms WHERE readings &^~ 'ミルク';

 term
------
 牛乳
(1 row)
```
"牛乳" の類義語として登録した "ミルク" でヒットしました！


また、他にも以下の検索条件でも同じようにヒットします。
```sql
-- ローマ字
SELECT term FROM terms WHERE readings &^~ 'gyuunyuu';
SELECT term FROM terms WHERE readings &^~ 'miruku';

-- 前方一致(ローマ字)
SELECT term FROM terms WHERE readings &^~ 'gyu';
SELECT term FROM terms WHERE readings &^~ 'mi';

-- 前方一致(カタカナ)
SELECT term FROM terms WHERE readings &^~ 'ギュウ';
SELECT term FROM terms WHERE readings &^~ 'ミ';

-- 前方一致(ひらがな)
SELECT term FROM terms WHERE readings &^~ 'ぎゅう';
SELECT term FROM terms WHERE readings &^~ 'み';
```

# 5. まとめ
PGroongaを使うことで、類義語辞書を簡単に実装できました。
個人開発やプロジェクトで日本語の検索機能を強化したい場合に、ぜひ参考にしてみてください!
透明感を持つIT部門へ：GDSCの挑戦

# はじめに
グループデジタルソリューションセンター（以下、GDSC）の採用・人材育成・組織マネジメントを担当するIT組織戦略チームから、今日の記事をお届けします。

IT部門って忙しいですよね。DXの時代の流れもあり、案件はどんどん増えていきます。
次から次に各所からの依頼が飛び込み、皆さん大忙し。
その割に、 「IT予算がこんなに大きいの？」
「IT部門が何をやっているかよくわからない。何にそんなに忙しいの？」 
なんて部外者から言われた経験はありませんか？
私はあります。腸が煮えくり返りながら、どうしたものかと考える日々です。

# 目指したいのは透明感
肌には透明感が欠かせないですよね。弊グループの製品は肌の透明感に…

おっと、話題が違いました。先述したような腸炎上事象がなぜ起こりやすいのか考えた結果、最近見えてきたことがあります。とにかく大事なのはアクションの透明感！周りが見えるということは、組織マネジメントにとって非常にプラスだということです。

透明感が必要なのは肌だけじゃないということですね。

アクションの透明性を高める効果は、対部外、対部内それぞれ以下の通りです。

> **【対部外】**
> 
> IT部門が会社の戦略に対してどのようなアクションをとっているかの理解を得て、共感性を高める → IT部門の社内プレゼンスの向上
> **【対部内】**
> 
> メンバークラスまで自分の担当案件だけでなく、会社の戦略に向けての視野を広げる。他の案件との関連性を可視化する → 主体性の向上、判断の質・精度の向上

まず私たちが目指すのは後者、対部内への仕掛けです。
（今後もちろん部外への試みも行います）
というのも、私たちGDSCはポーラ、オルビスをはじめとする
各ブランドのIT部門が統合した総勢90名の大所帯の部門です。
部門統合の目的の一つはブランドシナジーですが、
巨大な組織ゆえ、それも簡単ではありません。
元々仕事の進め方も違う、文化も違うといった背景もあります。
透明性どころか隣のチームの人の顔はわかるけど、
業務も戦略もよく知らないという課題に直面していました。
ですので、まずは部内からアクションの透明性を高める働きかけにチャレンジします。
具体的には以下に続きます。

# 案件思考→戦略思考へ
つい業務に追われると追いかけてしまうのは案件の進捗。もちろんQCDは大事な観点ですが、忘れてはいけないのはその案件がどの戦略と紐づいているかを意識することです。さらに部門の戦略だけでなく、会社全体の戦略、ミッションとの繋がりを意識することは判断の質を変えていきます。その意識によって戦略実行スピードの加速を目指し、業務進捗のマネジメントを変革します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941783/3a7cf596-ad90-8ef3-4818-2c39668dab53.png)



# 実際どうやって？（初手）
**AS IS**

チーム毎の案件管理
チーム毎の進捗報告（マネージャー→部長、役員） → メンバーからは戦略全体の進捗、他チームのアクションは見えない（案件思考になりがち）、資料の個別作成

**TO BE（これから）**

重点戦略にまつわる案件の進捗を1つのプラットフォーム（今回はBacklogを使用）で管理
**■具体的な使い方 **
Backlogの管理項目を駆使し、
戦略の単位で案件を束ね、進捗と繋がりを可視化

> 種別：重点戦略テーマ
> カテゴリ：チーム
> マイルストーン：報告の単位（ブランド、予算分類）
> 状態：KPIに対する進捗状況（◎～△の定性とN％の定量） ※ガントチャートのフィルタを用途に応じて使い分けることで、場に合わせて状況把握が可能（例：同じ案件でも、チーム単位、戦略単位での位置づけ情報把握ができる）
**■期待できる効果**

メンバーもマネージャーも戦略全体の状況を把握でき、
周囲のチームの状況もつかみやすい
個別の会議資料が減り、資料の準備工数も削減できる
# 今後のアクション
これは初手です。
スイカゲームでいったらやっとリンゴくらい。
いや、運用はこれからなのでまだブドウかも。
ここからスイカにしていくには透明性を高める運用の整備、工夫が必要です。
今後手掛けていきたいのはこの辺り

案件管理と工数管理の連動：ヒト
案件管理と投資管理の連動：カネ

ビジネスリソースをいかに最適に配分していくかという部分の透明性も高め、経営判断とリンクさせながらIT戦略を実現していく組織を目指していきます。

GDSCで働くメンバーが会社全体の戦略にどう貢献しているか実感を持てる、そんな仕組みを設計していきたいと考えています。

目指せ！透明感のあるスイカ！（違う話になってきた）

運用開始後の奮闘はぜひまたの機会に。

# :santa:弊社では一緒に働く仲間を募集中です:santa:
現在、様々な職種を募集しております。カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等の詳細は、ぜひ採用サイトをご確認ください。 https://engineer.po-holdings.co.jp/

この記事の内容は、11月26日に開催された「ITR ITTREND2024」にて、
サイボウズ社の広井様がご講演された「コミュニケーション基盤としてのIT戦略」からインスパイアを受けて執筆しております。
この場をお借りして、改めて感謝申し上げます。
GitHub ActionsでCloudFormationデプロイを自動化

## 初めに
ローカル環境からGit pushをトリガーにCloudFormationにもスタックを作成するワークフローを使用してCFnの自動デプロイを試してみます。

## リポジトリ構成
├── .github
│   └── workflows
│       └── cfn-deploy.yml
└── template.yml

※ファイルの置き場所を間違うとGithub Actionsがトリガーされないです

## 流れ
- プライベートリポジトリの作成
- AWSの認証情報を作成したリポジトリのシークレットに追加
- GitHubにローカルからpush
- pushをトリガーにGitHub Actionsが動く
- CFnスタックを自動で作成

## CFnテンプレート
使用するテンプレートは以前作成した冗長VPCのテンプレートです。
[冗長構成WebサーバーのCloudFormationテンプレートを作成、デプロイ](https://qiita.com/Ryuta_Uchimura/items/a77e533a6e11b942bc59)
## ワークフロー
使用するワークフローは下記のものです。
```
name: Deploy CFn Stack

on: push

jobs:
  deploy-cfn:
    name: Deploy CFn Stack to AWS
    runs-on: ubuntu-latest
    steps:

    - name: Checkout
      uses: actions/checkout@v2

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ secrets.AWS_REGION }}

    - name: Deploy CFn Stack
      uses: aws-actions/aws-cloudformation-github-deploy@v1
      with:
        name: test-cfn-stack
        template: ./template.yml
        no-fail-on-empty-changeset: "1"
```

### ワークフローの詳細
```
on: push
```
- プッシュイベントが発生するとトリガーされる
```
jobs:
  deploy-cfn:
    name: Deploy CFn Stack to AWS
    runs-on: ubuntu-latest
```
- ジョブの実行名と実行環境
```
 - name: Checkout
   uses: actions/checkout@v2
```
- actions/checkoutを使用してリポジトリのコードをクローンする。
- リポジトリ内のCFnテンプレートにアクセス可能となる
```
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ${{ secrets.AWS_REGION }}
```
- AWSにアクセスするための認証情報をリポジトリのシークレットからもってくる
```
- name: Deploy CFn Stack
  uses: aws-actions/aws-cloudformation-github-deploy@v1
  with:
    name: test-vpc-stack
    template: ./template.yml
    no-fail-on-empty-changeset: "1"
```
 - CloudFormationスタック作成
 

## ローカルからリポジトリにプッシュ
```
git clone https://github.com/<ユーザーID>/<リポジトリ名>.git
git add .
git commit -m "（コミットの説明コメント）"
git remote add origin （リモートurl）
git push origin master
```
## 動作確認
- ワークフロー
![スクリーンショット 2024-12-09 152555.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812406/c083945c-2ba8-1372-2e88-e1eebdd300fa.png)

- スタック作成
![スクリーンショット 2024-12-09 152806.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812406/67da971d-324a-79a9-5480-74f41ff1b6c8.png)


#### スタックの更新
- 試しにVPCの名前を変更してpushしてみます
![スクリーンショット 2024-12-09 154053.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812406/921b9885-4c95-0449-2642-41dba38b9203.png)
```
test-vpc → test-vpc-2
```
- 更新を確認
![スクリーンショット 2024-12-09 154334.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3812406/932d64af-9b93-f0f4-d6a4-3f684d982c34.png)
構成図を書くときに考えていること

# はじめに
新しいプロダクトをいじるとなった時、まずどのような構成になっているか把握したいとなりますよね。でも構成図を書こう！となった時いったいどこから書けばいいのかわからないとなって断念する…そんなことありませんか？自分はあります。
100%これで書けるようになるという方法はまだ見つかりません、見つかったら共有するし教えて欲しいですが、自分が書くときに気をつけたり考えていることをアウトプットしていこうと思います。

# 抽象度を決める
まずどれくらいの粒度で書くかを決めます。
例えば他プロダクトとのつながりさえ把握できればいいのなら、DBがどこにあるのかとかキャッシュの有無等を考える必要はないでしょう。
通信のデバッグをしたいのであればsecurity group等書いた方が良いでしょう。
こういったように目的別にどこまで書くかをざっくりと自分は決めています。

# 主要コンポーネントを把握する
まずどのリソースがあるかを把握します。
抽象度に則り、例えばロードバランサ、インスタンス、DB等どのようなリソースを使うかを洗い出します。
何かしらのツールを使っているのであれば、自分は必要そうなアイコンをこの辺りでフィールドに雑に出し始めます。

# 動作の流れを把握する
どう並べていくかを考えるときに、自分は動作の流れをたどってリソースを並べていきます。
例えばwebアプリケーションだったら、まずインターネットから名前解決を行なってルーティングされてALBに入って…といった形でその順にリソースを並べて矢印で繋いでいきます。

# 体裁を整える
繋がりをかけたら、構成図としての体裁を整えていきます。
自分はAWSの[AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ?](https://aws.amazon.com/jp/builders-flash/202204/way-to-draw-architecture/)をよく参考にします。
読み手が誰かと、最初に決めた抽象度に応じて書くことを決めていきます。
サイトの例を引用すると、「マルチ AZ を利用して可用性が高い構成にしていることを伝えたい」という場合には、EC2を利用する場合に基本的に利用されるEBSやセキュリティグループを描かないといったように、目的に応じた最後の取捨選択を行います。
個人的に一つ守った方が良いと思うのは、アーキテクチャの"流れ"は上から下 or 左から右に則って作ると見やすくなる印象があります。
![img_way-to-draw-architecture_06.8099fdbec65872413000309add2e2614bf0fa050.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546781/cefdd680-ff06-8a62-8ff1-6acc2dc5e856.png)
教育的dpの最後の問題【競技プログラミング】

# はじめに
- [教育的dp最後の問題](https://atcoder.jp/contests/dp/tasks/dp_z)をサクッと仕上げて、気持ちよく終わるつもりだったけど、これも最後の問題だけあって、そこそこ面倒っぽいね。
- 具体的に言えば、CHTというテクニックが必要だね。けど、[基本は覚えた！](https://qiita.com/kei_tnk/items/b3887336d40a999f9f77)
- ちなみに、計算量を気にしなければ、楽勝で解ける問題です。

# 問題
- カエルをスタートからゴールまで、最小コストで辿り着かせる場合のコストを求めよ。
    - 足場(i in 0..<N)には、高さhs[i]が設定されており、hs[i]は単調増加
    - カエルが足場[i]から足場[j]に移るとき、$(hs[j]-hs[i])^2+C$のコストが発生する。
    - 足場[0]から足場[N-1]に移動する最小コストを求めよ。
- 入力例
```
5 6 // 足場は5個、ジャンプコストC=6
1 2 3 4 5 // 足場の高さは、1 2 3 4 5
```

# 計算量無視のコード
- dp[i]について、足場iに至る最小コストとする。下記は、[貰うdp](https://qiita.com/kei_tnk/items/dbe3444b0f1be9b7b7a1)になってるね。
```swift
extension Array {
    init(_ cnt: Int, _ v: Element) {
        self = [Element](repeating: v, count: cnt)
    }
}

let (N,C) = [readLine()!.split(separator:" ").map{Int($0)!}].map{($0[0],$0[1])}[0]

let hs = readLine()!.split(separator:" ").map{Int($0)!}

let inf = Int.max / 2

var dp = [Int](N,inf)

// 初期化
dp[0] = 0

// 遷移
for i in 1..<N {
    var ans = inf
    for j in 0..<i {
        ans = min( ans , dp[j] + (hs[i]-hs[j])*(hs[i]-hs[j]) + C )
    }
    dp[i] = ans
}

print(dp[N-1])
```
- この程度は、計算量無視して良いなら、半分寝ながらでも解けるね。
- でも上記は二重ループになってるから$O(N^2)$になり、$N≦2×10^5$だからTLEよね。

# CHTの導入に向けた下準備
- [覚えたばかりのCHT](https://qiita.com/kei_tnk/items/b3887336d40a999f9f77#%E3%81%8A%E3%81%BE%E3%81%91%E7%9F%A5%E8%AD%98)を使って解く方針とする。
- `dp[j] + (hs[i]-hs[j])*(hs[i]-hs[j]) + C`のjに関する最小値を高速に求めたい。
- この式を書き換えて、jに関する最小値を求めようとすれば
    - $min(-2*hs[j]*hs[i] + (hs[j]^2+dp[j])) + (hs[i]^2+C)$と書ける。
- ここで
    - aj = $-2*hs[j]$
    - bj = $hs[j]^2+dp[j]$
- とすると、y = aj･x + bj (j in 0..<i)の直線群を使って、x=hs[i]に対する、yの最小値を求めるCHTの手法が使える。
- min部分をCHTの手法で計算し、別途、$x^2+C$を加算するのを忘れずに。

# CHTを導入して解く
```swift
struct CHT<T:Comparable & Numeric> {･･･} // 説明は省略！

extension Array {
    init(_ cnt: Int, _ v: Element) {
        self = [Element](repeating: v, count: cnt)
    }
}

let (N,C) = [readLine()!.split(separator:" ").map{Int($0)!}].map{($0[0],$0[1])}[0]

let hs = readLine()!.split(separator:" ").map{Int($0)!}

let inf = Int.max / 2

var dp = [Int](N,inf)

dp[0] = 0
var cht = CHT<Int>() // cht導入！

for i in 1..<N {

    //CHTへの直線追加
    let j = i-1
    let aj = -2 * hs[j]
    let bj = hs[j]*hs[j] + dp[j]
    let linej = (aj,bj)
    cht.append(linej)
    
    let x = hs[i]    
    var ans = x * x + C // min計算不要部分を予め加算。
    // for j in 0..<i {
    //     ans = min( ans , dp[j] + (hs[i]-hs[j])*(hs[i]-hs[j]) + C )
    // }
    let (a,b) = cht.getLine(x) // CHTにより、for-jループを破壊！！！
    ans += a * x + b // jに係る最小値を算出！
    dp[i] = ans

}

print(dp[N-1])
```
- これで提出したら、100msでACだったよ。あと、CHTのgetLine関数はニブタンで高速化済みです。
- 最初、全探索でgetLineするアルゴリズムだったときは、TLEがチラホラ発生しちゃったから、慌ててニブタン化しました。

# おわりに
- いやぁ、あっけなく、[教育的dp](https://atcoder.jp/contests/dp/tasks)を全制覇しちゃったね。当初、CHTには双対セグ木を使う必要があると勘違いしていたから､[双対セグ木にも手を出しちゃった](https://qiita.com/kei_tnk/items/af6f24c371d2cb84e6ef)けど、CHTで簡単に解けたよ。
- 次は何に手を出そうかな。