カナダIT留学ってどんな感じ？
これは フィヨルドブートキャンプ Part 2 Advent Calendar 2024 24日目の記事です。
毎年恒例のアドベントカレンダーがやってきました。 気づいたら最近はこれしかブログ書いてない…
今年も主にフィヨルドブートキャンプ関係者やどこかでつながってくださっている方々に向けて近況報告をします。
カナダ留学
今年の夏からカナダ（バンクーバー）に留学しています。 カレッジのコンピュータ系の学科で勉強中です。2年間通う予定です。
今月中旬に1学期目が終わり、カナダ生活にも慣れてきて、なんとかやっていけそうかなというところです。
今学期受講していたのは、ネットワーク、OS、プログラミング（C#）など4科目。1コマあたり約3時間授業があるので、1科目が日本の大学の2コマ分ぐらいあります。
C# は初めて触ったのですが、GUIで簡単にWindowsデスクトップアプリが作れて驚きました。 意外と面白かったです。来学期はJavaを学ぶみたいです。
プログラミングのテストはコーディングもありました。 それ以外の科目のテストは、紙またはPCで、選択式問題と記述問題でした。 英語力にハンデがあるので記述問題は大変でした。無事パスすることができてよかったです。
英語力
渡航前に受けたTOEICは900超でしたが、それで十分かというとそうでもありません。
そして語学留学ではないので、こちらでただ漫然と生活していても英語力が伸びる気配がありません（バイトとかしていたら伸びると思いますが）。講義を聞く時間が長いので、リスニングだけは少し伸びたかもしれません。 日常生活に支障はないのですが、このままの英語力だとこっちで仕事を見つけるなんて夢のような話です。
カナダ、特にバンクーバーは移民のまちで、みんな優しく拙い英語でも理解してくれます。 その分英語力を上げないといけないプレッシャーが低いです。
来年は、もっとイベントやボランティアなどに積極的に参加して、英語力（特にスピーキング）を伸ばしたいと思います。
カナダ生活
カナダの物価は日本の約2倍です。家賃、食べ物、日用雑貨など全部2倍ぐらいです。
バンクーバーにはユニクロ、DAISO、無印などがあり、日本のものはだいたい手に入ります（値段は約2倍）。
外食はほぼしたことがないのですが、外食はチップがいる分もっと高い気がします。日本よりおいしいものはなさそうですが…。
ありがたいことに、日本の仕事を一部継続させてもらっているので生活費はなんとかなっています。学費はえげつなく高いです。買い物はできるだけセール品を買うようにしています。節約はもはや趣味なので全然苦ではありません。
今住んでいるところは、マンションの一戸を2人でシェアしていて、家賃は光熱費ネット込みで月1,000ドル（約11万円）です。バンクーバーとしては平均的な値段だと思います。ヒーターがついていて家の中はとても暖かくて快適です。クーラーはない家が多いため夏は大変な日もあります。
キッチンが広くて料理が前より楽しいです。カレーやからあげ、ハンバーグなど日本にいたときと同じようなメニューを作っています。ただ、サンドイッチ用食パンだけは日本より激安なので、昼食にはサンドイッチやハンバーガーを作って食べたりしています。
観光地はまだ一つも行っていません。東京に住んでいたときもそうでしたが、長く住む予定だとなかなか観光に行くモチベーションが上がりません（引きこもりの言い訳）。来年はハイキングにも挑戦したいです。
総じて、楽しく元気にやっています。バンクーバーに来られることがあればぜひ声をかけてください！
Kaigi on Rails 2023 で同僚とモブプロしました
これは フィヨルドブートキャンプ Part 2 Advent Calendar 2023 1日目の記事です。
10月27日・28日に開催された Kaigi on Rails 2023 に、同僚でありフィヨルドブートキャンプ仲間でもあるトミーさん、あんすとさんと3人で登壇しました。 3人とも現在 Tebiki株式会社 で働いています。
登壇のきっかけ
3人とも、2023年5月に長野県松本市で開催された RubyKaigi 2023 に参加しました。
オフラインで大きい技術イベントに参加するのは初めてだったのですが、例に漏れずモチベーションが爆上がりしました。 （たとえほとんど理解できなくても…）
会場でお昼ご飯を食べているときに、私たちも登壇してみたいねという話になり、業務時間を週に1時間使わせてもらって Kaigi on Rails 2023 登壇を目標に、登壇内容を考え始めました。
最初は各自でプロポーザルを出すつもりでしたが、3人でペアプロ/モブプロしたら面白そうという話が出て、我々のチームで普段やっているペアプロ/モブプロ開発を紹介したら他の参加者にも役立ちそうということで、3人で1つのプロポーザルを出すことになりました。
発表内容
Kaigi on Rails 2023 での実際の発表はこちらから動画で見られます。
ペアプロ/モブプロ開発のメリットと実践 Tips の紹介、そして LIVE モブプロを行いました。
私たちが所属する Tebiki株式会社 では、開発やテストなど大半の作業を複数人で行っています。
フィードバックをもらうタイミングは、早ければ早いほど修正コストが低いというデータがあります（詳細は動画をご覧ください）。
ペアプロ/モブプロをすることにより、フィードバックサイクルを高速で回すことができ、結果的にプロダクト品質を向上させることができます。その上、ペアプロ/モブプロは楽しいです。
あと、レビューのやり取りって結構つらくないですか？コード見ながら直接話せば一瞬で終わることが何日もかかったりして。。。ペアプロだと、レビュー時間ほぼゼロです。
いろんな課題の解決策と思って導入したペアプロ/モブプロですが、導入当初はさまざまな問題にぶち当たりました。それをどうやって我々のチームが乗り越えたのか、そして実際どのようにペアプロ/モブプロをやっているのかを発表しました。
ペアプロ/モブプロ開発を本格的に導入したいチームにとっては参考になると思います。
LIVE モブプロでは、FJORD BOOT CAMP（フィヨルドブートキャンプ） のアプリを題材に使わせていただきました。
数週間かけて新機能を追加していたのですが、本番の約1週間前、発表の練習の段階になって、内容的にペアプロ/モブプロのよさを伝えるのに十分でないという話になり、急遽内容を変更することになりました。ちょうどよい Issue があって本当に助かりました。
（フィヨルドブートキャンプ関係者の皆様、使わせていただいてありがとうございました！）
発表内容の要約
- ペアプロ/モブプロのメリット
- 我々がペアプロ/モブプロ開発導入によって解決したかった課題と導入後の結果
- レビューが終わらない
- →レビュー依頼〜マージに平均2日以上かかっていたのが、ペアプロ開発導入後は24時間以内に
- 属人化
- →アンケートでは全員が属人化が減ったと思うと回答
- 新メンバーがキャッチアップしにくい
- →アンケートでは全員が新メンバーのキャッチアップが早くなった/どちらかといえば早くなったと思うと回答
- レビューが終わらない
- ペアプロ/モブプロ導入後の課題と解決策（ペアプロ実践 Tips）
- LIVE コーディング
- 題材：フィヨルドブートキャンプで実際に使われているアプリ
登壇しての所感
こんな大きなイベント登壇は初めてかつオフライン登壇も初めてででしたが、運営の方々からの連絡は丁寧でわかりやすく、安心して当日を迎えることができました。本番もトラブル等なく大変スムーズでした。
本番は3人いたこともあり、思ったほど緊張しませんでした。手は震えてましたが…
3人いたら準備も分担できるから1人で登壇するより楽かと思いきや、必ずしもそうではありませんでした。各メンバーで思っていることが違ったり、うまくいかなかったりして揉めそうな場面も何度かありました。バンドの解散理由でよく聞く“方向性の違い”ってこういうことなのかと思ったりもしました。
でも、終わった今感じているのは、楽しかったという気持ちが一番大きいです。大変なこともありましたが、この3人で Kaigi on Rails という大舞台で発表することができてよかったです。
会社や同僚にもたくさんサポートしてもらいました。この日のためにTシャツやシールを作ってもらったり、内容についてアドバイスをもらったり、業務時間内に準備・練習をやらせてもらったりなどなど。
自分が言うのもあれですが、いい会社だなーと思いました。
最後に
個人的に、毎年楽しみにしていたイベントで登壇する機会をいただけて感慨深く、うれしかったです。
初回のとき書いた記事を見つけました。。。
運営の皆様、素晴らしいイベントを開催していただいてありがとうございました。
ということで、これからも毎日ペアプロ/モブプロやっていきたいと思います。
ついでに宣伝ですが、「ほぼ全部ペアプロ開発」に興味のある方、ぜひ一緒に開発しましょう〜
近況報告（プログラマになって1年8ヶ月）
これは「フィヨルドブートキャンプ Part 2 Advent Calendar 2022」の18日目の記事です。
フィヨルドブートキャンプ卒業生として近況報告をします。
最近の生活
仕事
2021年3月にフィヨルドブートキャンプを卒業後、Tebiki 株式会社で働きはじめ、1年8ヶ月が経ちました。
普段は朝10時前に新宿のオフィスに出社し、19時頃退社します。週1〜2日はリモートワークもしています。
リモートかどうかにかかわらず、10時から19時までほぼオンラインでずっとペアプロ or モブプロで作業します。ペアプロについては前に少し書いたので、興味があれば読んでみてください。スライドの中にオフィスの写真もあります。分割キーボード最高。
最近はエンジニアが増えてきていて、フィヨルドブートキャンプ卒業生も入社してくれました。おかげさまで楽しく仕事できていると思います。
ペアプロ・モブプロでは相手の経験年数にかかわらず、学ぶことが多く、毎日いい刺激をもらっています。エディタの便利機能とか、ペアプロしてなかったら一生知らなかったようなことを毎日知れて楽しいです。
入社後思ったことは、フィヨルドブートキャンプでチーム開発を通して Git・GitHub 力をつけておいたのがよかったということです。リベースしたらどうなるか、マージしたらどうなるかとかそういうやつです。GitHub の運用ルールは会社によって異なりますが、最低限知っておかないと、そもそもルールが理解できなくて困ります。
フィヨルドブートキャンプ在籍中にいろいろ練習して失敗しておいてよかったです。普段は RubyMine を使っているので、コマンドラインはほぼ忘れてしまいましたが。
仕事以外
週に2〜3回、フィヨルドブートキャンプ卒業生や現役生とオンライン勉強会（輪読会）をやっています。在籍中から継続している感じです。
仕事を始めるとなかなか勉強の時間を取れないこともあるので、定期的に勉強する場を設けて習慣化するのは有効でした。技術の話はもちろん、他の勉強会情報や仕事上の悩みなどいろいろ話すことができ、自分にとっては強制的に勉強というよりは息抜きの時間のように感じることもあります。
こうやって気軽に話せる友人ができたことも、フィヨルドブートキャンプに通ってよかったと思うことの一つです。イベント参加や輪読会・もくもく会とかやっておいてよかったなと思います！
今後やっていきたいこと
最近は、テスト（RSpecとか）に興味があるので、そこをもっと勉強していきたいです。効率的なテストケースの洗い出し方とか、テストに必要最低限の DRY はどの程度か？とか。
あとはスクラムについても勉強中です。先月 PSM I という試験を受けて、スクラムガイドについて最低限の知識はついたものの、実践時にはスクラムガイドに書かれていない部分がたくさんあってわからないことばかりなので、本を読んだり勉強会に参加したりしています。結局は、そのチームに合ったやり方を見つけるしかないですね。
TypeScript の勉強も始めました。どうも JavaScript に苦手意識があるので、これを機に TypeScript マスターになって苦手を克服したいと目論んでいます。
フィヨルドブートキャンプ生の名に恥じないようにやっていきます〜
読んでいただきありがとうございました。
Kaigi on Rails _2022_ new でペアプロについて LT しました
2022年10月9日（日曜日）に開催された、Kaigi on Rails 2022 new というイベントで LT（5分間）をやらせてもらいました。10月21日・22日に開催される Kaigi on Rails 2022 のプレイベントです。
今働いている会社で取り組んでいる「ノンソロ開発」をやる中で、チームで試行錯誤してみつけた「ペアプロをスムーズに進めるための Tips」について発表しました。
スライドはこちら。
自分も実際やってみるまで知らなかったのですが、1時間以上ペアプロ・モブプロやるとめちゃくちゃ疲れます。休憩大事。
今回は5分という短い時間だったので「ノンソロ開発」自体の意義などにはふれられなかったのですが、フィードバックサイクルを高速に回すことで、質の高いプロダクトをできるだけ早くユーザーに届けるために導入しました。
そのほかの LT も興味深いものばかりで、Rubocop 好きとしては特に気になったのがこちらの発表。早速リポジトリだけ作ってみた！
先程のLT資料です。「雑Custom Cop作りのススメ」https://t.co/8qqasEICW4 #kaigionrails
— Yudai TAKADA / ydah (@ydah_) 2022年10月9日
運営の皆様、LT 聞いてくれた皆様ありがとうございました。
Kaigi on Rails 本編も楽しみです。
『達人に学ぶDB設計 徹底指南書』輪読会をやった
2020年の年末から、フィヨルドブートキャンプ内で『達人に学ぶDB設計 徹底指南書』の輪読会をやった。
Slack で輪読会の話が出たときに、DB関係の本を読みたい！と言ったところ、フィヨルドブートキャンプのアドバイザーであるベテランエンジニアの方がメンターをやってくださることになり、開催に至った。
初学者で集まって読むのも楽しく一人で読むよりは知識も深まるが、その分野の知識や経験が豊富な方に参加してもらえたことで、さらに何倍も有意義な会になったと思う。
ものすごく勉強になったのを独り占めするのはもったいないのと、自分の復習のためにも特に印象に残ったところだけでも書き残しておくことにしたい。
学んだこと〜データベースを制する者はシステムを制す
データベースは事実を保存するもの
プログラムと比べ、データはあまり変化しない。というか、そう設計されるべきだ。データ設計（データベース設計）は、プログラム設計に先立って行う。
たとえば、ユーザーの氏名（事実）が変わることはあまりないが、名前の表示の仕方（プログラム）を変えたくなることはよくある。
名簿はフルネームだけど、担当者名のところには苗字だけ表示させたい、とか。
可能な限り NOT NULL 制約をつける
事実を保存する前提に立つと、基本的にNULL（データが空っぽ）となることはない。
NULLを許容したくなったときは、データ設計自体を見直した方がよい。
たとえば、以下のような社員テーブルを考える。
| 社員ID | 姓 | 名 | 年齢 | 部署 |
|---|---|---|---|---|
| 200500123 | 山田 | 太郎 | 45 | 総務 |
| 201000111 | 高橋 | 花子 | 36 | 広報 |
| 202100567 | 鈴木 | 一郎 | 20 | ？？？ |
今年入社したばかりの鈴木さんは、研修後に配属が決定されるので、入社日時点では部署が決まっていない。
NULLを許容しないとなると、部署が決まるまで鈴木さんを社員テーブルに追加することができない。
こういうときは、このテーブルの設計自体がまずい可能性が高い。
社員テーブルに「部署」を入れる必要があるのか？配属先が変更になったら？複数の部署に配属される可能性はゼロか？
ということを考慮すると、「配属」というイベントが存在していることに気づく。
部署テーブル
| 部署コード | 部署名 |
|---|---|
| 010 | 総務 |
| 020 | 広報 |
| 以下略 | … |
配属テーブル
| 配属日 | 終了日 | 社員ID(外部キー) | 部署コード(外部キー) |
|---|---|---|---|
| 2005-06-01 | 2011-3-31 | 200100123 | 070 |
| 2011-04-01 | 2018-03-31 | 200100123 | 050 |
| 2018-04-01 | 200100123 | 010 | |
| 2010-06-01 | 2015-03-31 | 20100111 | 030 |
| 2015-04-01 | 20100111 | 020 |
現在進行中のところの終了日はNULLを入れたくなるからまた設計がおかしいのか…
と思うかもしれないが、こういうところには最大値を入れておくというテクニックがある。「事実」ではないが、つっこまないで…。
未来に起こる「かもしれない」ことを全て考慮するのは難しく、NULLを許容することが絶対に悪いということではない。
何かを優先すれば何かが犠牲になる「トレードオフ」の世界なので、部署を未定で登録しておくケースもあるかもしれない。
何を優先するかによって、考え方・正解がたくさんある世界だという点も大事。
可逆 / 不可逆を考える
上の社員テーブルでは、社員名の姓と名を別々のカラムにした。
データはできるだけ分解した方がいいというのはなんとなくわかるが、姓だけ、名だけでは誰かわからないので意味が失われてしまうのではないか？
カラムを分けるか、テーブルを分割するか考えるときは、可逆的か（元に戻せるか）どうか？を考えてみるとよい。
姓・名を別々のカラムにしておいたとして、フルネームが必要なときは、2つのカラムのデータを単純にくっつければいい（可逆的）。
逆に、氏名という1つのカラムに「山田太郎」と保存していた場合、社員の姓だけが必要になったときに、プログラムで姓だけを取得することは不可能。 絶対にフルネームでしか使わないということであればいいのかもしれない。
ちなみに、「年齢」はあまりよくなさそう。誕生日が来たらいちいち更新するのか？「生年月日」にしておけば、年齢はプログラムで求めることができる。
正規化は絶対ではない
データベースの勉強をすると必ず出てくる「正規化」という言葉。
ざっくりいうと、冗長性（重複）をなくしデータの不整合を防げるように整理すること。
正規化にはいくつか段階があり、正規化を進めれば進めるほどデータ整合性を高められるが、検索性能は劣化する。ここもトレードオフ。
正規化するのが絶対に正しいというわけではなく、パフォーマンスを優先してあえてデータを冗長に保持することもある。
たとえば、Twitter の「いいね!」数は、ある特定のツイートに対し誰が「いいね!」しているかをデータベースに問い合わせて計算すれば求めることができる。ただ、何万もの「いいね!」がつくことも珍しくない Twitter で、一つ一つのツイートに対してそんな処理をやっていると、結果が表示されるのに時間がかかったりデータベースに負荷がかかったりする。
こういう集計データ（サマリデータ）は、計算後の結果を別途保持しておくことによって、パフォーマンスを上げることができる。
トレードオフを理解した上での非正規化は、アンチパターンではない。
ER図をいきなり描くのは難しい
フィヨルドブートキャンプでは、Twitter の ER 図を描くという課題がある。苦戦した過去の自分へのアドバイスをいくつか。
とにかく、まずは具体的なデータを置いてみること。どういう形でもいいから、具体的な例を考えてデータの置き場所を作ってみること。
エクセルのような表を作って、セルに複数のデータが入ったりしてもいいから、とりあえず書いてみる。
その後、正規化したりリレーションシップを考えたりしていく。いきなり ER 図を描くのは難しい。
この本では、2種類の表記方法が紹介されているが、ググってみると、いろんな描き方をしている人がいて、どれが正しいの？となる。
ER図に関しては、厳密にどれが正しいというより、伝わることが一番大事。
主キーの考え方がRailsとは違う
この本を読むときに注意が必要なのが、主キーの考え方。
主キーの考え方には、ナチュラルキー（自然キー）とサロゲートキー（代理キー）というものがある。
参考：「ナチュラルキー」と「サロゲートキー」の違い｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典
ナチュラルキーは、事実を（必要に応じ組み合わせて）主キーにするのに対し、サロゲートキーは、事実とは関係のない番号などを人工的に主キーとしてつけるもの。ナチュラルキーの例は、上の社員テーブルでいうと「社員ID」や「部署コード」。これは、プログラムのためにつけたものではなく、現実世界に存在するID（コード）。
この本は、ナチュラルキーを使うべきで、サロゲートキー（代理キー）は推奨しない立場で書かれている。詳しくは本の「8-2 代理キー〜主キーが役に立たないとき」を参照。
一方、Rails はデフォルトでサロゲートキーを使うようになっているので、この立場の違いを知らないと理解が難しいところが多々ある。 自分も1回目に一人で読んだときはそれを知らず、理解できないところが多かった。
現在、現場ではサロゲートキーが使われることも多いようだ。
サロゲートキーは連番か
ちょっと話は逸れるが、サロゲートキーを連番にするかランダムな数字にするかという話題で興味深いツイートを教えてもらったのではっておく。
ベースブレッドのシナモンとメープルがうまいらしいので、ベースブレッドの購入を再開してみる
— ところてん (@tokoroten) January 4, 2021
ベースブレッドのマイページを見たら、注文番号が連番くさいので、一日当たりの注文量を出してみたら、割とえげつない事業成長をしていて、サブスクビジネスのすごさが分かった、今は月商8000万くらいぽい pic.twitter.com/IOukckfiwt
たとえば、ユーザーIDが連番だと、登録した人が「全ユーザーが何人いるか」わかってしまうので、あえてランダムな数字にすることもよくある。
難しい用語にこだわらなくていい
この本では、部分関数従属とか推移的関数従属のように難しい用語がいくつか出てくる。
現場ではあまり使わないようなものもあるので、細かい用語を一つ一つ覚える必要はない。難しい言葉は、ざっくり理解して次出合ったら覚えるぐらいでよさそう。
輪読会の概要
毎週土曜日22時〜23時に Discord で開催し、全13回。
参加者は、多い日は20人弱、少ない日は3人ぐらい。
項目ごとに5〜10分の時間を取って各自読みながら疑問点などを HackMD に書いていき、時間が来たら意見交換を繰り返す流れで進行した。
第7〜8回は、参加者を2チームに分けてモブプロっぽく ER図の作成会をやった。
参加してくれた皆さん、bluerabbit さん本当にありがとうございました。
『トヨタの失敗学 「ミス」を「成果」に変える仕事術』を読んだ
- 作者:(株)OJTソリューションズ
- 発売日: 2016/08/04
- メディア: 単行本
どんな本か
「失敗=悪」。これが世間の常識です。だから誰もが「失敗などしたくない」と思いながら仕事をしています。 「失敗したら上司に叱られる…」 「 問題を起こせばまわりに迷惑をかけてしまう…」 「 失敗したら責任をとらされる…」
このような事態が想定できるからこそ、 「失敗しないように無難に進めよう」 「失敗したら、バレないように隠してしまおう」 「いざとなったら力技でごまかそう」 という発想になってしまいます。しかし、「失敗は避けなければならないもの」という意識でいるかぎり、失敗から目をそらす姿勢が強くなります。そして同じような失敗を繰り返すことになり、事態は悪化していきます。また、新しいことや困難なことへのチャレンジにしり込みするので、職場のチームも自分自身の成長も減速します。
トヨタの現場の第一線で活躍してきたトレーナーたちが、口をそろえて証言していることがあります。 「トヨタの現場では、たくさんの問題やトラブルが起きる。でも、『失敗』という言葉はほとんど聞かなかった」 もちろん起きた現象だけをとらえれば、トヨタにもミスやトラブルなど大小さまざまな失敗がありますが、少なくとも現場レベルでは「失敗」という概念は存在しません。失敗したことをそのまま放置したら、それは文字通りの「失敗」に終わってしまいます。しかし、失敗に正面から向き合い、次に活かすことができれば、その失敗は改善プロセスのひとつとなります。「失敗」が「失敗」で終わらないのです。
現場のメンバーが知恵を絞って、「なぜ不良が起きたのか」を徹底的に考えます。そして、問題を引き起こしていた原因を突き止めて、二度と不良が出ないような対策を実施し、そのしくみは、他のラインや工場にも展開することで、組織として強くなっていくのです。
つまり、トヨタの現場では、問題やトラブルをよりよいモノづくりをするための「改善の機会」ととらえているのです。 トヨタの現場で働く人たちにとって「失敗」とは、改善へとつなげるチャンスであり、成果に結びつける「宝の山」です。 (はじめにより)
Amazon.co.jp より
所感
いろんな職場で使えそうな実践的な内容だった。上の抜粋を読めば大事なところがなんとなくわかるかもしれない。
「失敗＝悪」ではない
失敗は改善のタネで宝の山。これが一番大事だと思った。今まで、失敗についてじっくり考えたことがなかったが、当然のように失敗は悪いことだと思っていた。
できれば失敗は避けたいし、もし失敗したら隠したい。そう思っていた気がする。
この本を読んで失敗は悪ではないとわかっても、実際に仕事をする中で、失敗を隠したい気持ちをゼロにできるだろうか？
自分の無知やミスをさらけ出しても責められたりバカにされたりすることがない、心理的安全性が確保されている職場なら、可能だと思う。この本の中で「心理的安全性」という言葉自体は出てこないが、トヨタでは、工場で異常を見つけてラインを止めた作業員を誰も責めたりすることはなく、むしろ奨励されているという。そうやって問題を小さいうちに発見し、改善を続けていくことが大事なのだと知った。
心理的安全性が低く、失敗したとき個人が責められるような職場だと、失敗を宝の山と考えるのは難しいだろう。先日読んだ 不機嫌は罪である (角川新書) という本にも似たようなことが書いてあったのを思い出した。みんながニコニコして明るい職場は、離職率が低くなり業務効率が上がるそうだ。Googleによる調査で、生産性の高い職場にもっとも重要な要素が「心理的安全性」とされたことにも触れられていた。
心理的安全性が高いと生産性が高まると聞いて、メンタルが仕事の生産性にまで影響を与えるのかと漠然と考えていたが、今回『トヨタの失敗学』を読んで、生産性が高まる理由がわかった。それは、失敗を隠すことがなくなるだけでなく、日頃からさまざまな情報が共有され、ちょっとした気づきの段階で失敗の芽を摘み取ったり改善したりしていくことが可能となるからだろう。
エンジニアは、気をつけていてもバグを一度も出さない人はいないので、この「失敗学」の考え方はとても大事だと思った。
失敗から学び、改善してよりよくすることができれば、それはもはや失敗ではなく成長の1ステップ。
大事だと思ったことをメモ
- 「失敗＝悪」ではない
- 失敗を放置したら文字通りの「失敗」になってしまう
- 失敗は宝の山、改善のタネ
- 失敗したら真因を追求する
- 何が起こった？
- なぜなぜ5回
- 失敗しても個人の責任にしない
- 真因ではない
- 失敗が隠されるようになる
- チャレンジしない組織になってしまう
- 「人はミスをするもの」という前提で失敗しないしくみをつくる
- 小さい問題は繰り返されたり、後で大きい問題になったりする
- 問題が小さいうちに、自らの意思で問題を明るみに出す
- よその失敗を自分ごとととらえて対策を講じる
- 明るい職場は「失敗」が隠れない
- あきらめずに前進を続ければ「失敗」にはならない
大人の勉強法について考えた
学生の頃の勉強といえば、覚えるものだった。覚えなければテストで点数が取れないので、きちんと理解して覚えるようにしていた。
大人の勉強は覚えることが最終目標ではないと気づいたのが自分はかなり遅かったので、ブログに書いておくことにした。ここでいう大人の勉強というのは、プログラミングとかその周辺の話。
大人の勉強の目的は未来の自分へのカンニングペーパーを作ること
Webエンジニアが仕事をするときを考えてみると、学生の頃と違ってググってOK、カンニングし放題なので、仕事に生かすための勉強をするのであれば、一度理解したことをいかに早く正確に思い出せるようにしておくか、が一番重要だと思う。
つまり、大人の勉強とは、対象を理解した後に未来の自分へのカンニングペーパーを作ること、そして必要なときにすぐにそれを出せるよう整理しておくことだと思うに至った。
未来の自分を信用しないことも大事で、「さすがにこれぐらいは覚えていられるだろう」というような基本的なことも、迷ったら書いておいた方がいい。その後学んだ他の言語とごっちゃになってわからなくなってしまうかもしれないから（経験談）。
個人的にScrapboxはおすすめ
メモツールはいろいろあるので何でもいいと思う。自分が愛用しているのは Scrapbox。
フォルダ分けがなく階層構造を持たないことや見出しなどが作れないことにはじめはびっくりしたが、これが非常に使いやすい。書き出すまでの時間がゼロ。そして検索やページ間リンクもしやすい。もっと早く使っとけばよかった！と思っている。そういえば前にも書いた気がする。
書くハードルが低すぎる分、後から見ると意味不明になってることもあるけど、なんかの拍子にそういうのを見つけて修正したりするのも面白い。
公開プロジェクトにしておけば共有も楽だし、意外な場面で話題になったりすることも？
最近は技術的なことに限らず、何でも放り込んでいる。
タブ開きすぎ症候群にも効くかも
それから、自分の場合は、Scrapbox を使い始めてから、「気づいたらブラウザのタブを大量に開きっぱなしにしてしまう問題」も解決した。後から見返したいようなページであれば Scrapbox にリンクを張ったり必要な部分をメモしたりすることで、また見る「かもしれない」タブを閉じることができる（検索で上位に来ない公式ドキュメントのページなど）。検索すればすぐにたどり着けるようなページならそこまでしなくてもいい。
情報の粒度みたいなところも気にしなくていいからいいのかもしれない。ほんのちょっとしたメモからブログみたいな長文まで、内容も問わず何でも放り込めるところが好き。
こういうの（WebページをMacアプリっぽくする - masuyama's notes）を使うと、アプリっぽく使うこともできたりする。
今のところ、自分にとって Scrapbox 最強。これがないと多分何もできない人になりつつある。（バックアップ取っとかないと…）
間違いを見つけたら教えてください〜
