はじめに
いろんなところに"つよつよ"のエンジニアはいますが、"つよつよ"の組織は意外と少ないと思います。あくまでも組織は人でできています。そこで、組織としてやってきたこと、個人としてやってきたこと、それに対して新卒の立場としての感想をお伝えできればと思います。
今年の4月に新卒であるITの会社に入って働き始めました。そこから8ヶ月の中で、先輩の提案や自分の心がけとしてよかったものを実体験を基に書いていこうと思います。「新卒のやつが何を語ってんねん」と思うかもしれませんが、少しだけお付き合いください。
1. チームで取り組む組織実験（組織）
エンジニアは、PCとのコミュニケーションに多くの時間を費やす職種です。このような環境では、情報やベストプラクティスは豊富にありますが、組織の向上を目指す上では、それだけでは不十分です。ここで「コミュニケーション」の重要性が浮き彫りになります。私の会社では、
15分で終わる日次のミーティング
を行うことで、この問題に取り組んでいます。このミーティングでは、個人の進捗や情報共有の時間を設けています。SlackやChatwork、Discordなどのコミュニケーションツールが普及している中、アナログ的なミーティングを行うことに疑問を持つ人もいるかもしれません。しかし、これらのツールを使用した経験に基づき、意識的に対面でのコミュニケーションを選んでいます。
| 項目 | 日次MTG | Slackによる記入 |
|---|---|---|
| 概要 | 全員で集合し、日次タスクや共有事項などを発言 | 個人的にSlackのボットを活用して、専用のスレッドの配下にタスクや共有事項などを記入 |
| 時間 | 15-30分程度 （内容によって前後：ただしそこまで時間をかけない） |
0-5分程度 （個人の記入タイミングに依存する） |
| ポジティブ | ・1つの話題から質問や相談に発展し、詳細に確認しやすい ・コミュニケーションの機会となりうる |
・時間的制約がない ・他の人のタスクを見ることができるので把握しやすい |
| ネガティブ | ・時間的制約がある ・作業中断などをしなければらない |
・積極性がないと関われない ・コミュニケーションの機会損失 |
合理的に考えると、Slackによる記入が効率的ですが、人間的な側面からは、コミュニケーションを通じて人間関係を構築することにも価値があります。現在、私の会社では日次ミーティングの最適な形を模索しており、このミーティングを中心に実験を行ったり、意見交換の機会を設けています。日次ミーティングの方法としては、Slackとの併用やSlack上でのコンテンツを増やすなど、さらなる改善の余地があると考えています。ちなみに他の会社では、ミーティングの形態は多岐にわたります。例えば、スタンドアップミーティングは、短時間で行われるため作業の中断を最小限に抑えることができます。一方で、リモートワークが普及した現在では、ビデオ会議ツールを利用したミーティングが増えており、時間と場所の制約を超えた効率的なコミュニケーションが可能になっています。それぞれの会社の文化やニーズに応じて、最適なミーティング方法を選択することが重要です。
2. 新卒や若い人に裁量権を持たてみる（組織）
新卒の僕自身が言うのは違うかもしれませんが、そこそこ期待をされているように思います。しかし、これは2つの意味で理にかなっているといえます。
上の立場が危機感を持つ
→ 新卒や若手社員に期待することは、経営層や上位の職位にある人々に新たな危機感を与える効果があります。彼らが新しい視点や意見に触れることで、自身の考え方や行動に再考を促すことができるのです。
若い人たちの新たな気づき
→ 若手の社員は新鮮な視点を持ち、時には従来の方法に疑問を投げかけます。彼らの意見を聞くことで、組織全体が新たな発見や改善の機会を得ることができます
社会に入るとよく言われるものが「そういうものだと飲み込む」など現状を理解し、そういうものだとすることです。これは正直、脳死状態です。特にZ世代と呼ばれる人たちは、なぜ？が意外と原動力の基になります。逆に理由のない物事に対して否定的であることが多いです。Z世代だからと言うわけではなく、新人を育てることによる効果として、「上の立場が危機感を持つようになる」 は大きいのではないかと思います。「先輩である私が...」という気持ちが生まれ、負けるわけにはいかないと努力する可能性が生まれます（Qiitaでよく見る変なマウントおじさんも生まれてしまうこともありますが笑）。さらには、新人目線での意見として、教育リソースの見直しや一見薄っぺらい意見に耳を傾けて考えてみると新たな気づきがあるかもしれません。
個人の実体験としては以下の3つが特に裁量権を持たせてみるといいかもしれないと思っています。
- エンジニア教育（欲しかった研修や社内の知見を貯めるための活動など）
- 環境の改善活動（業務効率化や開発生産性のツールの使用や取り組みの提案など）
- 他部署との関係構築（他部署との窓口にすることで会社のシステム概要やビジネススキームの理解など）
3. ちょっとしたところのフォーマット決め（組織）
要件定義や申請などのフォーマットを決めておくといいでしょう。特に監査対応などでもチケットの書き方や優先度などが一定の基準で定められていると、記入スピードも早くなり、一定の質も担保されます。
例えば、親チケットなどの概要のところでは、以下のように書いてみるのはどうでしょう。
◾️ 背景（Who/What）
// ここでは、誰からどういう要望があったのかを書く
◾️ 原因（Why）
// なぜそういった現象が起こっているのか？
// なぜ必要なのか？
◾️ 方法（How）
// 実装方法や作成方法など
◾️ 期限（When）
// 納期はいつなのか？
// 想定期間はどれくらいなのか？
あくまでも上記は例ですが、このようにフォーマットを決めておくと新人でもほとんど説明がなしに書けたり、別の人がチケットを覗いた時に理解しやすいといった時間的コストは"ちりつも"で減らしていくことができるかもしれません。意外とこのコードを書く以外の仕事を減らすことは重要なことも多いようです。
4. 社内ナレッジの大全集を作る（個人）
社内のナレッジを貯めるために、社内用のQiitaみたいなものが存在する会社は多いと思います。この取り組み自体はものすごく大事で、似た現象や社内システムの特徴にフォーカスした知的財産が詰まっています。しかしそれが乱雑だと逆にコストがかかってしまいます。
実際、僕が入った時に、
「ローカル環境の構築では、このURLをみて...」
「ステージングでデプロイする方法は、このURLを見て...」
「〇〇案件の参考にこのURLを見て...」
とURLの嵐でした。どれだぁぁぁぁぁあああああ！！！！となり、これらのURLの整理をそれぞれ個人がやるのは新人の理解の本質には必要ではありません、どちらかというと
カンニングできる環境を作る方が効率的である
といえます。
それならば、【新人向け】とラベルをつけるなり、新たに新人向けのURL大全を作成していくという小さな取り組みをしていく方が簡単ですし、ナレッジも溜まりやすくなります。必要なものがなければ、書いていけばいいだけになります。
エンジニア組織をいかに"つよつよ"にするか
"つよつよ" のエンジニアはたくさんいます。でもなにを持ってつよつよと言えるかはさまざまです。
例えば
- web開発には詳しいけど、データ関係ができないようなスペシャリスト的な人
- 全般的な概要については詳しいけど、奥底まで理解がいっていない人
- 会社の中身はものすごく詳しいが、一般的なところは理解が浅い人
- 全部できてしまう珍しい人
など感じ方はそれぞれです。どの人材を育てたいかは会社の方針次第ですが、個人がどのように組織を作っていくかを考える必要があります。エンジニア組織をつよつよにするかは今後、永久に問題となっていくと思いますが、そこに向き合っている組織や個人ほど、つよつよになるのではないでしょうか。