mitsuのぶろぐ

基本的にはプログラミングの話のつもり。フロントエンドよりです。

Miroを使ってオンラインKPTAをやってみた

miro × kpta
miro × kpta

昨今のリモートワークの流れの中で、ご多分に漏れず私もリモートワークをしております。
そんな中で、どうにかしてオンラインでもいい振り返りを行うことができないか考えていたところ、別件で使っていたMiroというツールを使うと、効果的な振り返りができたので記載します。

振り返り

振り返りの手法としては KPTA を利用しています

www.kikakulabo.com

いつもオフィスでやる際にはホワイトボードと付箋を使って実施していました。
もちろん今リモートワークをしているときには残念ながらどこかに集まって実施、とはできないので、なにかオンラインで同様のことができないか模索していました。

Miro

そんな中で見つけたのが Miro です。

miro.com

オンラインのホワイトボード系のツールで、パーツも豊富で自由度高く操作することができます。

オンライン時のルールとして

まだまだ運用については発展途上なところがありますが、現状は以下のようなルールでおこなっています。

■運用事項
- 基本は一応ホスト(後述)の人が画面をzoomなどWeb会議で共有をしておくが、基本は個々人がMiroの画面を見て、操作することを推奨
- 基本は1KPTA 30分で想定
- 明らかに延長しそうな場合はMTG設定時に長めに確保すること(反省したいこと盛りだくさん、や、参加者が多いと長引きやすい傾向があるので、そこは見越して設定すること)
- 開始前までに自分のKeep、Problem、Tryを書いておき、まとめて各エリア内に配置しておく。また他のメンバーが書いたものに目を通しておく


■ 役割分担
- ホスト :
 ・zoom(などのオンラインMTGツール)のURL準備と参加者に共有
  ・全体の進行
  ・グルーピングと、グルーピングした内容のタイトル付け(グルーピング自体は付箋を移動させる程度、清書は書紀の人に任せる)
  ・tryをベースにactionを決めていく

- 書紀 :
 ・ホストの人が大まかにグルーピングした内容や付箋の配置などを見やすく再配置などする
 ・複数人KPTAに参加者がいれば、Keep、Problem、Tryにそれぞれ書紀を配置する
 ・関連性のあるものに対してや付箋間やアクションに対して矢印などをひっぱる

オンラインのメリット

事前に反省内容を列挙しつつ、他のメンバーの反省内容を把握した状態でMTGに参加することができる

オフラインでやる場合でも、自分の分は先んじて用意することは可能ですが、他のメンバーが書いた内容に目を通すことができるのはオンラインならではのメリットだなと思います。先に目を通すことができるため、各々が思っていることの「共有」自体にはあまり時間をかける必要がなくなり、「質問」や「議論」に時間を使うことができます。

MTG参加者がただ聞き手に回るだけではなく、付箋の整理などで全員でMTGをつくっていける

オフラインでやる場合は上記役割分担の「ホスト」に該当するような人が全体の進行などをしますが、他の人は付箋に課題を書き出したあとは聞き手にまわることが多いです。物理のホワイトボードだとどうしても複数人で触るには難しいのですが、オンラインだと複数人で同時に編集することが容易であるため、課題の列挙やグルーピングなどが(ホストに頼り切りになることなく)スムーズにできます。
また、各々がMTGに対して役割ができ、「全員でMTG」をすることができます。

過去のKPTAの確認がしやすい

現状の運用では、同一のMiroのボード上にKPTAのシートを適宜追加するようにしています。このことにより、以前のKPTAシートがすぐちかくにあり、新たにKPTAをするときも過去のものを確認しつつ実施することができます。

オンラインのデメリット

オンラインによる操作のしにくさや不慣れな場合に、リアルでやるときよりも時間がかかってしまう

オンラインKPTAを実践しはじめのときに顕著だったのですが、操作性に不慣れな中で、リアルのときと同じ運用をしてしまうと、時間がかかってしまうことがありました。ある程度オンライン用にやり方を変更(情報の「共有」にかける時間は極小化し、「議論」に時間を使うスタイル)をしてきてからはだいぶ完全されましたが、やはりオンラインの物理ホワイトボードと付箋での手軽さのノリとは勝手が違うなと思います

議論を深めたい場合、うまくホストがコントロールできないと沈黙が続いたり、誰かが一方的に意見を言ったりなど適切に議論ができないことがある。

これはKPTAに限らず、オンラインMTGの課題だと思います。KPTAの場合はactionを決める際に、tryが不足していたり、課題感が不明瞭だとメンバーの雰囲気がわかりにくければ更にactionに落とし込むのが難しいときがありました。運用やファシリテーションでうまく全員が意見を言い合えるようコントロールできればよいかと思います

最後に

オフラインにはオフラインの、オンラインにはオンラインの良さがそれぞれあるなと思います。対面でのMTGに慣れていた方はオンラインでのMTGでは難しさを感じることが多いかと思いますが、(自分も当初はKPTAをどうしようかと悩んでいました)Miroと組み合わせ、また、オンラインなりのやり方を模索したおかげで、今までより保存性・視認性に高いKPTAの運用ができるようになりました。
オンラインの良さを活かしてMTGができるとよいなと思います

ループ処理するなら forEach > for > while という順でmethodを検討すべき、と思っている理由

TL;DR

forEach などのarrayのインスタンスが持ってる「その配列の中身を操作する」メソッドの方が
無限ループ も起きないしいいよね、というところです。

はじめに

配列などの複数のデータに対して、何らかの処理をするとなった場合ループの処理を実装するかと思います。
その際に端的に言うとメソッドとして forEachforwhile あたりが選択肢になってくるかと思いますが、個人的にはforEach -> for -> while の順で使用するメソッドを検討したほうがいいと思ってます(forEachが使えるならforEachを使おう、使えないなら次にforが使えないか検討しよう、という意味です)

なぜ、この順番で検討したほうがいいかと思ってる理由を以下に記述してきます。
※一旦jsの話として書きますが、思想自体は他の言語でも共通だと思います。

ループ処理を使うときに意識したいこと

個人的に意識したいところとしては以下の2点です

無限ループ

意識したいこととして2点あげてますが、はっきりいってこれがメインの理由です。
警察につかまる騒動でも一時期話題になりましたが、ループでまわす処理が終わらずずっと続いてしまうあいつのことです。
クライアント側にしろサーバー側にしろメモリは食われて動作しなくなるし、100歩譲ってメモリが生きてても後続の処理は実行されなくなるので、絶対に避けたいところです。

デバッグのしやすさ

ループしたいデータの中身が絶妙にキレイではなく、特定のデータに対してバリデーションかけたりが必要だったりするパターンもあるかと思います。
その際に実行タイミングで確認したいとなったときに1件1件止めながらのチェックとかは、件数すくない場合はいいですけど、多くなるととてもじゃないけどそんなことはできません。
そのため確認がしやすい構造のほうがよいです。
※詳細は割愛します。

各methodの特徴

forEach

const sampleArray = [1, 2]
sampleArray.forEach((sample) => {
  console.log(sample)
})

jsで書くとなると上のようなかんじになります。

利点

確実に Array内の要素の個数 しか実行されません。 空の配列でも実行はされますが、エラーとかは履きません。 確実に無限ループを防げます。

またtypescript (× VSCode)の場合、

type SampleArrayType = {  // SampleArrayTypeという型の規定です
  id : number
  text : string
}

const sampleArray : SampleArrayType[] = [ // ※
  {
    id : 1,
    text : "Sample 1"
  },
  {
    id : 2,
    text : "Sample 2"
  },
]

sampleArray.forEach((sample) => {
  console.log(sample.hoge) // <- "hoge"なんていない、とEditor上で怒られる
})

// ※ ": SampleArrayType[]"の表記は はsampleArrayという変数は"SampleArrayType"という型の"配列"([])で変数定義します、という型定義です。
// そのため、
// {
//   id : "3",
//   text : "Sample 3",
//   name : "Lifebook"
// }
// とか突っ込むと「idがstringで定義されてるけど、SampleArrayTypeの型としてそれは駄目やで」と
// 「SampleArrayTypeの型にnameなんてプロパティ存在しないで」と怒られます

forEach内の sample の変数が型推論で自動的にSampleArrayTypeの型として認識され、エディター上でエラーを吐いてくれます。
実行時のエラーじゃなくて、実装時にわかってくれるのは修正コストが一番低いのでめちゃありがたいです。

欠点(?)

ループ数が確実にArrayの個数に依存するので、forとかよりは多少自由度はさがりますが、そこは実装次第な気がします。

for

const sampleArray = [1, 2]
for (let index = 0; index < sampleArray.length; index++) {
  console.log(sampleArray[index])
}

利点

上にも書いてますが、forEachよりは多少自由度はあるかなと思います。
スタートのindexを0ではない数字からスタートしたり、ループ数をindex < sampleArray.lengthではなく別の数字にしたい、などあればこちらをいじるといろいろできます。

欠点

ただし、個人的には上記をいじると無限ループのもとになりかねないと思っているので、それならforEach内で分岐書いたりしたほうがいいと思います
極端な話しですが、上の例でいうと let index = 3、 index > sampleArray.length と書いた瞬間に無限ループです。

const sampleArray = [1, 2]
for (let index = 3; index > sampleArray.length; index++) {
  console.log(sampleArray[index])
}

画面ロード時に必ず実行されるタイプの処理であればテストのタイミングで気づくかと思いますが、何らかの処理(特定のタイミングでボタンを押した際に実行など)をしたタイミングでループがまわるものとかは時折テスト漏れで本番時に発覚するなどありえるため、実行回数が必ず決まっているもののほうがよいなと思います

While

const sampleArray = [1, 2]
let count = 0
while( count <= sampleArray.length){
  console.log(sampleArray[count])
  count++
}

利点

正直上の例文ではwhileの必要性はまったくないですし、冗長になってますが、再帰的に何かを処理したり、ループしたい内容がループの処理をした結果増減する(ループする回数がループ前に確定していない)ものとかだとwhileを使わざるをえないかと思います

欠点

この3つのメソッドの中で一番取り扱いに注意が必要だと思っています。
上記forの話での無限ループの記述は若干冗談を交えているところはありますが、(とはいえ可能性は全然あると思ってます)
上のwhileの場合、 count++ の処理を消した瞬間に無限ループなので、本当に怖いと思ってます。

終わりに

ということでループ処理についてちょっとまとめてみました。
無限ループのくだりは初期実装時というよりも、とくに修正タイミングとかで如実になる内容かと思うので、メンテナンス性の高いコードを書くという点では意識するとよいのかな〜と思います。

IEでforEachが使えなかった(という誤解)

IEだと未だに使えないjsのmethod多いですよね・・・
(なぜまだ必死こいてIEのサポートをしなきゃいけないかなんて聞かないでください・・・)

結論

NodeListforEach をサポートしていない・・・

developer.mozilla.org

やってたこと

const lists = document.querySelectorAll('.list')
lists.forEach((li) => {
  // hogehoge
})
  • そもそも アロー関数 のタイミングで怒られる
  • function に書き換えても「forEachサポートしてないから!」と怒られる
  • Array.prototype.forEach を見にいって、「IEもサポートしてるじゃん!」と勘違いする

developer.mozilla.org - よくよく考えたら document.querySelectorAll って普通のArrayじゃないもの返してきてた気がする(そして前も似たことやってた気がする) <- イマココ

終わりに

IEつらい・・・

Nuxt × Firebaseの環境を作ったときにcore-jsまわりで怒られたこと

nuxt-firebase

nuxtとfirebaseを使って簡単なタイムラインぽいWebアプリを作ろうとした際に、buildしたタイミングでコケたという話です。
core jsが〜と怒涛のログが出てきました。。。

エラー時の状態

どうやって作ったか

npx create-nuxt-app hogehoge といったよくあるnuxtプロジェクトの作成コマンドで作りました。
オプションはちょいちょい入れていますが、それらは package.json 参照ということで。

nuxtのバージョンは 2.11.0 でした

package.json

...
"dependencies": {
    "firebase": "^7.8.0",
    "@nuxtjs/dotenv": "^1.4.1",
    "nuxt": "^2.0.0",
    "vuexfire": "^3.2.1"
  },
"devDependencies": {
    "@nuxtjs/eslint-config": "^1.0.1",
    "@nuxtjs/eslint-module": "^1.0.0",
    "@nuxtjs/vuetify": "^1.0.0",
    "@vue/test-utils": "^1.0.0-beta.27",
    "babel-eslint": "^10.0.1",
    "babel-jest": "^24.1.0",
    "eslint": "^6.1.0",
    "eslint-config-prettier": "^4.1.0",
    "eslint-plugin-nuxt": ">=0.4.2",
    "eslint-plugin-prettier": "^3.0.1",
    "jest": "^24.1.0",
    "prettier": "^1.16.4",
    "vue-jest": "^4.0.0-0"
  }

...

でたエラー

普通に yarn dev と打ち込んだら

 ERROR  Failed to compile with 34 errors

These dependencies were not found:

* core-js/modules/es6.array.find in ./.nuxt/client.js
* core-js/modules/es6.array.iterator in ./.nuxt/client.js
* core-js/modules/es6.date.to-string in ./.nuxt/utils.js, ./.nuxt/components/nuxt.js
* core-js/modules/es6.function.name in ./.nuxt/client.js
* core-js/modules/es6.object.assign in ./.nuxt/client.js
* core-js/modules/es6.object.keys in ./.nuxt/utils.js
* core-js/modules/es6.object.to-string in ./.nuxt/router.scrollBehavior.js, ./.nuxt/components/nuxt.js
* core-js/modules/es6.promise in ./.nuxt/client.js
* core-js/modules/es6.regexp.constructor in ./.nuxt/utils.js
* core-js/modules/es6.regexp.match in ./.nuxt/client.js
* core-js/modules/es6.regexp.replace in ./.nuxt/utils.js, ./.nuxt/components/nuxt.js
* core-js/modules/es6.regexp.search in ./.nuxt/utils.js
* core-js/modules/es6.regexp.split in ./.nuxt/utils.js, ./node_modules/babel-loader/lib??ref--2-0!./node_modules/vue-loader/lib??vue-loader-options!./.nuxt/components/nuxt-build-indicator.vue?vue&type=script&lang=js&
* core-js/modules/es6.regexp.to-string in ./.nuxt/utils.js, ./.nuxt/components/nuxt.js
* core-js/modules/es6.string.includes in ./.nuxt/client.js, ./.nuxt/components/nuxt-link.client.js
* core-js/modules/es6.string.iterator in ./.nuxt/client.js
* core-js/modules/es6.string.repeat in ./.nuxt/utils.js
* core-js/modules/es6.string.starts-with in ./.nuxt/utils.js
* core-js/modules/es6.symbol in ./.nuxt/index.js, ./.nuxt/components/nuxt-link.client.js
* core-js/modules/es7.array.includes in ./.nuxt/client.js, ./.nuxt/components/nuxt-link.client.js
* core-js/modules/es7.object.get-own-property-descriptors in ./.nuxt/utils.js
* core-js/modules/es7.promise.finally in ./.nuxt/client.js
* core-js/modules/es7.symbol.async-iterator in ./.nuxt/client.js, ./.nuxt/components/nuxt-link.client.js
* core-js/modules/web.dom.iterable in ./.nuxt/utils.js, ./.nuxt/components/nuxt-link.client.js

To install them, you can run: npm install --save core-js/modules/es6.array.find core-js/modules/es6.array.iterator core-js/modules/es6.date.to-string core-js/modules/es6.function.name core-js/modules/es6.object.assign core-js/modules/es6.object.keys core-js/modules/es6.object.to-string core-js/modules/es6.promise core-js/modules/es6.regexp.constructor core-js/modules/es6.regexp.match core-js/modules/es6.regexp.replace core-js/modules/es6.regexp.search core-js/modules/es6.regexp.split core-js/modules/es6.regexp.to-string core-js/modules/es6.string.includes core-js/modules/es6.string.iterator core-js/modules/es6.string.repeat core-js/modules/es6.string.starts-with core-js/modules/es6.symbol core-js/modules/es7.array.includes core-js/modules/es7.object.get-own-property-descriptors core-js/modules/es7.promise.finally core-js/modules/es7.symbol.async-iterator core-js/modules/web.dom.iterable

To install them, you can run: npm instal ... と言われたって「はいそうですが」とinstallはしないので回避策を調査。
とりあえず firebase のuninstallしたらまたちゃんと動いたので、 firebaseのインストールが起因してることはわかった。(firebaseが悪いとは言ってない)

参考 qiita.com

結論

一旦採用したもの

@firebase/app
@firebase/firestore
@firebase/auth

個別にインストールしたらエラーが出ずにbuildされました。

github.com

公式の情報によると

v2.6.0時で、 nuxt.config.js をいじってcore-jsの2系と3系を入れてbuildできるようにサポートしてるよ、とのこと。 nuxtjs.org

余談

firebaseが原因?

firebase が悪いのか、と言われたらそのへんは厳密にはわからないかんじですね。
どちらかというと nuxt と組み合わせるとコケてるよ、といった話が。。。

github.com

nuxt上でのissue

firebase をキーワードにしたissueはあがってなさそう・・・? github.com

core-js 3系のデフォルト対応

今回の件、わざわざconfigをいじらなきゃいけないというところもあって、本来ならnuxt側がそもそも対応してたほうがよいのでは?と思いつつ、v2.6.0以降のリリースノートを見てもcore-jsまわりの話はなさそう。。。
と、思ってたら3系にあげる動き自体はあるようです。 github.com

これが入ったらわざわざconfigいじらなくてもよくなるのだろうか・・・
今後のverupに期待。

「IT業界の病理学」を読んで

IT業界の病理学
IT業界の病理学

IT業界の病理学

完全にタイトルに惹かれて読みました。笑
各テーマ(ex: エンジニアリング、プロジェクトマネジメント)とかの解説書の一角に、「こういう問題が発生したら、こう対処したらいい」みたいな言説があったりするかもしれませんが、「IT業界」という大きな枠から「よくある問題とそれに対する解消法」といった観点で書かれている本は珍しく、読んでいておもしろかったです。

以下は読んで特に興味深かった内容です。

本からの抜粋

アジャイルのチェックリスト

チェック項目 判定
ユーザーは協力的か No -> アジャイル不可
開発メンバーのスキルは十分か No -> 不可
サービス開始日は決められており、延長不可か Yes -> 不可
ミッションクリティカルか Yes -> 重大な被害が出ることがある
ユーザー、メンバーは同じ場所で作業できるか No -> 不可
厳密なタイムマネジメントで管理可能か No -> 不可
開発のあと、別のベンダーが運用するか Yes -> XP不可

このあたりの駄目なポイントは覚えておきたい。
そもそも導入可能か、という判断基準であるところはもちろん、
ものによっては時間経過によって変化し、駄目なパターンになってしまっていることもあるので、忘れずにいたい。

レビューの頻度ややり方など

重大欠陥を効率よく検出するレビュー手法の提案と 有効性の実験報告 https://www.juse.or.jp/sqip/workshop/report/attachs/2012/SQiP3-riku.pdf

https://www.juse.jp/sqip/symposium/archive/2013/day1/files/happyou_shiryou_A1-1.pdf

なんとなく「あまりサイズ感が大きくなく」「できるだけ早いタイミングで」「複数回やる」ほうがレビューはいいのかなと思っていたが、体系的にまとまってるものを見たことがなかったので、ちゃんと読んで説明できるようにしたい

バグレポートの改善に向けた 問題事例の調査とアンチパターン作成

https://www.juse.jp/sqip/symposium/archive/2014/day2/files/happyou_C3-3.pdf

こちらも同様。ちゃんと把握しておきたい。

DevOpsの体制

解決案としては「対等の連携ではなく、上下をつける」という方法が有効です。
・開発を上にして、運用部門を管理・コントロールさせる
・運用部門を上にして、開発は運用サイクルの一環という位置づけにする

DevOps内で開発と運用は対等な関係をイメージしていたが、たしかに対等だと対立が起きてうまく進まないことがあるのだなと改めて理解した。

開発を上にしちゃうとちょっと運用側がないがしろ、というか実装やリリースを優先されてしまいそうなイメージもあるが、運用側が強くなると、開発側が不満を憶えそうな気もする。。。
もちろんちゃんと歩み寄れ、という話ではあるが、どちらの体制がよいのかとても興味がある

高齢化するばかりの運用現場

これは単純に読んだ感想であるが、運用現場にも高齢化の波が押し寄せているのだなと思った。
過去の慣習がそのまま残り、職人芸化した運用手法や、それを変える風潮のなさ。
どんな場でも、どんどん日々勉強し、改善していくという環境を作っていく必要があるのだなと考えた。

マネジメント/リーダーシップ理論

以下あとで確認したい

レヴィンのリーダーシップ類型
ゴールマンの6つのスタイル
三隅のPM理論

納期の考え方

日本の納期はピンポイントの日付だが、本来は○○日~☓☓日と幅をもたせるべき
デコルマら「熊とワルツを」

冷静に考えると確かにピンポイントで決まってる必要はないなと思った。
もちろん何らかの公開日とかは定まってる必要はあると思うが、納期自体は幅があってもよいと思った。
大きなプロジェクトとなるとさらに不確定要素が多くなるため、柔軟性が求められる。

エンジニアをレベルアップさせる「ファシリテーション入門」

さすがWeb上になんでもある時代・・・
勉強します
https://gihyo.jp/lifestyle/serial/01/facilitation

全体の雑感

当たり前ではあるが、各テーマに対して深堀りした研究や本などもあって、あんまりそのへん勉強せず、過去の知識だけでなんとかしようとしているなと改めて思った。
本の中で記載のあった引用元の本を起点にもう少し勉強してみたいなと思った。 特にレビューまわりとか・・・

「問題解決」を読んで

問題解決
問題解決

論理的にモノゴトを考えるときに、「なんとなく」目的 -> 手段を考えたり、MECEになってるかとかを考えているが、 果たしてその考え方や想定が適切かどうか気になったので、読んでみた

本からの抜粋

問題解決の3ステップ

Where : 問題がどこにあるのか
Why : その問題の原因はなにか
How : ではどうすればよいか

基本中の基本、というところであるが、自分が説明するときにWhereとWhyが割とセットにしてしゃべったり思考したりしてしまってる気がした。
結果としてHowはそこそこ的を得たものにはなっていると思うが、説明するときとかにどこの話をしているのか曖昧になると、聞き手にとっては伝わりにくくなってしまう可能性があるなと思った。
このあたりは意識したい。

問題特定のポイント

1 問題の全体を正しく捉える
2 問題を適切に絞り込む
3 論拠をつけて問題を特定する

1については、一言に「体調が悪い」といっても「頭痛」や「腹痛」であったりと発生場所が様々だったりするので、ターゲットにした全体(この例でいう「体調が悪い」)から全容を正しく捉えるようにする必要がある。
2については、「腹痛」といったときに、お腹のどこが痛いのか、どう痛いのかなど詳細を特定する必要があるということ。
3については、その腹痛という症状の観測が適切かを判断するものになる。触診して確かに痛いかどうかなど検査する必要があるということ。

全容把握や絞り込みが適切かどうかが結構怪しいなと思う。
結構気を抜くと過去の経験則から「こんなかんじだろう」であったり「ここが怪しい」とサクッと答えを出してしまっていることがある気がする。
だからこそ「全体を正しく捉える」が大事になってくるんだろうな・・・
もしくはきちんとどこまでがスコープかを提示する必要がありそう

分解と深堀りの違い

- 分解 深堀り
目的 Where : 問題の所在地を突き止める Why : 原因を突きとめる
意味 あるものを単に分ける : MECE あるものの「因果」「理由」を考える

これも多分意識しないと、分解したいのか深堀りしたいのかが曖昧になる気がする。特に気がついたら深堀りしがち。。

「4W」で多くの切り口を洗い出す

When : いつ起きた問題か
Where : どこで起きた問題か
Who : 誰が起こした問題か
What : 何についての問題か

上記の内容を見てまず思ったこととしては、この観点を意識できていないことが多く、課題点をブレストして出し切るのが弱かったんじゃないかと思った。
この項目を意識すればもう少し網羅的に課題を考える気がする。
※ロジックツリーをうまく使おう

「論拠」と「原因」違い

論拠 : 問題が問題である理由 原因 : 問題が発生してしまう理由

「なぜ旅行に出かけるのですか」
-> ①リフレッシュしたいから
-> ②家族に言われたから
①は目的(for)、②は理由(because)
ここが曖昧になりがち

問題が問題である理由はきちんと把握した上で合意形成を行う必要がある。

「なぜなぜ分析」の8つのポイント

<深く>掘り下げる
①Where で絞り混んだ問題から掘り下げる
②「なぜ」を繰り返す
③論理の飛躍に気をつける
④打ち止めになるまで彫り続ける
<広く>掘り下げる
⑤もれなく幅広く可能性を考える
<正しく>掘り下げる
⑥事実で確認する
⑦正しい日本語で掘り下げる
⑧「自分を主語」として掘り下げる

もちろんどれも大切だと思うが、個人的に興味深いところは⑦である。
誰かに説明するときには言葉のチョイスにすごく悩む。
誤解を与えず、極力同じ認識になるように言葉を選ばなければ、間違ってモノゴトが進んでしまう可能性がある。

あるべき姿設定の流れ

視点を定める

①大目的 : 何をやりたい will
②内部環境 : 何ができる can
③外部環境 : 何が必要 must

目的を具体化する
  • 誰が
  • 何を
  • どうする
目的を指標化する

KGI

個人的に視点を定める際にはまず圧倒的にwillで「そもそもどうあるのが理想か」みたいなのを叩きだしたあとにmust -> canあたりで現実的な答えを出してくのがいいんじゃないかと思ってる。

「課題」ということば

「課題」という言葉は「問題」「原因」「対策」という意味で用いてもさほど違和感がないところが厄介である。
「問題」と「原因」という言葉も曖昧になりがちなので、より分かりづらい表現な気がした・・・
言葉は正しく使いたい。

このあたりは意識して問題を分析して、解決できるようにしたい

VSCodeの正規表現を使って一括で置換した話

特定のファイル名をjsでstringとして扱えるようにしたかったのです

確かファイル名がcsvにまとまっていて、その中身は

1.pdf
2.pdf
3.pdf
...

といったかんじで並んでました。
このファイル名をstringとして配列に列挙したかったときの対処法です。

やったこと

replace

.+ で1文字以上の文字列として認識されるとのこと。
() でくくって置き換えの欄に $1 とか書くと、その括弧を参照できるそうです。

以下のリンク先にいろいろ載っていました。 qiita.com

もっと使いこなしたいなあ・・・