【小ネタ】最近読んだ本について

最近読んだ本について何となく書いてみます(漫画は含めていないです)。量が多いので6ヶ月以内に絞り、内容を2/3以上読んだものに限定してみました。

購入しただけで積読状態な本は主に技術書が多いので、そろそろそっちを消化するか…と思いつつ早幾年。。。

本紹介

kindle unlimited な本が半分くらいある。書籍代はケチらない主義だけど、unlimitedで読み放題のお得感につい釣られてしまいます。

ビジネスモデル思考法 ストーリーで読む「儲ける仕組み」のつくり方

ビジネスモデル思考法 ストーリーで読む「儲ける仕組み」のつくり方

マーケティング・インタビュー 問題解決のヒントを「聞き出す」技術

マーケティング・インタビュー 問題解決のヒントを「聞き出す」技術

ユーザーインタビューをはじめよう ―UXリサーチのための、「聞くこと」入門

ユーザーインタビューをはじめよう ―UXリサーチのための、「聞くこと」入門

ザ・ファシリテーター

ザ・ファシリテーター

凡人が最強営業マンに変わる魔法のセールストーク

凡人が最強営業マンに変わる魔法のセールストーク

PROOF MARKETING(プルーフマーケティング)?ギネス世界記録®の突破力

PROOF MARKETING(プルーフマーケティング)?ギネス世界記録®の突破力

仕事は楽しいかね?2

仕事は楽しいかね?2

仕事は楽しいかね? (きこ書房)

仕事は楽しいかね? (きこ書房)

一生使える見やすい資料のデザイン入門

一生使える見やすい資料のデザイン入門

あなたの話はなぜ「通じない」のか (ちくま文庫)

あなたの話はなぜ「通じない」のか (ちくま文庫)

おまけ(技術書)

最近、あまり技術書を買わなくなっている気がする… 半年に限定するとこんなもんだろうか。積読状態なままのものが他に3冊くらい…💦

レガシーソフトウェア改善ガイド

レガシーソフトウェア改善ガイド

Webフロントエンド ハイパフォーマンス チューニング

Webフロントエンド ハイパフォーマンス チューニング

さいごに

色々読んでる気になっていたけど、積ん読や途中で読むのを辞めた本を除くと、1ヶ月3冊程度のペースだったのでガッカリ。kindle unlimitedは値段を気にせずつまみ食い出来るのが良いのですが、内容が想像と違ったり、いまいち面白くなかったりで途中で読むのをやめることが非常に多いので、今後はunlimitedではなく良書に絞って冊数を増やしたい感があります。

活発な議論を促すために必要な「心理的安全」の具体策について考えてみた

f:id:haru_skywalker:20170626175155p:plain

私は現在、Webサービスの開発に携わっていて、サービスの今後の追加機能だとかプロダクトの今後について、チーム内でミーティングをすることがよくあります。現会社に入社するまでは、フリーランスで数社のベンチャーやスタートアップのプロダクトの開発チームの一員としてお仕事をさせてもらっていましたが、その時にも、同様にプロダクトの方針に関わるミーティングにも何度か参加させていただく事がありました。

入社して5ヶ月が経ったのですが、フリーランス当時と今とで、チーム内のミーティングの在り方が全然違うなぁ、と思うことがよくあります。そのことについて少し書きたいと思います。

スタートアップでよく見る人間関係

私の半径5m内での感想になりますが、スタートアップの創業メンバーというのは、以前から友人関係・同僚関係にあった人同士が会社を興しているケースが多く、人間関係がフラットな状態から始まっていることが多いように思います。人間関係がフラットというのは、先輩/後輩、上司/部下、経営者/従業員といった、各人をカテゴライズする属性を感じさせない人間関係のことを言っています。

そういった人たちのコミュニケーションは、多少の気遣いはあるものの、会話は基本タメ口だし、時には冗談も言い合える関係。プライベートな情報も日常的に共有しており(おそらく無意識に)、その人の性格だけでなく、得意・不得意、共感ポイントなどもある程度分かり合っている。

そのため、定例ミーティングも形式的なもので終わらず、何も発言しない人がいた…といった無意味な打合せは少なかったように思います。

少人数のプロダクト開発の現場において、例えばプロダクトの今後の方向性を議論するような重要な場面では、密度の高いブレストが求められると思います。フラットな関係の人同士の集まりでは、「一理あるけど、それってちょっと違くね?うまくいえないけど」といった気軽な会話が可能で、総じて活発な議論になりやすい。(議論が発散していくリスクも多少ありますが)

一方で、フラットな関係ではないサラリーマンチーム(と、ここでは呼ぶことにします)の場合、もし誰かの発言に違和感があっても、「うーん、それはどうなんだろう… でもハッキリとした根拠や理由が今は思いつかないな… なんて言えばいいだろう」などと心の中でワンクッションが入って、発言を迷っているうちに話がどんどん先に進んでしまう、といったケースはあるんじゃないでしょうか。(私はよくある)

「活発な議論」というお題目においては、どう考えてもフラットな関係のメンバー同士のほうがその目的を達成しやすいと思うのです。

フラットな関係を作るためには

チーム開発の文脈では、「発言しやすい雰囲気(心理的安全)を作るのが大切」といったことがよく言われています。

確かにその通りなんだけど、でも具体的にどうやったらいいの?といつも思うのです。いきなり全員が友達になれるわけではないし、ある程度の規模の会社なら、当然ながら上司/部下の関係は出来上がっていて、すぐに取っ払うことも難しい。

いきなりフラットな関係に持っていくのはかなり無理があるので、おそらく段階的にやっていく必要があると思っています。

例えば、まずファーストステップとして、「お互いをニックネームで呼び合う」くらいから始めてみる。これ、人間関係構築の初期における鉄板で、ニックネームで呼び合うと、セカンドステップの「タメ口で話す」に移行しやすい、という副次効果もあります。

ビフォー: 「阿部さん、この件の進捗どんな感じでしょうか?」
アフター: 「アベちゃん、この件の進捗どんな感じ?」

“ちゃん付け” で呼びかけてるのに、敬語だと逆に違和感ありますからね。

私にはこの程度しか今は浮かばないのですが、精神論ではなく実践できる具体的案について、何かアイデアがあればぜひ共有していただきたいです。

さいごに

一見するとくだらないと思われるかもしれません。でも、本気で「チームの心理的安全」について考えるなら、ただ漠然と「各人が気をつける」だけでは何も進展しないので、具体策にまで落とし込んで実施していく必要があると思うのです。

もし、ニックネームやタメ口は性に合わないわ… というメンバーが多そうな場合には、もういっそ諦めて、誰か絶対的なリーダーシップを持った人の独裁チームにする方がまだマシ。だと私は思っています。中途半端にお互いを立てあって、気を使い合った上辺の議論よりも、ジョブス的なリーダーシップを持つ人に導いてもらうほうが、議論もまとまって意味のある打合せになる気がします。

アプリエンジニアもUIレビューしよう

f:id:haru_skywalker:20170617020613p:plain

私が所属しているチームはBtoBのWebサービスを開発しているのですが、専属デザイナがいるわけではないため、デザイナ経験のある私がUI全般の責任者をしています。

UIに変更が入る時は、Issueの時点でデザインをどうするかコメントを求められたり、担当者がPRした内容のうちUI部分のレビューをする、という感じになってます。

小さな機能変更であれば、現場の開発者がボタンを1個増やす程度の修正はよくあるかと思います。そういうちょっとしたUIの変更時に、コードレビューとは別に「UIレビュー」を別のエンジニアがやってみたらどうだろう?と、ふと思いました。

というのも、今日偶然このスライドを見て、これは良いなと思ったのです。


初めてのレビューでも、二次受けレビュアーがいてくれれば安心できますよね。自分が気付けなかった部分があれば、指摘で更に成長できる。

これって何もコードレビューだけじゃなく、色々なことに応用できそうです。そう、UIレビューです。

ツールを使うだけがデザインではない

デザインを勉強したいけど、デザインツールを使ってまで何か作るのはちょっと…と思ってる人は多いんじゃないかと。それなら、UIレビューから初めてみませんか。

おそらく、大半のエンジニアはUIデザインに真剣に向き合う機会がほとんど無いと思うのです。なのでレビュアーになることでその機会を作りましょう。

実際にやってみると分かるのですが、デザインルールが決まっていないグレーゾーンのものって結構多くて、例えばサブミットボタンなら色や配置は決まっていても、そうでないボタンの色/大きさはどうすべきか?など。ある程度ルールがあったとしても、やはり例外は出てくるものです。そんな時に、

  • このボタンデザインはこれで正解なのか
  • 配置はここで良いか
  • ラベルは利用者にとって分かりやすいか
  • 前後のパーツとのバランスは取れているか
  • 押した時の動きはどうか

たかがボタン1つですが考える視点はいくつもあります。コンシューマ向けサービスだと、更にコンバージョンへの影響なども気にする必要があるかもしれません。

レビューを正しく行うことよりも、これらを真剣に考えることが大切なのです。二次受けのレビュアー(デザイナ)がいれば、自分のレビューの答え合わせになりますし、気付けなかった指摘があれば一粒で二度美味しい。

これならイラストレーターやフォトショップを使うこともないので、やってみようかな?という気持ちになれたんじゃないでしょうか。

UIレビューの具体例

デザインレビューって個人の好みになってしまうのでは?と懸念するかもしれませんが、大きなデザイン変更ではなく、ちょっとした変更のレビューであれば、好みが入る余地はあまり無いです。

例えば今日私が実際にレビューしたのは、こんな感じでした。

これまではグレーのボタンが1つだったボックスに、機能追加でボタンが2つ追加されていました。1つの時は良かったのですが、狭いボックス内にグレーのボタンが3つとなると事情は変わってきます。私がコメントしたのは、

「メイン操作となるボタンだけ色を付けて目立たせ、利用者が迷いなく操作できるようにしよう」

というものでした。結果だけ聞くと簡単そうだと思ったかもしれません。実装している時には既存のデザインに引きずられたりして、案外気付かないものですが、レビュアーになるとよく見えてきます。

そしてこの程度なら、指摘された人は今後似たようなケースの時にすぐに応用できますね。小さな変更のレビューでは、指摘の大半は容易に実践できて応用可能なものなので、爆速でパターンの引き出しが増えていきます。

毎回レビューするのも大変だとは思うので、期間を決めてやるといいかもしれません。例えばチーム内で週ごとに順番でやるのも良いと思います。

さいごに

どんな方法であれ、大切なのは真剣に向き合う機会を作ることです。それが意識に繋がります。私たちの身の回りは、ありとあらゆるデザインで溢れています。意識が芽生えるだけで、目に入るほぼ全てのものが勉強対象になるのです。

今日、新しい洗濯機が届いたのですが、この操作パネルを見てください。

一色しか使っていなくても、ボタンの形状や大きさが異なるだけで、分かりやすくなっています。 意外と身近なところに色んな発見やヒントはあるのに、意識していないと気付けない。でも意識していれば気付くこともある。ただそれだけのことなのです。

Slackの専用チャンネルでフロントエンド周りの情報を垂れ流している話

f:id:haru_skywalker:20170613005305p:plain

早いもので、私が転職してから約5ヶ月になろうとしております。

二週間ほど前から、社内Slackでフロントエンド周辺の最新記事やトレンドなどを垂れ流すチャンネルを作りました。

内容は、Webブラウザ関連だったり、JavaScript関連だったり、JSフレームワークだったりと、とにかくWeb周辺で私がビビっと来た旬の情報を垂れ流すだけの、フロントエンド情報の専用チャンネルです。

なぜそんなチャンネルを作ったのか

単に自分の情報を整理する場が欲しかったのと、あわよくば他の人からも何らかフィードバックがあったら最高だと思ったから。

私が所属する会社はクラウドインテグレーションがメインなので、フロントエンドの話で盛り上がれる機会があまりないのです。無いなら自分で作ろうぜ!の精神により、勝手に作って勝手に垂れ流して、勝手にコメントしております。

現段階では9割方私しか発言していないですが、そんなこたぁ構わない。私が飽きるまで続ける所存です。

やってみてどうだったか

今まではローカルのメモにURLと簡単なコメントを残したりしていたのですが、これってすごく勿体無いなと。自分で言うのもなんですが、情報収集だけは割りとコツコツやってきたほうなので、こういうのは共有したほうが絶対良いよな、と。なんなら他の人の意見も聞きたいし、と。

でも、パブリックにするのは私の性格上ダメなんですよね。情報元に気を遣って当たり障りないコメントにするのは面倒だし、中途半端な知識のままネットの海に流したくないし・・・とアレコレ考えるとスピードが落ちる。何よりブログ形式にするほどの熱意も無い(文量的な意味で)。

なので、結論としてはSlackで簡単なコメント付きで共有するくらいが丁度いい。これが本当に丁度いい。

ちょっとしたコメントと共にURLを共有するのをマイルールにしているのですが、実際に続けてみると、内容をそれなりに理解しないと簡易コメントも書けないので、流し読みで終わらせず、知らなかったこと・分からないことは調べる癖が付きました。今までのようにローカルでストックするだけだと、この強制力は働かないので、これは続けてみて良かったと実感している点です。

さいごに

私としてはこのSlack垂れ流しは結構気に入っております。

情報のシャワーを浴び続けるうちに、点と点が繋がって線になることはよくあるので、数ヶ月単位では目に見えた効果を感じなくても、年単位になると違うはず。そして何より継続は力なり。ほぼ自分のためにやってるようなものなので、これからも自分よがりな垂れ流しを続けます。

以上。

特に理由はないけど1日1冊読むチャレンジをしてみた話

f:id:haru_skywalker:20170323004538j:plain

タイトル通りで、特に理由はないけど最低1日1冊読んでみるかと思って3日続けてみた。(先週分も合わせると計24冊。内15冊は漫画)

たった3日なので、まったく偉そうに語れるような身分ではないけど、ちょっとした感想を。

  • 今自分がめっちゃ気になる・知りたい内容であれば1冊読む程度なら楽勝
  • 「ちょっと興味がある」レベルの内容だと途中で何度も睡魔に襲われる
  • 1日2冊行けるかな?とチャレンジしたら、インプット過多になって辛かった

概ねこんな感じ。読んだのはいわゆるビジネス書の類なので、小説とか技術書だと全然違うと思う。

上記以外で思ったことを、ダラダラと書いてみる。

興味津々な分野をまとめて読む

たとえば、マーケティングとかプロダクトマネージメント、UI/UX周りが自分の中で今一番知りたい情報なのだけど、関心度が高い分野は「仕事に直結しそうな情報が知りたい」など、自分の目的が具体的かつ明確なので、書籍全体を熟読する必要がなく「ここは役に立ちそうだからじっくり読もう」「ここは読まなくても良さそう」などの判断が簡単。つまり、必要な情報の取捨選択が容易なので、サクサク読み進められる。(=必要ないと思ったページはガンガン飛ばす)

今直面している課題や自分の状況に置き換えながら読めるので、読みながらアイデアもどんどん出てくるし、それをメモる行為も楽しい。あっという間に読了。

同じ分野の本を連続して読むと、表現が違うだけで内容が重複することが多いので、2冊目以降はさらにスピードが加速する感じ。なので、短期間でまとめ読みすると効率がめちゃ良い。

興味が薄い分野の対策

まず興味を持つことが大切なので、最初に目次をじっくり眺め、内容を予想して「ここは知りたい内容かも」と具体的にイメージするのが大切かなぁ、と。これは今も試行錯誤中。

ただ、確実に読書ペースは遅くなるので、もしなかなか読み終わらないなら、途中でやめても良いと決断する勇気も必要かと。(高い本だとツライですが…)

それから、睡魔に襲われた時は無理をしない。寝よう。

とりあえずアウトプットする

1冊読めば何かしら響いた情報がある。でもブログを書くほどではないし、そもそもブログとか面倒。そういう時はどこか垂れ流せる場所にとりあえず記録する。ツイッターでもいいけど文字数制限が面倒。今日試してみて良いなと思ったのがSlack。自分専用のチャンネルにダラダラと垂れ流してみた。

自分なりに理解した情報を、自分の言葉で言語化すると、記憶の引き出しが1個増えたような感じになる。インデックス付きでDBに格納されるようなイメージというか。同分野の書籍を複数読んだら、リレーションも増えていくイメージ。インデックスの再構築も起こる。

私はどうにかして仕事に繋げてやる!という気持ちで読んでいるので、アウトプットするモチベーションになっている、というのもある。

さいごに

しかし、興味津々なものってそんなに多くはないので、楽勝モードなのは最初だけだろうなぁ。

電車の移動時間で読むのが私的には一番ピッタリ来るので、リモートワークな日は読まない可能性が高いし、まぁ年間60冊読めれば良いほうかなと思ってる。

そして何より、Kindle unlimited のおかげで、値段を気にせず色々読めるのは大変ありがたい。アマゾンさん、ありがとう。

おらコミュニティさ行ぐだ

3月11日に行われた、AWSユーザグループのイベント「JAWS-DAYS 2017」のイベントで、トークセッションのスピーカーとして参加してきました。

f:id:haru_skywalker:20170317105107j:plain

jawsdays2017.jaws-ug.jp

AWSに携わる仕事に興味のある人もまだない人も、AWSやエコシステムで輝いた働きかたをしてる人たちの体験談にディープダイブしてみましょう」という趣旨のこのトークセッション。私が選ばれたのは、7年間のフリーランスを辞めてAWS専業の会社に転職したことが理由かな、と自分では思っています。

トークの内容については、そのうちアスキーさんが記事にしてださると思うので、私はマフィアトークで話しきれなかった「コミュニティに関わって良かった」ことについて書きたいと思います。

ascii.jp

AWSマフィアとは

トークセッションのタイトルに「マフィア」と物騒な名前が付いているのですが、それは「PayPalマフィア」と呼ばれる方々からインスパイアされたものだそうです。

tomoyaishida.com

上記サイトから一部引用します。PayPalマフィア、そうそうたるメンバーですね。

ペイパルマフィアとはオンライン決済システムPayPalの創業に関わったメンバーのことを指します。彼らはPayPalを創業し、その後eBayに売却、それにより数百億円規模の資産を手に入れます。そしてその資金を元手に各々が新たな会社を立ち上げ、そこで生まれたのが以下の企業です。
  • デビット・サックス → SNS「ヤマー」CEO
  • イーロン・マスク → 宇宙開発企業「スペース・X」、電気自動車会社「テスラモーターズ」CEO 太陽光発電会社「ソーラーシティ」会長
  • ピーター・ティール → 投資会社「クラリウム・キャピタル」創業者
  • リード・ホフマン → SNSリンクトイン」CEO
  • ジェレミー・ストップルマン → SNS「イェルプ」CEO
  • チャド・ハーリー →  動画サービス「YouTube」創業者

AWSコミュニティに関わったことが大なり小なり影響し、新たな道を進んでいる人にフォーカスを当てる企画にピッタリのネーミングです。

今回で2回目となるマフィアトークのスピーカーに選んでいただき大変光栄です。ありがとうございました。

コミュニティを通して得られたもの

転職の理由や経緯などは以前にもブログで書きました。

bump.hatenablog.com

ただ、その時はコミュニティとの関係については深く言及しなかったので、あらためて書こうと思います。

何度か書いていますが、私はフリーランス当初は仕事があまりなく日々悩んでいたのですが、ふとしたキッカケで「クラウド」というものを知り、その流れでユーザーコミュニティが主催する勉強会に参加するようになりました。それはJAWS-UGさいたま支部の第1回目の勉強会です。

その勉強会で、今回のマフィアトークの企画者でもある吉田さん(当時はcloudpackのエヴァンジェリストでした)や、ソニックガーデンの倉貫さん、さいたま支部の皆さんと初めてお会いしました。

吉田さんから、千葉在住の人が主体のユーザーグループが新たに出来る、と教えてもらい、当時AWSのことなんてほぼ何も分かっていないにもかかわらず、私も立ち上げメンバーに入れてもらうことに。それがすべての始まりでした。(倉貫さんからは他のコミュニティのことを教えていただき、それが後にRuby界隈の方々との交流に繋がったりもしています)

そうして各種イベントや勉強会の運営に携わるうち、生まれて初めてのLT、そして登壇する機会をもらいました。最初は「LTなんて無理です」と断っていたのですが、メンバーが背中を押してくれたのもあり、初めてのLT。これが自分の世界が変わった瞬間だったように思います。

たとえ目立った実績が無かったとしても、自分の中にある知識や経験など、何かしら発信できるものはある。高度なことじゃなくてもいい。もしネタに尽きたら、LT駆動で勉強してその成果を発表すればいい。どうせ自分には出来ない…と自らの可能性に蓋をしない。必要なのはほんの少しの勇気だけ。セルフブランディングを意識するようになったのもコミュニティを通じて得たものです。

JAWS-UGだけでなく、JS関連のコミュニティや大阪開催のコミュニティのイベントなどにも参加しました。おかげさまで多くの方とお知り合いになることができ、珍名なのが幸い(災い?)して、初対面でも「名前は見たことがある」と言ってもらえることも増えてきました。(特にこの業界は女性は少ないので覚えてもらいやすい、というのもあるかとは思います)

こうやって、コミュニティを通じて様々な人たちと知り合いになれたこと、学習範囲が広がったこと、諸々が影響して徐々に仕事の量も幅も増えていきました。会社員に戻ると考えた時も、ありがたいことにコミュニティで知り合った様々な方々から声を掛けていただき、その一人が現所属会社の代表の大石さんでした。

まとめ

こうやって振り返ってみると、フリーランス時代から今回の転職に至るまで、コミュニティに関わったことの恩恵は大きいなぁとあらためて思います。

私は特に突出した技能を持っているわけではないですが、たまたま自分の持ち合わせていたスキルや経験が、プロジェクトや会社にマッチすると感じてもらえただけだと思います。世の中には他にも同じようなスキルセットの人もいるし、もっともっと優秀な人も大勢いるけど、知り合うキッカケがないだけ。私の場合は、そのキッカケを作ってくれたのがコミュニティだった。そう思います。

「LTも無ぇ、登壇も無ぇ、執筆なんてあるわけ無ぇ、オラこんな自分嫌だ〜」と嘆く前に、まずは興味のあるコミュニティを覗いてみてはどうでしょうか。ただ参加するだけ、の状態からもう一歩踏み込んでみる。そのちょっとした勇気が、人生を変えるキッカケになるかもしれません。

転職先で自席がなくて最高だと思った話

f:id:haru_skywalker:20170223002351j:plain

フリーランス卒業のブログを以前に書きましたが、転職先に入社して1ヶ月が経ちました。

bump.hatenablog.com

ですが、実は1月後半からずっと続く家族および自分の体調不良(インフルエンザ1回、発熱3回)で、まだ貢献出来ているとは言えない状況なのが精神的にツライところです。(スキルが未熟というのもあるのですが💦)

というわけで、ワークスタイルや仕事内容などについてのエントリーは今後書くとして、入社してみてこれは良いなと思った超個人的な感想を書きたいと思います。

自席がないって最高✨

会社では、自席が決まっておらずフリーアドレスになっています。つまり、自分の仕事の状況に合わせて好きな席で仕事ができます。

www.publickey1.jp

詳しくは上記をご覧ください。

このフリーアドレス制の何が個人的に超良いと思ったかというと、デスクが散らからないことです。いくら自分だけデスク周りを整理整頓しても、他人のデスクまでは干渉できないですが、自席がない=デスクに私物を置けないので、必然的に全席散らかりません。

これ、些細な事だと思う人もいるかと思うんですが、ワタシ的には超重要です。

仕事中に散らかったスペースが視界に入るとそれだけで気が散る場合ってよくあるのです。何か書かれた付箋紙、所狭しと並ぶフィギュア、乱雑に置かれている書籍などなど。ホコリが溜まっていたり不潔な状態のデスクが隣だったら、最悪中の最悪です。

それが一切ない。というか出来ない。

一人ずつロッカーが用意されているので、私物はそちらに入れるようになっています。そのため、不要な私物を持ち込まない効果があります。皆さん誰しも一度は経験あるんじゃないでしょうか、退職時や異動時にデスクを片付けると「そういえばこんな物あったなー」という私物の数々。ハサミやホチキスなどの文房具類の多さに驚く瞬間。書類なんかは典型ですよね、とりあえず的な感じで山のように入ってませんか。

割れ窓理論

割れ窓理論ってご存知でしょうか。

割れ窓理論とは | ビジネス・心理学用語集:意味・解説など | ビジネス心理学

割れた窓理論というのは人間の心理を表した言葉です。割れた窓を放置していると他の窓も割られやすくなる、というものです。ゴミだらけのところというのはゴミが捨てられやすいのですが、ホコリひとつなくきれいに維持されている場所を汚すのは気が引ける。 この心理を利用することで、犯罪や風紀の乱れを早い段階で抑止できる、という理論になります。
ニューヨークは非常に治安の悪い街でしたが、この治安対策としてジュリアーニ市長は割れ窓理論を利用しました。まずは地下鉄の落書きを一つ一つ消していったのです。 さらに地下鉄内において多発していた無賃乗車の取り締まりにも取り組んだのです。地下鉄に描かれた落書きを消していくことで、次第に地下鉄内における犯罪が大幅に減少したのです。そして次第にニューヨークにおいて発生していた凶悪犯罪の件数自体も減少しました。


この割れ窓理論が職場に与える影響については、下記サイトから一部抜粋します。

business.nikkeibp.co.jp

実際、「割れ窓理論」の通り、汚い作業環境では「これでいいや」と仕事の完成度に甘さがあっても許容してしまう空気があるし、果ては不正なども発生するかもしれない。この負の価値観の連鎖が「割れ窓理論」であるが、ニューヨーク市がこの理論に基づいて軽犯罪取り締まりを強化し凶悪犯罪を予防したように、不正の抑制とまでは行かなくても、作業環境が整然としており綺麗な状態であれば人間心理の常として、やはりいい加減な仕事ぶりは減っていくと思われる。

整然とした環境が人間心理に与える影響は、自分が思うよりも大きいものです。

綺麗なデスクのほうが思考も整然としてくる、という効果も当然あるのですが、私が一番大きいと思っているのは、散らかった状態だと「整理する」というタスクがずっと未消化状態で頭の中に居座り続けことです。気になっていることリストとでも言えばいいでしょうか。ちょっとしたタイミングでこれが集中を妨げる要因になるのです。

現に今わたしがこれを書いている自宅のテーブルの上は散らかっていて、このブログを書きながら2割くらいは意識を奪われている気がします😅

さいごに

フリーアドレスのことだけで熱く語りすぎた感は否めませんが、オフィスの綺麗さは個人の作業効率にも少なからず影響を及ぼしていると思っています。

転職先について良いと思ったことは当然これだけではないので、また色々と書いていきたいと思います。