OmniAICreator/Qiita-1.07M huggingface dataset:
「通話かけてもいいですか？」って聞かなくてOK

:::note info
リモートワークにおいて、暗黙のルールのように「通話かけてもいいですか？」と聞くのをやめることでコミュニケーション効率が上がるんじゃないかという話です。
:::

# TL; DR

- **目的:** 状況に合わせて、テキスト/音声を適切に使い分けたい
- **問題:** 「通話かけてもいいですか？」って聞かないといけないことが無意識下レベルで心理的障壁となり、音声コミュニケーションが適しているケースでもテキストが使われてしまうことがある
- **解決案:** 毎回「通話かけてもいいですか？」って聞かなくていいのでは？

# 状況に合わせて適切なコミュニケーション方法を選択したい

業務中、他のメンバーと連絡を取る際、**チャットで行ったほうが良いケースと、口頭で行ったほうが良いケースがある**かと思います。

例えば、テキスト数行で終わるようなやりとりは、わざわざ通話で相手の作業の手を止める必要はないと思いますが、長文のチャットで何十件にもレスが連なるほど議論が盛り上がっているなら、一回口頭で話してしまったほうが効率が良かったりすると思います。

もしかしたら、人によってはテキストで全てを済ませたい人も居るかとは思いますが、 **この記事では、状況に応じてどちらにもメリットがある前提**です。

# 「通話かけてもいいですか？」と聞くことで起きる問題

周りに、事前に通話の承認をチャットで求めてからコールしてくる人と、いきなりコールしてくる人がおり、傍から見る限り前者のメンバーは、通話という手段を取ることに若干の抵抗を持っている印象が見て取れる場合が多いように思います。

なぜ事前承認を行うことが通話への抵抗につながるのか考えてみました。

## 1. 「通話」という状態を実現するまでのステップが増える

**承認無し:**
||誰が|内容|
|---|---|---|
|1|自分|`通話をかける`|
|2|相手|`受話`|

**承認有り:**
||誰が|内容|
|---|---|---|
|1|自分|`許可を求める`|
|2|相手|`許可する`|
|3|自分|`通話をかける`|
|4|相手|`受話`|

この**目先のちょっとした面倒くささが増えるだけで、非効率な行動を選択してしまう**人は意外と多いと思っています。

相手のステップまで増えるという点も、両者にとって地味な負担になりそうです。

例えば、弊社はフルリモートのため、交通費は月の定額支給ではなく、出社した場合のみ申請ベースで支給されます。

申請といってもシステムで3分ポチポチすれば終わる作業ですので、3分で500円の交通費が返ってくるなら、普通に申請したほうがお得です。

しかし、この3分の作業を面倒くさがって、自腹を選択する人は少なくないように思います。

同じように、通話許可の面倒くささを回避しようとして、**本来口頭のほうが効率の良いやりとりであっても**、（無意識下で）**チャットで済ませようとしてしまう**恐れがあります。

## 2. 「チャットは気軽／通話はヘビー」という差が生じる

オフィスの場合でイメージして、隣の人に「具合悪いので帰ります」と一言声をかけるのは別に重たいコミュニケーションではないように、**「口頭」そのものが特別重たいコミュニケーション手段というわけではない**と思います。

しかし、「〇〇さん、話したいことがあるのでお時間いいですか？」のように、事前に承認を求めた途端、大事な話または時間がかかる話がこれから始まるような空気になります。

もし、リモートになった途端に内容問わず常に承認を求めるようにしてしまうと、
話しかける側は、「*これは承認を求めるほどに見合わない内容なんじゃないか？*」「*通話は大げさと思われるんじゃないか？*」と（無意識下レベルで）感じて、**軽い話題で通話することに不要な遠慮をしてしまう**恐れがあります。

# 毎回「通話かけてもいいですか？」って聞かなくてもいいのでは？

ここで表題です。

**気軽にコールし**、受け取る側も出られない（または出たくない）状況なら**気軽に拒否するような文化**にすることで、テキスト・音声をよりフラットに使い分けられるようにしましょう。

## 同期的な働き方になってしまいリモートワークの強みが薄れるのでは？

常に通話に応答できるようにしていないと咎められる（あるいはそれに近い空気になる）、
通話中はカメラをONにしなければいけない、
といったような風潮を作ってしまうと、その通りだと思います。

:::note info
**出ない（出たくない）という選択も気軽に**取れる状況を維持しましょう。
:::

## 突然通話をかけると相手の作業の邪魔になってが迷惑なのでは？

オフィスに置き換えた場合、重要な会議の最中に突然別の人が話しかけて迷惑になるようなケースはあまりないかと思います。

これは、会議中の人はそもそも席におらず会議室に居るなど、会議中であることが一目瞭然なので起きないものと思います。

:::note info
リモートワークの最中でも同じように、**声をかけられたくない状況であることが傍から見て分かる状態に**すれば、**話しかけてほしくない場合に話しかけられない状態を維持**することができると思います。
:::

例えば、GカレとSlackを導入しているなら、連携させることで会議の時間中に自動でSlackのステータスをセットしてくれるようにできます。

もしくはその逆で、「話せない状況」を示すのではなく、「話せる状況」を示す運用も可能と思います。

弊社チームでの運用例を別記事に切り出してみましたので、もしよろしければこちらもご覧ください。
『[Discordを疑似オフィスっぽく運用する](https://qiita.com/laineus/items/66999a15a3adf0ce9eb7)』
別Viewを表示するModifier(sheet, alertなど)の位置は大切(SwiftUIの癖)

## 問題

メニューの中にisPresentedを切り替えて、Text("Next View")をsheet表示させるボタンがあります。

以下のコードで動くでしょうか？

```swift
struct ContentView: View {
  @State var isPresented = false
  
  var body: some View {
    Menu {
      Button {
        isPresented.toggle()
      } label: {
        Text("Button")
      }
      .sheet(isPresented: $isPresented) {
        Text("Next View")
      }

    } label: {
      Text("Menu")
    }
  }
}
```


## 解答: なんと動きません!

動かない原因は、`.sheet`(View Modifier)の位置です。
Menu内のButtonはクリックされた瞬間に消えてしまいます。
そのため`.sheet`(View Modifier)も消えてしまうのです。

## 解決方法(Tips)


:::note info
Buttonでsheet表示させたい時はButtonの一段階上にさせよう
:::


```swift
struct ContentView: View {
  @State var isPresented = false
  
  var body: some View {
    Menu {
      Button {
        isPresented.toggle()
      } label: {
        Text("Button")
      }
    } label: {
      Text("Menu")
    }
    .sheet(isPresented: $isPresented) {
      Text("Next View")
    }
  }
}
```



## alertやfullScreenCoverも同様

```swift
struct ContentView: View {
  @State var isPresented = false
  
  var body: some View {
    Menu {
      Button {
        isPresented.toggle()
      } label: {
        Text("Button")
      }
      .alert("Alert", isPresented: $isPresented) {
        Button("Close") {}
      }
    } label: {
      Text("Menu")
    }
  }
}
```

## おまけ(PhotosPicker)

このコードも一見動きそうですが、動きません。

```swift
import PhotosUI

struct ContentView: View {
  @State var photoItem: PhotosPickerItem?
  
  var body: some View {
    Menu {
      PhotosPicker("Photo", selection: $photoItem)
    } label: {
      Text("Menu")
    }
  }
}
```

これは動きます。

```swift
struct ContentView: View {
  @State var isPresented = false
  @State var photoItem: PhotosPickerItem?
  
  var body: some View {
    Menu {
      Button("Photo") { isPresented.toggle() }
    } label: {
      Text("Menu")
    }
    .photosPicker(isPresented: $isPresented, selection: $photoItem)
  }
}
```

これからわかるPhotosPickerの実装

こういった実装のためMenu内では動作しないことがわかる

```swift
struct PhotosPicker: View {
  @State var isPresented: Bool = false
  @Binding var photoItem: PhotosPickerItem?
  
  var body: some View {
    Button("Photo") {
      isPresented.toggle()
    }
    .photosPicker(isPresented: $isPresented, selection: $photoItem)
  }
}
```
Discordを疑似オフィスっぽく運用する

みなさま、リモートワークでの業務は快適に進められているでしょうか？

チームの働き方次第で、完全に非同期的に動いているチームもあれば、リモートワーク下であってもオフィスでの仕事と同じように気軽に人に話しかけられる環境を作りたいチームもあるかと思います。

近年では、まんまオフィスをアプリケーション化したようなサービスもちらほら登場していますね。

![Screenshot from 2022-12-08 23-04-26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/151137/5dc6f957-1487-e353-538f-78868d31b1db.png)
Gather: [https://www.gather.town/](https://www.gather.town/)

そういったサービスも面白いと思いますが、視覚的な雰囲気作りまで求めなければ、
Discordでもオフィスと同じようなコミュニケーションフローを実現することが可能です。

![Screenshot from 2022-12-07 13-00-39_plane.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/151137/789edaf8-12da-65e6-8a73-d49ad99c3c5b.png)

# Get Started

## 1. 自分専用のチャンネル＝席を作ろう

:::note info
自分の名前のボイスチャンネルを作って、通話OKの間は1人で常駐しておきます。
:::

![Screenshot from 2022-12-07 13-00-39_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/151137/a5d4e51c-62e2-039f-226a-283d1b1bb13c.png)

## 2. 話しかけたい相手の席に移動して声をかけよう

オフィスで、相手の席まで歩いて話しかけに行くのと同じ感覚です。

![Screenshot from 2022-12-07 13-00-39_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/151137/efaee3b3-1f0d-10e8-3a59-5a314bf004a9.png)

## 3. スピーカーはON、マイクはミュートにしておこう

業務中とは言え、自宅で働くわけなので、プライバシーを担保する必要があります。

:::note info
スピーカーはON、マイクはミュートにしておけば、話しかけられれば相手の声は聞こえるけど、自分側の音声はミュート解除するまで聞こえない、という状態にできます。
:::

安心して鼻歌を歌いながら作業してください。

![Screenshot from 2022-12-07 13-00-39_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/151137/5968c8d1-00f2-6694-ac9f-f7148d4126ce.png)

## 4. 離席や集中時など話しかけられたくない場合は退出しよう

稼働中、常に席に待機している必要はないと思います。

オフィスでも、自販機に行ったり、集中スペースで作業に没頭するために席を外すことがあるはずです。

![Screenshot from 2022-12-07 13-00-39_4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/151137/765420e3-3d50-053b-1efb-2630884c5fa2.png)

# おわり

皆さんのチームにも何かコミュニケーションノウハウがあれば、ぜひ記事にしてください！

よければこちらも: 『[「通話かけてもいいですか？」って聞かなくてOK](https://qiita.com/laineus/items/74636c33cc4ce549e207)』
Rubyのインストール方法いろいろ

Rubyのインストール方法は色々あるので、思いつくものを列挙していきたいと思います。

## インストール方法いろいろ

どの環境でもソースからのインストールがありますが、それは省略します。

### Windows

Windows なら RubyInstaller とか各種パッケージマネージャを使うのでしょうか。Windows 環境を使っていないので詳しいことはわかりません。RailsInstaller というのはちょっとみてみた感じだと最近は更新されていないようです。

### macOS

- OS にまだ `/usr/bin/ruby` が入っているかもしれませんが、将来(OSの他のプログラムからの依存がなくなったら?)削除される予定なので、普通は依存しない方が良いでしょう。

### macOS や Linux 共通

- `rbenv` と `ruby-build` : 普段はこれを使っています。Rubyコミッターでも使っている人が多いし、メンテナンスに関わっているコミッターもいるので、準公式のようなものかもしれません。
- `RVM` : `Bundler` がなかった頃、 `RubyGems` の環境を分離するために使っていたことがあります。シェルの環境の書き換えの癖が強いようで、カスタマイズしているものを壊されて使いにくかったので使わなくなりました。バージョンによってはいくつか独自パッチをあてていることがあるようなので、同じRubyのバージョンでも、他のインストール方法と挙動が違うことがあるかもしれません。
- `chruby` : 使ったことがないので評価できないのですが、インストール方法は `ruby-build` などを使うようなので、標準的なRubyを使えるようです。

### パッケージマネージャ

- `Homebrew` : 基本的には最新安定版が入ります。 `ruby@3.0` などで古いバージョンもインストールできます。使っていないので評価できないのですが、パッケージを `brew upgrade` にまとめたいときに便利そうです。
- `apt` など : それぞれの OS のパッケージマネージャにまかせると、他のパッケージと一緒に更新できて楽そうです。基本的に OS のリリース時のバージョンで固定されて、古いバージョンに固定されることになりがちなので、それが気にならない用途に向いています。バッチ処理用の小さいプログラムなどに使っています。
- `snap` : Ubuntu などで `sudo snap install ruby --classic` でインストールできる `ruby` です。<https://github.com/ruby/snap.ruby> で開発されていて、これも準公式のようなものです。環境が分離されていて、自動更新されるのは利点ですが、環境が分離されているので、たとえばDebian上だと`libc`のバージョン違いの問題で、拡張ライブラリを使うgemが使えないことがあります。

### Dockerイメージ

- <https://hub.docker.com/_/ruby> : Docker コミュニティの公式イメージ。Docker に詳しい人達がメンテナンスしているはずなので、環境変数などの設定は Docker に便利なようになっていて、Ruby の標準的なインストールとは違うものがあるようです。
- <https://hub.docker.com/r/rubylang/ruby> : Rubyコミッターが作成しているイメージ。Ruby の標準的なインストールに近いので、そういうRubyが使いたいとか、動作確認したい、という用途に向いています。

### 特殊用途のDockerイメージ

- <https://hub.docker.com/r/rubylang/all-ruby> : 全てのリリースバージョンで動作確認したいという用途に使います。詳しいことは[rubylang/all-ruby で ruby の全リリースの挙動を確かめる](https://qiita.com/znz/items/a2e47adc949af6f495ac)などを参照してください。
- <https://hub.docker.com/r/rubylang/rubyfarm> : `git bisect` のような用途に使うためのイメージです。使い方は必要な人にはわかる(か調べればわかる)はずなので、詳細は省略します。

### その他

- まだ安定版が正式リリースされたRubyではないのですが、[ruby.wasm](https://github.com/ruby/ruby.wasm)を使ってインストールせずに使うという用途も少しずつ出てきています。

## まとめ

色々なインストール方法とその概要を紹介しました。
基本的には個人の感想なので、参考にして、自分に向いた方法を使ってみてください。
Serverless Framework pluginのデバッグ

Serverless Framworkのplugin内で発生したエラーの原因を調べるための手順をまとめます。
試したことはないですが、pluginを開発したい人向けにも使えると思います。
ググってもヒットしなかったので、参考になれば幸いです。

以下、serverless-laysers pluginを例に記載します。

# 環境
- VSCode
- TypeScript: 4.8.4
- Serverless Framework: 3.24.1
- nodejs: 16.17.0

# 手順

1. 既存のpluginはインストールされていても良いとは思うが、デバッグ対象をはっきりさせるために削除。
   `npm uninstall serverless-layers -D`
1. serverless pluginのソースコードをプロジェクト内にgit clone。
   ```sh
    mkdir test
    cd test
    git clone https://github.com/agutoli/serverless-layers.git
   ```
1. pluginのソースコードをserverelss.yamlやserverelss.tsからの相対パスで指定。
   ```typescript:serverelss.ts
   plugins: [
       ...,
       './test/serverless-layers',
       ...
   ]
   ```
1. pluginsのソースコードのpackage.jsonを編集。(lib/index.js -> src/index.js)
   ```:test/serverless-layers/package.json
   "main": "src/index.js",
   ```
1. プロジェクトのDebug Configurationを追加。
   ```:.vscode/launch.json
        {
            "name": "debug serverless plugin",
            "type": "node",
            "request": "launch",
            "runtimeArgs": [
                "--inspect"
            ],
            "program": "${workspaceFolder}/node_modules/serverless/bin/serverless",
            "args": [
                "deploy"
            ],
            "console": "integratedTerminal"
        },
   ```
1. ブレークポイントを設定し、デバッグ実行。
　　　　　![スクリーンショット 2022-12-12 9.34.34.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/556119/7f473f27-918e-15be-56cf-b9580ac131ee.png)

※結局、serverless-layersの不具合ではありませんでした！

以上です。
インシデント対応フローを整備しよう

本記事は SRE Advent Calendar 2022 12日目のエントリーです:christmas_tree::santa::gift:

インシデント対応、皆さんはどのように行っていますか？
弊社ではインシデント対応の流れとして、大きく分けて3つの対応を行うようにしています。

1. まず **Severity Levels(SEVレベル)** を判定する
1. SEVレベルに応じた **エスカレーションフロー** に沿ってステークホルダーに情報連携しつつ、インシデント対応を行う
1. 対応完了後、 **ポストモーテム** を書く

それぞれの要点を以下にまとめてみます。

## 1.Severity Levels
- Severity Levelsとは？
  - インシデントの重大度を表すレベル
  - 影響の大きさをレベル別に言語化したもので 「SEV」によるレベル定義を使用して重大度を分類する
  - レベル定義は数値が低いほどより重大な問題として扱う
- Severity Levelsを定義する目的
  - 発生中のインシデントの重大度を明確にする
      - 予め定義しておくことでSEV判定に時間を使わず、サービス復旧に多くの時間を割けるようにする
- 運用
  - インシデント発生時、まず第一にSEV判定を行う
  - SEV判定に迷う場合は上位の重大度として扱って対応を進める
    - SEV-2以上はすべて「重大インシデント」とみなし、他の業務より優先的に対応する

##### 参考

https://response.pagerduty.com/before/severity_levels/

https://www.atlassian.com/ja/incident-management/kpis/severity-levels


## 2.エスカレーションフロー
- エスカレーションフローとは？
    - インシデント発生時に想定されるエスカレーション先/対応フローをSEVレベル別に定めたもの
- エスカレーションフローを定義する目的
  - インシデント発生時、情報連携先に迷わないで済むようエスカレーションフローを各チームで事前に整備し、有事の際にスムーズに情報連携できるようにする
    - SEVレベル別に「誰に報告するか?」「まずはじめに何をするか?」「チームでどのように役割分担して動くか?」等が分かるようにする
    - ドキュメントに基づいてチームメンバーが同じ判断基準で迅速な行動ができるようにする
    - 報告用Slackチャンネル、インシデント対応用Web会議室、ステークホルダーの連絡先など、事前に整備しておく
- 運用
  - フローを見ながら、SEVレベルに沿ったエスカレーションと対応を行う

大規模なインデントが実際に起きた時、対応を円滑に進めるには**役割分担(Incident Commander, Communication Lead 等)が重要**となります。
どんな役割があるんだろう？と思った方は、下記の参考記事を読んでいただき事前にチーム内で認識を合わせておくことをおすすめします。

##### 参考

https://response.pagerduty.com/before/different_roles/

https://pagerduty.digitalstacks.net/blog/top-skills-incident-commander/

https://newrelic.com/jp/blog/how-to-relic/on-call-and-incident-response-new-relic-best-practices-2

## 3.ポストモーテム
具体的な内容は割愛し、要点だけ書いてみます。

- 目的
    - 失敗から学び、改善する為の非難のない振り返り
        - 責任追求の場ではなく、問題の原因を掘り下げ学習し、同じ過ちを起こさないよう成長すること
        - 根本原因の確認と効果的な再発防止策等の検討
    - 影響と損害の評価
    - 事例の収集/共有
- 注意点
    - 非難しない・責任追及の場にしない
        - 誰々が悪いなど、特に個人に対する非難は行わない
        - 非難や責任追及が行われてしまうと、受けた側が防御的になり客観的なデータが出てくることは望めなくなる
    - 原因特定や再発防止は仕組みで考える
        - 問題発生の原因を個人の能力や注意に求めることはしないようにする
        - 個人に原因を求めてしまうと再現性のある再発防止策を導き出すことができない、もしくは困難になってしまう
        - NGワード：しっかり, 注意深く


以上ような流れでインシデント対応を行っています。

## 実際に運用してみて

このようなフローを定め、運用を回し始めてみましたが
初期段階ではまだ慣れていない為か **SEV判定とエスカレーションをせず、内々でインシデント調査/解決に向けて動き始めてしまい、詳細は事後報告。** のような事案がまだ発生していました。
そのような対応に気づく度、口酸っぱく**まずはSEV判定して報告しましょう:sweat_smile:** と言い続けていたのですがそれも気が引けたので、改善策としてポストモーテムのテンプレートに以下のような振り返り項目を追加するようにしました。

- 振り返り
    - SEV判定
        - 初動でSEV判定できましたか？
    - エスカレーションフロー
        - 事前に定めたフローに沿ったエスカレーションが出来ましたか？
    - うまくいったこと
        - 簡潔に
    - うまくいかなかったこと
        - 簡潔に

これにより、徐々に改善していった気がします。

余談ですが、現状の弊社の場合インシデント発生頻度はそれほど多くなく（月0-3件？程度）ポストモーテムの共有に関する運用は

- ポストモーテム共有フォルダ(社内からは誰でも参照可能)に置く
- エスカレーションフローで定義されている、インシデント対応用slackチャンネルで共有
- エンジニアの週次会議体で報告

のような内容となっており、インシデント管理ツールの導入は行っていない状況です。

今後、組織が大きくなり発生頻度や共有方法に関して課題感を感じたり、発生頻度に関わらず大きなメリットが感じられた場合は導入を検討していこうと考えています。


## まとめ

いかがでしたでしょうか？
事前に定めたフローに沿ったインシデント対応が行われるようになって
- インシデントの重大度に関して、Severity Levelsという共通認識を持てるようになった
- 発生中のインシデントの重大度が明確に判別できるようになった
- SEVレベルに応じたエスカレーションがスムーズに行われるようになった

等のメリットが生まれました。

以上、この記事が皆様の参考になれば幸いです。
SPSS Modeler ノードリファレンス 5-20 異常値検査(Anomaly Detection)

# 5-20 異常値検査ノード[モデル作成タブ]
<img width="200" alt="194_161異常値検査.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/f7d1ba40-b495-3469-01c7-61588eb4081b.png">


## 1.ノードの目的
他のレコード（行）と比較して異常度をスコアリングします。設備の異常検知や不正検知を教師なし型で行う際に利用します。

![スクリーンショット 2022-12-10 15.13.25.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/419af602-ef04-da4b-abd5-68b2ec95d367.png)


## 2.解説動画（60秒）
<iframe width="560" height="315" src="https://www.youtube.com/embed/uWWEhrVhBNw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## 3.クイックスタート

[異常値検査]ノードで異常なケースを特定します。
＊サンプルデータ（CSV）は[5.参考情報]からダウンロードできます。
スマートメーターの計器番号レコードに、30分間隔の48区間の時間帯がフィールドに記録されています。
![スクリーンショット 2022-12-10 14.35.42.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/2ba59065-0174-4c77-a8da-c413f766ed69.png)

次のようにストリームを作成します。
![スクリーンショット 2022-12-10 14.33.17.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/3cd3d9d7-4a6d-6321-b539-7257db36a83c.png)

[データ型]ノードを設定します。[データ型]タブで以下のように設定します。
![スクリーンショット 2022-12-10 14.36.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/c1f533d7-b5a3-8a07-8105-2c038284a15b.png)

[異常値検査]ノードは1％の異常を特定する初期設定で実行します。
![スクリーンショット 2022-12-10 14.36.56.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/97030ecc-1e43-8ffc-85e8-810eb60c45c6.png)

[異常値検査]を実行してナゲットが生成されたら[ソート]と[テーブル]を接続します。
![スクリーンショット 2022-12-10 14.48.07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/18fc9116-6033-ec12-4cd8-a668b6961dde.png)

[ソート]ノードは以下のように設定します。
![スクリーンショット 2022-12-10 14.37.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/c31a5e68-91fb-b4c7-97cd-76eeafcd6611.png)

[テーブル]を実行します。上から10レコードが異常＝Tで判定されています。それぞれの最もスコアが高い３つの時間帯と値が表示されます。
![スクリーンショット 2022-12-10 14.47.39.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/11992da0-8a6c-e17a-9531-7f2f121be125.png)

## 4.Tips

#### 異常値を捉えるための視覚化

複数系列グラフで異常レコードと同じグループのいくつかのレコードを比較すると理解が進みます。

![スクリーンショット 2022-12-10 14.27.54.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/286322/0bf3c974-604c-c58a-6620-e35a0de297dd.png)

手続きは以下の記事で解説しています。

https://qiita.com/416nishimaki/private/c5cc0c087b464fe162e5#%E6%96%B0%E3%82%B0%E3%83%A9%E3%83%95%E6%A9%9F%E8%83%BD%E3%81%A7%E3%81%AE%E8%A4%87%E6%95%B0%E7%B3%BB%E5%88%97%E3%82%B0%E3%83%A9%E3%83%95

## 5.参考情報

#### 利用データ

右クリックでリンク先を保存してください。

https://raw.githubusercontent.com/yoichiro0903n/blue/main/ano_data.csv

#### 異常値検査ノードを扱った記事

https://www.ibm.com/blogs/solutions/jp-ja/spssmodeler-push-node-8/

#### SPSS異常検知書籍紹介

https://www.ibm.com/blogs/solutions/jp-ja/book-spss-01/

#### 異常検知の自動化

https://www.ibm.com/blogs/solutions/jp-ja/learn-modeler-10/

#### ノードのヘルプ

https://www.ibm.com/docs/ja/spss-modeler/18.4.0?topic=models-anomaly-detection-node

#### SPSS Modeler 逆引きストリーム集（データ加工）

https://qiita.com/416nishimaki/items/4bf813e6cba84b2a1008

#### SPSS Modeler ノードリファレンス目次

https://qiita.com/416nishimaki/private/503037195081d3323eee
データマネジメントプロジェクトで検討が必要なことを整理する

# はじめに
これまでのデータマネジメントプロジェクト導入の経験を踏まえて、『アプローチ』『リソースプランニング』『スケジューリング』の３つの観点から、検討が必要と思われることを整理してみました。

# アプローチ
データマネジメントプロジェクトを進めるにあたり、『トップダウン』『ボトムアップ』２つの方法が考えられます。どちらが正解ではなく、それぞれの特性を活かして、プロジェクト立ち上げ・推進していく必要があります。

**トップダウン**

- 会社の戦略に合わせて、経営層の号令でプロジェクト検討開始
- 現場（IT部門と事業部門）に会社の戦略に合わせたプロジェクト目的が明確にカスケードできるかが鍵

**ボトムアップ**

- 現場の課題や苦労を積み上げて実現要望をまとめ、経営層に上げていく
- 現場担当者のモチベーション維持（当事者意識）、中期経営計画への順従、経営層への訴求ポイント（売上アップや在庫最適化等）が鍵

![TopDown&BottomUp.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2989318/4095fc49-e01c-de17-d5b6-efb51b8fa90d.png)

# リソースプランニング

データマネジメントプロジェクトのリソースプランニングは、『業務部門』『IT部門』『プロジェクト推進』の３つのカテゴリで検討する必要があります。この３つのカテゴリのバランスとモチベーション維持（当事者意識）が必要不可欠です。

**業務部門**

そのデータを必要としてる、もしくは活用したいと考えている関連部署・事業部
現場担当者（日々データを操作している担当者）、現場管理者（データ操作の管理者）、部門責任者（データオーナー）

**IT部門**

既存システムを運用している、そして新プラットフォーム導入を目指すシステム部
既存システム担当者（データ所在を把握している）、基盤担当者（既存ネットワーク/OS/DBを把握している）、現場リーダー（現場の取りまとめ役）

**プロジェクト推進**

プロジェクトマネージャー（プロジェクト推進役、QCD観点での管理とレポーティング）
アーキテクト（既存の仕組み、新規導入の仕組みの統合を検討）
実装担当（データ連携、マスタデータ管理、データ品質管理、API統合の実装担当、必要に応じて配置）

![ResourcePlanning.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2989318/252a466d-d8b9-d634-f015-3dc42bddf80a.png)

# スケジューリング
ビックバンでなく、大きく考えて小さく育てる（Think Big, Small Start）、小さい成功体験を積み上げるためのスケジューリングが必要と考えられます（適切な導入期間と成功度合い）。

- 最適なプロジェクト期間で無理のないゴール（1stスコープ）を設定する。
- 全STEPをプロジェクト推進にお任せでなく、徐々に自分たちで運用・活用できる仕組みに仕上げていくプロセスが重要。
- 業務部門・IT部門の中で、新規導入の仕組みを理解したスペシャリストを育てていく。
- もしくは、業務部門・IT部門以外に、データ管理専門部署を立ち上げ、データに関するスペシャリスト部隊を構築することもあり。
- 早い段階（要件定義フェーズ）で、要件を一部反映したプロトタイプを準備し、業務部門とのゴールイメージの共有を行う。
- どちらにしても、新規導入と並行したスキルトランスファーとOJTが必要不可欠。
- コストの観点からもプロジェクト推進のリソースはリリースされ、体制としての最適化が求められる。

![Scheduling.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2989318/f2b15478-19b1-77b2-eca3-200049ddd8cc.png)
IndexedDBの概念がわかりづらい件について

IndexedDBの概念がわかりづらいので、まとめてみた。

- オブジェクトストア
- インデックス
- キー
- 値

# オブジェクトストア
RDBでいうとこのテーブルに相当する。実態はただのオブジェクト
ややこしいのは、オブジェクトストア＝なんらかのオブジェクトという概念なので、
一概にテーブルと同じ。とは言い切れないところ。

オブジェクトストアを作成するサンプルは以下のとおり

```javascript
 var store = db.createObjectStore('user', {
     keyPath: "name",
     autoIncrement: false
});
```

# インデックス
オブジェクトストアを作るとき、構成定義は行わず、自由にキー・ペア形式でデータを挿入できてしまう。そのため、インデックスを作って、キーの制約設定をしたり、検索するときにインデックスで設定したキーで検索ができるようにする。

インデックスは、オブジェクトのキーではなく保存されたオブジェクトのプロパティの値を使用して、オブジェクトストア内に保存された値を検索することを可能にする。また、インデックスには、保存されたデータに単純な制限を強制する機能がある。

インデックスも一種のオブジェクトストアとしてIndexedDBでは捉えている。
基本、RDBのインデックスと仕組みは同じ。
（参考：[インデックスの意味とメリット・デメリット](https://www.dbonline.jp/sqlite/index/index1.html)）

# キー
RDBでいうところのカラムに相当。ただ、オブジェクトストアは構成定義がなく、その構成は自由になっている。いわゆるNoSQLに近い。なので、オブジェクトのプロパティと言ったほうが近い。

このキーの概念がIndexedDBでは大きく分けて２つある

|種類|説明|
| :---:|:---|
|インライン・キー|オブジェクトストア内にあるキーのことをインライン・キーと称する|
|アウトオブライン・キー|オブジェクトストアの外で定義されたキーのこと。|

keyPathを省略し、autoincrementをtrue、falseを切り替えることで、以下のような違いが生まれる。

autoIncrementをtrueでオブジェクトストアを生成すると、キーはインクリメントで自動生成される。

```javascript
var store = db.createObjectStore('user', {
        autoIncrement: true
});
```

autoIncrementはfalseでオブジェクトストアを生成すると、add()やput()でデータを追加するとき第二引数にキー値を指定しなければならない。

```javascript
var store = db.createObjectStore('user', {
        autoIncrement: false
});
```

|KeyPath|autoincrement|説明|
|:---:|:---:|:---|
|なし|なし|どんな種類の値でも保持できる。新たな値の追加をするときは個別のキー引数を指定する必要がある。|
|あり|なし|JavaScript オブジェクトのみ保持できる。オブジェクトはキーパスと同じ名称のプロパティを持つ必要がある。|
|なし|あり|どんあ種類の値でも保持できる。キーは自動的に生成される。|
|あり|あり|JavaScript オブジェクトのみ保持できる。KeyPath に指定したプロパティに自動的に値が生成される|

# 値
キーに入れる値のこと。EcmaScriptで使われる型であれば値として指定できる。

メソッドや、オブジェクトの種類についてはまた書くときにまとめてみたいと思います。
開発時に気をつけたほうが良いこと（機能的観点）

開発時に気をつけたほうが良いなと思ったことを抽象的機能単位でまとめました。
自身の経験や他の人の話が元ネタになっています・・・・・・
開発初心者の方に「こういうこと気をつけたほうが良いんだな〜」という気付きになれば幸いです！

## 参照系画面
- どのカラムの昇順、降順で表示させるか
- 検索結果を表示後、並び替えをするか
- 1ページに何件表示させるか（1ページあたり件数）
- ページャーを実装する場合の検索結果の持ち方（フレームワークに乗せるか、セッションか、リクエストパラメータか）

## 更新系画面
- Update文に更新対象カラムが指定されない場合のケースを考慮する（画面側で条件を全く入力せず更新を実行した場合など）
    - チェック処理を行い上記の場合はエラーとし更新を実行しないのが無難
- 更新できたか否かを返すか更新結果をどう扱うのか
- データを一括登録する際に、既にあったデータは削除してから一括登録を実施するパターン
    - データを登録しようとして、対象データがすべて空データの場合、削除だけ実行するのか処理を行わないことにするか
- 複数データをまとめて登録しようとする時、行の重複はどう対応するのか
    - 重複したまま登録する
    - 重複した一方を登録する
    - 重複したらそのレコードは両方とも登録しない
    - 重複があればエラーとし登録を実行しない

## 画面共通（フォーム）
- デフォルト値は空欄か、あるいは何らかの値を持つか
	- プルダウンリストの場合はキーバリュー両方
	- 値がありません、のようなメタな文言を表示することもある
- null、空文字、スペースだけの値を弾くのか、許容するのか
- 全角半角の違いを考慮するか
- プルダウンリストや複数項目チェックボックスはDBから値が取れないなど値がない場合はどうするか（空のものを表示、値がないことを示す文言を表示など、合わせてエラーメッセージ発出するか）
- 参照（Read）よりは更新（Update）、削除（Delete）で入力制限を厳しくする
- エラーメッセージの表示形式（画面上で表示、ポップアップで表示など。
    - 画面上とポップアップを併用する場合メッセージはどちらでも利用できるようにしておく
- 日付データを用いる際の開始日と終了日の時系列矛盾のチェック処理

## ログ
- フォーマット
- 出力先
- エラーレベルに応じた扱い
    - 例えば、DEBUG、INFOは開発時のみ、それら以上は常に出力しログファイルに残す
- ログがDB接続失敗などで出力できない場合、業務ロジック優先のためエラーログなど出すだけして例外を握りつぶすか否かの考慮
- できれば設計段階で共通化しておく

## DB接続
- SQLの記述形式（文字列生成かSQLファイルか）
- DB接続処理でのエラー、例外の扱いは明確にしておく（Class宣言、PS、コネクション、SQLExceptionのそれぞれに対して考慮）
- できれば設計段階で共通化しておく
- PreparedStatementでIN句を扱うときは、置換は使わずString文字列の状態でSQLを作る
    - IN句で指定するデータがVARCHAR型で「1」など数字の場合、数値に変換されエラーになる（※うろ覚えなので間違っているかも）

## ファイル操作
- ファイルのフォーマットは何か
- ヘッダーは必要か否か
- 文字コード
- csvの場合ファイルの中の項目自体にカンマが含まれたらどうするか
- 配置先はどこか
- ファイルの容量制限はするか
	- 処理途中でファイルを分割したり
- webアプリでファイルをアップロードする場合、データを保持して処理を続けるか、一旦サーバー側にファイルとして書き出すか
    - データの大きさによる
    - 各ブラウザのアップロードサイズ上限を超えないか（ChromeとMicrosoftEdgeとFireFoxは10GB、safariは2.01GB）
    - zipとして圧縮する場合、ツールによって圧縮率が違ったりするのでどのツールで圧縮するかの要件考慮
- チェック処理などのデータ操作とファイル操作は分離する
	- 分離させないとチェック処理結果とファイル操作が混在して、テストケースごとにファイル操作が発生するなど手間になりテストがしにくくなる
- 取り込み処理などでのnullと空文字と半角全角スペースの扱い
- CSVなどファイルから取り込んでデータを配列やArrayListにした時は、要素数のチェック


### 終わりに
自身の経験や他の人の話を今後にも使えるようにと一般化して書いています。
そのためわかりにくい、あるいは一般化できていないのなどご指摘いただければと幸いです！
今後新しく気づいたことがあれば追記していきたいと思います！
フローでMap変数を使う

["Map a Value" for Flow](https://github.com/aidan-harding/flow-map)

上記の和訳です。

マップは、Apex 開発者にとって馴染みのあるデータ構造ですが、Flow にもメリットがあります。それらは、多くの分岐があるいくつかの決定ノードを単一のノードに置き換えることができます。

このシナリオは多くの場所で発生します。たとえば、使用する電子メール テンプレートが選択リスト フィールドの値に基づいている電子メールを送信します。または、フィールドの値に基づいてレコードの所有権を割り当てます。

[ブログ](https://nebulaconsulting.co.uk/insights/maps-in-flow/)のフロー内のマップも参照してください。

# 簡単な例: Type からの Account Record Type

実証するために、タイプ (取引先の標準選択リスト項目) に基づいて取引先のレコードの種類を設定するおもちゃの例を使用します

**決定ノードの使用**
まず、決定ノードを使用した従来のアプローチ:

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/cd412a1a-6177-d2fa-a8a1-b2f5f72a8ad2.png)


ご想像のとおり、このフローはType決定ノードをチェックインし、対応するアカウント レコード タイプの開発者名を変数に割り当てます。次に、レコード タイプ ID を照会し、それをアカウントに割り当てます。

**マップ ノードの使用**

それは問題ありませんが、Map を使用して簡略化できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/966eb0d2-9720-abb2-5208-6b5c3b689c3c.png)


Typeこのバージョンでは、 からRecord Type Developer Name へのマッピングは1 つのステップです。その魔法の「Map a Value」ノードの構成を見てみましょう。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/2ac94a61-24ad-4be3-bfa2-09973a9084a3.png)


構成には次の 2 つが必要です。

+ 入力変数の名前
+ マッピング データのテーブル
次に、マッピングされたデータを出力します。シンプルで効果的！

# 別の方法: カスタム メタデータ タイプ

Get Records で Flow の効率的なクエリを利用して、カスタム メタデータ レコードにマッピング テーブルを保存することもできます。これにはフローでさらにいくつかのノードが必要ですが、カスタム コードは必要ありません。また、フローからマッピングを外部化するため、フローを開かなくてもマッピングを変更できます。

**カスタム メタデータ ルックアップ テーブル**

ルックアップ テーブルのカスタム メタデータ タイプを定義できます (マップが何をするかを調べる別の方法)。次に、そのテーブルの行を記録する別の型を使用できます。例でこれがどのように機能するかを簡単に確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/3b45c8df-e9f5-d716-09aa-36b55d701e9f.png)

複数のフローでこのアプローチを採用した場合にキーの衝突が発生しないように、このレコードの 2 層セットアップがあると便利です。たとえば、2 つのフローが「重要」キーに関心がある場合、それらが分類されないようにするために、異なるルック テーブル レコードに格納されます。

**カスタム メタデータ ルックアップ フロー**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/182e73f7-0c1f-dfb2-bc4f-12468d195a0c.png)

ここでは、マッピングを行うために 2 つのクエリが必要です。まず、ルックアップ テーブルの ID を取得します (現在、親の名前に基づいて行をクエリすることはできません)。Type次に、ルックアップ テーブルの行をクエリして、Account をレコード タイプ DeveloperName にマップします。フローの残りの部分は他のフローと同じで、レコード タイプ ID をロードして割り当てます。

**評価**

カスタム メタデータを使用すると、「値をマップする」アクションでマッピングするよりも設定に手間がかかります。ただし、構成をフローの外に持ち出すと、状況によっては役立つ場合があります。

# フローの例

これらの手法を使用した[フローの例](https://github.com/aidan-harding/flow-map/blob/main/force-app/main/default/examples)は、例で見つけることができます。

# インストール

「値のマッピング」アクションはパッケージではなく、単なる Apex クラス、設定用の LWC、および Apex テストです。したがって、次のディレクトリにあるファイルを組織にコピーします。

+ Apex: [FlowMap および FlowMapTest](https://github.com/aidan-harding/flow-map/blob/main/force-app/main/default/apexFlowMap/classes)
+ LWC：[flowMapEditor](https://github.com/aidan-harding/flow-map/blob/main/force-app/main/default/apexFlowMap/lwc/flowMapEditor)

同様に、カスタム メタデータ ソリューションは、[cmdtFlowMap](https://github.com/aidan-harding/flow-map/blob/main/force-app/main/default/cmdtFlowMap) ディレクトリにある個々のファイルとしてインストールすることもできます。

-----------------------------

+ [呼び出し可能なメソッド: フローと Apex の間でデータを送信する方法](https://unhandledsunshine.com/2021/08/12/invocable-methods-how-to-send-data-between-flow-and-apex/)

Apex の呼び出し可能なメソッドは常に List を受け取り、戻り値の型が null でない限り、List を返します。詳しくは、こちらの「インプットとアウトプット」をご覧ください。
[社内勉強会]シェルワンライナー入門

## この記事の概要
私は株式会社パソナに所属しており、WEB/AIチーム内で実施したシェルワンライナー勉強会の内容を紹介します。若干ニッチな分野かと思いますが、業務で活用できる場面はたくさんあると思い、社内に閉じる内容でもないため投稿しました。

## 対象とする読者
- シェルワンライナーを知らない、あまり詳しくない
- 業務効率化の手段を知りたい


### シェルワンライナーとは
ターミナルなどCLIから、目的の処理を達成するために作る１行のコマンドです。
基本ソースコードを残さないので、綺麗に書く必要はありません。動けばOKの世界です。

![シェルワンライナー発表用 .jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/af319e66-b6dd-3d3d-caba-bb6cdb133def.jpeg)

![シェルワンライナー発表用  (1).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/dae58bbd-f47f-1e43-aa19-209544615d08.jpeg)
 

### シェルワンライナー活用例
![シェルワンライナー発表用  (2).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/fcc3ffc9-fb8b-0a80-2d4f-908128832439.jpeg)

 ![シェルワンライナー発表用  (3).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/dc89d24f-6a61-d835-dfa1-13a5e15776fc.jpeg)

 ![シェルワンライナー発表用  (4).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/ef15b1b6-c61d-9910-6c38-539ee856260a.jpeg)

![シェルワンライナー発表用  (5).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/ce6b08cd-72d4-5705-bc87-908ce826cbbe.jpeg)

### 勉強会では演習問題を参加者に解いてもらいました

![シェルワンライナー発表用  (6).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/db6ff35c-f141-43fa-2005-a3a94b6fa98a.jpeg)

### 演習問題のヒント
![シェルワンライナー発表用  (7).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/9760f4fe-ca84-44d6-4d4b-3fb73daacb22.jpeg)

![シェルワンライナー発表用  (8).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/8ff861b6-9b47-8933-90d0-84c0ddb33d46.jpeg)

![シェルワンライナー発表用  (9).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/a1c6b4a3-fc88-3cc7-d625-5fe79787874a.jpeg)

### 演習問題解答例

![シェルワンライナー発表用  (10).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/2c09e3b7-9e33-55a1-e29c-4c9a4f0f2afa.jpeg)

![シェルワンライナー発表用  (11).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/66b36321-f269-36a1-6665-f1afe6f03893.jpeg)

### 
![シェルワンライナー発表用  (12).jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2986097/299659b3-bcee-4ffd-f189-f3841a71f6af.jpeg)

## 参考文献

https://www.amazon.co.jp/1%E6%97%A51%E5%95%8F%E3%80%81%E5%8D%8A%E5%B9%B4%E4%BB%A5%E5%86%85%E3%81%AB%E7%BF%92%E5%BE%97-%E3%82%B7%E3%82%A7%E3%83%AB%E3%83%BB%E3%83%AF%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%8A%E3%83%BC160%E6%9C%AC%E3%83%8E%E3%83%83%E3%82%AF-Software-Design-plus%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA/dp/4297122677
【python】勉強メモ-その3　2次元配列CSV出力


### 1．はじめに

二次元配列を、CSVフィルに書き込む場合、`writerows`を使いますが、
`writerows`は、全データーを一旦、メモリに読み込むため、データー量が多い場合には
メモリが足りなくなる可能性もあります。

そのような場合は、一行一行書き出すため、`writerow`を使います。


### 2．2次元配列をwriterowで記載する場合
では、2次元配列を、`writerows`と同じように`writerow`で書くと、どうなるでしょうか？
テキストファイル内には、`"['犬', 'ネコ', '豚']","['サル', '牛', '鳥']"`と出力されています。
意図した結果と違いますね。

```sampel_01.py

import csv

str_li = [
    ["犬", "ネコ", "豚"],
    ["サル","牛","鳥"]
]

print(str_li)
# [['犬', 'ネコ', '豚'], ['サル', '牛', '鳥']]

with open("test.csv", "w", encoding="utf_8", newline="") as f:
    writer = csv.writer(f)
    writer.writerow(str_li)

# 結果
# "['犬', 'ネコ', '豚']","['サル', '牛', '鳥']"

```

2次元配列を、`writerow`を利用してCSVファイルに書き出すには、
`for`文（ループ）を使います。意図した通りの結果になります。

```sample_02.py
import csv

str_li = [
    ["犬", "ネコ", "豚"],
    ["サル","牛","鳥"]
]

print(str_li)
# [['犬', 'ネコ', '豚'], ['サル', '牛', '鳥']]

with open("test.csv", "w", encoding="utf_8", newline="") as f:
    writer = csv.writer(f)
    for li in str_li:
        writer.writerow(li)

# 結果
# 犬,ネコ,豚
# サル,牛,鳥
```

### 3. 2次元配列をwriterowsを使って記載する場合
一応、一般的にも紹介されている`writerows`を使ってCSVファイルに書き出すコードも記載しておきます。

```sample_03.py
import csv

str_li = [
    ["犬", "ネコ", "豚"],
    ["サル","牛","鳥"]
]

print(str_li)
# [['犬', 'ネコ', '豚'], ['サル', '牛', '鳥']]

with open("test.csv", "w", encoding="utf_8", newline="") as f:
    writer = csv.writer(f)
    writer.writerows(str_li)

# 結果
# 犬,ネコ,豚
# サル,牛,鳥

```

### 4．参考
ここまでの内容が、分からない方は、以下のリンクを読み直してみてください。
[勉強メモ-その1](https://qiita.com/qiitataro/items/2d35722b00bfaf344220)

[勉強メモ-その2](https://qiita.com/qiitataro/items/58ed4cd45c24589cc39b)

### 5. 最後に
- ツッコミ歓迎致します。皆様のツッコミが、私のスキルアップにつながります！！
- お題なんかも出していただけると助かります。
- 実務では、もっと、こういう使い方もあるよ！！みたいなアドバイスもいただけると嬉しいです。
[Flutter] 今のコードをちょっと良くする（flutter analyze編）


![job_programmer.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/672609/156ec3aa-32e5-e675-635e-d5082fdb56a5.png)




こんにちわ。いせきです。毎日たくさんインプットがあるぐらいたくさん学べています！！
とても幸せに開発ができています。

今回は今のコードをちょっと良くする方法を共有していこうと思います。


# 何ができる??

今回は、`warning`を未然に防ごうという試みです。
以下のコマンドを打ってみてください。


```terminal
flutter analyze
```

と入力すると、warning内容がたくさん出てくるかもしれません。エラーではないのですが、直した方がいいよというFlutterからのメッセージです。

いいコードを書くうえでこの`warning`を防ぐということはとても大切です。


僕が、指摘をしていただいた例をご紹介します。

#### warningのファイル

```dart:widget_test.dart
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';

import 'package:flutter_training/main.dart';

void main() {}
```

`flutter analyze`を入れてみると以下の文章が出ました。

```terminal
   info • Unused import: 'package:flutter/material.dart' • test/widget_test.dart:1:8 • unused_import
   info • Unused import: 'package:flutter_test/flutter_test.dart' • test/widget_test.dart:2:8 • unused_import
   info • Unused import: 'package:flutter_training/main.dart' • test/widget_test.dart:3:8 • unused_import
```

この文章は、３つのimportは使っていないから削除してという文章です。意外と気づけていないものですね。僕は全く気づけていませんでした。

コードレビュー前にしておくとといいと思います！！
Web Semanticとは

Web Semantic は、Web上におけるセマンティック（意味的）情報を活用して、Webをより柔軟かつ拡張可能なものにする技術です。

Web Semantic は、Web上におけるデータをより柔軟かつ拡張可能なものにすることを目的としています。そのため、Web Semantic では、Web上におけるデータをより統一的かつ標準化された形式で表現することが重要です。

Web Semantic では、さまざまな技術が使用されます。その中でも、最も重要なものが RDF（リソース・デスクリプション・フレームワーク）です。RDF は、Web上におけるデータを表すためのデータモデルです。RDF では、データを「トリプル」と呼ばれる単位で表現します。トリプルは、「サブジェクト」「プロパティ」「オブジェクト」の3つからなり、データを表す基本的な単位です。

Web Semantic を活用することで、Web上のデータをより柔軟かつ拡張可能な形で扱うことができます。これにより、Web上のデータをより効率的に検索したり、統合したりすることができるようになります。

また、Web Semantic では、さまざまな標準や仕様が策定されており、それらを活用することで、Web上のデータをより標準化された形で表現することができます。これにより、Web上のデータをより統一的かつ一貫性のある形で扱うことができるようになります。

Web Semantic は、Web上のデータをより柔軟かつ拡張可能な形で扱うための技術であると同時に、Webをより柔軟かつ拡張可能なものにするための技術でもあります。

Web Semantic は、Web上のデータを RDF という標準化された形で表現することで、Web上のデータをより標準化された形で扱うことができるようになります。これにより、Web上のデータをより統一的かつ一貫性のある形で扱うことができるようになります。

また、Web Semantic では、さまざまな標準や仕様が策定されており、それらを活用することで、Web上のデータをより標準化された形で表現することができます。これにより、Web上のデータをより統一的かつ一貫性のある形で扱うことができるようになります。

Web Semantic は、Web上のデータをより柔軟かつ拡張可能な形で扱うための技術であると同時に、Webをより柔軟かつ拡張可能なものにするための技術でもあります。これらの技術を活用することで、Webをより柔軟かつ拡張可能なものにすることができます。
機械学習エンジニアに足りないもの

機械学習エンジニアとして、欠けているものとしては、以下のようなものが挙げられます。

1. ビジネスの理解：機械学習は、ビジネス上の問題を解決するためのツールです。したがって、機械学習エンジニアは、ビジネスの現状やニーズを理解し、それに応じたモデルを構築することが重要です。

2. データサイエンティストとのコラボレーション：機械学習は、データサイエンティストが収集したデータを使用して行われます。したがって、機械学習エンジニアは、データサイエンティストと協力して、有用なデータを収集し、データを準備することが重要です。

3. アルゴリズムの理解：機械学習では、様々なアルゴリズムが使用されます。したがって、機械学習エンジニアは、それぞれのアルゴリズムがどのように働くかを理解し、適切なアルゴリズムを選択することが重要です。

4. 技術的なスキル：機械学習エンジニアは、プログラミング言語やフレームワークなどの技術的なスキルを習得している必要があります。これらのスキルを使用して、モデルを構築し、デプロイすることができるようになることが重要です。

5. モデルの評価：機械学習では、モデルの予測精度を評価することが重要です。したがって、機械学習エンジニアは、モデルの予測精度を測定するための方法を理解し、適切な評価方法を選択することが重要です。

6. モデルの改善：モデルを構築した後も、その性能を改善するための取り組みが必要です。したがって、機械学習エンジニアは、モデルの性能を改善するための方法を理解し、適切な手法を選択して実行することが重要です。

7. モデルの解釈：機械学習モデルは、人間が理解しにくいものが多いです。したがって、機械学習エンジニアは、モデルの出力を人間が理解できるようにするための方法を理解し、適切な手法を選無事が重要です。
Google UXデザイン：レイアウト（グリッド）

# はじめに

わたしが[Google UX Design Certificateで得られた素晴らしい体験][google]を、特に重要だと思われるポイントを小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ Google UX Design Certificateを受講してみてください。

[google]: https://qiita.com/mapami/items/7a0d0a3d4661c50f8bec

https://www.coursera.org/professional-certificates/google-ux-design

<details><summary>これまでの振り返り</summary>

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/21e0608b-618e-054f-b3ed-3950bac1cc47.jpeg" width="700">

</details>

# レイアウト

レイアウトは通常、テキスト、スタイル、アイコン、画像の具体的な配置を指します。レイアウトの目的は、 ***<font color="MediumVioletRed">『情報を論理的に表現し、重要な要素を際立たせる』</font>*** ことです。

UXデザインの世界では、ページをレイアウトする方法がたくさんあります。今回から、グリッド、コンテクメント、スペースの要素について紹介します。

# グリッド

モックアップをデザインするとき、ページ上の要素を正しく配置することで、ユーザーの流れを改善し、ナビゲーションを容易にすることができます。しかし、特に新人デザイナーの場合、モックアップ内の要素をどこに配置すればよいかを推測するのは難しいものです。幸いなことに、私たちは正しい配置やレイアウトを簡単にするためのツールが使えます。

### ベーシックグリッド

まず、ベーシックグリッドがあります。

Figmaの基本的なグリッドはこんな感じです。ベーシックグリッドは一貫したデザインをするのに便利ですが、UXデザイナーは次に紹介するレイアウトグリッドを使用する方が一般的です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/4c3775cd-d47e-8942-e6ec-389cfe97197b.png" width="200">

### レイアウトグリッド

レイアウトグリッドは、デザイン内の要素を整理するための一連の列と路地です。列とは色のついたブロックのことで、路地とは列と列の間にあるスペースのことです。

Figmaのレイアウトグリッドはこんな感じです。
- 列は薄い赤色で、すべて同じ幅です。
- 路地は白色で、これもすべて同じ幅です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/55388d17-f222-1354-faa9-af3eebb35f38.png" width="200">

レイアウトグリッドの列の数は、デザインするデバイスの種類に依存します。
- ノートパソコンやデスクトップパソコンで見るような大きな画面向けにデザインする場合、レイアウトグリッドの列数は12列になるでしょう。
- より小さな画面向けにデザインする場合は、レイアウトグリッドのカラム数は少なくなります。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/989fefb7-0680-3b1b-0492-d38393658e4e.png" width="500">

# 疑問

### ベーシックグリッドとレイアウトグリッドのどちらを使うべき?
デザインするときに、ベーシックグリッドとレイアウトグリッドのどちらを使うべきか、疑問に思うかもしれません。これはデザイナーによって異なるので、選択するのはあなたです。ベーシックグリッドとレイアウトグリッドの両方を使うデザイナーもいれば、どちらかのみを使うデザイナーもいます。また、グリッドを全く使わないデザイナーもいます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/578c62d0-e950-12e6-b9d2-18d47a74c72c.png" width="400">


### グリッドは使うべき?

UXデザイナーとしてスタートしたばかりの頃は、いくつかの理由でグリッドを使用した方がよいでしょう。

- ***<font color="Teal">明快さと一貫性</font>*** を生み出します。効果的なグリッドは視線を誘導し、スクリーン上の要素をより簡単に、より快適にスキャンすることができます。
- デザインプロセスを速め、画面上の要素をより ***<font color="Teal">速く配置</font>*** することができます。
- ***<font color="Teal">デザインのコラボレーションを容易</font>*** にすることです。グリッドがあれば、デザイナーはだいたいどこに何を置けばいいのかがわかるのです。

# Googleで働くエントリーレベルのデザイナーによるモックアップ

Daneは、「Peacock」というアプリを作りました。

- ニューヨーク、サンフランシスコ、シカゴといった都市の画像の上に、検索バーが表示されていること。
- 各画像の四角形がまったく同じ大きさであること。
- 検索バーが画像の上の画面の真ん中に直接配置されていること。

Daneがグリッドを使ってデザインを計画し、要素を配置しやすくやすくした結果です。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/baf367a5-a051-f482-483e-7450d5576d61.png" width="200">

# Figmaでグリッドを適用する

右のプロパティ画面から「Layout grid」で「＋」を押します。デフォルトは、ベーシックグリッドです。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/f723aea3-946a-a9f4-daa9-8f12af7f3f35.png" width="500">

作成したGridを編集して、レイアウトグリッド（Columns)に変更してみます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2358573/309796c7-c2c4-5ffe-b817-02364d52532a.png" width="500">
失敗についてざっくり考えてみた

# 概要
[BBSakuraNetworks Advent Calendar 2022](https://adventar.org/calendars/7980) 10日目 に寄稿します。
今までのエンジニア生活の中で失敗が自分の成長につながっているなと最近よく感じています。
なので失敗について考えたことと今までの失敗をまとめていこうと思います。
かつての自分が出会い成長させてくれた失敗を共有することで少しだけ誰かに役に立てればいいと思います。

## コマンドライン
ではここからは具体的にどんな失敗と出会って来たかを記載していきます。
1. パイプの中で restart
ログを調査しているときに突然サーバが再起動して後から調べてみると、こんなコマンドを打っていたことがありました。
`# cat /var/log/messages | restart | grep ****`
はい、なぜ再起動したかお分かりですねw
間に restart コマンドが入っていて
確かこの時は、systemd コマンドで httpd の restart 時間を確認していたときだったと思います。
幸い検証環境だったのでよかったのですが、これが本番環境であったなら、、、
    この件で学んだのは、```極力 root ユーザにならない```、```パイプでのコマンド実行には気をつける```でした。
2. history 実行
ローカルでの開発環境だと history コマンド実行で前の history を見たり、↑キーを押してコマンドの再実行をすることがよくあると思います。ローカル環境だと自分が実行したコマンドしか出て来ないので、履歴からのコマンド打ち間違いをすることは少ないのですが、root ユーザや共通アカウントなどでhistoryからコマンド実行した場合自分と違う人が実行したコマンドも履歴が出てきます。特に↑コマンドで実行して、以前に```rm *```などのコマンドが実行されていると恐ろしい結果に。
実際に```rm *```を /var/log/** 配下で実行して特定プロセスのログが全て消え、問題になった現場に出会ったことがありました。履歴はローカル環境などでよく使うからこそ、本番環境や root ユーザでの実行には細心の注意が必要だと学びました。

## エンジニア方言は一般的な会話や資料では自重しなければならない時がある
1. ホゲホゲ, フガフガ
エンジニア以外の方へシステム仕様を伝えるために資料を作ることもあると思います。その時に先方から呼び出されてホゲホゲ、フガフガがちょっとした質問になったことがありました。
「ホゲホゲ株式会社ってなんですか？フガフガ部署ってどこの部署ですか？？」
エンジニアとの会話だと、ホゲホゲ、フガフガは市民権を得たメタ構文変数で自然と？？利用しているので、普通に資料にもホゲホゲ、フガフガを利用してしまいがちなのですが、エンジニア以外の方と話をする時はホゲホゲ、フガフガはエンジニア会話の共通語で日本人全員が当たり前に利用している言葉だと思ってはいけないと理解しました。最後にエンジニアが言葉を埋める時に使う用語ですと説明すると
「エンジニアだけで勝手に日本語を作らないでくださいよ(笑)」
とツッコミを受けました。
2. めんどくさい
プログラマーの三大美徳に
1.怠慢(Laziness)
2.短気(Impatience)
3.傲慢(Hubris)
というものがあります。Perl を開発したラリー・ウォールの言葉です。
(意味はネットを検索すると詳しく解説してくれている記事が多く見つかると思います。)
「めんどくさい」という言葉を「解決すべき問題が見つかったので、対応策を考える必要がある」の意味でエンジニアが利用することがよくあると思います。
しかし、仕事に対して「めんどくさい」ってエンジニア以外の人が聞くとあまり良くない感じに聞こえてしまいます。
「めんどくさい」はエンジニアとエンジニア以外で、ポジティブな意味とネガティブな意味という全く正反対の感情を持つ言葉の典型例だと思います。
この「めんどくさい」を何気なくエンジニア以外の方に使ってしまったことがあり、
「めんどくさいならやらなくていいですよ！」
とお叱りを受けたことがありました。
いつも何気なく利用している言葉がエンジニア以外にも市民権を得ていると考えて利用してはいけないと学びました。

## 最後に失敗について
失敗には積極的な失敗と消極的な失敗があると思います。
積極的な失敗: 行動した結果の失敗
消極的な失敗: 行動しなかった結果の失敗
どちらも失敗に違いないのですが、積極的な失敗の方が次につながる失敗であることが多く成長に対して貢献度が高い失敗であったと感じています。
当たり前のことしか言っていないのですが、この積極的な失敗と消極的な失敗を意識して積極的な失敗の回数を増やすことでエンジニアとして行動の質を高めることができるのではないかと考え、あえてこのことを最後に記載しました。
フルスタック機械学習エンジニア(MERN)

MERNとは、MongoDB、Express、React、Node.jsの4つのテクノロジーを組み合わせたフルスタックのWebアプリケーションフレームワークです。MERNスタックは、フロントエンド（React）とバックエンド（Node.js、Express、MongoDB）を提供することで、Webアプリケーションの開発を効率化します。

MongoDBは、ドキュメント指向のNoSQLデータベースです。このデータベースは、非構造化データをスキーマレスで保存し、JSONのような形式でデータを扱うことができます。

Expressは、Webアプリケーションフレームワークです。このフレームワークは、Node.jsで実装され、Webサーバーを構築するための様々な機能を提供します。

Reactは、JavaScriptのライブラリです。Reactを使用することで、Webアプリケーションのユーザーインターフェイス（UI）を構築することができます。

Node.jsは、JavaScriptの実行環境です。Node.jsを使用することで、JavaScriptをサーバーサイドで実行することができます。

MERNスタックは、JavaScriptを使用することで、フロントエンドからバックエンドまでのWebアプリケーションの開発を効率化することができます。このフレームワークを使用することで、Webアプリケーションの開発をスムーズかつ迅速に行うことができます。
MLOpsの実践方法

MLOps（Machine Learning Operations）は、機械学習のプロジェクトを開発、デプロイ、および維持するためのプラクティスです。これは、データサイエンティスト、エンジニア、および IT チームが一致した方法で機械学習モデルを開発、測定、および維持することを可能にするものです。

MLOps では、次のような手順を実行することが通常です。

1. データを収集して準備する：データを収集し、クリーニング、トランジション、および加工することで、トレーニングデータセットを作成します。

2. モデルをトレーニングする：機械学習アルゴリズムを使用して、トレーニングデータセットを使用してモデルをトレーニングします。

3. モデルを検証する：トレーニングされたモデルを検証データセットを使用して評価し、モデルの予測精度を確認します。

4. モデルをデプロイする：トレーニングされたモデルをプロダクション環境にデプロイし、実際のユーザーによる予測を受け付けるようにします。

5. モデルを監視する：デプロイされたモデルを定期的に監視し、予測精度が変化しないかを確認します。

MLOps では、これらの手順を自動化するためのツールやフレームワークが利用されることが多いです。これらのツールは、データの収集からトレーニング、デプロイ、そしてモデルの監視までのプロセスを自動化することで、効率的かつ一貫性のある方法で機械学習プロジェクトを管理することができMLOps では、さまざまなフレームワークやツールが利用されることがあります。これらのツールは、機械学習プロジェクトを効率的かつ一貫性のある方法で管理するために、データの収集からトレーニング、デプロイ、そしてモデルの監視までのプロセスを自動化することができます。

例えば、Kubeflow や TensorFlow Extended (TFX) は、機械学習のパイプラインを構築、管理、および監視するためのフレームワークです。これらのツールを使用することで、データの収集からトレーニング、検証、そしてデプロイまでのプロセスを自動化し、一貫性のある方法で機械学習プロジェクトを実行することができます。

さらに、モデルの監視には、ツール such as TensorBoard や MLFlow が利用されることがあります。これらのツールを使用することで、デプロイされたモデルを定期的に監視し、予測精度の変化や問題の発生を早期に検出することができます。

MLOps では、自動化や監視のためのフレームワークやツールだけでなく、データサイエンティストやエンジニア、そして IT チームの協力も不可欠です。そのため、MLOps を実践するためには、チーム間の協力とコミュニケーションを強化することが重要です。

また、MLOps では、プライベートクラウドやパブリッククラウド、そしてオンプレミス環境を統合するためのツールやフレームワークが利用されることがあります。これらのツールを使用することで、複数の環境を統合しモデルのトレーニングからデプロイまでを効率的また、MLOps を実践することで、データサイエンティストやエンジニアは、機械学習プロジェクトをよりスムーズかつ効率的に実行することができます。また、自動化や監視のツールを活用することで、品質の低いモデルや不適切な予測を早期に検出して防ぐことができます。


さらに、MLOps を実践することで、機械学習モデルをデプロイした後も、モデルの性能を定期的に監視することができるようになります。これにより、モデルの性能が低下した場合や、予測精度が悪化した場合に早期に対処することができます。

また、MLOps を実践することで、データサイエンティストやエンジニアは、トレーニングからデプロイまでのプロセスをより視覚的に理解しやすくなります。これにより、モデルをより正確かつ迅速にトレーニングし、品質の高いモデルをより早くデプロイすることができます。

MLOps は、機械学習プロジェクトを開発、デプロイ、および維持するためのプラクティスです。これを実践することで、データサイエンティストやエンジニアは、よりスムーズかつ効率的な機械学習プロジェクトを実行することができます。また、自動化や監視のツールを活用することで、品質の低いモデルや不適切な予測を早期に検出して防ぐことができます。
Pardot フォーム上の項目動作について

テクサポ 日本 7月12日 12:55 の記事の転載です。
個別に記事に直接アクセスできないので...

「メールアドレス以外の項目が表示されません！」
「Pardot フォーム項目に他の人の情報が表示されてしまいます！」  

基本的にこのような動作の背景には、 
フォーム送信を行うブラウザの Cookie 情報と Pardot のプロスペクト情報が紐づいている 
ことが多くあります。  
※ “Cookie” とは、デバイス ( PC やスマートフォン等の端末) のブラウザに対して発行・保持される「訪問者の情報」のことです。 

# メールアドレス以外の項目が表示されない   

**原因**

Pardot フォーム設定の [詳細] タブの画面にて、
**[すでに入力されていても常に表示する] という項目のオプションが無効になっている** 場合に発生します。  

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/8eda80ed-9882-062b-af31-5789e553528c.png)


(例) フォーム 項目X の [すでに入力されていても常に表示する] が "無効" の場合   
1. Pardot 上にプロスペクトA が登録されている (例: プロスペクト項目X の値は “A” )
2. プロスペクトA が、自身に紐づく Cookie が保存されているブラウザ上から、Pardot フォームにアクセスする 
3. Pardot フォーム上には、項目X 自体が表示されていない  

▼ [すでに入力されていても常に表示する] が "無効" のフォームの表示 
※ メールアドレス項目はデフォルトで有効になっており、無効にはできません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/e3bf3322-caf4-a88c-a865-ce1e937a12ef.png)

以上のように、対象の項目の値が既に Pardot 上に記録されている場合、 
Pardot フォーム上には、その項目自体が表示されない動作となります。


# フォームを表示するときにすべての項目が表示されないのはなぜですか? 

**対応策**
 「すでに入力されていても常に表示する」を有効化することで、 Pardot 上で既に値が登録されている項目も、フォーム上に毎回表示される動作になります。
  ▼ **[すでに入力されていても常に表示する] が "有効"** のフォームの表示
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/7ffff628-149b-63d9-e289-9a6b39a58dde.png)

# Pardot フォーム項目に他の人の情報が表示されている。  

**原因** 
フォームへアクセスしたブラウザの Cookie 情報が既存のプロスペクトと紐づいている場合、フォーム項目には、既存のプロスペクトの情報が表示されます。  

このフォームの仕組みにより、以下の動作に繋がるケースがあります。
  (例) Pardot メール内のフォームの URL を 第三者 がクリックした場合 

1. Pardot 上にプロスペクトA が登録されている (プロスペクト項目X の値は "A" ) 
2. 既存プロスペクトA 向けのフォームのトラッキングリンクをメール転送など何らかの形で第三者へ共有する 
3. 第三者 が共有されたフォームのトラッキングリンクをクリックする  

※ この時点で、プロスペクトA をトラッキングするための URL をクリックすることになり、第三者 によりリンククリックしたブラウザの Cookie 情報がプロスペクトA に紐づきます。  

4\. ) Pardot フォームにて他の人 (プロスペクトA) の情報 (項目X の値は "A") が表示される  

【フォームに他人の情報が入力されているのはなぜですか？】  
なお、そのフォームをプロスペクトA ではない人が送信すると、

A に紐づく Cookie 情報 (ビジター情報) が、フォームを送信したプロスペクトBに紐づくことになり、Pardot に記録されているプロスペクトA の過去の Web 上のアクティビティ (フォーム送信や Web サイト訪問 等) がプロスペクトB のアクティビティとして記録されることになります。  

このように Cookie 情報 (ビジター情報) の紐づき先が変更されることを、 「ビジターの関連付けの変更」と呼びます。  
+ [[ビジターの関連付け] 概要](https://help.salesforce.com/s/articleView?id=000315854&type=1&language=ja)

**対応策**

以下 2 つの方法で、"フォームに他の人の情報が表示されることを防ぐ" ことができます。 

+ フォームを キオスク/データエントリーモードに設定  
(※ 設定: Pardot フォーム編集画面 > [デザイン] ステップ > [詳細] タブ) 
フォームへアクセスした際に、訪問者 (ビジター) に対して Cookie を発行しないようにする設定です。 

+ AddThis コネクター を使用  
Pardot メール内に共有用のボタンを追加し、トラッキング対象外のメールとして、 転送することができるようになります。  

また、以下の方法では "「ビジターの関連付けの変更」を防ぐ" ことができます。  

+  フォームに [あなたのログイン名ではありませんか?] リンクを設置 
 (※ 設定: Pardot フォーム編集画面 > [デザイン] ステップ > [詳細] タブ)  

第三者がフォームにアクセスし、他の人の情報が表示されている場合、 [あなたのログイン名ではありませんか?] リンクをクリックすることで、 その時点で発行されている Cookie 情報を削除することができます。
Javascript Uncaught ReferenceError: require is not defined   

## 環境
Mac(M1, 2020)
vscode５

# [概要]
素のjavascriptでtodoアプリを作成中
入力した値をローカルホストに保存するためにまずは
document.querySelector("li")で取得しようとしたところエラーが発生した
```
const { Save } = require("@material-ui/icons");

const form = document.getElementById("form");
const input = document.getElementById("input");
const ul = document.getElementById("ul");

form.addEventListener("submit", function (event) {
  event.preventDefault();
  add();
});

function add() {
 let todoText = input.value;
 if (todoText) {
  const li = document.createElement("li");
  li.innerText = todoText;
  li.classList.add("list-group-item");
  ul.appendChild(li);
  input.value = "";
  saveData();
  }
}

function saveData() {
  const lists = document.querySelector("li");
  console.log(lists);
}
```


## ぶつかったエラー
Uncaught ReferenceError: require is not defined   

翻訳・意味
Uncaught ReferenceError: require が定義されていません
     script.js:1:18 で
## やったこと
1.コードを見返していたら覚えのない
const { Save } = require("@material-ui/icons");を発見
2.削除



## 結果
解決できた
saveData（）;をSaveDataと打ち間違えた際にmaterial-uiが反応して生成されてしまった。
「7つの権限レベル」で自律を支援する

最近流行りのChatGPTに「**自律**」について説明を求めると、次のような返答がありました。

>  自律とは、自分自身が自己管理や自己コントロールを行う能力のことを指します。これには、意志力や習慣、行動の決断などが含まれます。自律は、個人が成長し、自己実現するために必要な能力です。また、社会や集団での正しい行動や公正な判断をするためにも重要です。

**「自律」はどんな組織でも重要視される要素でしょう。**

しかし、実際に自律したメンバー、チームであり続けることはなかなか難しく感じています。なぜなら本人やチームだけの問題ではなく、それが属する環境に大きく左右されるものだからです。

そのような環境の要因を無視して、若手のメンバーや新しくできたチームに自律を強制させるのは、よい手段とは言えません。

## 自律性を高めるように支援する

そのかわりマネージャーや経験あるメンバーは、自律性を高めるような支援はできるだろう。というのが筆者の考えです。

そこで重要なのが「**権限**」です。「適切な権限をあたえよう」というフレーズは、おそらく何度も見たことがあるのではないでしょうか。筆者もこれを意識してよく仕事をしています。

そして最近読んだ『マネジメント3.0』で紹介されている権限の与え方にとても納得したので、これを紹介させてください。

## 権限は二択でなくグラデーション

権限をあたえようと考えたとき、よくやってしまう間違いは、

- この意思決定・タスクはAさんに任せられる
- この意思決定・タスクはAさんには任せられない

というように、**権限を与えるか与えないかの二択にしてしまう**ことです。

> あなたの最初の自動車教習で、あなたの運転共感があなたに運転ハンドルを任せたかもしれないが、彼は確実にあなたに左折する時あるいは右折する時を正確に告げたと私は思う。多くの教習の後、あなたはいくらかの経験を積んだところで、彼はあなたに「先週、あなたが電話ボックスに激突しそうになったショッピングセンターに行こうか」と言い、そこに着くまでの道をあなたが自分で探さねばならなかったかもしれない。そして、経験を積んだ運転者であれば、教官は「私が昼寝を取る間に、ここいらを少し運転してみないか」と言ったかもしれない。 [^1]

上記の例は、教官が生徒に対して「すこしずつ権限をわたしている」場面を描いています。

つまり**権限とはグラデーション**であり、**ある箇所の権限だけをわたすことが可能**である、ということです。

## 7つの権限レベル

『マネジメント3.0』では、権限のレベルを7つに区別しています。自分なりにまとめると、次のように説明できそうです。

1. 告げる: 意思決定した旨を伝える　※権限をまったく与えない状態
1. 売り込む: 意思決定に関心をもってもらう
1. 相談する: 意思決定について意見をもらう
1. 合意する: 意思決定をみんなでやる
1. 助言する: 意思決定をサポートする
1. 尋ねる: 意思決定を説明してもらう
1. 移譲する: 意思決定に関わらない

あらためて「告げる」と「移譲する」の間に、5つものレベルがあることに注目したいです。

個人的には「権限をわたしている」とは見られないであろう「**売り込む**」や「**相談する**」というレベルがあることに、とても共感を覚えました。

## 具体例

たとえば若いメンバーやチームに対して「**移譲する**」ことができない場合[^2]、どの程度の権限をわたせるか考えてみましょう。

もし意思決定やタスクを任せられないとしても、ゆえに「こっちでやる」ではなく「〜のようにしようと思っていますが、どうですか？」というように「**相談する**」ということができます。

これに対してメンバーやチームから積極的に意見が出るようで、それらの意見が納得いくものであれば、権限のレベルを「**合意する**」もしくは「**助言する**」に変化させ、自身はファシリテーターの位置に回ってもよいでしょう。

逆にメンバーやチームが意見を出すのもつらそうな状況であれば、まずは「**売り込む**」というレベルを設定して、自身で進めてしまうけれどもその意思決定やタスクがどのような意味を持つかを説明し、なんとなくでも理解を得るべきです。

もちろん「**告げる**」という権限レベルを利用するときもあるでしょう。その場合も、ちゃんとその権限レベルを行使することを伝えることで、メンバー・チームの信頼関係を不用意に壊さずに済みそうです。[^3]

## 最後に

自律性を高めるための支援として、適切なレベルの権限を意識して渡してみよう、という話でした。

「任せるよ」とか「自由にやって」と言うのはとても簡単ですが、実際は任せられていなかったり、あるいは逆にマネジメントをただ放棄しているだけだったり、上手くいかないケースはよくあります。

このような状態はむしろメンバー・チームの自律性を弱めてしまうと感じますし、心理的安全性の側面からもマイナスな状況ではないでしょうか。

「権限」という言葉は、ちょっと怖かったりトップダウンを意識してしまってとっつきにくいかもしれません。

しかしその苦手意識をとっぱらって、一度チャレンジしてみる価値はあると感じました。


[^1]: Jurgen Appelo『マネジメント3.0 適応力の高いチームを育むための6つの視点』、p144

[^2]: 個人的にはこのケースがほとんどだと思います。むしろ移譲してはいけない状況で移譲するようなミスをよく見ます。これは移譲ではなく「丸投げ」です。

[^3]: 筆者の感覚だと、むしろ信頼関係が増すように感じます。