PrAha Inc.

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

勉強会が秒で過疎った話

どうも、株式会社プラハ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 Challengeを作ったのか

こんばんは!

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

 

この度、自走できるITエンジニアを育成するオンラインブートキャンプ「PrAha Challenge」の提供を開始しました

 

prtimes.jp

 

 

今回は「なぜPrAha Challengeを作ろうと思ったのか」を書き残しておこうと思います。




ITエンジニアの成長は努力5割、環境5割

僕は個人的に、IT エンジニアの成長を決める要素は、個人の努力が5割、環境が5割だと考えています。

 

どれだけ毎日独学する人がいたとしても、独学は

 

・なかなか理解できず詰まる

・誤解する

・学ぶ価値の低い知識に時間を割いてしまう

 

などの理由から効率が低く、よほど学習能力の高い人でなければ必要な知識を短期間で習得できません。

 

逆にどれだけ恵まれた環境に身を置けても、自発的な努力をしない人がその恩恵を受けることはありません。せっかく指導を受けても、その内容を自分で復習したり、理解しようとしなければ、せっかくの環境が無駄になってしまいます。

 

どちらか片方では不十分で、努力する人が良い環境に身を置いた時に、人は最も効率的に成長できると考えています。

 

こうした考え方の背景には、私の個人的な経験もあります。私のエンジニアとしてのキャリアは「リクルートテクノロジーズ」という会社で始まりました。当時の環境が本当に優れていて、

 

・きちんと設計を考え抜いたコードを毎日見ながら働ける

・大半の作業が自動化されていて、コードを書くことに集中できる

単体テストが充実しているため、初学者でも安心してコードを書ける

・厳しく丁寧に指導してくれる先輩

・少しずつ今の自分にはできない課題に取り組ませてくれる上長

・学習意欲が高く、一緒に個人開発をしてくれた同期

 

などなど、エンジニアとして成長するために必要な要素が揃っている素晴らしい環境でした。

 

弊社(株式会社プラハ)も幸い学習意欲に満ちたメンバーが多く、輪読会、勉強会、ドメイン駆動設計のケーススタディなどが活発に行われています。実務においても日々メンバーと技術的な議論を交わすことを通じて、様々な知識を吸収できています。

 

こうして改めて自分のエンジニアとしての足跡を振り返ってみると、「良い環境で」努力を続けたからこそ、効率よく成長できたのだと感じています。もし環境が違えば、ここまで成長することはなかったかもしれません(勿論、まだまだ未熟な点ばかりですが)

環境は自由がきかない

ここまで成長には「良い環境」と「努力」が必要だと述べましたが、環境はなかなか自由がききません。

 

・全くコードレビューを受けられない

・テストを書く、設計を考える、リファクタリング、作業自動化など、質の高いサービスを作ろうとする文化がない

・モチベーション高く開発を学ぼうとする人が周りにいない

・難易度の低い仕事しか任されず、良い経験が積めない

 

こうした環境を抜けて、高い熱量を持った人たちと切磋琢磨できる環境を求めて弊社の採用面接を受けてくださる方がこれまで沢山いましたが、残念ながら弊社が求める技術経験を持たず「こんなテーマを学んでから、また面接しましょう!」と伝える事が多々ありました。

 

「恵まれた環境に身を置けない方が、効率的に技術を学ぶ手段は無いのか?」

「あえて転職という手段を取らなくても済むよう、良い環境を社外でも提供できないか?」

「転職という一歩を踏み出せないだけで、こうした不満を抱えている人は沢山いるのではないか?」

 

こう考えた末に、PrAha Challengeの設立を決意しました




PrAha Challengeが目指すもの

PrAha Challengeは上述の「良い環境」を社外で提供することを目的としています。

 

・熱量の高い仲間と教え合いながら、時には議論を通して理解を深める

・少しずつ難易度の高い課題に挑戦していく

・どうしても詰まってしまった時は経験豊富なメンターに相談できる

 

こうした取り組みを通じて学習を妨げる障害物を取り除き、 努力が成長に直結しやすいように支援して、質の高いサービスを開発できるエンジニアを増やしたいと考えています。




なぜ質の高いサービスを開発できるエンジニアを増やしたいのか

これまた個人的な話で恐縮ですが、プラハを立ち上げるに至った経緯をお話ししたいと思います。

 

エンジニアとして少しずつ開発経験を積んできた頃、起業した知人から「それなりに名の通った開発会社に数千万円出して開発を頼んだが、全くモノが出来上がらなかった。助けて欲しい」といった相談を何度も受けました。

 

また、これまで私が企画職として携わった新規事業においても、ちょっとしたエンハンスに何ヶ月もかかる、すぐに不具合が発生する、といった開発側の事情が仮説検証の足枷になり、事業が競争力を失っていく状況を何度も目の当たりにしました。

 

せっかく良いアイデアがあり、良いチームが揃い、資金を用意したのに、開発力の欠如が全てを台無しにしてしまう。こうした状況が一人の開発者として我慢なりませんでした。

 

もちろん開発は企画側との相性の問題があるため、一概に開発者のせいとは言い切れませんが

 

「質の高い技術者に巡り会えないことが、事業の足かせになっているのではないか?」 

「特に採用力がない新規事業やスタートアップほど、深刻な課題を抱えているのではないか?」

「新規事業に特化して質の高いサービスを作れる集団があれば、この課題を解決できるのではないか?」

 

こうした仮説を持ったのが株式会社プラハの創業理由の一つです。

 

一方、弊社でエンジニアを採用して受託開発することで少しずつ目的達成に近づけるものの、今のペースでは何年経っても根本的な解決には至りません。そこで自社の開発ノウハウをカリキュラムとして社外に提供する事で、所属を問わず幅広くエンジニアの開発能力の底上げに貢献する事を決意しました。

 

PrAha Challengeを通して開発能力を高めたエンジニアが新規事業の開発を担い、仮説検証を繰り返せる強靭なサービスを作る。こうした状態に少しでも近づけていけたら大変嬉しく思います。



 

もし興味をお持ちいただけたら、ぜひご応募ください!

praha-challenge.com

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

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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


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

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

 

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


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

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

 

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

 

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

 

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

 

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

 

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

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

 

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


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

 

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

 

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


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

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

 

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


個人攻撃をしない

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

 

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

 

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

 

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

 

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

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


行動を提案する

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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


まとめ

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

 

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

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

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

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

 ・全力で主張する事

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

 ・個人攻撃をしない

 ・行動を提案する

 

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

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

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

 

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

 

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

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

 

 

ヒエラルキー組織の前提

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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



プラハの前提

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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



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

 

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

 

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

 

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

 

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



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

 

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

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

 

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

 

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

 

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

なぜPrAha Inc.のエンジニアは設計を学ぶのか

こんにちは!株式会社プラハCEOの松原です。

 

PrAha Inc.では日々「エンジニアの設計力の強化」に取り組んでいます。

 

今年の冬には2ヶ月ほど毎週2時間近くかけてDDDにまつわる質疑応答会を実施したり、設計に関する技術書籍の輪読会を行ったり、3人ずつの小さなグループに別れて全社員でモデリングに取り組んだり...

 

 

 

なぜPrAha Inc.では設計を学ぶのでしょうか?

 

設計を学ぶ事は無駄にならない

WEBサービスを作る時にiOSアプリを開発する知識は不要だし、pythonで書かれたAPIを作る時にGo言語の知識は不要だし、バックエンドを全てlambdaで作成するならオンプレミスサーバの構築に関する知識は(一部を除いて)不要です。

 

作るサービス次第では、自分の保持している知識が無駄になる可能性があります。せっかく学ぶなら、何を作るにしても使える知識を習得したいものです。

 

それがソフトウェア設計です。

 

凝集度、結合度、デメテルの法則、SOLID、VIPER、クリーンアーキテクチャ、DDD、アトミックデザインに基づいた設計...

 

「変更しやすいコードを書く技術」は何を作る上でも役に立ちます。

 

今後AR/VRやDappsや未知の技術が現れたとしても、そこにソフトウェアが関わる以上、設計に関する知識が無駄になる事はありません。

 

「絶対に無駄にならないことから勉強した方が効率的だよね」と考えた末に、設計を学ぶことに決めました。

 

設計は、失敗した時の影響が大きい

ファットコントローラをリファクタした経験はありますか?

ビジネスロジックを大量に含んだフロントエンドを改修した経験は?

nullによる虫喰いだらけのDBをメンテナンスした経験は?

テストすら書けないコードを変更した経験は?

 

1つでも当てはまるなら、地獄を見たはずです。

 

初期段階の設計に失敗し、ゴミの上にゴミを重ねたコードを渡されたら、どれだけ優秀なエンジニアでも品質を維持するのは困難でしょう。

 

枝葉末節の実装に関するミスは簡単に直せます。

設計のミスは簡単には直せません。

 

だからこそ影響が大きい設計を学ぶべきだと考えました。

 

 

枝葉末節の技術は、どんどん自動化されていく

「コードを書くコード」はどんどん増えるでしょう。

 

bubble などのnocodeをはじめ、JS版のRailsライクなnest.jsfeathersjsOpenAIによるコード自動生成など、「人がコードを書く機会」は今後どんどん減っていくと考えています。ここまでの品質でなくても、ボイラープレートを自動生成するぐらいなら、僕のような何ちゃってエンジニアでも3時間程度でnpmパッケージとして公開できます。

 

自動化が進むと、例えば自分で最高のソートアルゴリズムを考えなくても、既に汎用化された最高のソートアルゴリズムが自動化に組み込まれていれば済むので、機械に近い低レイヤーの知識ほど習得する必要は薄れていくと考えます。

(勿論ソートがサービスの基幹であれば時間をかけて考えるべきですし、レガシーサービス、超大規模なサービスに関わる方々には必要な知識であり続けると思います)

 

機械に近い仕事ほど早く失われるとしたら、機械から最も遠いITエンジニアの仕事領域はどこか?と問われれば、それは設計です。

 

どんなツールをどう組み合わせてアイデアを形にするのか考える事。これがITエンジニアに残される最後の仕事ではないでしょうか。

(頑なに進化を拒むITサービスが時代の流れに抗い続けることで機械に近い仕事も残るとは思いますが、そうした不健全な生き残りについてはここでは言及しない...)

 

ヒトと機械のインターフェースが残る

より広義に捉えると、ヒトの世界と機械の世界のインターフェースが最後に残ると考えています。

 

盛んに騒がれる機械学習も大量の綺麗なデータが無ければ本領を発揮できませんが(最近はそうでも無いかもしれません?)「大量の綺麗なデータ」ほど現実世界で得難いモノも無い気がします。

 

機械は例外や汚れに弱い世界で生きています。複雑な現実世界をどうやって潔癖な機械の世界に落とし込むか。そこはITエンジニアの力量が問われる分野として残り続けると思います。

 

僕はITエンジニアの仕事が大好きです。コードを書くのは楽しいし、どう作るか考えるのも楽しい。この仕事を出来る限り続けたいと考えています。だからこそ、エンジニアであり続けるために必要な事(設計)から優先的に学びたいと考えています。

 

設計は、全員で学ぶ

少し細かい話に戻ると、設計は「全エンジニア」で「同時に」学ばないと効果が薄いと考えています。

 

例えば会社に1人だけ設計を意識しているエンジニアがいて、他の10人が一切設計のことは考えず、自由にコードを書く会社があったとしましょう。設計をきちんと考える1人のエンジニアはどうするでしょうか?多分、退職すると思います。

 

設計をきちんと意識する人にとって、設計に対する意識が低い相手と議論するほど消耗する事はありません。きちんと整理整頓する人の部屋に、汚部屋の主が引っ越してきて、家を荒らし回るような状況です。相当なストレスです。

 

かといって汚部屋の主を放置すると汚コードが量産されてしまうので、コードレビューで食い止めようとするかもしれません。

 

しかしコードレビューで設計を担保しようとすると、一人に注意した内容を何度も別の人に指摘する羽目になるため推奨しません。コードレビューは「明らかなミスがない事」などの確認に留めるべきで、設計の議論をする場としては非効率です。

 

最も効率的なのは全員で同時に学ぶ事です。一度認識が揃ってしまえば「どこにコードを書くべきか」という時間を取りやすい指摘事項が減らせるので、チームの開発効率も格段に上がります。ファイル名やディレクトリを見た瞬間に「多分こんなことが書いてあるんだろうな」と想像できる世界は幸せです。

 

それに、一人で学ぶより大勢で学んだ方が楽しいですしね。

 

 

まとめ

 

質問:

なぜPrAha Inc.は設計を学ぶ事を重視するのか

 

回答:

・最も無駄になりにくく、最も影響が大きく、かつ最後まで自動化されずヒトに残される領域になると考えているため。

・学ぶ時は全員で同時に学んだ方が良いし、楽しいよ。

 

現場からは以上です!

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

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

 

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

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

 

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