2026-10-13

複数タイムゾーン対応日程調整アプリをリリースしました

カナダに来てからずっと欲しかったアプリを作りました！

CrossTimely | Schedule across time zones: https://crosstimely.com/

イベントページを作ってURLを共有→参加者が出欠を回答

というシンプルなアプリですが、以下の特徴があります。

イベントページ作成時に世界各地の時間を確認できる
各参加者が自分のタイムゾーンで回答できる
アカウント登録不要

私は TechQ という Discord コミュニティの運営メンバーをやっているのですが、運営メンバーが日本・カナダ・ヨーロッパにいるため、毎回日程調整が大変なことがこのアプリをリリースする大きなモチベーションになりました。

技術スタック
開発方法
今後

技術スタック

React
TypeScript
Ruby on Rails (API)
PostgreSQL
TailwindCSS

開発方法

仕様書作成

まず初めに、マークダウンで仕様書を作りました。Codex の最新モデルはすぐ limit に達するので、主に GPT-6-Luma を使いつつ、最終レビューなど大事なところだけは GPT-6.1-Sol を使いました。（仕事では Claude Code、プライベートでは Codex を使ってます）

仕様書（抜粋）

## 3. ユーザーストーリー

### US-01 世界各地の時間を確認する

VancouverにいるAさんは、アプリを開くと自分の都市が初期表示される。Tokyo、Berlin、Torontoを検索して追加し、それぞれの現在の日付・時刻を確認できる。次回アクセス時にも選択都市が復元される。

自分の都市は削除できず、別の都市への変更のみ可能。他都市は削除できる。

### US-02 時差を比較しながら日程調整ページを作る

AさんはWorld Clockから連続した操作で候補選択に進む。日付を移動し、1時間刻みの比較表示で各都市の時刻を確認しながら、8件の候補を選ぶ。必要な候補だけ分を調整できる。候補一覧を確認してEventを作成し、共有URLを取得する。

### US-03
…（略）

## 4. 機能要件

### FR-01 都市の検索・管理

**確定:** 自分の都市を含め1〜10都市、都市名検索、他都市の追加・削除、自分の都市の変更、都市の並び替え、localStorage保存。同一都市の重複追加は不可。同じタイムゾーンでも別の都市なら追加可能。World Clockの都市行と都市選択肢には、都市名と合わせて現在時刻および`UTC+9`のようなUTCオフセットを表示する。

自分の都市は削除不可で、変更のみ可能とする。自分の都市を空にする操作は設けない。

**基本設計方針:** 自分の都市を候補日時入力の基準都市とし、都市一覧は追加順で表示する。
…（略）

Tech スタック含め仕様書が完成してから開発に入りました。

コーディング

コーディングエージェントには Codex GPT-6-Luma Medium を使用しました。

このモデルは GPT 6 の中では一番安いモデルです。このモデルなら5時間ぶっ続けで使っても limit に達することはありません。

安くて速いですが、よく間違えます。自分が読めない言語では使わない方がいいかもしれません。

たとえば、マジックナンバーを使ったり過去のマイグレーションファイルを直接書き換えたりしました。レビュー必須です。

AGENTS.md

リポジトリには AGENTS.md を含めていませんが、私の AGENTS.md では以下のような指示をしています。コミットごとにコードを自分でレビューするためです。

コード変更時はコミット計画を示し、承認後に実装開始すること
コミット計画には、以下の内容を含めること
- 予定されているコミット順序
- 各コミットの提案されるコミットメッセージ全文
- 各コミットに含まれる内容についての簡単な説明
- 各コミットで追加、変更、または削除される具体的なファイルパス（該当する場合は、対応するテストファイルも含む）
- 必要に応じて、関連する関数、コンポーネント、またはセクションを特定し、各箇所で計画されている変更について簡潔に説明すること

1コミット分実装されたらレビュー（必要に応じて修正）後コミット→次のコミット分実装

という感じで進めています。

CI

GitHub Actions で push 時にテストや Lint を回すようにしています。

デプロイ

アプリは、全部 Render でデプロイしています。

Frontend (React) -> Static Site
Backend (Rails API) -> Docker
DB -> Postgres

簡単でした。

GitHub 上で PR を main ブランチにマージすれば自動でデプロイされます。

デプロイ関係のメモはこっちにあります→アプリ作成メモ

今後

まだ対応言語が英語だけなので、まずは日本語対応させたいです。用途がグローバルなのでゆくゆくは他言語にも対応させていきたいです。

日本だけでも使えるのでよかったら使ってみてください。フィードバックもよろしくお願いします！

CrossTimely | Schedule across time zones

2024-12-24

カナダ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万円）です。バンクーバーとしては平均的な値段だと思います。ヒーターがついていて家の中はとても暖かくて快適です。クーラーはない家が多いため夏は大変な日もあります。

キッチンが広くて料理が前より楽しいです。カレーやからあげ、ハンバーグなど日本にいたときと同じようなメニューを作っています。ただ、サンドイッチ用食パンだけは日本より激安なので、昼食にはサンドイッチやハンバーガーを作って食べたりしています。

観光地はまだ一つも行っていません。東京に住んでいたときもそうでしたが、長く住む予定だとなかなか観光に行くモチベーションが上がりません（引きこもりの言い訳）。来年はハイキングにも挑戦したいです。

総じて、楽しく元気にやっています。バンクーバーに来られることがあればぜひ声をかけてください！

2023-12-01

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 での実際の発表はこちらから動画で見られます。

kaigionrails.org

ペアプロ/モブプロ開発のメリットと実践 Tips の紹介、そして LIVE モブプロを行いました。

私たちが所属する Tebiki株式会社では、開発やテストなど大半の作業を複数人で行っています。

フィードバックをもらうタイミングは、早ければ早いほど修正コストが低いというデータがあります（詳細は動画をご覧ください）。

ペアプロ/モブプロをすることにより、フィードバックサイクルを高速で回すことができ、結果的にプロダクト品質を向上させることができます。その上、ペアプロ/モブプロは楽しいです。

あと、レビューのやり取りって結構つらくないですか？コード見ながら直接話せば一瞬で終わることが何日もかかったりして。。。ペアプロだと、レビュー時間ほぼゼロです。

いろんな課題の解決策と思って導入したペアプロ/モブプロですが、導入当初はさまざまな問題にぶち当たりました。それをどうやって我々のチームが乗り越えたのか、そして実際どのようにペアプロ/モブプロをやっているのかを発表しました。

ペアプロ/モブプロ開発を本格的に導入したいチームにとっては参考になると思います。

LIVE モブプロでは、FJORD BOOT CAMP（フィヨルドブートキャンプ）のアプリを題材に使わせていただきました。

数週間かけて新機能を追加していたのですが、本番の約1週間前、発表の練習の段階になって、内容的にペアプロ/モブプロのよさを伝えるのに十分でないという話になり、急遽内容を変更することになりました。ちょうどよい Issue があって本当に助かりました。

（フィヨルドブートキャンプ関係者の皆様、使わせていただいてありがとうございました！）

発表内容の要約

ペアプロ/モブプロのメリット
- フィードバックのタイミングが早ければ早いほど修正コストが低い
- ペアプロするとソロプロに比べ不具合が少なくなる
- ペアプロで増えるコストよりペアプロによって減らせる修正コストの方が大きい
我々がペアプロ/モブプロ開発導入によって解決したかった課題と導入後の結果
- レビューが終わらない
  - →レビュー依頼〜マージに平均2日以上かかっていたのが、ペアプロ開発導入後は24時間以内に
- 属人化
  - →アンケートでは全員が属人化が減ったと思うと回答
- 新メンバーがキャッチアップしにくい
  - →アンケートでは全員が新メンバーのキャッチアップが早くなった/どちらかといえば早くなったと思うと回答
ペアプロ/モブプロ導入後の課題と解決策（ペアプロ実践 Tips）
1. うまいやり方がわからない
  - →Slack のハドルミーティングで画面共有
2. ペアの息が合わず迷走する
  - →開始前に方針を書き出す
3. めちゃくちゃ疲れる
  - → 1時間やったら10分休憩
4. ペアの役割を交代するタイミングを失う
  - →時間で強制的に区切る（15〜20分）
5. ドライバー超大変、ナビは見てるだけ？
  - →ドライバーではなく「タイピスト」、ナビが進行役でタイピストはタイピングする役割
LIVE コーディング
- 題材：フィヨルドブートキャンプで実際に使われているアプリ

speakerdeck.com

登壇しての所感

こんな大きなイベント登壇は初めてかつオフライン登壇も初めてででしたが、運営の方々からの連絡は丁寧でわかりやすく、安心して当日を迎えることができました。本番もトラブル等なく大変スムーズでした。

発表の様子（写真）

本番は3人いたこともあり、思ったほど緊張しませんでした。手は震えてましたが…

3人いたら準備も分担できるから1人で登壇するより楽かと思いきや、必ずしもそうではありませんでした。各メンバーで思っていることが違ったり、うまくいかなかったりして揉めそうな場面も何度かありました。バンドの解散理由でよく聞く“方向性の違い”ってこういうことなのかと思ったりもしました。

でも、終わった今感じているのは、楽しかったという気持ちが一番大きいです。大変なこともありましたが、この3人で Kaigi on Rails という大舞台で発表することができてよかったです。

会社や同僚にもたくさんサポートしてもらいました。この日のためにTシャツやシールを作ってもらったり、内容についてアドバイスをもらったり、業務時間内に準備・練習をやらせてもらったりなどなど。

自分が言うのもあれですが、いい会社だなーと思いました。

最後に

個人的に、毎年楽しみにしていたイベントで登壇する機会をいただけて感慨深く、うれしかったです。

初回のとき書いた記事を見つけました。。。

masuyama13.hatenablog.com

運営の皆様、素晴らしいイベントを開催していただいてありがとうございました。

ということで、これからも毎日ペアプロ/モブプロやっていきたいと思います。

ついでに宣伝ですが、「ほぼ全部ペアプロ開発」に興味のある方、ぜひ一緒に開発しましょう〜

Tebiki株式会社

2022-12-18

近況報告（プログラマになって1年8ヶ月）

日記・ひとりごと

これは「フィヨルドブートキャンプ Part 2 Advent Calendar 2022」の18日目の記事です。

フィヨルドブートキャンプ卒業生として近況報告をします。

今後やっていきたいこと

最近は、テスト（RSpecとか）に興味があるので、そこをもっと勉強していきたいです。効率的なテストケースの洗い出し方とか、テストに必要最低限の DRY はどの程度か？とか。

あとはスクラムについても勉強中です。先月 PSM I という試験を受けて、スクラムガイドについて最低限の知識はついたものの、実践時にはスクラムガイドに書かれていない部分がたくさんあってわからないことばかりなので、本を読んだり勉強会に参加したりしています。結局は、そのチームに合ったやり方を見つけるしかないですね。

scrapbox.io

TypeScript の勉強も始めました。どうも JavaScript に苦手意識があるので、これを機に TypeScript マスターになって苦手を克服したいと目論んでいます。

フィヨルドブートキャンプ生の名に恥じないようにやっていきます〜

読んでいただきありがとうございました。

2022-10-09

Kaigi on Rails _2022_ new でペアプロについて LT しました

勉強会など

2022年10月9日（日曜日）に開催された、Kaigi on Rails 2022 new というイベントで LT（5分間）をやらせてもらいました。10月21日・22日に開催される Kaigi on Rails 2022 のプレイベントです。

YouTube ライブ配信で、参加者は80名ほど。

今働いている会社で取り組んでいる「ノンソロ開発」をやる中で、チームで試行錯誤してみつけた「ペアプロをスムーズに進めるための Tips」について発表しました。

スライドはこちら。

speakerdeck.com

自分も実際やってみるまで知らなかったのですが、1時間以上ペアプロ・モブプロやるとめちゃくちゃ疲れます。休憩大事。

今回は5分という短い時間だったので「ノンソロ開発」自体の意義などにはふれられなかったのですが、フィードバックサイクルを高速に回すことで、質の高いプロダクトをできるだけ早くユーザーに届けるために導入しました。

そのほかの LT も興味深いものばかりで、Rubocop 好きとしては特に気になったのがこちらの発表。早速リポジトリだけ作ってみた！

先程のLT資料です。「雑Custom Cop作りのススメ」https://t.co/8qqasEICW4 #kaigionrails
— Yudai TAKADA / ydah (@ydah_) 2022年10月9日

運営の皆様、LT 聞いてくれた皆様ありがとうございました。

Kaigi on Rails 本編も楽しみです。

kaigionrails.org

2021-04-11

『達人に学ぶDB設計徹底指南書』輪読会をやった

達人に学ぶDB設計徹底指南書

作者:ミック
発売日: 2013/08/07
メディア: Kindle版

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回目に一人で読んだときはそれを知らず、理解できないところが多かった。

現在、現場ではサロゲートキーが使われることも多いようだ。

サロゲートキーは連番か

ちょっと話は逸れるが、サロゲートキーを連番にするかランダムな数字にするかという話題で興味深いツイートを教えてもらったのではっておく。

ベースブレッドのシナモンとメープルがうまいらしいので、ベースブレッドの購入を再開してみる

ベースブレッドのマイページを見たら、注文番号が連番くさいので、一日当たりの注文量を出してみたら、割とえげつない事業成長をしていて、サブスクビジネスのすごさが分かった、今は月商8000万くらいぽい pic.twitter.com/IOukckfiwt
— ところてん (@tokoroten) January 4, 2021

たとえば、ユーザーIDが連番だと、登録した人が「全ユーザーが何人いるか」わかってしまうので、あえてランダムな数字にすることもよくある。

難しい用語にこだわらなくていい

この本では、部分関数従属とか推移的関数従属のように難しい用語がいくつか出てくる。

現場ではあまり使わないようなものもあるので、細かい用語を一つ一つ覚える必要はない。難しい言葉は、ざっくり理解して次出合ったら覚えるぐらいでよさそう。

輪読会の概要

毎週土曜日22時〜23時に Discord で開催し、全13回。

参加者は、多い日は20人弱、少ない日は3人ぐらい。

項目ごとに5〜10分の時間を取って各自読みながら疑問点などを HackMD に書いていき、時間が来たら意見交換を繰り返す流れで進行した。

第7〜8回は、参加者を2チームに分けてモブプロっぽく ER図の作成会をやった。

参加してくれた皆さん、bluerabbit さん本当にありがとうございました。

2021-02-28

『トヨタの失敗学「ミス」を「成果」に変える仕事術』を読んだ

読書

トヨタの失敗学「ミス」を「成果」に変える仕事術

作者:(株)OJTソリューションズ
発売日: 2016/08/04
メディア: 単行本

どんな本か

「失敗=悪」。これが世間の常識です。だから誰もが「失敗などしたくない」と思いながら仕事をしています。「失敗したら上司に叱られる…」「問題を起こせばまわりに迷惑をかけてしまう…」「失敗したら責任をとらされる…」

このような事態が想定できるからこそ、「失敗しないように無難に進めよう」「失敗したら、バレないように隠してしまおう」「いざとなったら力技でごまかそう」という発想になってしまいます。しかし、「失敗は避けなければならないもの」という意識でいるかぎり、失敗から目をそらす姿勢が強くなります。そして同じような失敗を繰り返すことになり、事態は悪化していきます。また、新しいことや困難なことへのチャレンジにしり込みするので、職場のチームも自分自身の成長も減速します。

トヨタの現場の第一線で活躍してきたトレーナーたちが、口をそろえて証言していることがあります。「トヨタの現場では、たくさんの問題やトラブルが起きる。でも、『失敗』という言葉はほとんど聞かなかった」もちろん起きた現象だけをとらえれば、トヨタにもミスやトラブルなど大小さまざまな失敗がありますが、少なくとも現場レベルでは「失敗」という概念は存在しません。失敗したことをそのまま放置したら、それは文字通りの「失敗」に終わってしまいます。しかし、失敗に正面から向き合い、次に活かすことができれば、その失敗は改善プロセスのひとつとなります。「失敗」が「失敗」で終わらないのです。

現場のメンバーが知恵を絞って、「なぜ不良が起きたのか」を徹底的に考えます。そして、問題を引き起こしていた原因を突き止めて、二度と不良が出ないような対策を実施し、そのしくみは、他のラインや工場にも展開することで、組織として強くなっていくのです。

つまり、トヨタの現場では、問題やトラブルをよりよいモノづくりをするための「改善の機会」ととらえているのです。トヨタの現場で働く人たちにとって「失敗」とは、改善へとつなげるチャンスであり、成果に結びつける「宝の山」です。 (はじめにより)

Amazon.co.jp より

所感

いろんな職場で使えそうな実践的な内容だった。上の抜粋を読めば大事なところがなんとなくわかるかもしれない。

「失敗＝悪」ではない

失敗は改善のタネで宝の山。これが一番大事だと思った。今まで、失敗についてじっくり考えたことがなかったが、当然のように失敗は悪いことだと思っていた。

できれば失敗は避けたいし、もし失敗したら隠したい。そう思っていた気がする。

この本を読んで失敗は悪ではないとわかっても、実際に仕事をする中で、失敗を隠したい気持ちをゼロにできるだろうか？

自分の無知やミスをさらけ出しても責められたりバカにされたりすることがない、心理的安全性が確保されている職場なら、可能だと思う。この本の中で「心理的安全性」という言葉自体は出てこないが、トヨタでは、工場で異常を見つけてラインを止めた作業員を誰も責めたりすることはなく、むしろ奨励されているという。そうやって問題を小さいうちに発見し、改善を続けていくことが大事なのだと知った。

心理的安全性が低く、失敗したとき個人が責められるような職場だと、失敗を宝の山と考えるのは難しいだろう。先日読んだ不機嫌は罪である (角川新書) という本にも似たようなことが書いてあったのを思い出した。みんながニコニコして明るい職場は、離職率が低くなり業務効率が上がるそうだ。Googleによる調査で、生産性の高い職場にもっとも重要な要素が「心理的安全性」とされたことにも触れられていた。

心理的安全性が高いと生産性が高まると聞いて、メンタルが仕事の生産性にまで影響を与えるのかと漠然と考えていたが、今回『トヨタの失敗学』を読んで、生産性が高まる理由がわかった。それは、失敗を隠すことがなくなるだけでなく、日頃からさまざまな情報が共有され、ちょっとした気づきの段階で失敗の芽を摘み取ったり改善したりしていくことが可能となるからだろう。

エンジニアは、気をつけていてもバグを一度も出さない人はいないので、この「失敗学」の考え方はとても大事だと思った。

失敗から学び、改善してよりよくすることができれば、それはもはや失敗ではなく成長の1ステップ。

大事だと思ったことをメモ

「失敗＝悪」ではない
失敗を放置したら文字通りの「失敗」になってしまう
失敗は宝の山、改善のタネ
失敗したら真因を追求する
- 何が起こった？
- なぜなぜ5回
失敗しても個人の責任にしない
- 真因ではない
- 失敗が隠されるようになる
- チャレンジしない組織になってしまう
「人はミスをするもの」という前提で失敗しないしくみをつくる
小さい問題は繰り返されたり、後で大きい問題になったりする
問題が小さいうちに、自らの意思で問題を明るみに出す
よその失敗を自分ごとととらえて対策を講じる
明るい職場は「失敗」が隠れない
あきらめずに前進を続ければ「失敗」にはならない