110
70

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

「オブジェクト指向で書けるチーム」の作り方

Last updated at Posted at 2023-04-19

材料

  • オブジェクト指向※1に詳しく経験のあるリーダー:1人
  • オブジェクト指向で書かせたいメンバー※2:少々(1〜4人)
  • イチからチームで作れる大きさのプロジェクト※3:1つ

※1 オブジェクト指向でなくDDDでもデザパタでも代用可能
※2 「オブジェクト指向って美味しいの?」レベルのメンバーでも十分可能。設計に興味があるメンバーがいると仕上がりが速くなります。
※3 既存の設計にあまり依存せず、設計の自由度が高い案件だとよりよく仕上がります

レシピ

1.「今回のプロジェクトはオブジェクト指向で書きます。異論は認めん」とリーダーが高らかに宣言する

すべてはここから始まります。ポイントは、リーダーの絶対王政であること。

プログラムを手続きでしか書いたことないメンバーは、そもそもオブジェクト指向で書くと何がいいのか体験していません。なので、理論を教えて事前に納得してもらうより実際に見せたほうが圧倒的に早いです。そして、見せるにあたってメンバーに口答えさせずに粛々とOOP(オブジェクト指向プログラミング)を実行する必要があります。

余談:
ちなみにウチでやったときは、メンバー全員が手続きで書く世界しかしらないレベルでした。プロダクトには脳死で作られたサービスクラスが氾濫しており、メンバーはプリミティブな型でやりくりする石器時代の住人です。(私もその一人です)

もう一つのポイントは、リーダーが事前に設計を考えないこと。

あえて回り道をしながら設計していくことで、さっきの設計と今書いた設計の比較ができ、なぜこう設計すべきなのかという理解が深まるからです。ただし、リーダーにとっては「設計を考えない」というのはかなり精神的苦痛を伴います。体調が悪くなった場合は速やかに医師に相談してください。

2. “モブプログラミングで”開発をスタートする

手っ取り早くチームにOOPを普及させるために、モブプログラミングのメリットである「最速で知識が伝播する」という性質を利用します。モブプログラミングをやったことがなくとも、やり方だけさらっとググって見様見真似でやるだけで十分です。

注意:
コーディング途中の「なんでこうするんですか?」という質問は無視してください。日が暮れます。まずは出来上がったコードを見せることだけ考えてください。

3. メンバーが不満を口にし始める

数時間〜1日リーダー主導でモブをやっていると、メンバーが「意味がわかりません」「今何やっているのかわかりません」「やり方変えませんか?」とぶつぶつ文句を言い始めます。メンバー側は「概念をオブジェクトにする」という考え方を知らない石器時代の住人なので、現代テクノロジーに拒絶反応を示し始めます(一番ブツブツ文句言っていたのは私です。)

肉を炊いたらアクが出てくるのと同じレベルで自然な現象なので、リーダーは無視して絶対王政を貫いてください。くじけてはなりません。

4. 機能をひとつ作り上げた頃にメンバーがなんとなく良さを理解している

1機能作り上げたあたりで、メンバーがざっくりとオブジェクト指向の良さを体験し始めます。以下のようなミーハーな感想が出てくるでしょう。

  • 「めっちゃ読みやすい!!」
  • 「ポリモーフィズム(ダックタイピング)かっけえええ!」
  • 「テスト書きやすぅぅぅぅ」

かわいいですね。ここから、設計に面白さを見出したメンバーは自発的に設計本を読み漁るようになるでしょう。スパイスとして、開発途中におすすめ本を伝えて勉強を同時並行で進めてもらうのもよいです。

5. 慣れたらペア・ソロに切り替えて自分で書かせる

ここからは、メンバーが自分ひとりでも設計できるようにペア・ソロでタスクをアサインし、コードレビューで改善していきます。このあたりでメンバー相互で設計に関するレビューを行うようになります。PRでの設計レビューが難しい場合、ウチではモブレビューという手法を取り入れています。リファクタをモブで行うイメージです。

絶対王政スタートから半年ほどで、かなり洗練されたOOPをチームに根付かせることができていることでしょう。

6. プロダクトの全体的な設計に目がいくようになる

これまでは小・中規模のモジュール単位での設計がメインでしたが、ここからさらにMVCなどのフレームワークにおいて各モジュールの適切な粒度なんかをチームで議論し始めます。よく言う「ファットコントローラー」「ファットモデル」問題ですね。ここまで来ると、日々の開発の中でより洗練された設計、より実益のある設計(過剰設計の配慮)に向かってメンバーが自走し始めるため、定期的に勉強会を開催する程度で十分になります。

これで、一旦の完成です。お試しあれ☆

P.S.

ネタっぽく書いてますが、ウチのチームで効果実証済みの方法ですので「チームメンバーをオブジェクト指向で書けるようにスキルアップさせたい」とお考えの上長・リーダーの方はぜひ参考にしていただければと思います。

110
70
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
110
70

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?