新社会人のための会議で意識してみてほしいこと｜SHIFTのブログリレーDAY.13
ーこの春、頑張るあなたを応援したい！ー
こんにちは！SHIFTの公式note「SHIFTグループ技術ブログ」編集部です。
この春、新社会人になられた方や、転職など新天地でのスタートを切られた方など、今を頑張るすべての方へ（勝手に）エールを贈りたい！
今自分たちがもっているノウハウや経験を、書いてつないで、頑張るあなたに届けたい！そんな、“おせっかい心”から生まれた企画です。
・GW明けから勝負本番！良いスタートダッシュを切りたい！
・新人扱いしてもらえる今のうち！やっておくべきことは？
・みんなが優秀に見える・・・これから大丈夫かなあ。
そんなさまざまな気持ちに、社会人の仲間として、ときには少し先輩として、SHIFTの公式ブロガーたちが全力であなたに伴走します。
少しでも、今を頑張る方の前へ進む力になれますように。
みなさまにご一読いただければ幸いです！《開催期間：5/1-25》
DAY.12の本日はこちら！
『新社会人のための会議で意識してみてほしいこと』
DAY.11◀◀◀
頭脳の格闘技 将棋で脳に汗をかこう！ ～ ITエンジニア必見 将棋でスキルアップする方法とは？～ SHIFT将棋部
はじめに
こんにちは。SHIFTのいしいです。
社会人たるもの、会議は避けて通れませんよね。
そして聞いてるだけの会議ほど無意味なものはありません。
特にプロとして仕事を受注し、意見を求められるような立場であれば、
会議では何らかの提案をしていかなければなりません。
「まだ若手だから、とりあえず様子見しよう…」
そんな風に思っている新社会人の方も多くいらっしゃるかもしれませんが、
そんなことを言っていると２年たっても３年たっても傍観者から脱却できず、いつまでたってもプロ意識の欠如した働き方しかできません。
ということで、ここを意識すれば会議も怖くない！
というポイントを今回はご紹介したいと思います！！
…ちなみに、以前こちらのnoteで「エンジニアのための言葉選び」というテーマで、コミュニケーションについての記事を書かせていただいておりまして。今回は5月ということで「新社会人のための会議で意識してほしいこと」という第2弾的なテーマとなっておりますm(_ _)m
執筆者プロフィール：石井一成
業界経験7年目。 そろそろ若手は苦しいけれど、ベテランというにはまだまだ遠い経験値。 SHIFTでは、UNIT～GUIテストの自動化アーキテクトを主に担当しているが、 品質プロセスの改善とか、スクラム体制の構築支援とか、 効率化、品質向上の文脈ならチームビルドでもプロセス改善でも何でもやっています。 ジムで筋トレを自宅トレーニングに変更した結果、ちょっと筋量と脂肪量のバランスが改善されてきた。 健康はQOLの向上にだいじ。
本題："すべき"、"したい"、"できる"をきちんと使い分けよう
今回のポイントはずばり「"すべき"、"したい"、"できる"をきちんと使い分けよう」です。
当たり前のようでいて、これが意外と難しい。
英語でいうとshould(≒must),will,canですね。
そして会議で混乱するときというのは大抵これらがごっちゃになって話がまとまらなくなる時です。
たとえば「開発者には単体テストをきちんと書いてほしいんですよね。」
という意見が出たとしましょう。
皆さんはこれ、どのように受け取るでしょうか。
声のトーンが厳しければ、
「開発者が単体テストを書くのは当たり前のことで、
書いてないなんてありえないんです。今すぐ書いてください」
という選択の余地のないshouldな命令にも見えますし、
声のトーンが穏やかだったり、前後の文脈によっては
「今はかけてないですけど、単体テストを書いて品質を良くしていきたいですよね。みなさんは同じ気持ちですか？あんまりそうは思ってないですか？
認識のすり合わせをして今後の方向性、対応の優先順位を整理したいです。」
といった、強制力のほとんどない意見提示(will)、今後の方針検討だけしたい場合もあり得ると思います。
あるいは、
「ソースがテスタブル（テスト可能な状態）になっていないので、
ソースをリファクタリング（改善）したいんですけど、どうしたらできますかね？」
というできてないからできる（can）ように改善したいね、
と改善案の検討の場を設けようとしているようにも見えます。
言われた側はこの辺の意図が不明瞭だと、
shouldなのか,willなのか,canなのかを予測して返事をするわけですが、
予測が外れると悲しいことが起こります。たとえば
A「～できるようになりたいですよね」(canで発言)
B「改善します」(shouldで受取)
A「え、全部任せちゃっていいの？解決できなかったとは言わせないよ？」
A「～したいですよね」(willで発言)
B「こういう協力をしてもらえると改善ができると思います。」(canで受取)
A「え、なんかやる前提だけど、優先順位はそれが最高でいいんだっけ？
まあやるっていうならやらせとくか。メインタスクが遅れたとは言わせないけど」
こんな行き違い、たくさんあるのではないでしょうか。
会議って、それぞれ役割の違う人たちが、
違う問題意識をもって、限られた時間の中で話し合いを行うんですよね。
そうすると、それぞれ違う前提をもって前置きを省略し、
ある人にとってはどうでもいいことを別の人は強い熱量をもって話し始めたりします。
そうするともうかみ合わない。
ケンカしないでいいところでケンカし始めたり、
ケンカを恐れて意見が出なくなり、適切な意思決定ができなくなったりするわけです。
困りますよね。
上にあげた会話例であれば、
「開発者は単体テストを書く"べき"とは思っていますが、
できるかできないかは別にして、その認識はあいますか？
認識あうようであれば、単体テストを充実"させていきたい"んですけど、
フロントエンドの単体テストって経験がないとなかなか難しくて、
現状の体制だと"困難（できない）"ですよね。
開発者を一人、一時的に単体テスト専属にしてテストサンプルを作ることで、スキルトランスファーを加速させて単体テストを拡充"できる"ようにしたいんですけど、そういう体制を構築いただくことって可能ですか？」
ぐらい丁寧に発言したほうがよいのですが、
いうべきことが多くてこんな文章簡単には出力できないですよね。
言うべきことを整理するときには「"」で囲ったように、
should→will→canで考えを整理するといい感じにまとまります！
さらにそれぞれにBecause（なぜならば）をつけるともっといい感じになります！
例）
Should:単体テストのカバレッジはC0で85％以上を目指すべきですよね。
Because:徹底的な仕組み化（標準化）を行っているGoogleの指標値がそのぐらいだからです。
Will:我々としては95％を目指したいです。
Because:というのも、現在のソースコードはほとんど必須のビジネスロジックだけで構成されており、
めったに通らない異常系の分岐などは全くないからです。
Can:きちんとテストコードを書く時間さえ確保できればトレーニングは特に不要で、十分実現可能です。
Because:開発チームの技術力的にも、現状のコード実装的にも特に問題は見当たらなかったので、最低限の時間確保で十分だからです。
といった感じでしょうか。
まあこれはあくまで例なので、課題が2段階3段階あったり、複雑に絡み合ってたりすると
should→will→canのきれいな流れができない場合もあるかとは思いますが、
・この1文はshould,will,canのどれを言おうとしているのか？
・それぞれに適切な根拠（Because）があるか？
を意識するだけで、かなり混乱を避けられるようになるでしょう。
まとめ
ということで少し長くなりましたが
新社会人のみなさま。
ぜひともshould,will,canを使いこなして、
スマートな社会人生活をお送りいただければと思います。
最後までお読みいただきありがとうございました！
明日のバトンは、
▶▶▶DAY.14
＼SHIFTのブログリレー全記事CHECKはこちらから／
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/