許可を求めるな、謝罪せよ
久しぶりにイベントに参加してきました。
昔ほど積極的に外部イベントに参加することは多くはなくなりました。
今回はおしゃれな代官山で行われた、@type (転職＠type - マッチする求人情報が分かる、探せる、転職サイト)とエンジニアtype (エンジニアtype - エンジニアのシゴト人生を考えるWebマガジン)が主催の キャリアごはん というイベントに行ってきました。
実はこれ、2回目のイベントなのですが、初めて行われたイベントにも実は参加していて、今回2回目の参加でした。
以前のイベントはこちら、
engineer.typemag.jp
前回は無料でおしゃれなレストランで食事ができて、エンジニアのキャリアや仕事の話などをざっくばらんにできるイベントで、特に無料というところが良かったのと、
業界でもトップを走る人たちからノウハウを聞くことができるとてもいいイベントでした。
今回は無料ではなく、参加費1500円かかりましたが、それでもこれからの自分にとってプラスになることが得られるならば安いものだと思ったので参加しました。
参加している人の層は社会人で、30前後の方が殆どでした。学生でいた人もいるのかな？席が同じになった人たちは大体自分より5つか6つほど上のエンジニアの方々でした。
イベントについて
イベントの内容としては、テーマとして【2016年の技術と仕事】を語るがあったのでそれに準じた話でした。
前半は、業界のトップを走る方々のトークセッション。後半はグループに分かれて、パネラーを交えてのワークショップというものです。自由に食事を取りながら学べる感じです。(食事はビュッフェ形式)
ゲストのパネラーは
・楽天株式会社 技術理事 吉岡弘隆 氏
・株式会社トレタ CTO 最高技術責任者 増井雄一郎 氏
・株式会社ソラコム Confounder & CTO 安川健太 氏
・フリーランス iOSエンジニア 堤修一 氏
みなさんそれぞれ自己紹介も兼ねての最近のトレンドについてや、
働き方、キャリア、仕事に対する姿勢などとても面白い話でした。
そして後半の部としてパネルディスカッションが、
今回自分の席には、楽天株式会社の技術理事、吉岡弘隆さんが来てくださりました。
そこで話された話の中で１つ自分がとても納得したものについて紹介します。
許可を求めるな、謝罪せよ
本記事のタイトルにもなっている言葉ですが、これはイベント後半のワークショップで話されたものの１つです。
自分は今、100人規模のベンチャー企業でアルバイトとして働いてるのですが(Web開発の事業部は20人弱) この話が今いる自分の環境と自分にとって、とても大事な考え方だと思ったの、でここに書き残しておきます。
「許可を求めるな、謝罪せよ」はエンジニアで仕事をしていく上でとても重要なマインドの一つじゃないかと思います。
この言葉は、もともとアメリカの3M(３Ｍ｜３Ｍジャパングループ)という会社のメアリー・ポッペンディーク氏が話したものだそうです。
"It is easier to ask forgiveness than permission. With a sincere attitude toward one’s work, the chances of doing real damage or harm are small. Consequences from bad calls, in the long run, do not outweigh the time waiting to get everyone’s blessing."
『許可を求めることより許しを乞う（謝罪する）方が簡単である。ひたむきに仕事をすれば、深刻なダメージや危険にあう可能性は低い。間違った決定による時間が、長期的にみて、みんなの許可を得るために待つ時間を上回ることはない）』
出典：
http://multimedia.3m.com/mws/media/171240O/3m-coi-book-tif.pdf?&fn=3M_COI_Book.pdf
僕は今日、というよりついさっき、このイベントに参加するまではこの言葉すら聞いたこともありませんでした。
初めて聞いた時はその意味をイマイチ掴みとることができなかったのですが、この「許可を求めるな、謝罪せよ」というのは日本の社会的なルールとは相反している考え方の一つだということを今日話を聞いて理解しました。(日本の社会的なルールが悪いという話ではありません）
エンジニアの話でいうと、あるユーザーが使っているプロダクトがあるとしたらそれをさらに良くすることができ、かつユーザーがさらに幸せになる実装を行えるのであればそれは上司に許可を取らずとも実装してしまえ！
という、少し乱暴ではありますが「上司に許可を取る暇があったらコードを書いて幸せにしろ」ということです。
日本は社会的な文化で上司の許可、つまり、「許しを請う」てから動くことが一般的でありそれが常識とされています。しかしwebの業界では確かにその考えも大事だと思われていますが、それ以上にユーザの幸せが最優先だという考えの方が強くあります。
許しを請うことからスタートすることは不要なトラブルを防ぐことにもなりますし、責任的な話もきっちりつくため納得して話が進んでいくため安心感はあります。
ただその代わりに時間的資源はものすごくかかってしまうのは事実です。
簡単に実装を行えるはずなのに、その実装を行うまでの許可を取る資料作成や段取り決めに時間がかかり結果としてプロダクトの回収に時間がかかる。そういったことがたくさんあるのではないかと思います。
nanapi創業者の古川健介 氏(けんすう)さんもこのことについて記事を書いていました。
以下、参考
blog.livedoor.jp
謝罪せよ、というのは最悪やってみて悪かったら謝りましょうということです。トライ&エラー、やってみてダメだったら素直に悪かったことを謝りましょう。
ただ、この考え方で仕事をしていてもさすがに、「アプリのデータ全て消しました」や、「このアプリ自分は気に入らなかったので消しました」など。
プロダクトを使ってくれているユーザーが不幸せにならない選択肢に対しての考え方であるということを忘れていけません。
けんすうさんのブログではこんなことが書かれていました。
特に許可をとるために、説明資料をつくって、というプロセスは、時間がかかるだけじゃなくて、
説明資料内のロジックの整合性をあわせるために、資料のための案になっちゃうことが多々あるんですよね。
僕の前職のリクルートでも、許可というのはかなり少なかったのですが、それでも新規案をつくるときは、資料を頑張って作っていました。
しかし、資料段階では、どうしても資料での整合性をあわせるために、なんかいけていないロジックになったりしちゃう。
僕も同じことを感じます。何か提案をする時や、相手を口説く時には説得材料の資料をつくりその資料内でのロジックを合わせるための案になってしまい、結果、おもしろさがなくなってしまったり、やたらと時間をかけて無駄にしてしまったりすることがあります。
そんな時間があるくらいならばエンジニアたるものプロトタイプでもなんでもプロダクトを作って、プロダクトの改善してみせて、それらを上司にみせてチェックをもらいそのまますぐデプロイやら何やらやったほうが効率がいいです。
それで、「何勝手なことやっているんだ！」と怒られたら謝罪しましょう、それでことは済みます。
この「許可を求めるな、謝罪せよ」というエンジニアの考え方を組織で持つことはかなり難しいことだと思います。
すでに大きな組織30~40人ほどになるとまず無理ではないのかなぁと思います。新しくこの考え方を浸透させ、根付かせるのは。
ワークショップでは、この考え方を持った仕事をしたければ組織を変えるよりも自分が転職してこの考え方でやれる組織に入るほうがいいという話になりました。
自分を変えることは簡単ですが、組織を変えるというのはかなり大変で難しいと思います。
これからのキャリアを考える上で、今もこれからもweb業界で活躍するエンジニアになるには、この考え方でユーザーの幸せを増やす、大胆な手数を打てる人がなれるのではないかなと思いました。
