PrAha Inc.

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

Apex Legends最強エンジニア決定戦 PrAha Cup を開催しました

こんにちは、株式会社プラハCEO兼エンジニアの松原です。

 

株式会社プラハでは最近Apex Legendsが圧倒的なブームで、社員の6割近くがApexを日常的にプレイしている状態。「Apex部」なる部活動も社内に誕生して、概ね月1回くらいの頻度で社員で集まって出撃しています。

 

youtu.be

 

しかし、しばらくApexを遊んでいると

 

「カジュアル/ランクだけ回るのも飽きてきたな〜」

「カスタムマッチやりたいな〜」

「でも、なかなか自分たちのレベルで参加できるカスタムマッチ見当たらないな〜」

 

こんな声が社内で聞こえてくるようになりました。

 

そこで「ないなら作ればいいじゃない」ということでRespawn Entertainmentにカスタムマッチの主催権限を問い合わせてみました。

  • 問い合わせから実際に権限をもらうまで6週間かかった
  • 相当の知名度がないと権限はもらえない

等の情報がネット上に散見されたため、あまり期待はしていなかったのですが

 

あっさり権限もらえました

 

問い合わせた数日後には「いいよ!」と気さくな返信。恐らく日本語で問い合わせると翻訳待ちキューに詰め込まれてしまうのではないでしょうか。英語で問い合わせればすぐに対応してくれる気がします。

 

ニーズ調査

何かしらの縛りを設けた方が大会のエッジが立って注目してもらえるのではないか?思い「Apex最強のエンジニアを決める」というコンセプトで試しにTwitterに投稿してみたところ良い感じの反響をいただけたので、この方針で進めることに。

 

 

 

ライブ配信の調査

2年近く冬眠状態だった公式YouTubeアカウントを掘り起こしてYouTube上のライブ配信にも挑戦してみました。

 

ライブ配信の際にはディレイ(配信の意図的な遅延)をかけておかないと、実況動画を見た参加者が全体の戦況を把握できてしまいます。PS4組み込みのライブ配信ではディレイがかけられないことが判明したため、キャプチャーボード(Elgato HD60S)を購入して

PS4 -> キャプチャーボード -> MacBook Pro

といった具合に映像と音声をPCに取り込んで配信することに。配信ソフトにはOBS Studioを使いましたが、Macでキャプチャーボードからの音声を取得するにはOBS Linkを追加でインストールしなければいけません。

 

後に判明するのですがMacBook Proでは圧倒的にマシンスペックが不足していたため動画はカクつき、音は盛大にズレていました。素直にゲーミングPCを買えばよかった。

 

カスタムマッチの仕様調査

Apex Legendsのカスタムマッチサーバーを扱う上で、いくつか注意すべき点があります。

  • サーバーは3時間程度で自動的に再起動する
  • チーム名を変更しないとマッチリザルトが表示されない
  • 定期的にコントローラーを触らないと管理者の接続が切れてしまう

 

起動から概ね3時間でサーバーが再起動するため、同じ管理者コードを何マッチも使い回しているとマッチ中に再起動されてしまう恐れがあります。管理者コードは出来る限り使いまわさないように注意しました。

 

チーム名を変更しないとリザルトが表示されず、順位やキル数が分からなくなってしまう不具合も確認されています。こちらはカスタムマッチの権限を付与される際に、リザルトを取得するためのエンドポイントも教えてもらえるので、そちらのエンドポイントにマッチのトークンを送ればjson形式でマッチの詳細データが返ってきます。

 

サーバー管理者であっても、定期的にコントローラーを動かさないと「一定期間操作がなかったので切断されました」画面が表示されてしまいます。配信準備中も適度に左スティックをクリクリして乗り切りました。

 

LPのリリース

tin-citrus-e28.notion.site

 

弊社デザイナーに作ってもらったPrAha Cupのロゴを載せたLPをnotionで作成しました。本当にnotion有難い!秒速でLPが完成しました。応募はGoogle Formでまとめて管理しています。

 

実況/解説の練習

Apexは20チーム・60名で争われるバトルロイヤルなので、実況・解説がないと何が起きているのか若干把握しづらいゲームです。できればプロの実況/解説者を招きたかったのですが、記念すべき第1回大会はせっかくなら手作り感満載で開催してみようと思い、自分が担当することに。

 

実況といえば古舘伊知郎さん!ということで古舘さんの本を何冊か読んで実況について少しだけ勉強。大会で言いたいフレーズをいくつかストックしておいたり、他のカスタムマッチ実況者のフレーズを書き留めて準備しました。

 

「血煙漂うWorld's Edge。日頃はWEBサービスを開発するITエンジニアの指が今宵は破壊のみを求めて躍動します」

「上空数千メートルから、血に飢えた開発者たちの唸り声が響き渡ります」

 

みたいなフレーズが手元のメモに書かれていました。おどろおどろしいですね。

 

チーム名や参加者の名前から、参加者がキルした/された場合のフレーズも何パターンか用意していました。例えばNullPo選手であれば

 

キルされた時は「ついにNullPoがデバッグされた!」

キルした時は「NullPoを踏んでしまった!事前のテスト不足か!」

 

実況中は基本的に一人ずつの視点にしか入れないためフレーズの9割近くは披露されることなくお蔵入りとなりましたが、頭の中で事前に状況をイメージして発言を練っておく作業は間違いなく実況に役立ったと思います。

 

リハーサルマッチ

当日になって「あれ、サーバーが立ち上がらない!」みたいな不具合があってはいけないため、任意参加のリハーサルマッチを本番の数日前に実施しました。

f:id:praha-inc:20220114182910p:plain

リハーサルマッチの声がけ

リハーサルマッチで配信テストを実施した際はそれほど音ズレは気にならなかったのですが、本番では音ズレがだいぶ大きくなっていました。チーム数が増えることがそこまで影響するとは予想外でした・・・

特に本戦第1試合はDiscordを起動しながら配信していたため紙芝居のようなカクつき具合。2試合目以降は配信ソフト以外を全て落としたら少しマシになりました。次回はお金に物を言わせてちゃんとしたモンスターマシンを用意して配信に臨みたいと思います。

 

本番

そして迎えたPrAha Cupの本番。当日の公式映像はこちらからご覧いただけます:

youtu.be

 

結果はLPにも記載の通り、ToNoSamaKingsが見事に本戦の総合1位を獲得。

交流戦ではSHA-256が総合1位を獲得しました。

改めておめでとうございます!!

 

カスタムマッチを主催してみて

とんでもなく楽しかった。

 

実況者視点だとマッチ全体を俯瞰できるので、近々接敵するチームや、挟まれそうな位置にいるチームが一目瞭然です。少しだけ先の展開を予測しながらマッチを楽しめる体験は新鮮でした。

 

また、多くの参加者にとってPrAha Cupは初のカスタムマッチになったようです。

「カスタムマッチ楽しそうだから参加してみたい、でもちょっと実力が不安だ・・・」

そんな方が気軽に楽しめるカスタムマッチとして月1くらいのペースで今後も開催できたら嬉しいなぁ。

 

あと社外のApex仲間が一気に増えたので、大会関連のSlackワークスペースで一緒に出撃する仲間を定期的に募っています。

f:id:praha-inc:20220114184701p:plain

 

そんな株式会社プラハではApexを遊べる方の他にも、一緒にスタートアップのWEBサービスをデザイン・開発してくれるデザイナーやエンジニアを常に募集しております。もしご興味をお持ちいただける方が居たら、ぜひ気軽にお声がけください。

一緒に出撃してカジュアル(マッチ)面談しましょう!

 

個人的名シーン

本戦の後に参加者をランダムに入れ替えた交流戦を行ったところECHO_JAVA_HOME選手とnullpo_0000選手が同じチームになり、ノックされたJAVAがヌルポを必死に守る姿が秀逸でした。参加者の属性を絞ると、こういう奇跡的な巡り合わせが起きるのもまた面白い!

 

www.youtube.com

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. 例:「最近プロジェクトでこんなことがあったので、こんなことを考えた」

 

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

 

勉強会が秒で過疎った話

どうも、株式会社プラハCEO兼エンジニアの松原です

 

弊社ではメンバーの技術力を高めるために数々の勉強会を開催してきましたが、色んな失敗を経験してきたのでひとまず共有したいと思います

 

 

TL;DR

  • 何も考えずに勉強会を開催してたら過疎った
  • なので色々と変えた
  • ISUCONやSECCONやハッカソンなど、何かしらのアウトプットがあるタイプのコンテストに参加するための交通費、宿泊費、懇親会費用などを会社で負担することにした
  • 有識者を呼んで講義をしてもらうための有識者クーポン」を発行した
  • 輪読会に使う技術書は全額会社負担にした

 

 

何も考えずに勉強会を開催したら過疎った

文献によると弊社で行われた最古の勉強会は2年前に「各々が好きな内容をLTする」という(良くある)形式で行われました。この形式の勉強会は「LT用の資料を用意するの半端なく大変なんですけど?」の一声と共に秒で過疎りました

 

デブサミとかオーディエンスの多いLTなら労力に見合うかもしれませんが、オーディエンスが少ない勉強会のために資料を毎回用意するのは気が引けちゃいますよね...

 

また聞いている側からも「興味を持てないテーマだった時に辛い」といった声もあり、喋る側も聞く側も辛いLOSE-LOSEの状態になっていました

 

(教訓)

・準備の手間がかかる割にオーディエンスの少ない勉強会はすぐ過疎る

・ある程度テーマを絞っておかないとオーディエンスに興味を持ってもらえない

 

 

じゃあ勉強会のテーマを揃えてみよう

「LTの内容に興味を持てない」を紐解いていくと、以下のように細分化できました:

  • ジャンルの問題(フロントエンドは好きだけどインフラは興味がない)
  • レベルの問題(簡単すぎて眠い、難しすぎて同じ日本語とは思えない)
  • 必要性の問題(直近の業務で使わない知識なのでアンテナが反応しない)

 

「じゃあ勉強会のジャンルと、レベルと、必要性を揃えよう!」

 

ということでDDD勉強会が社内で定期的に開催されるようになりました。

 

ジャンル:揃ってる(DDD)

レベル:みんなで同じ本を読みながらハンズオンで進めるので、レベルも揃ってる

必要性:業務ですぐ使える

準備負荷:資料を用意する必要がない(書籍を読んで不明点をまとめておくだけ)

 

「これで完璧やんけ!」と思ったのも束の間、DDD勉強会も過疎りました

 

 

なぜDDD勉強会は過疎ったのか

弊社では6プロジェクトほど並行しており、プロジェクトごとに求められるスキルセットも異なります。プロジェクトによってはDDDより他テーマの方が学ぶ優先度が高いため、少しずつ参加者の気持ちがDDDから離れていきました

 

また勉強会が進むほどメンバーの知識も増えるので、後から参加するメンバーと昔から参加していたメンバーの知識差が拡大するのも問題です

 

スキルもバラバラなエンジニアが沢山いる会社で常に優先度最上のテーマが揃うことは殆どないので、勉強会のジャンルを会社全体で絞るのはあまり良い解決策ではなかったなぁ、と振り返っています

 

(教訓)

・勉強会のテーマを絞ると、より優先度の高い学習内容に直面した参加者が離脱する

・同じテーマをずっと勉強していると参加時期によって知識差が生まれて、レベル感をそろえた勉強会が実現しづらくなる

 

 

 

ダイソンプロジェクト爆誕

しかしWEBの世界は日進月歩。最新の知識に触れ続けなければ競争力を失います

 

・準備の手間がかからず

・ジャンルは絞らない

・それでいて万人に役立つ(明日から使える)知識に触れられる

 

そんな勉強会の方法を模索した結果、ダイソンプロジェクトが立ち上がりました

 

説明しよう、ダイソンプロジェクトとは!

 

一般的にソフトウェア開発の現場はプロジェクトを新規作成した時が最も生産性が高く、既存コードが増えるほどに変更が困難になり、生産性が落ちる傾向にあります

 

プロジェクトが肥大化しても生産性が落ちない事こそが開発者の腕の見せ所、ということで日々プラハの社員が生産性を落とさないために実施した工夫をお互いに共有する、というコンセプトで誕生した勉強会です

 

こんな感じで各々が毎週スレッドに自身の工夫を列挙して

f:id:praha-inc:20210406115357p:plain

(名前を公開されたくないメンバーが居るため塗りつぶし)

 

全員が毎週の全体定例(WEB会議)でスレッドに目を通して、気になった工夫に質疑応答するような形式です

 

過去の勉強会との差異としては

 

・手間がかからない

 ・自分がやったことをSlackに書くだけ

・目的が統一されている

 ・「生産性を上げる」という目的が統一されているため万人受けする

 ・工夫のジャンルが幅広いので(人によってはインフラだったり、人によってはフロントエンドだったり)様々な事例に手軽にキャッチアップできる

・レベル感が揃ってる

 ・各々が実際に現場で実施した創意工夫なので、すぐに実務で役立つ可能性が高い

 

 

 

「吸引力生産性が落ちないただ1つの開発組織を目指す」というコンセプトで発足したダイソンプロジェクトですが、これも過疎りました

 

吸引力が、落ちた

最初こそみんな頭を捻って

「aspidaを使ってフロントエンドにAPIに準じた型を付与しました!」

「docker-compose upだけでローカル開発環境が立ち上がるようにしました!」

「スナップショットテストを追加しました!」

 

など様々な知見を共有していたのですが、半年も経つと徐々に知見が出なくなり

 

f:id:praha-inc:20210406115731p:plain

 

何も知見を出せなかった人には某調査兵団の「何の成果も!あげられませんでしたぁぁ!!」スタンプを付けるという謎の文化が発生する始末

 

なぜ吸引力が落ちたのか

仮説としては以下2点です:

割れ窓理論

・対話と深度の不足

 

 

割れ窓理論

イデアが底をつき始めたタイミングで「まぁそういう週もあるよね」となぁなぁにしてしまったのは良くなかったなぁ...と反省しています

 

毎週必ず自分の創意工夫を発表しなければいけないプレッシャーが最新事例への探究心や現プロジェクトに対する改善意識を刺激する」と期待していたのですが、そのプレッシャーが弱すぎたことで望む結果が得られなかったのではないでしょうか

 

ただプロジェクトの状況次第では改善の機会が少ない時もあるし、この取り組みが苦痛になって欲しくない気持ちもあり、強制力を発揮できませんでした

 

 

対話と深度の不足

限られた会議時間で毎週10人超から事例を投げられると、事例ごとに取れる時間が短くなってしまい

 

「Docker Composeで全部立ち上がるようにしました!」

「いいですね」

「はい」

「・・・」

「・・・」

 

思春期の娘と距離感を測りかねている父親みたいな会話が増えてしまいました

 

知っている人からすれば「おう、俺もやったわ

知らない人からすれば「え、イメージつかない・・・聞きたい・・・でも時間が・・・」

 

と、どちらにとっても中途半端な深度になってしまったのが原因ではないかと反省しています。気になるテーマを深掘りする余地が欲しかった

 

 

ダイソンプロジェクトの活かし方

とはいえ自身もダイソンプロジェクトを通じて「Storybookにfigma連携機能があったのか」とか新しい気づきを得ることもあり、情報にキャッチアップするためのフィード的な役割は果たしてくれているように思います

 

なのでダイソンプロジェクトは勉強会というよりはフィードとして延命していく事になりました。勉強会を企画するときは幅を優先するのか深さを優先するのか、事前に決めておくのが良さそうです

 

しかし「フィードだけじゃなくて、もっと深いところを学びたい!現場を経験している人ならではの知見に触れたい!」という欲求が抑えきれず、議論型勉強会が誕生しました

 

議論型勉強会の進め方

YESかNOで答えを出せるテーマを選ぶ(例:export defaultするべきか?)

参加者をペアに分ける

ペア同士で議論してもらい、YES/NOいずれかの立場を選んでもらう

・ペアを集めてグループを組んで議論してもらい、YES/NOいずれかの立場を選んでもらう

全員で議論して、YES/NOいずれかの立場を選んだら終了

・議論が白熱したら次回に持ち越し

 

特に「YES/NOで答えを出せるテーマを選ぶこと」と「まずペアに分けて議論すること」が特に重要だと考えています

 

 

なぜYES/NOで答えられる議題が大事なのか

YES/NOで答えを出せない問いを選んでしまうと(例:設計ってどこまで考えるべき?)「あぁそういう意見もあるよね〜」「それもいいよね〜」「それな」と、お互いの意見を全受容するだけの時間になってしまい、あまり対話が生まれません。最終的に「なんか分かった気がするけど、実際やってみたらわからん」状態に陥りがちです

 

強制的にYES/NOの結論を出す制限を設けることで意見が適度に対立し、細かな部分まで理解を深められるのではないかと考えました

 

例えば

・フォームコンポーネントを作った際、入力情報の状態はコンポーネントで持つべきか、上位層(ページなど)で持つべきか?

・フロントエンドのドメインロジックを切り出す際はクラスを使うべきか、関数を使うべきか?

 

みたいなテーマを用意して20分ぐらい議論していると適度に賛成と反対が分かれて、議論を通じて「なるほど、こういうケースだと確かに困るな」みたいな学びが得られます

 

 

 

なぜペアに分けるのが大事なのか

弊社は争いを好まない平和の民が多いので、血気盛んなサイヤ人が混じらない限り議論が発展しません。よしんば発展したとしても発言力の強い人が喋り続けてしまうので、できるだけ均等に発言の機会を与えたいと考えました

 

そこで参加者をペアに分けて

 

・まずペアで議論

・その後、各ペアが出した結論を元にグループで議論

 

というプロセスに分けることで一人当たりの発言時間を増やしました

 

議論型勉強会の評価

個人的には議論型勉強会は他の勉強会より学びが多いように感じていますが、まだ始めて日が浅いので効果検証中です

 

 

勉強会が過疎る理由

というわけでここまでの「勉強会が過疎る理由」を総括すると

 

・準備が大変

・内容に興味がない(レベルが合わない、必要性が低い)

・割れ窓が放置される

・知りたいところを深掘りできない

 

 

今後やってみること

これまでの反省を活かして、これからは以下のような施策を試そうとしています:

 

1)ISUCON、SECCON、ハッカソンなどの参加費用を負担

上記のように何らか手を動かしてアウトプットを伴うイベントに参加する場合は交通費・宿泊費・懇親会費用などを全額負担します

 

ISUCONで言うと過去問を動かすためにベンチマーカーにかかる費用とか、パフォーマンスチューニングに必要な知見を得るための技術書籍等の費用も全部会社が負担します。反省会(という名の暴飲暴食)で鉄板焼きとか食べたら、その費用も会社が負担します。

 

議論型勉強会から「自分の頭で意見を組み立てたり、手を動かしたときほど学びは定着しやすい」というポイントも学んだので、特に手を動かす勉強を積極的に支援したいと考えました

 

2)有識者クーポンの発行

有識者クーポンとは:一人当たり毎月1万円まで使えるお金の名前です。毎月上限1万円まで有識者に技術顧問として質疑応答してもらったり、出張講座を開催してもらうための費用として使えます

 

「データベースの仕組みをさらに詳しく知りたいけど、さすがに社内にはそこまで詳しい人がいない時にクーポンを使って(会社のお金で)データベースの専門家に教えを乞う」みたいな用途で使ってもらえたら嬉しいなと

 

「是非あの人に講師を頼みたいけど1万円だと引き受けてもらえない・・・」

 

そんな時は同じテーマに興味を持つ人を複数人集めてクーポンを組み合わせることで、より高額な報酬を有識者にお支払いできるようになります。なので10人が興味を持つ有識者なら10万円まで使えます(グルーポンみたい)

 

多くの社員が興味を持つテーマなら会社としても手厚く支援した方が良いと思うので、社員の興味が強い領域に自然とお金が使われる制度を考えてみました

 

制度の人気が出たら順次金額を上げていこうと思っています

 

3)技術書は輪読会に使う場合、全部会社負担

技術書の会社負担に関しては議論が紛糾しましたが、輪読会を通じた社員同士の交流に対してなら出費を惜しみたくないと考えて、複数人での輪読会に使用する場合は技術書の購入も全額会社負担にしました

 

というわけで社内のSlackで「この本を輪読したい人いませんか〜?」と募って、2名以上集まったら会社負担で購入してOK、という制度に落ち着きました

 

プラハには部活制度が存在しているので(社内の部活動に5000円まで費用補助する取り組み)輪読会も部活の一種と捉えられるかもしれませんね

 

 

結論:勉強会は難しい

プラハはエンジニアの採用時に「週末も個人的にコードを書いたり、勉強しているか」「ものづくりが好きか」といった点を重視しています

 

なので学習意欲に関しては総じて高いはずなのですが、そんな環境でも質の高い勉強会を維持することは困難でした

 

これからも色んな形式を試して最適化していきたい。そんな初春です

 

 

PR

「技術者として技量を高めたい」

プラハに興味がある」

 

そんな方がおりましたら、ぜひ一緒に働きませんか!

 

www.praha-inc.com

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

プラハチャレンジとは

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」と手取り足取り子供のように教える必要はなく、プラハの社員は自主的に判断して物事を考えられるという土台に組織が成り立っています。

 

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