PrAha Inc.

PrAha Inc. のブログ、あるいは社員の観察日記

PrAhackathon 2021-2022が開催決定!

≪年末年始、イベント開催決定のお知らせ≫

こんにちは!

この度、年末年始の2週間開催の完全オンラインハッカソンイベント『PrAhackathon(プラハッカソン)2021-2022』の開催が決定いたしました~!!

■イベント概要

『PrAhackathon(プラハッカソン)2021-2022』はPrAha Inc.が開催するオンラインハッカソンです。「アイデアのままで終わらせない」を会社の軸とするPrAha Inc.が、頭の中にあるアイデアを形にする楽しさを参加者と分かち合い、競い合い、共に称え合う。そんな楽しみながら切磋琢磨できるプログラムとなっております。

 

記念すべき第一回目のハッカソンテーマはズバリ、

「WEB会議中カメラOFFでも相手が安心できる仕組み」

です!

外出が制限されていたコロナ禍において活用が加速し、オフライン会議に代わって会議の新常識として定着しつつあるWEB会議。そんなWEB会議ですが、相手のカメラがOFFになっているとどうしても相手の表情が読み取れず不安になってしまうことも多々あります。しかし「気まずい」「見られるのが苦手」など、カメラをOFFにしておきたい方が職場に居ることもあるのではないでしょうか。

今回はそんな方がカメラをOFFにしていても相手が安心して会議に参加できるようなサービスがテーマです。

 

■開催スケジュール・参加人数

 

 ・開催期間

  2021年12月26日(日)~2022年1月8日(土)の2週間

 ・申込受付期間

  2021年11月27日(土)~2021年12月24日(金)

 ・参加数

  1~5名を1チームとして10チーム予定

 

イベントの詳細につきましては、以下よりご覧ください↓↓

tin-citrus-e28.notion.site

 

 

■応募方法

【参加チーム応募フォーム】PrAhackathon(プラハッカソン)2021-2022

1~5名のグループでご応募頂くことが可能です。上記フォームからご応募ください。

応募者多数となった場合は抽選の上、10チーム程度の参加を予定しております。

 

ぜひ今年の年越しは『PrAhackathon(プラハッカソン)2021-2022』で楽しくモノづくりにチャレンジしてみませんか~!?

 

皆様からのたくさんのご応募を、心よりお待ち致しております!

良い振り返りのために

どうも、株式会社プラハCEOの松原です。

twitter.com

 

開発プロジェクトでは定期的に振り返りを行いプロセスの改善を行うことが多い。しかし、やり方を間違えると振り返り会はお互いに負の感情を蓄積させるだけで終わってしまうことがあるため、より良い振り返りのために重要だと思う考え方や行動を社員に向けてまとめてみた。せっかくなのでブログでも公開してみる。

 

失敗に関する原則

  1. 失敗するのは当たり前
    1. 自分の限界を超えて挑戦したら失敗するのが当たり前!だから失敗を隠す必要はない。
    2. 失敗しなかったということは自分たちの既存能力の範疇で全ての仕事が完結したということなので、単に仕事の難易度が適正値より低かったことを示している。だから失敗しない=偉いわけじゃない。ただ仕事があなたにとって簡単すぎただけかもしれない。
    3. 失敗したからといって自分に価値がないとは思わないこと。自分一人では回避不可能な失敗もある。誰か一人が100%全ての失敗の原因であることはあり得ない。仮に一人のプロジェクトで失敗したとしても、そのプロジェクトに一人で任命した会社も原因の一端。だから自分一人で全ての責任を感じる必要はない。
    4. 誰だって失敗する。失敗にどう対処するかで真価が問われる。
  2. 失敗には痛みが伴う
    1. 失敗すると痛みを感じるのは必然。自転車を初めて漕いだ時に体中を擦りむいたように。誰だって失敗したら気分が落ちる。失敗したことを振り返ることは辛いし、痛い。
    2. でも痛みを恐れるあまり失敗から目を背けると、失敗から何も学べない。同じ失敗を繰り返してしまう
    3. 同じ失敗を繰り返して何度も痛みを味わうか、いま振り返って痛みを味わう代わりに同じ失敗をしなくなるか。後者の方が良くない?
  3. 失敗は他者と共有することで効果を増す
    1. 失敗したことを自分一人の胸の内に秘めていると、自分しかその失敗から学べない。失敗は周りと共有しよう。
    2. 何のために僕たちは同じ会社に所属しているのか。それはお互いの失敗から学ぶためだと思う。毎回自分で失敗していたら時間がもったいない。会社の仲間の失敗から学ぼう。
    3. 自分の失敗を周りに提供するだけでみんなに貢献できる。自分の失敗を周りに伝えるあなたの勇敢さが、失敗を許容する文化を醸成する。周りに共有するだけであなたの失敗は学びになる。 
    4. 「うわーこいつ失敗してるwwwダッセーwww」と嘲る子供のような人はこの会社に居ない。仮に居たとしても、そんな人を相手にするのはあなたの時間が勿体ない。失敗から一緒に学ぼうとする大人がちゃんと周りにいるから、そういう人との時間を増やそう。
    5. 失敗に気づかない、失敗を隠す、失敗を認めない、失敗から学ばない、失敗する人を笑う。そういう人の方が何万倍もダサい。失敗するほど難しいことに挑戦したあなたの方がカッコイイ。あとは失敗からみんなで学ぼう。

 

振り返り会に挑む上での心構え

 

  1. フィードバックは個人ではなくプロジェクトについて述べる
    1. 誰だって批判されたら気分が悪くなる。イラッとする。
    2. 批判されると人間は「自分は悪くない」と弁明することにエネルギーを使うようになる。言い訳をしたり、「悪いのはあいつだ」と他人に失敗の原因を探すようになる。不毛だ。
    3. それか、批判された人がその場限りの謝罪をして終わる。「次からは気をつけます!」って。他の人はスカッとするかもしれないけど誰か一人が不快な思いになるだけだし、再発防止の仕組みは一切生まれていない。ほとんど意味がない
    4. だから個人ではなくプロジェクトについて述べよう
      1. 例:「あの人のコードがクソだった」→「誰でも最低限の品質を保ったコードを書ける仕組みが必要だった」
      2. 例:「相手側の担当者からの仕様変更が多すぎた」→「スケジュールに支障をきたす仕様変更を抑える仕組みが必要だった」
      3. 例:「PMが全然タスクを洗い出してくれなかった」→「タスクの不足にチームが気づく仕組みがなかった」
  2. 裁判ではない
    1. 誰が正しいとか誰が間違っているとか決めることに意味はない。誰が悪かったかハッキリさせてその人を排除しても、その人と似た別の人が入ってくれば、また問題が再発する
    2. 正しいかどうか決めるのではなく「これからどうすれば良いか」だけを考える。建設的なことだけを論じる。
    3. タイムマシンを使って、同じメンバーでもう一度同じことに挑戦した時に失敗しないための仕組みを考えるのが振り返りの目的なのだから
  3. 人格攻撃しない
    1. 失敗にかこつけて人格攻撃することはこの会社では認められない
    2. 問題を指摘することは構わない。ただし人格攻撃であってはいけない
    3. タイムマシンを使って、同じメンバーでもう一度同じことに挑戦した時に失敗しないための仕組みを考えるのが振り返りの目的なのだから
  4. 議論に勝ち負けは無い
    1. 主張することに問題はない。だけどムキになって議論に勝つことに意味はない。勝つことを過度に意識して「よし、論破した!勝った!」と悦に浸っている間、相手は「こいつと話すのめんどくさいから納得した風に装っておこう」と演じているだけかもしれない。議論に勝ち負けはない。余裕のある方、より器の大きい方が譲っているだけかもしれない
    2. 様々な考えが俎上に上がるのはとても良いこと。議論に勝つことを考えるのではなく、それぞれの考えからいいとこどりをして、より良い解決策を練ろう。
  5. 自分の意見が常に取り入れられるわけではない
    1. 誰であっても意見を強制することはできない
    2. 「このような事実を基に論理的に考えるとこのように行動するのが良いと思うけど、あなたはどう思う?」と尋ねることしかできない
    3. いくら意見を尊重する文化でも、すべての意見が無条件に受け入れられるわけではない。当然意見が対立することもある
    4. 意見が否定されることと自分が否定されることは常に切り分けよう。意見が否定されたからといって落ち込むことはない
    5. また全てのプロジェクトには(ホラクラシーのロールに任命された)責任者がいる。全ての意見を取り入れて責任者が最終的な決定を行い、その結末に責任を負う。だから自分の意見が全て通るとは限らない。
  6. 意見は率直に述べる
    1. 心理的安全性という言葉は「いまの発言で自分は傷ついた。心理的安全性が低い!」といった具合に誤解されていることがある。自分にとって耳障りの良い言葉しか流れない空間を心理的安全性が高いと錯覚してしまうことがある。正しい心理的安全性の定義は「shared belief that the team is safe for interpersonal risk takingこのチームは対人関係のリスクをとっても安心だと共通認識を持てること)」
    2. つまり「あの人が傷つくかもしれない(対人関係のリスクを取れない)」と思って意見を引っ込めることは逆に心理的安全性が低い状態を示す。
    3. 心理的安全性が高い組織ではどのような問題も率直に言うことが推奨される。
    4. この会社は心理的安全性の高い組織でありたい。そのためには上述の通り「個人ではなくプロジェクトについてフィードバックする」「裁判をしない」といった配慮や、伝え方を考える必要はある。だけど遠慮は不要。
    5. 傷つくか否かは当人の人格による影響が大きい。他の人ならなんとも感じないことにも傷つく人は居る。申し訳ないけれど、それは相手個人の課題でありチームの課題ではない。チームの課題は個人の課題とは分離して議論しなければならない。相手は自分が過度に傷つきやすいことを示すことで問題を指摘されることを回避するかもしれない。でもその結果、その人は周りから指摘を受けて学習する機会を失う。それはその人の課題であり、その責任は当人しか背負えない。
  7. 耳の痛い意見も聞き入れる
    1. 十分に配慮されていても、自分に問題があることを指摘されると人は当然腹が立つ
    2. しかし論理的に考えて自分に問題があることが明らかであれば、そこから目を背けても問題は消えない
    3. むしろ問題を指摘されても学ぼうとしない、改善しようとしない人、という烙印を押されるだけ
    4. 誰でも失敗するし、誰でも苦手なことはある。苦手なことや失敗にどう対処するかで真価が問われる。
  8. 日常的に自分の意見を表明する
    1. 意見を伝える場は振り返り会に限定されない。振り返り会まで自分の不満を全て溜め込む必要はない
    2. フルリモートで働くと、どうしても情報が不足する。職場でお互いが見えていれば非言語コミュニケーションで推察できる情報が全く伝わらない
    3. だから積極的に自分の考えを日常的にSlackなどで表明することが大事だと思う。
    4. 「あの人は常日頃こんなことをつぶやいているから、多分こんなことを考えているだろう」と事前情報を持つ相手と対峙するのと、全く事前情報を持たず何を考えているのかわからない未知の相手と対峙するのと、どちらの方が自分の考えを伝えやすいだろうか?
    5. 自己開示するのは相手のためだけではなく、自分の身を守ることにも繋がる。
      1. 例えば子育てが非常に大変なことを常に発信していれば、勉強会などに参加できない時にその理由を周囲が推察しやすい。何も発信していないと「あの人は勉強しない人」と思われる危険性がある
      2. 最近プライベートで嫌なことがあったからイライラしていることを発信していれば、周囲もそれを知った上で対応を変化できる。何も発信して居ないと「あの人は情緒不安定」と思われる危険性がある
    6. もちろん自己開示することに抵抗のある人がいることは理解しているので、強制はしない。ただ自分を守る上でも、周りと協働する上でもメリットがあると思うので推奨してみたい
    7. 特に感情や思考に関する情報はフルリモートだと得にくいので、積極的に発信すると良いと思う
      1. 例:「最近こんなことがあったので辛い or 嬉しい」
      2. 例:「最近プロジェクトでこんなことがあったので、こんなことを考えた」

 

深夜の殴り書きなので内容にまとまりがなくて恐縮だけれど、他にも意識すべきポイントが見つかったらどんどん加筆していきたい。

 

プラハチャレンジのメンターを募集しております!

プラハチャレンジとは

praha-challenge.com

 

参加者がペアやチームを組んで実践的な課題に挑む、ピアラーニングを中心としたプログラミング・ブートキャンプです。設立に至った背景:

 

praha-inc.hatenablog.com

 

なぜやるのか

Web エンジニアの成長は「環境」と「本人の努力」の掛け合わせだと考えています。良い環境(良いメンター、適度に挑戦的な案件、学習意欲の高い仲間など)に恵まれ、そこに当人の努力が加わった時、最も効率的にエンジニアとしての知識や経験が蓄積されると考えています

 

しかし必ずしも良い環境に身を置ける人ばかりではありませんし、環境を変えるためには転職するなど大きな一歩が必要になります。そこで学習意欲の高い業務経験1~2年目のWebエンジニアを対象に、実践的な課題に取り組み、熱意の高い仲間と切磋琢磨できる環境を社外にも提供して、開発業界全体の底上げをしたいと考え、プラハチャレンジを設立しました

 

メンターの仕事

・6名前後の参加者から成るチームとオンラインで週1回1時間程度、課題に取り組む上で解消できなかった疑問点や、実務ではどのように対応しているのか、などの質疑応答を行います

・チームとの質疑応答(メンターセッション)をお願いしたいと考えております

 

例えば以下のような質問が寄せられます:

- サブドメインから発行されたcookieはfirst party cookieでしょうか、third party cookieでしょうか?

- 実務では、どのような時にローカルストレージを使うのでしょうか?

- aタグを経由して遷移する際は、なぜCORSエラーが発生しないのでしょうか?

- ReactのdangerouslySetInnerHTMLをどうしても使わなければいけない時、セキュリティの観点からどのような対応が必要でしょうか?

- 実務において、ビジュアルリグレッションテストはどのようにCI/CDに組み込まれるのでしょうか?

- カバリングインデックスについて説明いただけないでしょうか?

- TypeScriptのisolatedModulesをtrueにしたらエラーが発生しました。回避するためにはexport {} など、とりあえず何かをexportする方法を見かけましたが、これ以外に方法はないでしょうか?

 

こうした質問を理解し、可能な限り正確な一次情報(RFCフレームワークの公式サイトなど)を調べる、あるいはご自身の実務経験や推測から回答を用意し、メンターセッションで参加者に分かりやすく伝えることが求められます

 

プラハチャレンジに登場する課題領域については、こちらをご覧ください:

PrAha Challenge | 中級エンジニアを育てるブートキャンプ(カリキュラム)

 

メンターに求められる条件

下記の条件を全て満たすこと:

・情報を調べるのが好き
 誤った知識を伝えないために、英語文献や公式サイトを含め、情報を効率的に収集できること

・収集した情報を言語化して伝えられること
 必要に応じて図解や例え話なども用いて、分かりやすく伝えられること

・実務経験が豊富であること
 調べた知識のみならず「実務だとhoge」「こんなことを過去に実施した」など、ご自身の開発者としての経験を話せること

・人に教えたり、一緒に考えるのが好きであること
 時には正解のない質問を受ける事もあります。そんな時はプラハのエンジニアやメンターと共に回答を模索していくことになります。一緒に考えたり、議論したり、探求することが好きな方とご一緒したいと考えております!

 

下記いずれかの条件を1つ満たすこと:

・React x TypeScriptを用いたフロントエンドの開発経験2年以上(Next.jsも経験があると最高!)
・サーバサイドの開発経験2年以上(言語やフレームワーク不問。node.js x TypeScriptだと最高!)

・どちらも満たしていたらファンタスティック!

 

条件面

主に平日の夜8時以降、土日の朝あるいは夜に不定期に設定されることが大半です。実際の稼働時間に関しては、相談して決められればと思います

 

・最低稼働時間:4時間以上/週

・報酬:時給4000円〜6000円(税抜)

・開始日:2021年4月〜

 

 

最後に

プラハチャレンジの参加者の大半は、平日はエンジニアとして働きながら、仕事終わりや土日に課題を進めています。こうした学習意欲の高い参加者からの質疑応答に真剣に答えることを通じて、自分自身の知識や理解を深める機会にもなります。

 

一緒にエンジニア界隈全体の底上げに取り組んでいただける方の応募をお待ちしております。

 

 

応募方法

大変お手数ですが、以下の弊社エンジニア採用フォームよりご応募いただけますと幸いです。「その他」の項目に「プラハチャレンジメンター希望」とご記載ください!

https://www.praha-inc.com/recruit/engineer

 

株式会社プラハ(PrAha Inc.)について

「物作りが好きな人が、物作りを楽しめる環境を作る」ことを目的に設立した3年目のIT企業です。新規事業に特化した開発とデザインを月額定額で提供する受託開発のほか、自社サービスを並行して開発する「ブートストラップ型経営」を実践しています。

 

社内制度は「ホラクラシー」を採用。オフィスはなく、原則フルリモート。社内制度もトライアンドエラーを繰り返し、少しずつ改善している。そんな会社です。

 

メンターではなく、エンジニア、あるいはデザイナーとして働くことに興味を持ってくれた人は、こっちも見てね!

www.praha-inc.com

 

 

なぜ議論が大切なのか、そして効果的な議論の方法

どうも、PrAha. Inc CEOの松原です。

 

先日、社内向けに「なぜ議論が大切なのか」を明文化ところ、思った以上に好評だったため、内容をそのまま以下に転載します。

 

===================

 

今回はチームとして働く上で避けて通れない「意見を主張してぶつけあう事」、つまり議論に関して考えていることを明文化してみます 。

 

アメリカ式の教育では何を教わるのか

僕は自己主張が非常に激しい方です。それは多分教育の影響が強いと考えています。

 

僕は幼稚園から高校までずっとアメリカンスクールに通い、意見を言わないことは失礼だと叩き込まれて育ちました。

 

授業が終わるまでに一度も自分の意見を主張しないと先生に呼び出されて怒られるし、数学の授業であっても「自分とは解法が違う人を見つけてどちらの解法が優れているか議論しなさい」とか、ディベートの部活も盛んだったし、とにかく議論することが生活の中心にある学校生活でした 。

 

アメリカ型の価値観では、自分の意見を述べないことには二つの解釈がなされます。

 

一つ目は 「この人は何も考えていない」
二つ目は「この人は失礼だ」

 

何も言わないということは何も考えていないということだ」と解釈されるので、日本のように「 何も言わない人も言わないなりに考えているはずだ」 とは考えてくれません。なので間違った意見をたくさん言う人よりも、意見を言わない人の方が低い評価を受けてしまいます。

 

また「何も意見がないと言うことは、相手の発言に無関心か、真剣に聞いてないからだ。なんて失礼なやつだ」とも解釈されます。

 

「意見を述べない人は低評価」
「自分の意見を述べることは礼儀」

 

こんな文化圏で育った僕にとって、自分の意見を述べることは呼吸と同じくらいの感覚で染み付いています。

 

なので僕の自己主張の強さに驚く人が居たとしたら、「こういう教育背景から作られた人格なんだな」と見てもらえたらちょうど良いのではないか、と思います。

 

意見を主張することは、「人の集まり」から「チーム」になるために最も重要

こうした背景に加えて、僕は意見を述べること、議論する事を「人の集まり」から「チーム」になる上で最重要だと考えています。

 

各々が自分の意見を主張する事なく、自分の仕事範囲に止まって黙々と作業するのはチームではなく「人の集まり」の状態です。烏合の衆とも言いますね。

 

そうではなく、各々が持ち寄った意見を全力でぶつけあう事で、より良いアイデアに育てていく。異なる視点を持ち合うことで、一人では気づけなかった問題に気付き、それらをまとめて解決する新しいアイデアを生み出していく。

 

こういう事を安心して出来るのがチームで、チームになるためには全力の議論が欠かせないと考えています。

 

チームの定義に関して僕は「タックマンモデル」を参考にしていますが、ここで説明すると長くなりすぎるので今回は割愛します。 興味のある人は是非こちらの入門書を読んでみてください 。


議論する上でとても大事な考え方

ただの人の集まりからチームになるために大事なのは、全力で自分の意見を主張してぶつけるのを(議論する事を)恐れないことです。この時、いくつかの考え方を大事にする必要があります。

 

・全力で自分の意見を主張する
・意見の否定を、人格の否定と切り離す
・個人的に攻撃しない
・行動を提案すること


全力で自分の意見を主張する

周りから見ると僕は「何が何でも自分の意見を通そうとする人 」に見えるかもしれません。

 

その通りです。僕は意見を言う時は、全力で自分の意見を通そうとするのが礼儀だと考えています。

 

「どちらでもいいんだけど」とか「あんま考えてないジャストアイデアなんだけど」みたいな予防線を張ってから自分の意見を言う人が日本には多い気がしますが、これと同じ事を僕の母校で続けると 「じゃあ言わなくていいよ。ここは真剣に意見を言う場だから」と止められます。

 

”Say what you mean”って言われます。直訳で「本心を言ってよ」ですが「本気で言いたいことを言ってよ」「本気になれよ!もっと熱くなれよ!(CV:松岡修造)」みたいな意味でも使われます。

 

スポーツだって同じですよね。本気で練習した方が効果は高いはずです。全員が本気で練習している中に一人だけ本気じゃない人が混じったら、怒られますよね。

 

全員が全力で自分の意見を通そうとするからこそ、議論が白熱して新しいアイデアが生まれる。

だから意見を主張する時は、全力で意見を通そうとすることに躊躇しないでください 。健全なエゴを持つことを恥じる必要はありせん。

 

ただし議論が終わったら、後腐れなしです。


ドイツで働いてた頃、 会議で大声を張り上げて相手の意見を否定していた人同士が、翌朝には仲良くコーヒー飲みながら談笑している姿を何度も見ました 。河川敷で殴り合った後に仲良くなる不良に近い感覚なのでしょうか。

 

「全力で議論するけれども尾を引かない」

 

どうすればこんな事ができるのでしょうか?次のポイントで解説します


意見の否定を、人格の否定と切り離す

人との衝突を避けたいがために議論そのものを避けている人が日本には多いように感じます。これは議論の場数を踏んでいないから起きる「あること」が原因です。

 

それは、意見を否定されるのに慣れていないことです。

 

日本人は圧倒的に意見を否定される経験が少ない。

逆にアメリカ人は意見を否定される経験が豊富です。

僕が12年の学校教育で意見を否定された回数なんて数え切れません。

 

議論を通じて意見を否定される経験を積み重ねていくと、 否定されるたびに心底へこんでいては心がもたないので

 

「意見を否定されただけで個人の人格を否定されたわけではないさ」

 

と気楽に捉えて議論に挑めるようになります。

 

日本では、自分の意見を否定されると怒る(もしくは悲しむ)人をよく見かけます。
これは意見の否定と人格の否定を切り分けられていない人の防御反応だと思います。
確かにこういう人が周りに多いと、自分の意見を言いづらくなりますよね。

 

だからまずは、自分の意見が否定された時に、自分個人が否定されたと思わないように心がけてください。そうして意見を否定されることに慣れてください。意見を否定されることに慣れてくれば、主張するのも楽になるはずです。

 

PrAha Inc.は本当に人の良い社員がそろっているので「相手の意見を否定したら傷つくのではないか」 と遠慮してしまう気持ちは理解できます。だからこそ 「自分は特殊な訓練を受けているので否定されても特に傷つきません」 と言える人が増えてくれば、 より議論しやすくなるのではないでしょうか 。

 

もしどうしても誰かの意見を否定することに不安があればまず僕の意見を否定してください。僕は特殊な訓練(?)を受けているので、 意見を否定されることに抵抗はありません 。

 

ただし前述の通り、全力で意見を主張することが議論の礼儀だと考えているので、おかしいと思った事には全力で反論して、僕の意見を通そうとします。そしたら、あなたも自分の意見を全力で通そうとしてください 。そうして議論を楽しんでいきましょう。

 

議論は相手を打ち負かすためにあるのではありません。自分一人では気づけなかったことに気づき、 より良いものを生み出すのが議論の目的です。意見を否定された時は「その否定意見も併せて解決する方法はないか」と考えるチャンスと捉えて、新しいアイデアを考える方が楽しいのではないでしょうか。

 

議論も「ものづくり」の一環です。一人では生まれなかったアイデアを生み出して、その誕生を一緒に楽しんでいきましょう。


個人攻撃をしない

全力で議論することに慣れてくると一度は発生するのが個人攻撃です。

 

議論が白熱してくると「 どうして理解できないんだ、頭悪いな! 」とか「この間失敗したくせに何偉そうなことを言っているんだ」とか、相手を傷つけるために言葉を使う瞬間が出てくるかもしれません。

 

(逆にこんな事を言いかけた事が一度もなければ、それはまだ本気で議論していない証拠かもしれません)

 

相手の意見ではなく相手そのものを否定したり、「君の話だから聞かない」みたいな相手に合わせた議論をし始めると、 議論の前提にある信頼関係が崩れます。これが「 心理的安全性 」が欠けている状態ですね 。

 

これだけはしないように注意しましょう。

一度でも個人攻撃をすると信頼が失われて、 その信頼は長い時間をかけないと取り戻せないと考えてください。


行動を提案する

日本の会社で議論する人を眺めていると 「行動を提案していない 」人をよく見かけます。

 

例えば「新商品を作ろう」と誰かが提案した時に「こんなリスクがあるぞ」と指摘されて、喧々諤々の話し合いが始まったとしましょう。

 

僕はこれを「議論」だとは考えていません。

 

議論はお互いに「こうすべきだ」と行動を主張し合うことが原則です。
片方が行動を主張して、もう片方がその問題点を指摘しているのは議論ではありません。質疑応答です。

 

もし問題を指摘した方が「今は既存商品にリソースを集中しよう」と行動まで言い切っていたなら、議論が成立していると思います。もしくは「何もしない」事を主張するのも、有効な行動提案です。

 

でも実は質疑応答をしているだけなのに、自分は議論をしていると勘違いしてしまうのは不健全です。これまた母校の話ですが、質問ばかりしている人は「で、あなたの意見は?」と聞かれます。

 

ラクラシーの議論も、質問と反対フェーズに別れていますよね。あれはすごく明確にアメリカ式の討論のフォーマットに則っているなぁ、と思いました。

 

相手の主張を理解するために質問することは非常に重要です。でも意見を言うことを忘れて、質問だけで終わらないように気をつけてください。


まとめ

以上が僕の議論に対する考え方です。

 

・僕は議論をする事が当然の環境で育った

・だから僕の主張の強さに驚くことがあったら、そういう環境で育ったからなんだなと考えてもらえたらちょうどいいかもしれない

・議論は、「人の集まり」から「チーム」になる上で最も重要

・議論をするためには4つの考え方が大事

 ・全力で主張する事

 ・意見の否定を人格の否定と切り離す

 ・個人攻撃をしない

 ・行動を提案する

 

PrAha Inc.が日本で最も活発に議論が交わされるチームになってくれたら嬉しいです。

プラハは社員に対してどんな前提を持っているのか

どうも、株式会社プラハCEOの松原です。

 

今回はプラハが自社社員に対してどんな前提に成り立っているか、まとめてみます。(社内向けに発信したメッセージをこちらに転記してます)

 

内定者を含めると16名を迎えたプラハでは、2ヶ月ほど前から全社的にホラクラシーを取り入れ始めました。

ティール組織の一つとして挙げられるホラクラシーは、一般的な組織構造とは様々な前提条件が異なるため、その前提を事前に共有しておくことが大切だと考え、ここに明文化します。(内容の大半は書籍「ティール組織」から拝借しています)

 

 

ヒエラルキー組織の前提

一般的なヒエラルキー組織(管理職がいて、社員は何をするにしても上長の許可が必要な組織)は、以下のような前提に成り立っています。

 

社員は子供である。 子供が親の保護を必要としているのと全く同じように、社員は保護を必要としている

 ・例:重大な決断を行う際にはヒエラルキーのトップを通す必要がある。そうしないとアホな判断をしてしまう

 

・社員は怠け者なので見張られていないと勤勉に働かない

 ・例:労働時間の管理とか、オフィスが必要とか

 

・ 社員はお金を得るためだけに働く。自分がなるべくたくさんのお金を稼ぐために必要なことをする

 ・例:本業をサボって副業や個人の仕事をする、会社のお金を着服する

 

・ 社員は組織にとって何がベストかよりも自分の利益を優先させる。社員は自分さえよければ良いと思っている

 ・例:会社の誰かが困っていようと、自分に直接の関係がなければ放置する

 

・ 社員は会社の業績に影響を及ぼすような責任が重い仕事をしたがらない

 ・例:エンジニアなら開発に関することだけ、デザイナーならデザインに関することだけ考えたいはずだ

 

・ 社員は何をいつどうするべきか、命令される必要がある



プラハの前提

一方でプラハは自社の社員に対してこんな前提に成り立っています:

 

プラハの社員は信頼に足る大人である。創造的で思慮深く、重要な意思決定を下す能力を持っている

 

プラハの社員は管理しなくても、仕事をサボらない。自分の責任を全力で全うしようとする

 

・ 自分の判断と行動に対する説明義務を果たし責任を取れる

 

・何か必要なことがあれば、誰かが助けてくれるのを待つのではなく、自発的に解決できる

 

・失敗しても構わない。最も悪いのは失敗することではなく、何もしないこと

 

・自分たちの才能と技術と想像力を使って会社と世界に貢献したいと考えている

 

・お金以上に大切にしているものがある



なのでプラハには統制のためのルールがほとんどありません。

 

・まずオフィスがありません。物理的に労働時間や勤務態度を相互監視しなくても、プラハの社員は自分で判断して、責任を全うする人だと信じています。

 

・休暇日の上限もありません。仕事に支障のない範囲を自分で見極めて休みを取れる人だと信じています。

 

・ホラクラシーに基づいているため、意思決定の際に上長の判断を仰ぐ必要はありません。自分が責任を持ったロールである限り、自分で判断して物事を進めてもらって構いません。

 

・受託開発の案件の継続可否、人員の追加や離任などは現場の方が決定権を持っています。社員が「案件の継続をしない」と判断したら、代表の僕であっても、その判断に従います。



要は、統制するか、信頼するかの違いだと考えています。

 

統制があるのは社員に対する信頼が無いから。

統制が無いのは社員に対する信頼があるから。

 

プラハが統制しない(ルールが殆ど無い)のは、社員を信頼に足る大人だとする前提があるからです。

 

「これはダメ、これはOK」と手取り足取り子供のように教える必要はなく、プラハの社員は自主的に判断して物事を考えられるという土台に組織が成り立っています。

 

この前提を保ったまま、心地よい会社を作って行けたら嬉しいです。

炎上しないプロジェクトの進め方

株式会社プラハ代表兼エンジニアの松原です。

 

いろんなWEBサービスを開発する中で「こうすればプロジェクトの炎上を防げるのでは?」と感じる行動や考え方が見えてきたので、それをチェックリスト化して社内で運用し始めました。

全ての開発現場が炎上から無縁になりますように。

 

https://www.notion.so/128a7aaa68434230bc5dfce322bd1811