y_megane.log

日々の勉強や改善ネタの備忘。

メルカリのエンジニア向け日英ボキャブラリーリスト[結合・加工]

このテキストは以下の作品を一部改変して利用しています。

メルカリ エンジニア向け日英ボキャブラリーリスト / CC BY 4.0

メルカリが公開しているエンジニア向け日英ボキャブラリーリストのCSVを結合して少し加工したもの。

  • CSVからマークダウンに変換する際に使いづらかったセル内改行を含む行を変更・削除
  • ふりがな付きの日本語列を削除

github.com

日本語 English 例文 English
チケットを取る take a ticket すでに3つチケットを取っているので、今週は取れません。 I can't take a ticket this week because I have already taken 3.
すでに adv. already ー ー
プルリクを出す make/create a pull request 昨日、プルリクを出しました。 I made a pull request yesterday.
開発する v. develop 今、Xを開発しています。 I'm developing X now.
修正する v. correct, revise 修正は今日中に終わると思います。 I think I'll revise it by the end of today.
マージする v. merge XをYにマージしました。 I merged X with Y.
進める v. [*transitive verb 他動詞] このチケットは、Kenさんと一緒に進めています。 I'm working on this ticket with Ken.
[システムが]動く v. work, operate システムがちゃんと動いてないことがわかった。 I realized that the system was not working properly.
ちゃんと adv. properly ー ー
間に合う be in time, make a deadline 来週のリリースには間に合いそうです。 It seems that we'll make the release next week.
状態 n. status QAしてもらえる状態のものがありますか。 Is there anything ready for QA?
課題 n. issue 課題が見つかった。 We found some issues.
要件 n. requirements 要件は明日、テックリード(TL)に共有します。 I'll share requirements with TLs tomorrow.
仕様 n. specification document まだ仕様が決まってない。 The specs haven't been decided yet.
固まる (*自動詞) v. take shape (*intransitive verb) まだ仕様が固まっていません。 The specs haven't taken shape yet.
支障 n. obstacle, hitch それによって(プロジェクトに)支障が出ています。 It interferes with it (our project).
影響 n. effect これは、お客様に影響があるインシデントじゃないです。 This is not an incident that has an effect on customers.
原因 n. cause これから原因を調べます。 I will look into the causes now.
相談する v. consult マネージャーに相談する。 I'll consult with my manager.
困る v. be in trouble 何か困ってることがありますか。 Do you have any difficulties?
[人/チームと]連携する v. work together, align with これはteam Bと連携してやっていきます。 We are aligned with team B to do this (task).
sync(シンク)する v. sync あとでテックリード(TL)とsyncしておきます。 I will sync with TL later.
設定する v. set 目標を設定する。 I'll set goals / I am setting goals.
反映する v. reflect 先週修正したけど、Jiraに反映されてません。 I edited it last week, but it isn't reflected on Jira (yet).
効率 n. efficiency そのやり方は、効率がよさそう。 That method seems efficient.
詳細 n. details 詳細はdocsを見てください。 Please check the docs for details.
詳しく adv. in detail どんなインシデントだったか詳しく教えてもらえますか。 Could you tell me about the incident in detail?
方針 n. policy まだ会社の方針が決まってない。 The company policy has not been decided yet.
補足 n. supplementary, additional ケンさんの話への補足なんですけど、、、 Let me add something to what Ken said,
効果的 ナadj. effective このやり方が効果的だと思います。 I think this way is effective.
達成する v. achieve 先週、OKRを達成しました。 We achieved our OKR last week.
報告する v. report プロジェクトについて報告します。 I will report on the project.
議論する v. discuss それはEMが議論しているところです。 EMs are discussing it now.
不具合 n. defect, bug ちょっと不具合があるので、今日中に直します。 There are some defects, so I'll fix it by the end of the day.
順調 n/ナadj. smooth これは、順調に進んでいます。 This is working well.
量 n. amount タスクの量が多すぎます。 There are too many tasks.
具体的 ナadj. concrete 具体的にどんなインシデントでしたか。 Could you expain the incident more concretely?
状況 n. situation QAのリソースが厳しい状況です。 We're in a tough situation in terms of QA resources.
現状 n. present situation 現状を説明します。 I'll explain about the present situation.
進捗確認 n. progress check まずは、進捗確認をしましょう。 Let's start with a progress check.
優先順位 n. priority 優先順位を決めたほうがいいと思います。 I think we should decide the priority.
残る v. remain 残っているチケットはありますか。 Are there any tickets left?
着手する v. initiate それって、もう着手してますか？ Have you already initiated it?
調整する v. adjust 最近忙しすぎるので、タスクの量を調整したほうがいいいと思っています。 I'm thinking I should adjust my workload because I've been too busy these days.
認識 n. recognition, understanding 全員で認識を合わせたいです。 I'd like to make sure everyone's on the same page.
ずれる v. be out of alignment 認識がずれてないか確認したいです。 I'd like to make sure there's no misunderstanding between us.
変更する v. change スケジュールが変更しています。 The schedule has been changed.
開始する v. start 来週からキャンペーンが開始します。 We will start a campaign next week.
前倒しする v. reschedule to an earlier time このプロジェクトは、前倒しで進めましょう Let's move up this project. (Ex: from next qtr to this qtr)
以降 n. from コードレビューは、来週以降の予定です We're planning to do a code review from next week.
締切 n. deadline, due date 締切はいつですか。 When is the due date?
先に adv. ahead 他のミーティングがあって、ちょっと遅れるので、先に始めてください。 Please go ahead with the meeting without me as I'm running late due to another meeting.
事前に adv. in advance 話したいトピックは、事前に書いておいてください。 Please write the topics you want to talk about in advance.
早めに adv. early これは来週リリースなので、早めにやった方がいいと思います。 I think we should work on this earlier because we will release it next week.
一旦 adv. temporarily, for a moment 一旦、このやり方で進めましょう。 Let's move forward in this way, temporarily.
環境 n. environment すべてテスト環境に反映しました。 Everything has been reflected in the test environment.
業務 n. business, task ネット環境が悪くて、業務に支障が出ています。 The internet environment (ex: wifi) here is bad, which is hindering our business.
機能 n. feature, function どんな機能があったら、もっとお客様のためになると思う? What features do you think would be more beneficial for our customers?
運用 n. operation これは、ちゃんと運用ができていません。 That operation is not working properly.
観点 n. point of view QAの観点からすると、このタスクの優先順位は低いです。 From QA's point of view, the priority of this task is low.
重要 n./ na-adj. important どれが一番重要な問題ですか。 Which one is the most important issue?
画面共有 n. screen share 画面共有してもらえる？ Can you share your screen?
デプロイ n. deployment 昨日、デプロイ、完了しました。 I completed the deployment yesterday.
動作確認 n. checking or testing operation 動作確認はいつしますか。 When are you going to test the operation?
実装する v. implement これは来週実装します We're going to implement this next week.
安定している v. be stable (それは、)バ グを直したので、今は安定しています。 It's stable now since I've resolved the bugs.
発生する v. occur オンコールのときに、問題が発生しました。 An issue occurred when I was on call.
対応する v. deal with, handle これは、他のチームが対応してくれるので、うちのチームはしなくていいです。 For this issue, our team doesn't need to deal with it since another team will.
削除する v. delete Jiraに同じ内容のチケットが２つあるので、こっちは削除しますね。 I'll delete this because there are two tickets with the same content on Jira.
保存する v. save すみません、修正したあと、保存し忘れました。 Sorry, I forgot to save it after I fixed it.
検討する v. consider, think about ロールバックのやり方は今検討中です。 We're now thinking about how to roll it back.
関係する v. be related to このチケットに関係してる人って、誰だっけ？ Who's the person related to this ticket?
継続する v. continue weekly sync ミーティングは、今後も継続していきましょう。 Let's continue the weekly sync meetings as we've been doing.
測る v. measure この目標を達成したかどうかをどうやって測りますか。 How do you measure if you've achieved your goal or not?
検索する v. search この画面は検索しにくいですね。 This screen layout makes it difficult to use the search function.
時期 n. period, season リリースの時期は、調整中です。 The release period is being adjusted.
未確定 n. / na-adj. undecided スケジュールは未確定です。 The schedule hasn't been decided yet.
不足 n. shortage, lack of チーム内のコミュニケーション不足が、問題になっています。 The lack of communication among team members is becoming a problem.
余裕 n. time / money / space (to spare), have room in someone's mind 今月は、リリースが多くて、みんな余裕があんまりない。 We don't have time to spare since we have a lot of releases this month.
正常 n. / na-adj. normally, normal システムが正常に動いてないので、今日中に鈴木さんが確認する予定になっています。 Since the system isn't working normally, I'm going to check with Suzuki-san today.
最優先 n. top priority これはリリースが来週なので、最優先で進めたほうがいいと思います。 I think it's better to make this the top priority because the release is next week.
直接 adv. directly 困ったことがあったら、直接マネージャーに相談してください。 Please talk to your manager directly if you have any problems.
途中 n. in the middle of, halfway 今、このチケットをやってる途中ですか。 Are you in the middle of working on this ticket?
処理 n. process 返金処理は、昨日、完了しました。 I completed the refund process yesterday.
集中する v. 1. concentrate (focus on) サイトへのアクセスは、どの時間帯が一番集中しますか。 What time is access to the site most concentrated?
遅延する v. delay 昨日の夜、システムに遅延が発生しました。 A system delay happened last night.
作業をする v. work 明日、バージョンアップする作業をします。 I'll work on updating this tomorrow.
担当する v. be responsible for, be in charge of この業務は、どこのチームが担当してるか知ってる？ Do you know which team is responsible for this work?
追加する v. add 話したいトピックがある人は、議事録に追加しておいてくださいね。 Please add the topics you want to talk about to the notes.
提案する v. propose, suggest 何か提案がある人は、明日までに私にDMしてください。 If you want to suggest anything, please DM me by tomorrow.
導入する v. implement 新しいサービスを導入する時期はまだ決まってません。 The timing of implementing the new service hasn't been decided yet.
落ちる v. drop, go down 夜中にアクセスが集中して、サービスが一時的に落ちました。 The service went down temporarily late last night because of a spike in access.
移動する v. move, shift 今Q対応しないチケットは、次のSprintに移動しておきます。 Tickets that we won't deal with this Q will be moved to the next sprint.
被る v. have a schedule conflict (*casual) すみません、他のミーティングと被ってるので、明日のスタンドアップミーティングに参加できません。 Sorry, I can't join tomorrow's stand up because of a schedule conflict.
ミーティングを抜ける v. leave the meeting すみません、次のミーティングがあるので、先に抜けますね。 Sorry, I need to leave now because I have another meeting.
けっこう adv. quite 来月はけっこう忙しくなると思うので、みなさん、今のうちにゆっくり休んでくださいね。 Please take it easy now since we're going to be quite busy next month.
ギリギリ adv. at the last moment, barely このチケットは、ギリギリになりそうですが、締切までに終わると思います。 It'll be really tight, but I think I'll just barely get the ticket done by the deadline.
基本的に adv. basically 基本的に、来Qのみなさんのアサインは、今Qと変更ありません。 Basically, everyone's assignments won't change much from this Q to next Q.
ちなみに adv. also, in addition ちなみに、いつぐらいまでにリリースの時期が決まるか、わかりますか。 Also, do you know when the release period will be decided? Approximately?
視点 n. point of view お客様視点で考えてみて。 Think about it from the customer's point of view.
雑談 n. small talk, chat まだ10分ぐらいあるので、ちょっと雑談でもしましょうか。 We still have about 10 minutes left, shall we just chat?
段階 n. phase 今は、テストの準備をしている段階です。 I'm in the preparation phase of the test now.
既存 n. existing 既存のソースを見て、考えてみます。 I'll check the existing sources and then think about it.
事例 n. case 先週、それに似た事例がありました。 There was a similar case last week.
品質 n. quality リリースを早めると、QAの品質を保つのは難しくなると思います。 I think it'll be difficult to maintain the QA quality if we move the release date up.
処理 n. processing 返金処理は、いつ完了しそうですか。 When do you think we'll finish processing the refund?
障害 n. fault, system error 最近、障害が多く発生している。 A lot of system errors have been happening these days.
クリティカル n-adj. critical, specially important 今のところ、クリティカルな障害は起きてません。 There are no critical failures yet.
挙動 n. (system) behavior, acting ちょっと待って、Chromeの挙動がおかしい。 Hold on, Chrome is acting weird.
やつ n. thing ※casual 来週QAする予定のやつ、ある？ Is there something you plan to do QA for next week?
作成する v. make (document or plan) リリースまでのスケジュールを作成したので、まだ見てない人は、今日中に確認してください I've made a schedule for the next release, so please check it by the end of today if you haven't.
設計する v. plan, design, layout ABテストを設計するときの注意点については、ここを読んどいてください。 Please check here for the important points about planning AB tests.
展開する v. expand, be open to この資料は、全メンバーに展開されています This document is now open to everyone.
(内容を)詰める v. decide details この件、もう少し詰めた方がいいですね。 We should think about this more in order to decide the details.
任せる v. delegate, leave something with someone このプロジェクトは、佐藤さんに任せました I've delegated this project to Sato-san.
見積もる v. estimate 見積もると、だいたいトータルで2ヶ月かかります。 I estimate it will take about 2 months in total
紐づく v. link この情報は、お客様IDに紐づいています This information is linked to customer ID.
感じ n. like [something] こんな感じです。 It's like this.
以外 n. besides, except ここに書いてあるトピック以外に何か話したいことありますか。 Is there anything else you want to talk about besides the topics written here?
同時に adv. at the same time, simultaneously 同時に担当できるプロジェクトの数には限界があります There's a limit to the number of projects we can handle at the same time.
結局 adv. after all, in the end これを解決しておかないと、結局、リリース直前に問題が出てくる。 If we don't solve this problem, in the end it'll happen just before the release.
ほぼ adv. mostly このチケットはほぼ終わりました I've mostly finished this ticket.
そもそも adv. in the first place そもそも、このミーティングの目的はなんでしたっけ？ What was the point of this meeting in the first place?
どんどん adv. one after the other (usually quickly) どんどん意見を言ってくださいね Let's all share our opinions one after the other.
〜側 n. side これはQA側で対応します OK, the QA side will deal with this.

ターミナルでSSH接続先を補完させる

ターミナルでSSH接続先を補完させる。

iterm（に限らず）[SSH]の接続先をタブキーで保管できるようにする。 bash-completionを使う。

# macの場合
brew install bash-competion

.bashrcに記述を追加

if [ -f `brew --prefix`/etc/bash_completion ]; then
        . `brew --prefix`/etc/bash_completion
fi

ssh {tab} と入力して補完されれば成功。
~/.ssh/kwnon_hosts のホスト名が候補に出るらしい。

参考

ふりかえりに関する用語・略語のまとめ

カイゼン アジャイル

新人教育のふりかえりをどう進めようか考える過程で復習・調査したことばのまとめ。
フレームワーク、指標、etc

網羅的なリストではなく、私がなにかの機会に思い出したり聞いたりしてメモに残そうと思ったもの。
きまぐれで更新。
※主にふりかえりam に影響されると更新

参考

フレームワーク

DPA : Design the Partnership Alliance

ふりかえりに限らず、場の雰囲気を決めるための活動。
ふりかえり時に提示するグランドルールの元にする、アイスブレイクとして使う等。

以下の5つの質問から3つ程度を選び全員で答える、それをふりかえりの指標とする。

  • どんな雰囲気を作り出したいか？
  • その雰囲気を作りだすためにどんなことをしますか？
  • 困難なときお互いにどのようにありたいか？
  • この関係にどのようなものが持ち込まれると、さらに豊かになるか？
  • あなたは個人として、この関係にどんな貢献をしますか？

ふりかえりのアクティビティ紹介：DPA - Qiita
ふりかえりam - ep.1

KPT

  • Keep: 良かったこと（続けること）
  • Problem: 悪かったこと
  • Try: 取り組みたいこと（Keepの強化・Problemの解消）

上記のカテゴリごとに5分〜10分程度で付箋に書き出して共有しながら進めていく。
後述する指標に基づいて具体的で達成基準のある改善案（Try)を生み出すことが重要。

KPTA（Action）として、次に取り組む具体的なアクションを作って担当割するところまでやるパターンもあるらしい。

YWT

  • やった
  • わかった
  • 次にやる

期間中にあったことを思い出す、成長したことを確認する、次に学ぶことを探す。 成長、学習にフォーカスしたポジティブな性格が強いフレームワーク。 新人研修など教育的な面が強い状況で使いやすそう。

YWTという振り返り手法について | ナカシマガジン

FDL

  • Fun: 楽しかったこと
  • Done: 達成したこと
  • Learn: 学んだこと

期間内にやったことを思い出しながら上記3カテゴリのベン図中に配置していく。
楽しかった＆達成した、学んだけど達成してない、学んだ＆達成＆楽しかった、など。
YWT以上に学習やモチベーション向上にフォーカスしたフレームワークという認識。

仕事に対して楽しみや学びを喜べる程度の意識・文化のチームでないと機能しなそう。 あるいは研修のグループワークなどカジュアルな活動のふりかえりとして導入するとハードルが下がりそう。

ファン・ダン・ラーン(FDL)ふりかえりボード - Qiita

Timeline

期間内に起こった「出来事」とそのときの「感情」をセットにして書き出していく手法。
KPTやYWTは課題解決や習慣の強化のための手法だが、Timelineは記憶の想起・共有のための手法。

まずは個人で出来事と感情を書き出していき、その後チームで共有する。 ポジティブな感情とネガティブな感情を表すために2色の付箋を使うとよい。 個人で出来事を思い出す際、時系列順に期間の最初から思い出す必要はなく思い出したものか次へ次へと連想していけばよい。 必然的に最近の出来事をまず思い出すため、連想していくと自然と新しいできごとから古いできごと、と並んでいく。

ふりかえりのアクティビティ紹介：Timeline - Qiita
ふりかえりam - ep.2

指標・その他

SMART

目標設定の指標。
ふりかえりの文脈だと、KPTなどから次のアクションを考える際に実現可能なアクションを考えるためのポイント。

  • Specific（具体的に）
  • Measurable（測定可能な）
  • Achievable（達成可能な）
  • Related（経営目標に関連した）
  • Time-bound（時間制約がある）

目標設定の5つのポイント「SMART」とは？ | GLOBIS 知見録

MORS

ふりかえりの文脈ではないが、以前読んだ本に似たような指標があった。
なにかを教えるときは人そのものではなく行動に着目すべきという内容で、「行動」の指標として挙げられていたもの。

  • Measurable (計測できる)
  • Observable (観察できる)
  • Reliable (信頼できる)
  • Specific (明確化されている)

行動科学を使ってできる人が育つ! 教える技術 | 石田 淳 |本 | 通販 | Amazon

Developer Summit 2020 メモ

勉強会

視聴したセッションのメモ。ボリューム満点すぎて全然書けてないが、備忘として。

A-1 その後のソフトウェア・ファースト

及川 卓也(Tably)

人と技術、組織が鍵。その育成を支援している。
ソフトウェアファーストはソフトウェアが一番偉いという意図ではなく、 ソフトウェアによってスケールすることを最初から認識して、戦略として考える事が重要。

SIer

Sier自社のメリットだけでなく顧客の利益最大化を目指してほしい。 日本のIT他国に対して遅れている。顧客の国内競争だけ見ていては不足。 海外の競合まで見て世界レベルの物作りを志してほしい。

世界のライバルに勝つ、でもまだ視座が低いのでは？
コロナウィルスなど世界が抱えている課題の解決を目指してほしい。

自社が儲かる<顧客が儲かる<日本が儲かる<世界が儲かる
顧客や国内だけを食っていると顧客や国内の縮小によって自社の収入源も失われていく。

ソフトウェアとは？

米国：ビジネス…MSなどをソフトで成功した企業がある 欧州：科学…標準化などアカデミック 日本：製造…工場による大量生産のイメージ

リモートワーク

対面からオンラインになって情報が欠落しないわけがない。
ソフトウェア・ファーストの時点では否定的。
子育てや体調面をカバーする福利厚生としてのリモートは必須。
そうでない場合、拠点間の情報格差を埋めるコストが生じる。リモートが本当に最適な方法か？

リモートワークで顕在化した課題。ハンコなど。見えるようになったのはいいこと。
実は不要だったものが見えるようになった。

C-2 心理的安全ジャーニー ～Slackで安全を実装する5つの手法～

片岡 俊行(ゆめみ)

心理的安全ジャーニーSlackでの５つの実装方法｜Ray Kataoka｜note

心理的安全性

無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だという安心。
くつろげる状態ではなく安全な状態。工事現場の「安全」のイメージ。

新しいことに挑戦するには協力が必要。
心理的安全性が求められるのは挑戦の状況。

無知・無能：催促・・・新しいことへの挑戦者
批判・横槍：協力・・・挑戦者を助ける者

通常モードは？
必要なのは信頼。
催促に対して善意から協力してくれているという信頼。

信頼を得るためには親和が必要。
利他自損。見返りを求めず相手のために労力を払ってくれる。

親和を得るには催促・協力が必要。機会がないと深まらない。
そこで関係性を深めるために感謝・賛成を示して相手を認める。これを小さく日々積み重ねる。

心理的安全ある・ない問題の要因。
クリティカルシンキング不足、アサーションの有無、態度。
個人スキルの問題であり訓練して鍛えられる。

実装方法(ゆめみのSlack事例)

ルール
ルールとペナルティの明確化。
イエローカードを2枚受けると一部の権限を失う。

砂場
ゆめみでは全メンバーが専用チャンネルをもつ。Timesと近いが異なる。否定感情を吐露するチャンネル。 雑談チャンネルがあるので日常の出来事プライベートの開示できているが、感情の開示はなかなかできないので、それを促すチャンネル。

補助
AMA（Ask Me Anything) Slack社が実施している施策。
MBWA（Management by walking around) マネージャが話しかけて回る施策。

B-3 現役開発者が語るSalesforceテクノロジーとデジタル・トランスフォーメーション

田中 奈穂子(freee)
田中 宏樹/神田 貴博/林 良行

B-4 フルリモートで事業にコミットするエンジニア組織とは

民輪 一博(K.S.ロジャース)

リモートワークは向く人、向かない人はいる。
ルールを明文化することが重要。全体が見えるReadme。
全体で使うツールは統一する。

B-8 リモートワーク×Employee Experienceでつくる ～with コロナ時代の「Work fun! Management」とは～

新村 北斗(Works Human Intelligence)

【デブサミ】リモートワーク × Employee Experience でつくる～with コロナ時代の「Work fun! Management」とは～ - Google スライド

（今までの）目標設定、フィードバック、評価…
これまでは顔色、過ごし方など会って見て分かる情報があったが、在宅によって得られなくなった。

リモートワークで対面コミュニケーションがなくなり「様子を見る」ということができなくなっている。 行動や評価が明確になるよう今までより具体的な目標設定が必要。

Work

この在宅期間にどう目標設定するか？

職務特性 心理状態 アプローチ
技能多様性、タスク完結性、タスク重要性 上司と腹落ちする目標を決める
自律性 自分で決める
フィードバック 組織として与える

Fun

なぜ目標設定するのか？
現状を変えたい⇛やりたい、やならなければならない、やりたい
【やりたい】状態にしたい。

Management

目標の特性
創出・開発
向上・強化
改善・解消
維持・継続

主題：簡潔な題名
副題：なぜしたいか、誰をどんな状態にしたいか
アクションプラン：いつまでに、何をするのか最低3つ、できれな5つ以上書く
達成の定義：

運用五箇条

  • 目標設定は時間がかかるものである
  • 目標設定はいつでも追加・修正してよい
  • 達成できたら素晴らしい・できなかったら分析する
  • 進捗管理をするのではなく、障害を取り除いてあげる
  • 節目でFBを得られる機会を必ず設ける

A-9 プロダクト作りのトランスフォーメーション

市谷 聡啓(レッドジャーニー)/粕谷 大輔(はてな)/門脇 恒平(プレイド)

在宅勤務でパフォーマンスが低下していると仮設を立てて計測してみた。
計測が目的であり良し悪しを図ってはいけない。
命を守るための在宅勤務なので、結果を受けて改善していくことが重要。

計測方法：プルリク消化数
3ヶ月計測した結果、個人差はあるがチームとしては影響していなかった。

WorkingAgreementを作った。

  • 必須な会議体
  • レビューフロー
  • リリース当番など

スプリントに合わせて見直していく。
在宅勤務によって裁量が増えたが、チームとしててのイベント参加など強制力のある一定のルールは必要。 またルールが明確な方が基準がある分新しいことにもチャレンジしやすい。

伝統的な単体テストと一般的な単体テストの違い

SIer, メーカー, IT子会社などトラディショナルなシステム開発現場における「単体テスト」は正しい(？)意味での単体テストと違う意味で使われていることが多い。
そんな現場でもCI/CDとか自動テストとか頑張っていこうね、という空気はあったりなかったりするが、そもそも単体テストの概念が違うのでテストの粒度とかテストコードとか、会話が噛み合わない。

そんなトラディショナルな現場でテストコード書いていくには、言葉を正しく理解して根本的なところから攻めていかない何も始まらないよね、というポエム。

トラディショナルな手法を否定するとかこうするべき、という話はとくになく単にこういう齟齬がありますよ、というお話。

言葉の意味としての単体テスト

単体テスト - Wikipedia

コンピュータプログラミングにおいて単体テスト（たんたいテスト）あるいはユニットテスト（英語: Unit test）とは、ソースコードの個々のユニット、すなわち、1つ以上のコンピュータプログラムモジュールが使用に適しているかどうかを決定するために、関連する制御データ、使用手順、操作手順とともにテストする手法である。

テストの粒度に関して同じくWikipediaより

手続き型プログラミングでは、ユニットは、モジュール全体のこともあるが、より一般的には、個々の関数や手続きである。オブジェクト指向プログラミングでは、ユニットは、クラスなどのインタフェース全体だが、個々のメソッドであることもある。

テスト技術者資格制度のシラバスでも同じように書いてある。
JSTQB-SyllabusFoundation_Version2018.J03

テスト対象
コンポーネントテストの典型的なテスト対象の例：
• コンポーネント、ユニット、またはモジュール
• コードとデータ構造
• クラス
• データベースモジュール

トラディショナルな単体テスト

トラディショナルな文脈での単体テストはクラスやメソッドというユニット単位ではなく、「単機能」を指すことが多い。

SierやメーカーITの開発現場では「単体テスト仕様書」というものがあり、データのパターンや画面入力のパターンがケースとして羅列されている。
この「単体テスト」仕様書は基本的に機能単位で作られる。
もっと具体的にいうと、画面単位やバッチ単位の「単体テスト」仕様書となる。
単体テストを実施する際は、アプリは開発サーバーにデプロイされ開発機DBに接続しており、開発者はブラウザからアクセスしてテストする。
で、画面をスクショとってExcelに貼るわけだが、それはまた別のお話…

以下のサイトがまさにそういう表現になっていた。
単体テスト・結合テスト・総合テストの違い、観点や注意点を簡単に説明する | 若手プロマネの羅針盤

「関数やメソッド単位にロジックの不具合を検出する」と定義されるのが一般的だが、どの単位で単位テストを実施するのかは、プロジェクト毎に定義すべきである。 つまり、単体テストを画面やバッチ機能単位で実施しても良い。

テストコードやCIが一般的じゃなかった頃は、どこもこういうものだったのだろうか？
いずれにせよ、単体テストを上のように定義するとテストコード書いてどうこうなる世界ではなく、ユニットテストかとEnd to Endテストとかゴチャ混ぜというか、区分がない。

加えて、テスト仕様書はだいたい会社としての標準フォーマットとか開発ルールとして定められている。
「次の案件はテストのやり方変えよう！テストコード書いていこう！」
となったとしても、ルール側にも干渉しないと、多分テストコード書いた上でいつもの「単体テスト」も実施する羽目になる。

おしまい

トラディショナルな現場で脱レガシー、というか生まれた瞬間からレガシー化していく事象と戦っている人はたくさんいて、テストコード書きたいしリリース頻度も上げたいけど、そもそもテストコードを書く技術とかCI環境とか、そういう技術的な話以前の壁が険しくてつらいね、というお話。

Sierとか大企業の内製とかでこういう呪縛を脱した事例を知りたい。
テストコードの書き方は勉強できるし教えれるけど、この壁に対して現場のエンジニアレベルでどう戦っていいのかわからん…

あとこういう事象はエンプラ界隈だと常識だと思うけど、Web系とか自社開発系だと驚愕の事実だったりするんだろうか。

de:code2020 セッションメモ

勉強会 VSCode Git

Microsoftのカンファレンスであるde:code2020視聴時のメモ。

開催期間：6 月 17 日 (水) – 7 月 17 日 (金) 17:00 オンラインにて

www.microsoft.com

A01 React Native で Windows アプリ開発 ~React Native for Windows~

React Native for Windows とは React で Android/iOS の UI を作ってネイティブコード生成。TypeScript 開発も可。
2020 年 2 月からハイパフォーマンスな C++版が Windows のデフォルトになった。
Native Module や Native UI Components を使うことでネイティブ UI や API を利用できる。
ReactNative のコンポーネントをネイティブ開発に組み込むこともできる。

デモ：Android と Win のプレビューを出しながら開発。開発コードはWinとAndroidに同時に反映される。

A02 Azure Bot Services を使って Teams bot を開発する

【第 1/5】Teams bot をローカル (Visual Studio 2019) で開発し、Azure で無料で動かす【その１：VS でローカル web サーバ立てる編】 #decode20 #A02 - Qiita

Azure Bot Services Bot 開発の IDE。エンドポイント定義、SDK、Bot とチャネル間のフレームワーク。

BotFrameworkSDK

Step1:ローカルでエミュレータ使って開発
Step2:ローカル Bot に Teams から接続。Teams ＞ 365 ＞ Azure(Bot チャンネル)＞ ngrok ＞ローカルサーバ
Step3:AzureAppService に Bot をデプロイ。Teams ＞ 365 ＞ Azure・・・逆順で帰ってくる

Step1:ローカル実行（エミュレータ）
空プロジェクト＞拡張 FW ＞ BotFramework
再起動して新しい PJ ＞ Echo Bot テンプレート＞実行・・・Bot サーバは OK.

BotFramework エミュレータを入れる（GitHub から入手）
エンドポイント設定して動作確認。

Step2:ローカル実行（Teams） Azure ＞ BotChannelsRegistration
ngrok で localhost のポートをトンネルしてエンドポイント生成。BotChannels に登録。
appId,appSecretswoVS の secret.json に設定。
Teams アプリのマニフェスト作成（アイコンと manifest.json を zip）して Teams から Upload。

Step3:AppService Azure の AppService を立ち上げる。
VS ＞発行＞ AppService を選択して発行。
Secret 設定、BotChannels のエンドポイント更新。

A06 Azure Kubernetes Service と Azure DevOps による GitOps の実践

IaC ＋ Kubernetes によってコードによって、宣言的にインフラ構築が可能になった。
変更追跡も容易になった。
IaC のデプロイや切り戻し、CI への攻撃が課題になってくる。

GitOps マニフェストを Push すると GitOps 側で環境との差分を検知。差分があればデプロイ実行。
インフラ側に Push 用のエンドポイントを容易する必要がない＝悪意あるデプロイを受けない。 Pull型。

A04 Azure ならこうする、こうできる！

AWS と Azure の比較。
課金と管理の単位が違う。AWS はアカウント単位だが Azure はサブスクリプション単位。
特定のリソース群ごとにサブスクリプション(課金単位)を分けて管理することも可能。

Azure のマルチ AZ 構成では IP のセグメント分ける必要がない。
Azure の AZ はペアが設定されていて（東京と大阪など）マルチ AZ はを選択するとそれらが使われる。

教材としては MS Learn が無償で使える。Azure の無償環境もついてくる。

A11 Azure 10 周年の節目に見直したい、Azure インフラのちょっと大事な話

Azure10 年の歩み。
デビューは 2008 年。当初は 1 日止まるメンテナンスなどもあった。現在はほぼ無影響でメンテナンス。

可用性セットは１つのデータセンターのクラスタのひとつ。
クラスタ内の 1 台が落ちても大丈夫だが、クラスタで共有している電源や空調などが落ちると全滅する。
可用性ゾーンは、電源などが独立したクラスタの組。
ゾーンがまるごと落ちてもサービスを継続できる。

A14 「あつまれ フロントエンドエンジニア」 Azure Static Web Apps がやってきた

いままでは WebApps…オーバースペック。BlobStorage…機能不足。
クラウドデザインパターン：Coulout Static Hosting Patttern

Azure Static Web Apps
GitHub Actions と統合された CI/CD。GitHub のリポジトリとフォルダ指定すれば OK. プロダクトと別にプレビュー用のサイトにデプロイ可能。
AzureFunctions と統合されたサーバレス API
無料プランあり。コンテンツはグローバルに配置、CDN あり。

A31 Development from anywhere! 全ての開発者が生産性を維持するためにマイクロソフトが貢献できること

リモートワークによって 52%が生産性 UP（アメリカの調査）

Code from anywhere

リモートアクセスのセキュリティ、セットアップ時間、

  • Vidual Studio Codespaces クラウド開発環境。ブラウザベース。

  • VisualStudio Intellicode AI による高性能は

    Collaborate from anywhere

  • VisualStudio Live Share VS の拡張機能。共同編集が可能。

  • GitHub

  • Azure Boards アジャイル用のかんばんツール。スクラム対応。

    Ship from anywhere

  • GitHub Actions Azure と連携すると手軽にデプロイ。

  • DevTest Labs
  • Azure Monittor, Insight
  • Azure Policy

マイクロソフトが実施していること

  • カルチャー醸成
    • Teams 上でのカルチャーチャンネル
    • ランチ、コーヒー、通話しながら散歩、ゲーム
  • 情報共有
    • ヘルプリスト
    • リモートワークの指針
    • ハードウェアガイダンス
    • ベストプラクティス
  • 技術セットアップ
    • モニター、周辺機器など作業効率を損なわない環境
    • VSCodeSpace、WindowsVirtualDesktop などクラウド利用
  • 価値提供
    • リズムを維持し、Teams 上で実施
    • Azure Boards, Whiteboard を活用
  • ペアプログラミング

A51 未来を生き抜く子どもの教育、マインクラフトで扉を開くコンピューターサイエンスの学び。

マイクラでのバーチャル卒業式。大学の校舎、政府公式にサーバー提供、昔話を再現、音楽の実験、etc
マイクラのバージョンによるが、科学実験やプログラミングが可能。

  • Python を学ぶ
    • マイクラ内のコードビルダーでコーディングやブロックプログラミングが可能。
    • コマンドを学ぶこともできる
    • 現実世界の AI の働きを学ぶ
  • 学習のプロセス
    • 想像：なにをつくるか
    • 調査：どう作るか
    • 試行：つくってみる
    • 修正：作り直す
    • 発信：作ったものを発信
  • Minecraft カップ 2019

B01 今日から始めたくなる Power Platform 入門編 ～デモで分かるローコード開発の無限の可能性～

  • PowerApps ノーコード・ローコードでアプリ開発
  • PowerAutomate ワークフロー機能。RPA 機能も追加。トリガーとアクションを設定する。
  • PowerBI データ可視化、分析。
  • PowerVirtualAgents Bot 開発。

データコネクタ、カスタムコネクタによって手軽にほかシステム連携。
CommonDataService：GUI で触れるデータストア。

キャンバスアプリ GUI でシンプルな画面開発。スマホ機能、カメラ、MR など利用可能。

モデル駆動型 ダッシュボードなど複雑なモデルを開発。
モデルを定義して対応するフォームを開発する。

PowerApps ポータル 社内ポータル向け。 Azure,Google などの認証基盤を使って認証機能をつけることもできる。

B41 Power Apps の可能性 ～やらない技術者に未来はない？～

ハンズオン。 SharePoint で用意したテーブルを用いて申請フォーム作成。
ブラウザ上で部品を並べてアプリ作成。
Windows フォームアプリや OutSystems のもっとシンプル＆イケてる版。

M13 開発者が語る！ Microsoft Teams アプリケーション開発の実例とコツ

タブアプリケーション
Planner のようにタブとして表示するもの。Web アプリを Teams 内で表示しているようなもの。
認証などを Teams 向けに改修すれば既存の Web アプリの流用も可能。

ボットアプリケーション ちょまどさんのセッション参照

Z02 セキュアなソフトウェアを実現する、GitHub のコード解析のご紹介

セキュリティ侵害の 53％はコードの脆弱性が原因。 セキュリティリサーチャーは不足している。リサーチャーによって CodeQL のクエリなど日々開発されている。

  • コードのセキュリティ

    • CodeQL
      • コード上の脆弱性を探索
      • 脆弱性のメソッドコールを辿って分析、表示でき(XSS の呼び出しから発言まで）
      • GitHub Actions として提供
      • セキュリティインシデント発生時にパターンを検知するクエリを作成し全プロダクトに実行することで網羅的に検査
      • 分析時のクエリに追加することで予防
    • Code Scanning
      • CodeQL による脆弱性探索を開発者ワークフローの提供

  • 依存関係のセキュリティ

    • 依存しているライブラリの脆弱性が見つかった場合にアラートを上げる
    • 脆弱性の詳細、解消されたバージョンなど
    • バージョンアップ用のプルリクを作成。リリースノートへのリンクなど補足情報つき
  • 安全なデプロイメント

Z03 GitHub 新機能のご紹介（2020 年 5 月発表）

  • GitHub Mobile
  • GitHub Actions
    • Organization でランナーを共有できる
    • ランナーにタグをつけて、フローごとに使用するタグを指定できる（GPU マシン、高 CPU マシンなど）
  • Codespaces
    • リポジトリのクローン、定義されたツールや拡張機能などがすべてインストールされた環境構築が可能。
    • devcontainer.json
  • Discussions
    • タスク管理である Issue と議論を分離
  • Secret Scannning
    • Push された瞬間にシークレットを検知。
    • すべての Git ヒストリをスキャン
  • Code Scanning
    • コードをマージする前にコードレベルの脆弱性を検知。
    • 他の SAST ツールによる拡張も可能
  • GitHub Private Instances
    • GitHub マネージドのシングルテナントのクラウドサービス
    • Azure 上にホストされる
    • AzureAD との統合