OmniAICreator/Qiita-1.07M huggingface dataset:
【Rustのまほう2】#10 敵キャラクターの構造

https://x.com/cubbit2/status/1866780063276077342

というわけでボスキャラクターを作っています。Bevy Engineにおける敵キャラクターももちろんひとつのエンティティで、多数のコンポーネントの集合体になっています。Bevyでの開発の雰囲気をお見せしたいと思いますが、以下がボスキャラクターの実際のコードです。コンポーネントのプロパティ部分は省略してあります。

```rust
commands
    .spawn((
        Name::new("huge slime"),
        StateScoped(GameState::InGame),
        Enemy,
        Life { .. },
        HugeSlime { .. },
        Actor { .. },
        ActorState::default(),
        EntityDepth,
        AseSpriteAnimation { .. },
        Transform::from_translation( .. ),
        (
            RigidBody::Dynamic,
            Velocity { .. },
            Collider::ball(24.0),
            GravityScale(0.0),
            LockedAxes::ROTATION_LOCKED,
            Damping { .. },
            ExternalForce::default(),
            ExternalImpulse::default(),
            ActiveEvents::COLLISION_EVENTS,
            CollisionGroups::new( .. ),
        ),
    ))
    .with_children(|parent| {
        parent.spawn((
            HugeSlimeSprite,
            AseSpriteAnimation { .. },
            Transform::from_xyz( .. ),
        ));
    });
```

各コンポーネントの役割は以下のようになっています。全部は紹介しきれないので主要なものだけ。

- `Name` エンティティの名前。名前を付けてインスペクタで覗いたときに見つけやすいようにしてます
- `StateScoped` このエンティティを`InGame`ステートでだけ存在するようにしていしています。これでタイトル画面に戻ったときにこのエンティティは自動的に削除されます。
- `Enemy` 敵キャラクターであることを識別するための独自のコンポーネント。こういうプロパティは持たないがエンティティの種類を識別するためのコンポーネントを**マーカーコンポーネント**なんて読んだりすることもあります。
- `Life` 攻撃がヒットするヒットポイントが減るという動作をするエンティティを表します。敵キャラクターだけではなく、背景の本棚やランタンなどの物体にもこれが設定されており、攻撃すると壊れて消滅するようになっています。
- `HugeSlime` このボスキャラクター特有のプロパティを定義しています。たとえばこのボスキャラクターは一定時間ごとに飛び跳ねるので、今飛んでいる状態なのかどうかを表していたりします。
- `EntityDepth` 奥行を調整するエンティティを表すコンポーネント。このゲームは２Dですが、前後の重なりはZ座標で指定します。そしてキャラクターは画面上方向ほど奥なので、Y座標が大きくなるとそれに伴ってZ座標は小さくなる、という調整が必要になりますが、その調整をするエンティティを表しています
- `AseSpriteAnimation` ボスキャラクターの影の画像です
- `Transform` ボスキャラクターの位置です。ボスキャラクターを移動させるときに、このコンポーネントのプロパティを直接変更することはないです。`ExternalForce`コンポーネントを変更して外力を与え、物理エンジンがそれを計算して`Transform`コンポーネントに結果を書きこむことでキャラクターが移動します。

以下は物理エンジン関係のコンポーネントです。

- `RigidBody` 剛体の種類を表します。普通の動く物体を表す`Dynamic`の他にも、壁など動かない物体を表す`Fixed`、一定の軌道を動き回るリフトなどを表すのに便利な`KinematicPositionBased`や`KinematicVelocityBased`があります
- `Velocity` 物体の速度。これは直接指定するというより、外力や他の物体との衝突によって物理エンジンが決定する感じになります
- `Collider` 物体の形状を表します。ここでは`ball`なので円形です。
- `ExternalForce` 外力。これを設定するとエンティティを力で押すことになり、つまりその力の方向にこのエンティティが動くようになります。

このほかに、さらにこの親エンティティの子として別のエンティティを追加し、そこに `AseSpriteAnimation` や`Transform`で
ボスキャラクター本体の画像を表示しています。この子のコンポーネントのY座標を調整することで、影の位置はそのままでボスキャラクターの画像のY座標だけ大きくし、ジャンプしているように見せています。

こんな感じで多数のコンポーネントの集合体としてエンティティを定義するのが Bevy の Entity Component Systemです。クラスや継承、オブジェクトコンポジションを主体にオブジェクトを構築するオブジェクト指向ベースのゲームエンジンとはかなり雰囲気が異なることがわかると思います。
変数はなんでもよいのか？

この記事は東京海洋大学NePPの Advent Calendar 2024の１１日目です。

## はじめに
初心者の私にとって、いざプログラミングをしてみようとなると

コード書いてみる!
→変数をいれなきゃいけない
→参考に他の方のコードを見てみるといくつか似たような変数がある
→ただ変数ってどういれればいいの、、？

と変数の「原則」について分からないまま書いたコードが以下です。

<img width="300" alt="[スクリーンショット 2024-12-11 183030.png]" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946215/818104bb-8eec-cf8d-cc3b-433d51d98d4b.png">


## ここでの疑問
- 変数ってどう表せばいいのか？
- 言い換えれば、変数として入れられれば文字はなんでもいいのか？

こういった初心者すぎる個人的な疑問をこの機会に解決していきます。
(※本記事はGASについての記載です)

## 答え
<br>
一応変数としてなんでも入れられる

**ただ**

分かりやすいように**最低限の規則**がある
<br>
- イメージ
難しい方程式のある値をt,mなどに置き換えて計算しやすくすることがあります。ここで置き換える文字というのはt,mではなくても良いのです。ましてやイラストで置き換えてもよい。といったものでしょうか。
<br>
<img width="300" alt="[0.jpg]" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946215/0f93d489-9e61-7763-3353-67a77fadfd35.jpeg">

しかし、分かりやすいようにほぼ多くにアルファベットが使われています。

## GASの規則とは
こちらの記事がとても分かりやすく、また上記で掲示した写真のコードも記事に沿って書き直してみました。


[AutoWorker〜Google Apps Script(GAS)とSikuliで始める業務改善入門](https://auto-worker.com/blog/?p=6328)

<br>
<img width="300" alt="[スクリーンショット 2024-12-11 185809.png]" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3946215/715ba77a-5b29-913f-097e-003bdc93a8a4.png">

大体をキャメルコードに直しただけですが、ぱっと見でもこの変数が何を表しているのかをはっきりさせていれば良いと感じています。

## まとめ
ちょっとした変化に過ぎないですが、1度でもその意味を聞いたことでプログラミングに関する「抵抗感」が圧倒的に軽くなった気がします。

- **変数には分かりやすいように一定の原則があり、それに沿った変数を与えなければいけない。**
GitHub のデプロイメントのレビュー負荷を下げる方法

GitHub の [Environments](https://docs.github.com/ja/actions/managing-workflow-runs-and-deployments/managing-deployments) を活用することで、ワークフロー実行前に [デプロイメントのレビュー](https://docs.github.com/ja/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments) をすることができます。ワークフローのビルドパラメータ `on.workflow_dispatch.inputs` もレビューしたい場合は次のような一工夫が必要です。

例えば誤った環境にデプロイしていないかをレビューしたい時に役立ちます。

# 改善案

このように [run-name](https://docs.github.com/ja/actions/writing-workflows/workflow-syntax-for-github-actions#run-name) に `${{ toJSON(github.event.inputs) }}` を表示させることで、ビルドパラメータのレビューも手軽に出来るようになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/32736/37bd4943-9b53-60b1-09ee-75b71cde29ae.png)


```diff
name: deploy
+ run-name: Run by @${{ github.actor }} ${{ toJSON(github.event.inputs) }}
- run-name: Run by @${{ github.actor }}
on:
  workflow_dispatch:
    inputs:
      target:
        type: choice
        required: true
        options:
          - dev
          - stage
          - prod
      force-destroy:
        type: choice
        required: true
        options:
          - false
          - true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: deployments
    steps:
      - run: deploy.sh
```

別解として、次のようにビルドパラメータをダンプをするジョブの追加も考えられますが、ワークフローの実行名に表示させた方が目立つので忘れずにレビューできます。

```diff
+ jobs:
+   dump:
+     steps:
+       - run: echo "${{ toJSON(github.event.inputs) }}"

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: deployments
    steps:
      - run: deploy.sh
```

# もっと改善案（実行理由を書いてもらう）

実際に [デプロイメントのレビュー](https://docs.github.com/ja/actions/managing-workflow-runs-and-deployments/managing-deployments/reviewing-deployments) を運用してみると、ワークフロー実行者のデプロイの意図が分からないと判断できない場面があります。この課題はワークフロー実行者に **コメントを書いてもらうことで** 解決できるかもしれません。

```diff
name: deploy
run-name: Run by @${{ github.actor }} ${{ toJSON(github.event.inputs) }}
on:
  workflow_dispatch:
    inputs:
      target:
        type: choice
        required: true
        options:
          - dev
          - stage
          - prod
+     reason:
+       description: 'デプロイの目的を書いてください'
+       type: string
+       required: true
+       default: 'デプロイの目的は、〜'

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: deployments
    steps:
      - run: true
```

こうすることでワークフロー実行時に必ずコメントを求めることができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/32736/51a7def8-bc21-ce65-7372-d6dc501213bc.png)

コメントが長いとワークフロー一覧では尻切れになってしまいますが、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/32736/80d6ea9e-bb71-57ce-599e-ffd633d568ed.png)

クリックして詳細画面からは次のようにコメントは最後まで表示され、実行者の意図とビルドパラメータが合っているかをレビューすることができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/32736/03903a9f-49e2-7b68-9d5a-e789931e2b2f.png)

# おわり

GitHub の [Environments](https://docs.github.com/ja/actions/managing-workflow-runs-and-deployments/managing-deployments) は環境ごとにシークレットを格納するだけでなく、レビューや対象ブランチの制限など、主にデプロイに必要な機能が備わっていて便利です。一方で通常のコードレビューと比較するとデプロイメントのレビューは機能が十分でなく、レビュアが判断に困る場面があります。今回はビルドパラメータと実行理由を表示させるちょっとした工夫で、レビュアの負荷を下げる取り組みをしました。
送信レートの制御

>送信レートをどのように制御したら良いであろうか。

# フロー制御と輻輳を考えて送信レートを制御する
>送信レートの制御には、２つの制約要素を考える必要がある。第一は、フロー制御である。これは、受信側に十分な受信バッファがない場合に必要となる。第二は輻輳であり、ネットワークの容量が不足する場合に問題となる。

### ネットワーク層からのフィードバックで制御するが、フィードバックの内容が様々
>トランスポート層プロトコルが送信レートを制御する方法は、ネットワークを通して返されるフィードバック情報に依存する。ネットワーク層が違うと、フィードバックの仕方も違う。フィードバックは明示的であることも、暗示的であることもある。それはまた、正確であることも、曖昧であることもある

#### 様々なフィードバック
>明示的で正確な方法の一つは、ルーターが送信側に対してレートをシグナルとして伝えることである。XCPなどはこの方法を使う。

>明示的で曖昧な方法の一つは、TCPとECNを組み合わせて使う方法である。これは、輻輳を経験したパケットの中にルーターがビットを立てて、送信側に遅くするように伝えるのがあるが、どの程度遅くするかは伝えない。

>暗示的な方法はシグナルを用いない。FAST TCPは計測した往復時間を暗示的なシグナルとして用いて、輻輳回避を行う。

>今日のインターネットで広く利用されている輻輳制御は、TCPwith drop-tailあるいはREDルーターと呼ばれるものである。これはパケット・ロスを推定し、それに基づいてネットワークが輻輳状態であるかどうかを判断する。この種のTCPの変形は多数ある。

# 制御規則によって送信レートを上げ下げする
>`明示的で、正確なシグナルが与えられるのであれば、トランスポート・エンティティは、それを用いて送信レートを制御することができる`。例えばXCPでは、送信者にレートが通知されると、送信者は単純にそのレートを使うだけである。しかし他の場合は、推測が必要となる。`輻輳を示すシグナルがなければ、送信者は送信レートを上げる`。一方、`輻輳を示すシグナルが与えられたとき、送信者は送信レートを下げる`。送信レートの上げ下げの方法は、`制御規則(control law)`と呼ばれ、これが性能に大きな影響を与える

### AIMD(加算増加・乗算減少)の効率性と公平性のグラフを見て段々と最適点に収束される
>加算で増加、乗算で減少させる場合（AIMD)を考えよう。AIMDの動作を図6-25に示す。効率的で公平な最適動作点に向かって進むことが理解できるであろう。どのような動作点からスタートしても最適点に収束する。これがAIMDが広く使われる理由である。

>上記に加えて安定性に関する議論の結果、AIMDがTCPが制御規則として用いられている（すぐに輻輳状態になったり、回復が遅いとネットワークは不安定である。したがって、安定性のためには、増加は緩やかで、減少は緩やかの方が良い）

https://bookplus.nikkei.com/atcl/catalog/23/03/16/00728/
Swiper のイージングが変わらないときは .swiper-slide にCSSを書く

## 前提

- Swiper 11 系を使用
- （以下は関係ないかもしれないが一応記載）
    - Astro 3 系
    - Tailwind CSS 3 系

## 結論

Swiper のイージングが変わらないときは `.swiper-slide` にCSSを書くと変わる（かもしれない）。

`.swiper-wrapper` ではなく `.swiper-slide` に。

```css: サンプルを書くほどでもないCSS
.swiper-slide {
  transition-timing-function: cubic-bezier(1,0,0,1);
}
```

## 気づいた経緯

Swiper で実装したスライドショーに対して「イージング調整できませんか？」という依頼を受けた。

調べると「 `.swiper-wrapper` にCSSを書いてね」という情報が多くヒットした。
公式のIssueにも残っている。

https://github.com/nolimits4web/Swiper/issues/496

:::note 
このIssueは2013年だが、2021年にも「イージングのオプションを追加してほしい」というIssueが立っていた。

「CSS の transition-timing-function で簡単に変更できますよ」という回答でクローズされている。

https://github.com/nolimits4web/swiper/issues/4377
:::

初期設定のCSSを見たら、確かに  `.swiper-wrapper` に `transition-timing-function` のCSSが適用されている。

簡単でよかった〜と思いCSSを追加したが、変わらない。

わかりやすいように秒数を増やしてみたり、バウンドするぐらい極端なイージング曲線にしてみたり、もろもろ試したが変わらない。

なんで？バージョンアップで調整不可になったとか？と焦りつつ、各セレクタのCSSを見直してみた。
そうしたら、 `.swiper-slide` にも `transition-timing-function` のCSSが適用されていた。

もしかして？と思い、CSSを追加した。
あっさり変わった。

## わかっていないこと

- これだけ有名なライブラリなのに、 `.swiper-slide` にCSSを足してイージングを調整するという記事がパッとは見つからなかった
    - そんなことあるか？
    - （自分のプロジェクトだけがバグっていた可能性も大いにある）
- この方法でイージングを調整した場合、 `.swiper-wrapper` に適用されている `transition-timing-function` は何の役割があるのだろうか
[React] keyプロパティを利用してstateをリセットする

# はじめに

Reactの`key`プロパティと言えば、通常はリスト要素を一意に特定するために利用しますね。
実は、その特性を応用して状態(state)をリセットする方法があります。
本記事では、実際にあった事例をベースに、その方法について紹介します。

https://ja.react.dev/learn/preserving-and-resetting-state#option-2-resetting-state-with-a-key


# 状態が更新されない問題

以前、あるライブラリのコンポーネントを利用していた際、「渡す値を更新しても表示が切り替わらない」という問題が発生しました。
その時の内容を簡易化して再現したものを共有します。

## 問題のコード

`CountMonitor`コンポーネントにカウントを渡し、カウントをボタンで増やすという単純なものです。

```tsx
import { useState } from 'react'
import './App.css'

const App = () => {
  const [count, setCount] = useState(0)

  return (
    <>
      <h1>Key Usage Sample</h1>
      <div className="card">
        <button onClick={() => setCount((count) => count + 1)}>
          Count UP!
        </button>
        <CountMonitor count={count} />
      </div>
    </>
  )
}

// これは実際には外部ライブラリ内のコード
const CountMonitor = (props: { count: number }) => {
  const displayNumber = useState(props.count)

  return (<>
    <div className="card">
      現在のカウントは「<>{displayNumber}</>」です。
    </div>
  </>)
}

export default App
```


## 問題発生時の動作

問題のコードを実行したものが以下です。

![test.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/36a84719-ce42-a42d-1950-8273e9c3b572.gif)

ボタンを押しても『現在のカウントは「0」です。』のままで、表示が更新されません。

## 原因

原因はライブラリ内の以下のコード

```tsx
const displayNumber = useState(props.count)
```

Reactでは、`props`が更新されてもコンポーネントの内部状態（`useState`で管理される状態）は維持される特性があります。
useStateの初期化（上記のコード）は、コンポーネントの初回レンダリング時にのみ実行されます。そのため、`props`が更新されても、再レンダリング時に初期値が再評価されないため、更新された値が反映されません。

## 解決方法

コンポーネントの作りがイケてないので、修正したいところですが、外部ライブラリのためそうはいきません。
そこで利用できるのが`key`プロパティです。

`key`プロパティはコンポーネントが同一のものかの判断に使われます。
つまり、この値が変わるとReactが別のものになったと判断します。
これにより、`CountMonitor`再作成され、その際に新しい`props`の値が正しく初期化に使用されるようになります。

## 改善版のコード

改善版では、`CountMonitor`の`key`プロパティに`count`の値を利用して一意なキーを指定しています。これにより、カウントが変わるたびに新しいコンポーネントが生成されます。

```diff_tsx
import { useState } from 'react'
import './App.css'

const App = () => {
  const [count, setCount] = useState(0)

  return (
    <>
      <h1>Key Usage Sample</h1>
      <div className="card">
        <button onClick={() => setCount((count) => count + 1)}>
          Count UP!
        </button>
-       <CountMonitor count={count} />
+       <CountMonitor key={`counter-${count}`} count={count} />
      </div>
    </>
  )
}

// これは実際には外部ライブラリ内のコード 
const CountMonitor = (props: { count: number }) => {
  const displayNumber = useState(props.count)

  return (<>
    <div className="card">
      現在のカウントは「<>{displayNumber}</>」です。
    </div>
  </>)
}

export default App
```

## 改善版の動作

改善版のコードを実行したものが以下です。

![test2.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3294382/dc5759b4-6b7d-b6c7-f15d-022ea1562e40.gif)

ボタンを押した時にカウントが増えるようになっていますね！
  
これは、ボタンをクリックしてカウントを増やすたびに、CountMonitorコンポーネントが新しいkeyを持つため、Reactは古いコンポーネントを破棄し、新しい状態で再生成します。
これにより、useStateが毎回初期化されるようになりました。


# 注意点

今回の事例は`key`プロパティの理解を深めるために紹介しました。
ただ、この方法では毎回コンポーネントが破棄されて再生成されるため、大量の更新が発生するケースではパフォーマンスが低下する可能性があります。
あくまで止むを得ない場合の対応として活用しましょう。

# まとめ

`key`プロパティはリスト表示以外の使い方を紹介しました。
この記事で少しでも理解が深まりましたら幸いです。
夜型の僕が朝活に目覚めて生産性が爆上げしたお話。

# はじめに

この記事は、株式会社スピードリンクジャパン Advent Calendar 2024 の13日目の記事です。


https://qiita.com/advent-calendar/2024/slj


こんにちは！
今回は朝活に目覚めた僕の体験談を紹介したいと思います。
最後まで見ていただけたら、嬉しいです！

![.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3524127/c5659059-7d1d-73d6-fbc4-9d46bc48660f.gif)



# 1. なぜ夜型だったのか？
* #### 夜の方が集中できると思っていた。
夜は静かで邪魔が入りにくいため、勉強や作業がはかどるように感じていました。
特に楽しい作業ほどアドレナリンが出てしまい、寝る時間関係なく作業をしてしまうことがあったりもしました。

* #### 趣味に没頭する時間が夜だった
仕事終わりや休日などは基本家でお酒を飲みながら、アニメや映画を見るのが日常でした。1日の出来事を忘れられ、何も考えずにアニメや映画をみる時間が好きだったのかもしれません。

* #### 自分は夜型と思い込んでいた
元々朝起きるのが得意ではなかったというのもありますが、夜の方が自由な時間を確保できて気楽だと感じることが多かったのです。特に夜は、周りからの干渉が少なく、スマホやパソコンで好きなことに没頭できる時間でした。「この時間こそ、自分のゴールデンタイムだ」とさえ感じていました。

* #### 睡眠リズムが乱れ過ぎていた
一度夜更かしをしてしまうと、それが続いてしまい、気づけば夜型が習慣化していました。週末の夜更かしが平日にも影響し、寝不足が当たり前に感じる生活になっていました。


# 2. 朝活を決心したわけ
* #### 睡眠リズムの安定
    * 今までの平日の睡眠時間は多くて5時間、少ない時は1~2時間という睡眠リズムだったため、最低でも5~6時間寝るようすることで、常に調子を安定させたかったからです。

* #### 寝落ちしてしまうことが多く、体が痛いことが多かった
    * お酒を飲みながら、アニメや映画を見ているとよく寝落ちしてしまうことが多く、次の日体が悲鳴を上げていることが多かったです。

* #### 時間ギリギリに起きてしまうことが多かった
    * 出社する場合やリモートの場合でもいつもギリギリに起きて、急いで準備をしてという毎日慌ただしく、仕事に臨んでいたから。

# 3.現在の朝活ルーティーン
※在宅の場合

* #### 出勤2時間半前に起きる
    * 今まで在宅の時は、時間ギリギリに起きてしまうことが多かったのですが、なるべく余裕を持って起きることで、その日にどんな作業をするかなど1日のスケジュールをたてることで、慌てず作業に入らなくなりました。

* #### 起きたら15~30分ほど歩く。
    * 在宅の際は、なかなか外に出ていなかったので、朝の散歩を取り入れることにしました
    * 朝何も考えずに歩くことで、リフレッシュした気持ちで仕事に入れます。
* #### 1時間勉強する
    * 今までは夜に勉強を取り入れていましたが、朝の勉強ほど捗るものはありません
    * 今はJavaScriptの勉強やRailsでのバックエンドの方も勉強しています。

# 4. 生産性が爆上げした理由
* #### 睡眠リズムの安定
朝型に転換することで、一定の睡眠時間を確保でき、体調が安定しました。安定した睡眠により、集中力やエネルギーが向上し、作業効率が上がったと考えられます。

* #### 慌てずに過ごせる朝の時間
出勤前に余裕を持って起きることで、1日のスケジュールを落ち着いて立てることができ、慌てず作業に入れるようになりました。この余裕が精神的な安定を生み、焦りやストレスを減少させたことが生産性向上に寄与した可能性があります。

* #### リフレッシュ効果のある朝の散歩
朝、外に出て歩くことで、リフレッシュし、脳が活性化されます。これにより、仕事に取り組む前に心身が整い、集中力が高まりやすくなったと思われます。

* #### 朝の勉強時間
夜の勉強よりも朝の方が集中でき、効果的に学習できるという実感があることで、知識の習得速度が向上し、全体的な生産性が高まりました。

# 4. 参考にしたモーニングルーティーン

* https://youtu.be/D-4i5W1u3m0?si=1-nycrC85jubOKpg

* https://youtu.be/ciCpnG2fWes?si=w_mgCAG4wQAPPwYy

* https://youtu.be/WZnbzDDgjRg?si=z_AF45dX6AQhmNvW


# 最後に
いかがでしたか？
ぜひこの記事を読んで、10分でも早く起きてみよ！という人が増えてくれると嬉しいです！

では、次の記事で〜！
Terraform Cloudでtfvarsファイルを使う方法

# はじめに

どうも、@to-fmakです。最近Terraform Cloudでtfvarsファイルを使う必要があったので、その実現方法について簡単に共有したいと思います。

# ディレクトリ構成

今回使うTerraformのディレクトリ構成が下記の通りです。

ルートディレクトリにtfファイルを配置し、そこからmodulesディレクトリ内のsampleモジュールを呼び出す構成です。変数定義はvariables.tfに記載し、値は環境ごとにenvディレクトリ内のtfvarsファイルに分けています。

```txt
.
├── env
│   ├── dev.tfvars
│   ├── prd.tfvars
│   └── stg.tfvars
├── main.tf
├── modules
│   └── sample
│       ├── main.tf
│       ├── outputs.tf
│       └── variables.tf
├── providers.tf
└── variables.tf
```

planやapplyを実行する際に、`-var-file=`のCLIオプションで、環境に応じたtfvarsファイルを指定します。

# Terraform Cloud移行時の問題点

上記TerraformコードをTerraform Cloudに移行する必要がありました。

Terraform Cloudの設定として、以下を利用しました。

- ワークスペース: GithubをVCSとして連携し、リモート実行モード(remote execution mode)を使用
- トリガー: Terraform CloudのUIやGitHubのPR作成・マージをトリガーに、planやapplyを自動実行

ただし、この設定では-var-file=のようなCLIオプションが利用できず、別の方法でtfvarsファイルを指定する必要がありました。

# ワークスペースの変数について

Terraform Cloudでは、各ワークスペースに環境固有の変数を直接追加することで、tfvarsファイルを指定せずにapplyを実行できます。この方法では、Terraform CloudのUIから変数を管理するか、tfeプロバイダーを使って変数をコードで管理することも可能です。

ただし、今回は既存のtfvarsファイルをそのまま利用したいため、ワークスペースに変数を直接追加する方法は採用しませんでした。

https://developer.hashicorp.com/terraform/cloud-docs/workspaces/variables

https://registry.terraform.io/providers/hashicorp/tfe/latest/docs

# *.auto.tfvarsファイルについて

Terraformは、.auto.tfvarsファイルを自動で読み込む仕組みを提供しています。作業ディレクトリにこのファイルを作成すれば、planやapply実行時に自動的に適用されます。

注意点として

- .auto.tfvarsファイルの変数はterraform.tfvarsより優先される
- コマンドラインやHCP Terraformのワークスペース変数で指定された変数が最優先される

>Variables in the .auto.tfvars files take precedence over variables in the terraform.tfvars file.

>Variables in the HCP Terraform workspace and variables provided through the command line always overwrite variables with the same key from files ending in .auto.tfvars.

https://developer.hashicorp.com/terraform/cloud-docs/workspaces/variables

この方法は共通設定には便利ですが、環境ごとに異なる変数が必要な場合、既存のディレクトリ構成やファイル内容を変更する必要かと思います。

# 環境変数TF_CLI_ARGS_planの活用

Terraformでは、TF_CLI_ARGS_xxxという環境変数を使ってコマンドのデフォルトオプションを指定できます。これにより、コマンド実行時に毎回オプションを記述する必要がなくなります。

https://developer.hashicorp.com/terraform/cli/config/environment-variables

```bash
# CLIオプションを指定する場合
terraform plan -var-file=./env/dev.tfvars

# 環境変数を設定して実行する場合
export TF_CLI_ARGS_plan='-var-file=./env/dev.tfvars'
terraform plan
```

Terraform Cloudでこれを実現するには、対象ワークスペースに必要な環境変数を追加する必要があります。

また、Run typeを「Plan and apply」に設定すると、applyは直前のplan結果に基づいて実行されるため、TF_CLI_ARGS_applyの設定は不要です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2954734/addaae69-6a74-a45d-3c37-e87db15b61a4.png)

# おわりに

Terraform Cloudで変数を設定する方法は複数あります。本記事では、既存のtfvarsファイルをそのまま適用する方法に焦点を当てて解説しました。実際にTerraform Cloudを活用する際は、プロジェクトの目的や要件に応じて最適な方法を選択し、効率的で柔軟な環境管理を実現していただければと思います。

# 参考URL

https://developer.hashicorp.com/terraform/cloud-docs/workspaces/variables

https://registry.terraform.io/providers/hashicorp/tfe/latest/docs

https://developer.hashicorp.com/terraform/cli/config/environment-variables

# エンジニア募集

Gakken LEAP では教育をアップデートしていきたいエンジニアを絶賛大募集しています！！
ぜひお気軽にカジュアル面談へお越しください！！

https://gakken-leap.co.jp/recruit/
[翻訳記事 | AWS初心者] クラウドの概念 | クラウドコンピューティングのモデル (IaaS, PaaS, SaaS)

# [翻訳記事 | AWS初心者] クラウドの概念 | クラウドコンピューティングのモデル (IaaS, PaaS, SaaS)

元記事: https://devblogeasyoon.xyz/blog/aws-certification-basic-cloud-model


## クラウドコンピューティングの種類

- **クラウドコンピューティングモデル**と**クラウドコンピューティング展開モデル**に分類される：
  - **クラウドコンピューティングモデル**: クラウドコンピューティングが提供するサービスの種類による分類。
  - **クラウドコンピューティング展開モデル**: クラウドコンピューティングが提供される方法による分類。

---

## クラウドコンピューティングモデル

- **基本的なアプリケーション構成要素の5つ**：
  - **ネットワーク**: LANカード/ケーブル
  - **ストレージ**: SSD / HDD
  - **コンピューティング**: CPU / RAM
  - **OS**: Windows / Linux
  - **アプリケーション**

- 提供される構成要素による分類：
  - **IaaS**
    - Infrastructure as a Service（インフラストラクチャ・アズ・ア・サービス）: インフラのみを提供。
    - ネットワーク + ストレージ + コンピューティングを含み、OSとアプリケーションはユーザーがインストール。
    - 仮想コンピュータを借りるのと同様。
    - 例: AWS EC2

  - **PaaS**
    - Platform as a Service（プラットフォーム・アズ・ア・サービス）: アプリケーションコード以外の全ての構成要素を提供。
    - インフラやサーバーなど、アプリケーション開発に必要な構成要素を提供し、コードをアップロードしてすぐに実行可能。
    - 例: Firebase, Supabase

  - **SaaS**
    - Software as a Service（ソフトウェア・アズ・ア・サービス）: インフラ + OS + 必要なソフトウェアを提供。
    - サービス自体が提供され、特別な設定をせずに利用可能。
    - 例: Gmail, Slack, Dropbox など

---

## クラウドコンピューティング展開モデル

- **パブリック（クラウド）モデル**
  - アプリケーションの全てがクラウド内で実行される。
  - 低コストなリソース。
  - 高い拡張性。

- **プライベートモデル**
  - カスタマイズ性が最も高い。
  - 初期リソースコストが高い。
  - メンテナンスコストが高い。
  - セキュリティが強化されている。

- **ハイブリッドモデル**
  - プライベートモデルとパブリックモデルの混合。
  - プライベートからパブリックへ移行する段階で多く利用される。
  - プライベートモデルのバックアップとして利用されることが多い。
新人プログラマの心に火をつけてくれた本たち

私自身が新人プログラマだったころに読んで「心に火をつける」ためのマインドセットの形成に役立ったなと感じた書籍です。どれも有名な書籍なので、そのタイトルに関連する記事はたくさん書かれていそうです。

というわけで、書籍に関連した記事を検索できるためのショートカットリンクもあわせてつけました。

## 『達人プログラマー』


プログラマーとしての考え方や仕事への取り組み方に焦点を当て、学び続ける姿勢や自律性を養うきっかけになります。

https://qiita.com/search?q=%E9%81%94%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC

## 『Unixという考え方』 


シンプルで小さなツールを組み合わせ、柔軟で効率的なシステムを構築するための考え方が散りばめられています。

https://qiita.com/search?q=Unix%E3%81%A8%E3%81%84%E3%81%86%E8%80%83%E3%81%88%E6%96%B9


## 『エッセンシャル思考』

やるべきこと考えることがたくさんあるとき、それらに忙殺されないように本当に重要なことに集中するための考え方が得られます。

https://qiita.com/search?q=%E3%82%A8%E3%83%83%E3%82%BB%E3%83%B3%E3%82%B7%E3%83%A3%E3%83%AB%E6%80%9D%E8%80%83

## 『具体と抽象』

抽象的思考と具体的思考を行き来し、問題解決力を鍛える基礎が身につきます。最初は具体のことしか考えられず他の事象への転用がうまくできなかったのですが、知識としてインプットしておくとじわじわと効いてきて、この本で言っていたのはこの事だったのか！という発見が多いです。

https://qiita.com/search?q=%E5%85%B7%E4%BD%93%E3%81%A8%E6%8A%BD%E8%B1%A1


## 定期的に読み返す
どれも書籍として読みやすいのですが、一度では咀嚼しきれなかったりそのときの自身の経験や知見からはすべてを受け取れていないものも多いので定期的に読み返しながら理解をより深めていくことをおすすめします！
プロ野球｜凡退の種類と打率の関係

## 概要

本記事では、打者の凡退分類（ゴロ、ライナー、三振、内野フライ、外野フライ）と打率の関係についてpythonを用いて統計的な分析を行いました。凡退分類の割合が打率にどの程度影響を与えるのかを回帰分析により検証し、また打率3割以上と打率3割未満の違いを比較しました。

## 円グラフ（凡退分類の割合）

```python
# 円グラフ表示関数
def plot_pie_from_means(mean_df, title, column_name):
    data = mean_df[['分類', column_name]].copy()
    total = data[column_name].sum()
    data['割合'] = data[column_name] / total
    plt.figure(figsize=(8, 8))
    plt.pie(data['割合'], labels=data['分類'], autopct='%1.1f%%', startangle=90)
    plt.title(title)
    plt.show()

# 円グラフ表示
plot_pie_from_means(mean_over_300_100, '打率3割以上100打席以上の凡退平均割合（その他除外）', '割合_3割以上100打席以上')
plot_pie_from_means(mean_under_300_100, '打率3割未満100打席以上の凡退平均割合（その他除外）', '割合_3割未満100打席以上')
```

以下は、打率3割以上の打者と打率3割未満の打者における凡退分類の平均割合を示した円グラフです。
### 打率3割以上100打席以上の凡退分類割合
![スクリーンショット 2024-12-11 18.26.14.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933685/8ac3b863-cb1b-9160-e6f2-6128b148bc4f.png)

### 打率3割未満100打席以上の凡退分類割合
![スクリーンショット 2024-12-11 18.26.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933685/f9cd03da-5a86-b493-ee1e-0042904ae3a1.png)


## 回帰分析結果

回帰分析では、各凡退分類が打率に与える影響度（回帰係数）とモデルの説明力（決定係数R²）を計算しました。

### 回帰係数（各凡退分類の影響度）

- **三振: -0.1506**
  - 三振割合が増えると打率が下がる。三振を減らすことが打率向上に寄与する可能性。
- **ライナー: +0.0728**
  - ライナー（直線的な当たり）が増えると打率が上がる。強い打球をライナーで飛ばす打者はヒットを増やしやすい。
- **外野フライ: +0.1130**
  - 外野フライが増えると打率が上がる傾向。外野への当たりは守備間を抜けやすいことが原因かもしれない。
- **ゴロ: -0.0193**
  - わずかにマイナスで、打率にはほぼ中立的な影響。
- **内野フライ: -0.0160**
  - わずかなマイナスで、打率への影響は少ない。
- **決定係数R²: 0.1582**
  - モデルが打率を約15.82%説明できることを意味する。凡退分類だけでは打率を十分に説明するのは難しいことが分かる。

```python
X = final_data[categories]
y = final_data['打率']

model = LinearRegression()
model.fit(X, y)

print("\n回帰係数:")
for f, coef in zip(categories, model.coef_):
    print(f"{f}: {coef:.4f}")

print(f"切片: {model.intercept_:.4f}")
print(f"決定係数R^2: {model.score(X, y):.4f}")
```


## グループ間比較（3割以上 vs 3割未満）

### 平均割合

| 分類 | 割合_3割以上100打席以上 | 割合_3割未満100打席以上 |
|------|----------------------|----------------------|
| ゴロ | 0.401971             | 0.373716             |
| ライナー | 0.026079             | 0.024042             |
| 三振 | 0.254996             | 0.287403             |
| 内野フライ | 0.083868             | 0.092017             |
| 外野フライ | 0.233086             | 0.222821             |

### 傾向

- **高打率（3割以上）の打者**:
  - 三振と内野フライが低く、ゴロ、ライナー、外野フライがわずかに多い。
- **低打率（3割未満）の打者**:
  - 三振と内野フライが多く、ゴロ、ライナー、外野フライが少ない傾向。

## 考察

### 1. 三振が最も打率低下に影響している

三振は最も打率に悪影響を与える凡退分類であり、三振を減らすことが打率向上に有効と考えられる。
バットをフラットに出している打者が多いと考えられる(ボールとバットが当たるポイントが増えるため)。

### 2. ゴロ、ライナー、外野フライが打率にプラス

ゴロ、ライナー、外野フライは打率をわずかに押し上げる傾向がある。前に打球が飛ぶだけでヒットになる確率は上がる。

### 3. 決定係数R²が低い理由

決定係数が0.1582と低く、凡退分類だけでは打率を十分に説明できない。他の要因を考慮したモデルの改善が必要。

## まとめ

- 三振を減らす戦略が打率向上の鍵。
- バットをフラットに出すことが鍵になる可能性がある。
- 凡退分類だけで打率を説明するのは不十分であり、複数の要因を統合した分析が重要。
【Laravel】－初学者向け　Laravelの基本Artisanについて

今回はLaravelでよく出てくるArtisanの用語について
説明していきたいと思います。

# Artisan（アルチザン）とは？
Artisan（アルチザン）とは？
Laravelに搭載されているコマンドラインインターフェースのことです。
Artisan（アルチザン）にはLaravelでよく使う操作やファイル生成を行ったりします。


# artisanコマンドについて

artisanコマンドはいろいろあります。

artisanコマンドを一覧で表示
```
php artisan list
```

マイグレーションの実行
```
php artisan migrate
```

コントローラーを作成
```
php artisan make:controller
```

モデルを作成
```
php artisan make:model
```

上記のコマンドはよく使うので、覚えておくと便利でしょう！
Elixirで作る「DDJ-FLX4のジョグ対応ブロックくずし」　その１　プロジェクト作成からライブラリ追加まで

# ジョグとは

DJコントローラーにある写真の円盤です
本来は、スクラッチや曲の再生位置を調整する為に使います

![p_20241211_172127_720.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/295814/4f033a8c-9fa6-2b03-c51e-d3d30649ada6.jpeg)

# これから作るゲームの仕様

```
　■　■　■　■　■　■　■　■　←　ブロック
　■　■　■　■　■　■　■　■　
　■　■　■　■　■　■　■　■　

　　　　　　　　　●　←　玉

　　　　　　　　■■■　←プレイヤー　

```

- `プレイヤー`は左右に動けます
- `玉`は、当たると跳ね返る
- `プロック`は`玉`に当たると消えます
- `玉`は、`プレイヤー`より下に行くとゲームオーバーです


「DDJ-FLX4のジョグ対応ブロックくずし」とは`ジョグ`の回転で`プレイヤー`の操作します

:::note warn
コラム作成者は音楽のセンスが無いためDDJ-FLX4はゲームコントローラーに見えてしまいました
:::

:::note alert
コラム作成者にDDJ-FLX4の使い方が違うと突っ込まないでください
これはコラム作成者の仕様です
:::

:::note info
DDJ-FLX4は入院中に頂きました
ありがとうごさいました
1年前退院まで我慢できなくて病院に持ち込んでしまいました
:::

# 環境
- OS Ubuntu 22.04
- DJコントローラー PioneerDj DDJ-FLX4
- Elixir (1.17.2) 
- Erlang/OTP 26
- ライブラリ
  - portmidi
  - Rayex

# 前提知識
下記の僕が書いたコラム、ここで生かされます

https://qiita.com/t-yamanashi/items/6200672d48ef9e7a9df6

https://qiita.com/t-yamanashi/items/d02c12f33fc18c585a4b

# まずはプロジェクトを生成する

```sh
$ mix new ddj_block
$ cd ddj_block
$ mix test
```

# ライブラリの追加

```diff_elixir:mix.exs
defmodule DdjBlock.MixProject do
  use Mix.Project

  def project do
    [
      app: :ddj_block,
      version: "0.1.0",
      elixir: "~> 1.17",
      start_permanent: Mix.env() == :prod,
      deps: deps()
    ]
  end

  # Run "mix help compile.app" to learn about applications.
  def application do
    [
-     extra_applications: [:logger]
+     extra_applications: [:logger, :portmidi]
    ]
  end

  # Run "mix help deps" to learn about dependencies.
  defp deps do
    [
+     {:rayex, "~> 0.0.3"},
+     {:portmidi, "~> 5.0"}
      # {:dep_from_hexpm, "~> 0.3.0"},
      # {:dep_from_git, git: "https://github.com/elixir-lang/my_dep.git", tag: "0.1.0"}
    ]
  end
end
```

```sh
$ mix deps.get
```

# ソース

https://github.com/ymn-t-yamanashi/ddj_block/releases/tag/v0.01

今回はここまで
つづく

https://qiita.com/t-yamanashi/items/e1d4299cc18310f79c57
Libpam-google-authenticatorを使ってSSHでLinuxでログインする

## 最近この内容を知ったのでまとめてみました。

# SSHで `libpam-google-authenticator` を使って二段階認証を設定する

Linux サーバーに SSH でログインする際、二段階認証（2FA）を導入してセキュリティを強化する手順を紹介します。`libpam-google-authenticator` を使用し、Google Authenticator アプリを使ったワンタイムパスワード (OTP) 認証を追加します。

## 前提条件

- Linux サーバー (例: Ubuntu, CentOS など)
- SSH が既に動作している
- `sudo` 権限を持つユーザー
- スマートフォンに Google Authenticator アプリをインストール済み

## 手順概要

1. `libpam-google-authenticator` をインストールする
2. SSH で PAM 認証を設定する
3. ユーザーごとに Google Authenticator を設定する
4. SSH 設定ファイルを編集し、二段階認証を有効にする

---

## 1. `libpam-google-authenticator` のインストール

まず、Google Authenticator の PAM モジュールをインストールします。

### Ubuntu または Debian 系の場合

```bash
sudo apt update
sudo apt install libpam-google-authenticator
```

### CentOS または RHEL 系の場合

```bash
sudo yum install epel-release
sudo yum install google-authenticator
```

## 2. PAM 設定の更新

`/etc/pam.d/sshd` ファイルに、Google Authenticator を使うための設定を追加します。

```bash
sudo nano /etc/pam.d/sshd
```

ファイルの一番下に、次の行を追加します:

```plaintext
auth required pam_google_authenticator.so
```

## 3. ユーザーごとに Google Authenticator を設定

各ユーザーが Google Authenticator で使用する OTP を生成します。

### Google Authenticator を設定するユーザーでログインし、次のコマンドを実行します:

```bash
google-authenticator
```

ここで、いくつかの質問が表示されます。設定例は一例ですので個々での設定でお願いいたします。

- 新しい認証トークンを作成しますか？: `y`
- その後、緊急のスクラッチコードが5つ発行されます。
- .google_authenticator　ファイルを更新しますか？ `y`
- 同じ認証トークンの複数回使用を禁止しますか？これにより約30秒ごとに1回のログインに制限されますが、中間者攻撃に気付いたり、防いだりする可能性が高まります。 `y`
- 同期の誤差を許可しますか？: `y`
- 再利用可能なバックアップコードを表示しますか？: `y`
- Rate-limiting 機能を有効にしますか？: `y`

この操作により、QR コードと秘密鍵が表示されます。Google Authenticator アプリで QR コードをスキャンして、OTP を生成できるようにします。

## 4. SSH 設定を変更して 2FA を有効にする

次に、SSH の設定を変更します。

### `/etc/ssh/sshd_config` ファイルを開きます。

```bash
sudo nano /etc/ssh/sshd_config
```

次の 2 つのパラメータを確認・変更します:

```plaintext
ChallengeResponseAuthentication yes
UsePAM yes
```

設定を保存して終了したら、SSH サービスを再起動します。

```bash
sudo systemctl restart sshd
```

## 5. 設定のテスト

設定が完了したら、一度 SSH 接続を試みます。パスワードの後に、Google Authenticator に表示されるワンタイムパスワードを入力するよう求められます。

```bash
ssh your-user@your-server-ip
```

## まとめ

これで、SSH ログインに二段階認証が追加されました。今後は、パスワードに加えてワンタイムパスワードを入力する必要があるため、セキュリティが大幅に向上します。Google Authenticator や、sshでのログインが可能です。

---
[CDGC] Microsoft Sharepoint Onlineのスキャン

<h1> はじめに

[インフォマティカ](https://www.informatica.com/ja/)が提供する、 [CDGC](https://www.informatica.com/ja/products/data-governance/cloud-data-governance-and-catalog.html)(データガバナンス＆カタログ)を使って、Microsoft Sharepoint Onlineからメタデータを取得(スキャン)するためのガイドです。

Sharepoint Onlineのメタデータを取得するための全体的な流れは下図の通りです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/82f2f768-041c-9636-331a-013560d8c1da.png)

<h1>前提条件

メタ情報抽出権限：
１．Microsoft SharePoint Online アカウントに接続し、Microsoft SharePoint Online アプリケーションにアクセスできること。
２．Microsoft SharePoint Online コネクタを設定すること。
３．サイトおよびそのコンテンツ（サブサイトやドキュメント ライブラリなど）への読み取り権限を付与すること。

<h1>接続作成

Sharepointの接続は事前に作成する必要があり、少しAzure側の作業や確認が必要となりますので、詳細は[Informatica IDMC上にSharepoint Online接続を作成](https://qiita.com/nickqinsc/private/112f2935d9bf8de6e627)の記事をご覧ください。


<h1>カタログソースを作る

これからカタログソースを設定します。

新規ボタンより、新しいジョブを作ります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/39210369-dc4c-d7f5-b38a-45d2ea698924.png)

カタログソースからMicrosoft Sharepoint Onlineを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/45030b8b-c591-01c7-4584-733aa7e7b566.png)

全般情報にジョブ名前を入れて、接続リストから事前に作成されたSharepoint Onlineの接続を選択して、接続をテストします。画面上に「テスト成功しました」のメッセージが出てきたら、問題なく接続できたのことです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/2f0d3663-0907-4031-aa0d-85ad43e6171c.png)

次、メタデータ抽出設定を行います。
ランタイム環境は自社のSecure Agentを選択します。
メタデータ変更オプションでメタデータの変更を保持するか削除するかを選択します。
メタデータの抽出範囲に対してフィルターかけることが可能です。

:::note warn
データ分類がAIエンジンが自動的にやって欲しいであれば、データ分類の設定に入って、ボタンをオンにすればOKです。
今回は最小限の設定で行きたいので、省略します。
:::

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/20ca038d-8519-5b6d-0eda-915090ff8591.png)

他の設定は必須ではないため、このまま保存して、実行しましょう。実行完了しましたら、データガバナンス＆カタログの画面にて結果をチェックしましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/db1f72b9-4728-6ba1-9ab9-584b0d554d50.png)

<h1>まとめ

Informaticaのカタログ製品は非常にシンプルな設定だけでメタデータを自動抽出できますので、ぜひ一度お試しください。
また、Informaticaカタログの他の機能について興味がございましたら、コメントをお願いします。
5分で完成！AIと遊んで似顔絵アイコンを作ってみた✏️

こんにちは、デザイナーのコットンです。
先日、近所に引っ越してこられた方がご挨拶に来てくださった際にいただいたのが「久世福のだし」。実は以前にも別の方からいただいたことがあって、「これって引っ越しのご挨拶の最適解なんじゃない？」と密かに思っていました。たぶん、これが正解です。

この記事は LabBase テックカレンダー Advent Calendar 2024 の 11 日目の記事です。

https://qiita.com/advent-calendar/2024/labbase

## はじめに
今回は Adobe Illustrator の「生成塗りつぶし」機能（生成AI）を活用し、オリジナルの似顔絵アイコンを作成する方法をご紹介します。短時間で完成できるこの方法、ぜひ試してみてください！

## 対象者
- プロに頼む予算がない方
- 時間がないけれどクオリティも妥協したくない方
- 他人と同じアイコンに飽きてしまった方

## 手順
作業は大きく3つのステップに分かれます。これだけ見ると至ってシンプルですが、5分で本当にできるのかを疑います。

1. 手書きのイラストを作成 (2分)
2. 描いたイラストをIllustratorに配置 (1分)
3. 生成塗りつぶしを使って生成 (2分)

### 手書きのイラストを作成
生成塗りつぶしの機能を使うにはベクターデータである必要があるため、やる気ゼロでイラストを書きます。著者は、[Procreate](https://procreate.com/jp) を使って写真からトレースしましたが、Illustratorで直接描いてもOKです。この程度で精度がどうなるかが気になりますね。

![procreate.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/05ff1cc3-29d3-5709-4408-36b8f6340509.png)

### 描いたイラストをIllustratorに配置
Procreateで描いたイラストをPNG形式で書き出し、Illustratorに配置します。その後、画像トレースを使ってベクターデータに変換します。シンプルな線画なので種類はスケッチアートで問題ありません。

![画像トレース.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/25887023-5b8b-ac1f-d1ac-cce35e2290d9.png)


次に、アイコン用の正円を楕円ツールで作成し、イラストと調整します。
![icon-circle.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/51adb99a-28ff-ad61-ed00-a3b50cb833ef.png)


### 生成塗りつぶしを使って生成
イラストを選択すると、コンテキストタスクバーに「生成塗りつぶし（シェイプ）」が表示されるので、そこから生成を開始します。

![生成塗りつぶし-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/087c116e-6cdb-4383-5661-6c8b15a8f3b8.png)

プロンプト入力画面が表示されますが、フォーム横の歯車アイコンをクリックして詳細設定に遷移します。
プロンプトに何も入力しなくても自動的に生成されますが、「30代の男性」など、基本的な情報を入れると精度が上がります。

![生成塗りつぶし-02.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/64d87968-e9eb-1b8d-fabd-439e0d58a283.png)

今回は主に以下のような設定で生成してみました。

```
プロンプト：
 - Aさん：根暗なキノコカット、30代男性
 - Bさん：エネルギッシュ、30代女性
 - Cさん：薄いヒゲ、40代男性、爽やか
シェイプの強度：中
ディティール：中
スタイル参照：あり
効果：フラットデザイン
カラーとトーン：白黒
```

## いでよ、生成！そして願いをかなえたまえ！！
はい、生成された結果がこちらです。元のイラストの特徴が適度に誇張されていて、短時間でこのクオリティなら問題ないでしょう。上手く表現できなかった部分は手書きイラストの精度を上げると良い感じに生成できるかもしれません。

![generation-ai-2471.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/071aefea-3bb9-35a4-f676-1c0a677f187a.png)

## 生成のコツ
生成すると、3パターンの異なるデザイン案が提案されます。そこを絞るのがスタイルですが、この方向が良いなというアセットがあれば参照することができます。そうすることである程度、デザインを統一することが可能になります。

![スタイルの参照.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/a4555616-6405-ef55-d6dd-fca1fa5dd798.png)

また、ディティール設定を「最高」にすると、より細かい表現が可能になります。何か海外映画に出てきそうなアーティスティックな仕上がりになりました。

![generation-ai-2471-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3933203/c206339b-3f8a-e6b5-88eb-b145226a4224.png)

## 最後に
いかがでしたか？
生成AIを使うと、今まで時間がかかっていた作業が驚くほどあっという間に終わります。このスピード感とクオリティは、「未来のデザイン」そのものかもしれませんね。興味が湧いたら、ぜひ一度試してみてください！

それでは、また次回の記事でお会いしましょう。
立方を作る話

## 点と線から面を作り、立方を作る
ここまでに点と線（因子と水準）をテストし、面を作る（因子水準の意味のある塊）の、
話をしました。次は、立方を作る話です。

[[点と線、因子と水準の話]](https://qiita.com/EgaSaQA/items/56db9f23fa82ab1f4311)
[[面を作る話]](https://qiita.com/EgaSaQA/items/96c3c58be07d014abaea)

この層は、確実に MultipleCondition になります。

##
ここまでの話で、点と線→面との保証ができたところで、次は立方の話です。
立方でテストされるものの例としては、以下のものがあります。

面を因子とした水準
- 時系列
- ブラウザ特性（Webの場合）
- モバイル特性（モバイルアプリの場合）
- コンパチビリティ
- ユーザーストーリー
- 複雑な組み合わせテスト
などがあります。

ここでいうブラウザ特性とは、ブラウザでのテストならではのテストセットです。
具体的には、
- キャッシュ
- クッキー
- タブ
- ブックマーク
- セッション分け（シークレットブラウザ、種類の違うブラウザ）
- ブラウザバック、フォワード、クローズ、最大画面、最小画面、リフレッシュ
- SPAの非同期部分
などが考えられるでしょう。

また、モバイル特性としては
- アプリ非アクティブ
- アプリクローズ（複数パターン）
- 電源　ON/OFF
- ネットワーク ON/OFF
- 強制状態遷移
などなど、アプリの特性よって増減があります。

面と面をつなぐところで、複雑なパスがあるのをイメージしていただけますでしょうか。
![立方と.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/156898/d4403989-ed04-68fd-a1fb-79ea678c20e1.png)

## 
一方、最初からここだけを見るテストを、QAテストとしているチームも多くあります。
エンジニアが基本的なテストは実地しているので、最初から複雑なエッジケースや出やすい部分を
見るというものですね。その場合、探索テストのアプローチともいえるでしょう。
効率はいいのですが、テストの網羅性を説明できないので、
何をもって良しとするかは、説明できるようにしておきたいですね。
【kintoneカスタマイズ初心者】cybozu developer networkのチュートリアルの理解を深める（try/catch編）

# はじめに
ノベルワークスのつつみんです。12月に入社し、研修中です。初心者なのでカリキュラムとして、[cybozu developer networkのチュートリアル](https://cybozu.dev/ja/tutorials/)に取り組んでいます。
今回は、チュートリアルに取り組む中で、try/catchについて検証した結果をまとめていこうと思っています。
ここからどんどん深めていくのを目標にしています。
[Promiseとasync/awaitで非同期処理をしてみよう](https://cybozu.dev/ja/tutorials/hello-js/promise/)
[kintoneカスタマイズで非同期処理をしてみよう](https://cybozu.dev/ja/tutorials/hello-kinapi/async/)

 # try/catchについて検証してみた
### 準備
商品アプリ1と商品アプリ2を作成
取得した商品名を転記する文字列1行フィールド作成

## 2つ目の処理でエラーがでるようにする
### try/catchがある場合とtry/catchがない場合の比較

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3957410/270039d1-53c2-6d87-aecd-758e5e828dec.png)
## 結果
try/catchがある場合は、kintoneの画面に1つ目の処理の結果『商品1』が出力されている。
try/catchがない場合は、kintoneの画面に1つ目の処理の結果『商品1』が出力されていない。

# まとめ
try/catchがある場合は、2つ目の処理でエラーがでた場合、3つ目の処理をとばしreturn eventされるため、1つ目の処理はレコードに反映されています（商品1）。

try/catchがない場合は、2つ目の処理でエラーがでた場合、それ以降は実行されず、return eventされないため、レコードには成功している1つ目の処理も反映されていません。

try/catchがない（上記のコードの）場合は、エラーが発生した場合、そこで処理が止まってしまう点に注意が必要です。
try/catchがある（上記のコードの）場合は、エラーが起こった場合でもreturn eventしてしまうため、アプリを使用しているユーザーがエラーに気づかない可能性があります。

:::note info
実際のkintoneカスタマイズでは

catchの使い方として「なんかエラー出たから処理中断して、ユーザーに教えよう」っていうのが多いです。
```
try {
 ～
} catch(error) {
 event.error = "なんかエラー出たよ: " + error.message
 return event;
}
```
:::

# おわりに
実際に手を動かすことの大切さを痛感しました。ドキュメントを読んで理解はした気でいました。（アプリを作ったりするのが面倒だなと少し思ってしまっていました。）
でも、実際にアプリを作ってkintoneの画面上で確認することで、よりしっかり理解できたような気がします（もちろん、まだまだですが。）
教訓は、手を動かそう！！です。
次の課題に向けて頑張ります！
[CDGC] Microsoft Purviewのスキャン

<h1> はじめに

[インフォマティカ](https://www.informatica.com/ja/)が提供する、 [CDGC](https://www.informatica.com/ja/products/data-governance/cloud-data-governance-and-catalog.html)(データガバナンス＆カタログ)を使って、Microsoft Purviewからメタデータを取得(スキャン)するためのガイドです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/74d7d2f0-03e7-7eff-370a-53fbe0f1c315.png)

<h1>事前準備

CDGCがセットアップ済みであり、メタデータコマンドセンターのメニューにアクセスできるライセンス、およびユーザロール、ユーザである事を確認して下さい。こちらの[ナレッジベース](https://knowledge.informatica.com/s/article/FAQ-CDGC-apps-licenses-roles?language=ja)より手順をご確認下さい。

<h1>前提条件

Microsoft Purviewからメタ情報を抽出するため、下記の２点を確保する必要があります。
・Purviewへのアクセス権限とネットワーク通信を確保すること。
・データの読み出す権限があること。

<h1>スキャン設定

CDGCでソースシステムからからメタデータを抽出するには前提にあるようなソース毎の要件を満たしたユーザーで接続を作成する必要があります。

:::note warn
接続を作成する際に Secure Agent を指定する必要があります。もし、まだインストールされていない方はこちらの[ナレッジ]((https://knowledge.informatica.com/s/article/HOW-To-Install-a-secure-agent-on-a-Linux-machine?language=ja))を参考に Secure Agent をインストールしてください。
:::

メタデータコマンドセンターからスキャン設定を行います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/5b70324c-2ee3-4fa6-1f22-823c89ee8310.png)

新規ボタンより、新しいジョブを作ります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/39210369-dc4c-d7f5-b38a-45d2ea698924.png)

カタログソースからMicrosoft Purviewを選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/f1953f0f-79fc-221a-977e-d2aaef9829d6.png)


Purviewソースへの接続は通常に管理者画面で作成する方法と違い、直接メタデータコマンドセンターで接続を設定することとなります。

下図をご参照ください。Purviewの接続情報を記入して、「次へ」をクリック。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/42f65aaf-e70a-de5a-fdab-26200820cabf.png)


メタ情報を抽出する際の設定となります。
ランタイム環境は自社のSecure Agentを選びます。
メタデータ変更オプションでメタデータの変更を保持するか削除するかを選択します。
メタデータの抽出範囲に対してフィルターかけることが可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/c8680733-4723-e99d-c17b-36b43452769b.png)

Step３の関係者とStep４のスケジュール設定がなければ、そのままで大丈夫です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/cd0533a4-6850-9c06-8112-29585485b16d.png)

設定の保存して、実行します。実行が完了しますと、データガバナンスとカタログの画面にて、Purviewのメタデータを確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986164/7ac7559e-28d0-1a6b-f4de-aa14d2abdeed.png)

<h1>まとめ

Informaticaのカタログ製品は他のカタログ製品のメタ情報を管理することができるため、カタログのカタログだと言われています。
また、Informaticaカタログの他の機能について興味がございましたら、コメントをお願いします。
【kintoneカスタマイズ初心者】cybozu developer networkのチュートリアルの理解を深める（分割代入編）

# はじめに
ノベルワークスのつつみんです。12月に入社し、研修中です。初心者なのでカリキュラムとして、[cybozu developer networkのチュートリアル](https://cybozu.dev/ja/tutorials/)に取り組んでいます。
今回は、チュートリアルに取り組む中でサンプルコードの中に出てきた分割代入について備忘録として残しておこうと思います。
# 分割代入とは
分割代入（Destructuring Assignment）とは、JavaScriptの構文の1つで、配列やオブジェクトの要素を簡単に取り出して変数に割り当てる方法です。

今回勉強したチュートリアル、はじめようkintoneプラグインのサンプルコードでは、プラグインの設定画面で保存された config オブジェクトから、sourceFieldValue、targetFieldValue、spaceFieldID の値を取り出して利用していました。
```JavaScript
const {sourceFieldValue, targetFieldValue, spaceFieldID} = config;
```
どんな時に使うと便利なのか、他にどんな使い方があるのかについてまとめてみたいと思います！

## 分割代入の例
### オブジェクトから特定のプロパティを取り出す
```JavaScript
//定義
const person = {
  name: "Taro",
  age: 30,
  job: "Engineer"
};
// // 分割代入を使用して特定のプロパティを取り出す
const { name, age } = person;

console.log(name); // "Taro"
console.log(age);  // 30

```
・person というオブジェクトから name と age プロパティを取り出し、それぞれ同名の変数に代入
・元のオブジェクト（person）はそのまま保持

:::note info
こんなときに使うと便利
大量のデータが含まれるオブジェクトから特定の値を取得する場合
:::
:::note info
メリット
必要なデータだけを取り出せる。
オブジェクトのプロパティ名をそのまま変数として使用できる。
:::

### 関数の戻り値を効率的に扱う
```JavaScript
function getUser() {
  return { id: 1, name: 'Taro', age: 30 };
}

// 戻り値を分割代入で取得
const { name, age } = getUser();
console.log(name); // 'Taro'
console.log(age);  // 30
```
:::note info
こんなときに使うと便利
関数がオブジェクトや配列を返す場合
:::
:::note info
メリット
不要なプロパティを無視しながら、必要な情報だけを取り出せる。
:::

# まとめ
分割代入は、オブジェクトや配列の要素を簡単に変数に割り当てる方法。
コードを短く、読みやすくするために便利です（必要に応じて別名も指定できます）。

:::note info
比べてみる

最初に紹介した、今回のチュートリアル（はじめようkintoneプラグイン）のサンプルコード（分割代入）の場合
```JavaScript
const {sourceFieldValue, targetFieldValue, spaceFieldID} = config;
```
分割代入を使わなかった場合
```JavaScript
const sourceFieldValue = config.sourceFieldValue;
const targetFieldValue = config.targetFieldValue;
const spaceFieldID = config.spaceFieldID;
```
サンプルコードの方が短く、分かりやすい。
必要なデータのみ取り出せる。

:::

# おわりに
とっても初心者の内容ですが...分割代入について知らなかったのでまとめてみました（配列の分割代入についても勉強しました）。知らなかったら、一つずつ変数に代入してたと思うのでここで知れて良かったです。スクールとかに通って勉強してない人ってこういうことは、どうやって学んでいるのだろう･･･。
分割代入を使って、効率よく、読みやすいコードを書きたいなと思っています。
AI駆動開発時代におけるCI/CDやインフラについて

# AI駆動開発時代におけるCI/CDやインフラについて

※本記事はまだ記述中です。後日更新予定です。

本エントリは[クリエーションラインアドベントカレンダー](https://qiita.com/advent-calendar/2024/creationline) 11日目の記事です。

世間と同様にクリエーションライン社内でも生成AIを利用したAI駆動開発について話題が尽きず、[bolt.new](https://www.creationline.com/tech-blog/chatgpt-ai/ai/75677)の登場によって、今後の開発について更により活発な議論が繰り広げられています。
私は元々Kubernetesなどを中心したインフラエンジニアであることもあり、CI/CDやインフラ目線でAI駆動開発について考えてみたいと思います。

bolt.newのような生成AIによる開発は現在のところプロトタイプ開発やPOCなどで主に使用されるでしょう。
これはAIによる生成物がまだプロダクションの品質ではないということもありますが、
顧客と会話しながら要望がすぐに反映されて動くものが見えるということがプロトタイプ開発にマッチしているからだと思います。要望を追加したり、意見を変えても文句ひとつ言わず対応してくれますしね。(Token量で追加課金が必要ですが)

ただ、近い将来AIの品質も向上するし、品質よりもリリース速度をより優先するプロダクトが出てくる可能性もあります。例えば、開発者が品質を考慮して作成した場合30日かかるとします。AIで生成すると1日で作成できます。※AIで作成した場合も最低限のテストは実施している想定。

早くリリースできるということはその分だけユーザのフィードバックやサービスそのものへの改修に時間をあてることができます。30倍の速度でリリースができるので、同じ時間で30のサービスをリリースするようなゲームチェンジャーも現れるかもしれません。もちろんプロジェクトの種類や業界によって求められる品質は異なりますが、そのような可能性があるということになります。

サービスの企画側や提供者は開発者ほどコードの品質を気にしてなく、中身がブラックボックスであっても機能テストが通っていれば問題ないと考える人も多いかと思います。開発者は品質の重要性を訴えていくのが、仕事になるかもしれません。

話を一旦戻しまして、CI/CDについて一度おさらいしたいと思います。CI/CDとは「Continuous Integration（継続的インテグレーション）/ Continuous Delivery（継続的デリバリー）」の略称です。
- 開発チームの各環境でのビルド、テスト、およびデプロイメントを統合的に管理し、自動化を行うことにより開発チームの負荷を増やすことなく迅速かつ頻繁にリリースを継続できる環境を提供します。
- 自動テストやセキュリティチェックもパイプラインの中で実行することができ品質の向上やセキュリティ強化なども図れます。

## 1. AIによる継続的開発
AIが生成したコード(およびそれを元にしたアプリケーション)に対し、フィードバックを行いコードの修正を行うを繰り返すことは
CI/CDをより高速に回すことにも似ています。
ただし、生成AIによる変更は改善が必要な個所の修正のみではなく全体を大きく変更してしまう可能性があります。
変更前のソースをバックアップしておく必要があると有識者の方も仰っています。
また、生成AIによってどのような変更が行われたのかについても生成AI側のみで履歴として残っており、開発者が統合的に履歴を追うことができません。
直接開発者がコードの修正を行うこともあるが、開発者が行った更新とAIが変更した更新が明確にわかる必要があります。

少し脱線しますが、copilotなどを使用してコードの一部を生成AIで作成してもらう、つまり補足的な使い方の場合、
コードをコミット/マージした人がコードに責任があるべきではという議論があるようです。
少量のコードであれば可能であるが、難しい議論だと思います。

話を戻すとCI/CDツールのコード管理として以下の機能が求められると思われます・
- AIによる修正、変更を管理し、巻き戻しにも対応できること
- 変更内容、つまりAIに対して入力したプロンプトも管理できること
- AIによる修正なのか、メンバーによる修正なのかを分類できること
- AIによる大量の変更に対応できること (履歴やログの増加)

## 2. 品質の向上
現在の生成AIにおいてもテストコードの追加を要望すれば...


## 3. デプロイ

## 4. インフラストラクチャー
ゼロから始める受託開発 - 思わぬ失敗の連続談

本記事は、Lancers（ランサーズ） Advent Calendar 2024 の11日目の記事です。

# はじめに
はじめまして、ランサーズ株式会社の山口と申します。
今年からランサーズにジョインし、現在はシステムインテグレーション事業に携わっています。
前職では、プロジェクトマネージャーやディレクターとして、小規模な受託開発案件に従事していました。
また、受託開発事業の立ち上げにも関わり、それに付随する様々な職務や管理職としてのマネージャーも経験しました。
本記事では、その際に経験した失敗談を、ほんの少しのユーモアを交えながら共有させていただきます。

内容を見ると「そんなの当たり前じゃん！」と思われるかもしれませんが、実際にはそれを実践することの難しさに、何度も頭を抱えた経験があります。

# どんなことをしていたのか
営業、売上管理、部下の育成、プロジェクトのマネージャーやディレクター、時にはデザイナーやエンジニアとしても様々な職務に奮闘していました。
一見、多才に見えるかもしれませんが、実際には全てを中途半端にこなすだけで、自分自身が大変な状況に陥ってしまったのです。

# 失敗事例
プロジェクトの失敗や受託開発での見通しの甘さなど、数多くの失敗がありましたが、今回はその中でも特に印象的なものをいくつか紹介させていただきます。

 - 開発ってどうやればいいの？ - 手探りでの苦闘
 - 前回、こんな話でしたよね？ - 要件のすれ違い
 - 仕事がない！ - 順調からの急転直下
 - 育成ってどうやってやればいいの？ - 育成方法の模索
 - 手がいっぱいで回らない... - マルチタスクの弊害

## 開発ってどうやればいいの？ - 手探りでの苦闘
このタイトルを見て、「何を言っているんだ？」と思われるかもしれません。
これまでは、企業のベンダーとしてIT担当の方とコミュニケーションを取りながら開発業務を行ってきました。
しかし、非IT企業の方とのプロジェクトでは、今までのやり方が全く通用しないことに気づかされました。
プロジェクトの進め方から説明しなければならず、「どうすればいいんだ！」と頭を抱える日々が続きました。

### 対処法 - コミュニケーションを密に
クライアントとのコミュニケーションを密に取り、非IT企業の方にもわかりやすく説明することを心がけました。
言葉やテキストだけでは伝わりづらい場合は、図などを用いて視覚的に表現するなど、とにかく両社の認識のずれを解消するまで話し合いを重ねました。この地道な努力が、問題解決への鍵となりました。

## 前回、こんな話でしたよね？ - 要件のすれ違い
クライアントとの打ち合わせでは、要件を詰めることが重要です。
しかし、決まったはずの内容が食い違っていることがあり、かなりの手戻りが発生することが多々ありました。 
「前回、この仕様で確定したと思うのですが…」、「いや、違う。こう言ったよ。」などの認識の齟齬が発生し、仕様が大きく変わることもしばしば。結局、頭を抱える状態に陥ってしまうのです。

### 対処法 - 録音と議事録の徹底
打ち合わせ内容は全て録音し、議事録とともに共有することを徹底しました。
当たり前のことですが、これまでは適切に実践できていなかったがために起きた問題だと反省しました。
録音と議事録の共有を習慣化することで、仕様のすれ違いを未然に防ぐことができるようになりました。

## 仕事がない！ - 順調からの急転直下
受託開発を始めた当初は、次々と仕事が決まり、「余裕だな！」と思っていました。
しかし、その後突然仕事がなくなってしまい、当初の計画では上手くいかず、再び頭を抱えることになってしまいました。 
仕事がないためにメンバーを手放すことになり、そのせいで新たな案件が受けられないという負のスパイラルに陥ってしまったのです。

### 対処法 - 丁寧な対応と提案書の質向上
この状況に対する特効薬はありませんでしたが、どんなお客様に対しても丁寧に対応するよう心がけました。一見、相見積もりだけが目的と思われる案件にも真摯に向き合い、提案書の質を上げるなどの工夫を重ねました。こうした地道な努力を続けることで、徐々に仕事を受注できるようになっていったのです。

## 育成ってどうやってやればいいの？ - 育成方法の模索
新規事業のため、若手のエンジニアが大半を占め、彼らの育成も同時に行わなければなりませんでした。 
開発面では何とかこなせましたが、PMやPLとしてどのように業務を進めるべきか、手探りの状態が続きました。 
私自身、「見て覚えろ！」という環境で育ってきたため、部下に教えられることは少なく、同じような状況を繰り返してはいけないと思いつつも、具体的な改善策が見いだせずにいました。

### 対処法 - 試行錯誤の連続
この点については、最も反省しています。
1on1などは実施していましたが、どのように進めれば良いのかわからず、十分な効果を得られませんでした。 
タスクを任せて自主的にやらせるべきだったのか、失敗した際には自分が手助けせずに対処させるべきだったのか、
あるいは、1から10まで手順を詳細に説明すべきだったのか。
様々な方法を試してみましたが、最善の育成方法を見出すことはできませんでした。

## 手がいっぱいで回らない... - マルチタスクの弊害
冒頭でも少し触れたように、営業、売上管理、部下の育成、プロジェクトのマネージャーやディレクター、時にはデザイナーやエンジニアとして、あらゆる役割をこなしていました。 
そのため、手が回らずに部下のモチベーションや育成、コミュニケーションをおろそかにしてしまったのではないかと反省しています。

### 対処法 - 役割分担の重要性
業務が忙しすぎて問題を解決できていなかったのは、自分一人で全てをこなそうとしていたことが原因だと気づきました。 
そこで、少しずつではありますが、役割を分担するようにしていきました。 
自分で全てをこなすのではなく、他の仲間に頼ったり、社内でできない場合は、社外の方に協力を仰いだりと、様々な方法を試みました。 
チームメンバーに適切に業務を任せることで、自身とメンバーに余裕を持たせるマネジメントが最も重要だと実感しました。

## まとめ
本記事の内容の多くは、「そんなの当たり前じゃん！」と思われるかもしれません。
しかし、実際にはそれを実践することの難しさを痛感する機会が多くありました。 
失敗から学び、次に生かすことが何よりも重要だと考えています。
私の経験が、同じような状況に直面している方の参考になれば幸いです。 
最後までお付き合いいただき、ありがとうございました。

Lancers では、一緒に働けるメンバーを募集しています！
https://recruit.jobcan.jp/lancers01/list/all/all
State of AI Report 2024:  2025年の予想

## AI予測： 未来への展望と課題

AI技術は驚異的なスピードで進化を続け、社会の様々な分野に大きな影響を及ぼしています。ソースでは、AIの将来予測に関する多岐にわたる洞察が提示されており、今後の発展と課題について示唆を与えています。

### 1.  研究分野における予測

ソースでは、AI研究分野において、今後12ヶ月で起こると予測される事柄が以下のように述べられています。

* **OpenAI o1を超えるオープンソースモデルの出現**: 推論ベンチマークにおいて、OpenAI o1を凌駕するオープンソースのAIモデルが出現すると予測されています。 これは、オープンソースコミュニティの活発な活動と、AI技術の民主化が進むことを示唆しています。
* **AI Scientistによる論文発表**: AI Scientistによって生成された研究論文が、主要な機械学習学会またはワークショップで受け入れられると予測されています。 AIが研究プロセス自体を自動化する可能性を示しており、AI研究の新たな時代を予示する出来事となるでしょう。

### 2.  産業分野における予測

* **ノーコードアプリの普及**: コーディング経験のないユーザーが作成したアプリやウェブサイトが、口コミで広がり、App Storeのトップ100にランクインする可能性が予測されています。 これは、AIツールがより使いやすく、誰でも高度なアプリケーションを開発できるようになることを示唆しています。
* **AI搭載検索エンジンの進化**: AIを搭載した検索エンジンが、より洗練された機能を提供し、ユーザーエクスペリエンスを向上させると予測されています。 OpenAIは、ChatGPTに統合される予定の検索機能「SearchGPT」のプロトタイプを試験しており、Perplexityのようなユーザーインターフェースが示唆されています。
* **音声認識技術の商業化**: 音声認識技術の精度向上により、カスタマーサポートやコールセンターなど、様々な分野での実用化が進むと予測されています。 Assembly AIやDeepgramなどのスタートアップ企業は、大規模な音声データセットとTransformerモデルを活用し、従来の自動化システムでは困難であった、自然な音声の認識や処理を実現しています。
* **AI創薬の進展**: 個別化された「ネオアンチゲン」療法（INT）の開発と実用化が進むと予測されています。 INTは、がん細胞によって生成されるがん特異的な変異である「ネオアンチゲン」をコードするmRNAで構成され、患者の免疫系を活性化してがん細胞を排除します。
* **AIファースト製品の成長**: AIファースト製品が企業内で定着し、ユーザーエンゲージメントと収益の増加が期待されています。 AI企業の収益成長は、従来のSaaS企業を大きく上回っており、AI技術のビジネスへの浸透が加速していることが分かります。
* **デバイス上AIの進展**: Appleのデバイス上AI研究の成果により、パーソナルデバイス上でのAI処理が加速すると予測されています。 Appleは、高性能かつ小型のオープンモデルをリリースしており、デバイス上での推論処理に重点を置いています。

### 3.  政治・規制分野における予測

* **国家安全保障審査の対象となるAI投資**: 外国政府による米国の大規模AI研究所への100億ドル以上の投資が、国家安全保障審査の対象となると予測されています。 AI技術の国家安全保障上の重要性が高まる中、外国政府からの投資に対する規制が強化される可能性を示しています。
* **EU AI法の緩和**: EU AI法の初期段階における実施は、当初の予想よりも緩和されると予測されています。 法律制定者が規制の過剰介入を懸念し、AI技術のイノベーションを阻害しないよう、柔軟な運用が求められると考えられます。
* **データ収集に関する訴訟の影響**: 生成AIにおける著作権問題をめぐる訴訟が本格化するにつれ、フロンティアラボはデータ収集方法を見直す必要に迫られると予測されています。 OpenAIやGoogleは、主要メディアとライセンス契約の交渉を進めていますが、MetaやPerplexityは「フェアユース」の主張を維持しており、著作権問題の解決にはまだ時間がかかりそうです。

### 4.  安全性分野における予測

* **NVIDIAの市場支配**: AIチップ市場において、NVIDIAの優位性は揺るぎないものと予測されています。 NVIDIAは、高性能なGPUと成熟したソフトウェアエコシステムにより、AIチップ市場で圧倒的なシェアを占めています。
* **ヒューマノイドへの投資の減少**: 製品市場適合を実現するのが困難であるため、ヒューマノイドへの投資は減少すると予測されています。 非ヒューマノイド型のロボットスタートアップ企業への投資意欲は依然として高い一方、ヒューマノイド型ロボットはコストの高さや技術的な課題から、実用化に苦戦する可能性があります。

### 5.  AI予測に伴う課題

AIの将来予測は、楽観的なものばかりではありません。ソースでは、以下の課題についても指摘されています。

* **AIの悪用**: AI技術は、偽情報やバイオテロリズムなどの悪用にも利用される可能性があり、対策が急務となっています。
* **倫理的な問題**: AIの利用に伴う倫理的な問題、例えば、AIによる差別やプライバシー侵害、雇用への影響などは、社会全体で議論を深めていく必要があります。
* **安全性確保**: 高度なAIシステムの安全性確保は、AI技術の健全な発展と利用のために不可欠です。安全性評価の標準化、悪用防止技術の開発、国際的な協力体制の強化などが求められます。

### 結論

AI予測は、AI技術の将来像を描き、その可能性と課題を明らかにする上で重要です。AIは、社会に大きな変革をもたらす可能性を秘めていますが、同時に様々なリスクや課題も抱えています。AI技術の恩恵を最大限に享受し、そのリスクを最小限に抑えるためには、AI開発者、研究者、政策立案者、そして社会全体が協力し、AIの未来について議論を深めていく必要があります。