Aさんから学ぶオブジェクト指向設計

はじめに

筆者はインターン先でエンジニアとして働いている。
エンジニアは筆者だけでなくもう１人(今後「Aさん」と呼ぶ)居たのだが、先月(2023年8月)いっぱいで辞めてしまった。Aさんは辞める最終日に人事の方と仕事や会社に関するフィードバッグをしたらしく、その結果が筆者に共有された。

フィードバッグ内容にはAさん自身の学びについての話があった反面、会社や個人に対する改善点なども共有された。その中の筆者に対する改善点として、「オブジェクト指向を持った方がいいと感じた」と伝えられた。

筆者はその内容を聞き、「『オブジェクト指向』は知っているけど、どの点において足りないと感じたんだろう」と思った。
※実際はちゃんと知ってなかった(by 記事書いた後の筆者)

といった背景があるので、本テーマは「オブジェクト指向とはどういうものか」「Aさんはどういう点においてオブジェクト指向が足りていないと感じたのか」「どう直すべきか」を考えていきたい。

思考の順番

1. オブジェクト指向の事前知識
   1. 共通概念としてのオブジェクト指向
   2. プログラミングにおけるオブジェクト指向
   3. 設計におけるオブジェクト指向
2. Aさんは筆者のどの点において「足りない」と評価したか
   1. 実際にどんなこと言われたのか羅列
   2. 事前知識をもとに考える
   3. 改善点を考える
3. まとめ

オブジェクト指向の事前知識

筆者の持ち合わせている知識で考えると以下のような感じ

▼共通概念

「(ある役割を持った)モノ」ごとに分割し、モノとモノとの関係性を定義していくことでシステムを作り上げようとするシステム構成の考え方

▼プログラミングにおけるオブジェクト指向

プログラムを「単体」ではなく「かたまり」で考える

👇例
ゲームのモンスターや武器のステータスに対し、「１つ１つのステータスを調整しよう！」ではなく、「『モンスターA』・『武器A』でステータスを調整しよう！」といった感じ

▼設計におけるオブジェクト指向

※筆者はここに関して知識を持ち合わせていないのでネットで調べる
【参考文献】
１．オブジェクト指向設計とは? - Qiita

・オブジェクト指向設計を知るうえで、「Subject (主体)」と「Object (客体) 」を知っとく必要がある
　・Subject：見る側。知る側。　※対象は「一般的な人」「利用する人」などの主体
　・Object：どう見るか・知るか・考えるか。　※対象は「Subjectはどう理解するか」という客体
　⇒オブジェクト指向設計の考え方には、「存在Aに対し、『Subjectは存在AをObject』として理解する」という概念が干渉する
　ーーーーーーーーーーーーーーーーーーーーー
　・例：『自転車』で考える。
　　・Subject：一般的な人
　　・Object：１人用の乗り物として見る。「○○のように操作する」と知る。移動するものと考える。
　　・考え方👇
　　　・自転車について、一般的な人は「１人用の乗り物であり、ペダルに乗ってアクセルやブレーキ等の操作をしながら移動するツールである」と理解する
　ーーーーーーーーーーーーーーーーーーーーー
・オブジェクト指向設計は、「Object (客体) をもとに存在Aをモデル化 (=単純化)してソフトウェアを設計すること」である
　・簡単に言うと、「存在Aに対する見た目や機能などへの共通認識を定義化し、それをもとにソフトウェアを設計すること」を指す
　・例
　　・存在A：物理的現象
　　　Object：現実世界で起こる物理的ななんらかの発生
　　　設計したもの：数理モデル(現実世界の物理現象 ⇒ コンピュータ世界でシミュレート)
　　・存在A：人
　　　Object：それぞれが個性や体質や経歴を持つ
　　　設計したもの：ユーザーアカウント(人に関する情報 ⇒ コンピュータ内で存在(管理))

👆コメント
・設計時にオブジェクト指向ができると利用する側の視点に立つことができ、ユーザーに合ったシステムを開発することができるね
・プログラムにおけるオブジェクト指向は、「プログラムを『かたまり(Object)』として考える」こと
・設計におけるオブジェクト指向は、「ユーザー(Subject)の考える理想像(存在A)の『特徴(Object)』を考える」こと

Aさんは筆者のどの点において「足りない」と評価したか

前提としてAさんは、「プログラミングを書くうえで、ユーザーに対するオブジェクト指向が足りていない」と考えている。

Aさんと働いていく中でいくつか筆者への指摘があり、その内容はオブジェクト指向が関係していると考える。ただその関係性は現状うまく言葉にできていないので、本記事で言語化したい。

↓↓↓ 実際に言われた内容を思い出してみる ↓↓↓

▼実際にどんなこと言われたのか羅列

１．「上司が『○○さん(筆者)は○○といったミスを過去にしてた』みたいなこと言ってましたけど、多分行動に移す前に上司に相談していればミスしなかったと思います」
２．「上司に質問する意識とか習慣は大事ですよ」
３．「コード書くとき○○さん(筆者)はコードしか見てないです。もっとユーザー視点に立つべきです」

👆コメント
・絶対オブジェクト指向設計に関することじゃん

▼事前知識をもとに考える

Aさんに言われた事と事前知識をもとに考察してみる

まずAさんから言われた内容から、Aさんにとっての筆者の「明確なミス」は以下の通りである。
　・行動に移す前に上司に相談しなかったこと
　・ユーザー目線の開発をしていないこと

このミスをオブジェクト指向設計と絡めて考えると、筆者の足りていない思考は以下の通り
　・「開発前に皆で『正しいObject』を定義化するべき」という正解への軸を定める視点
　　👆前提として持つべき基盤
　・「成果物を利用する人(Subject)は、きっと○○がしたいのだろう(Object)」という予想
　・「ユーザーから『○○してほしい』と要求する意図と理想像はきっとこうだろう」という予想
　　👆個人で考える領域
　・「自身の考えるObjectは間違っているかもしれない」という不正解の可能性という視点
　　👆皆で考える領域

まとめると、「筆者は完成形を個人の解釈だけで定義化し、『正しい成果物』を全体で定義化することを怠ったこと」が問題である。
Aさんが言いたかったことはこれであり、だからフィードバック時に「○○さん(筆者)はオブジェクト指向が足りていない」と評価した。

▼改善点を考える

改善点を考えるにあたり、変化するべき項目と正しい方向性は以下の通り

【変化するべき項目】
・個人で解釈する成果物を作ることが目的になっている点
・自分の意見を共有する必要性を感じていない点

【変化するべき正しい方向性】
・「相手の理想像」を把握する為の行動

そのうえで、Ａさんが実際に言っていた事と二度と言われない為の具体的な行動を考える
ーーーーーーーーーーーーーーーーーーーーーーーー
１．「上司が『○○さん(筆者)は○○といったミスを過去にしてた』みたいなこと言ってましたけど、多分行動に移す前に上司に相談していればミスしなかったと思います」

【対策】
・実行前に、依頼人と『理想像』『フローの概要』の共有をする

👇例
１．上司から依頼があったら、「○○という目的の手段として○○があるということですね」と自分の意見を共有
　　・もし違かったら修正してくれる
　　・テーマに対する新たな視点が出てくるかもしれない
２．実行前に、「私はこの作業に対して○○というフローで行おうと考えていますが、何か不足している事や根本的に間違っている事などはありますでしょうか」と伝える
　　・もし違かったら修正してくれる
⇒正しいObjectを全体で定義化することに成功！
ーーーーーーーーーーーーーーーーーーーーーーーー
２．「上司に質問する意識とか習慣は大事ですよ」

【対策】
・「正しいObjectを定義化するべき」という考え方をもつ
・質問しやすい環境を作る

👇例
・普段から相手とコミュニケーションをとる
　・自分だけでなく相手も「この人と話すべき・話したい」という意識を持った方が円滑に物事は進む
　・相談しやすい人間関係を作る
・コミュニケーションを取りやすい環境を作る
　・近くに上司がいる環境(リモート ⇒ 出社)
　・連絡先交換する
⇒そもそもの会話をしやすい環境づくりに成功！
ーーーーーーーーーーーーーーーーーーーーーーーーー
３．「コード書くとき○○さん(筆者)はコードしか見てないです。もっとユーザー視点に立つべきです」

【対策】
・オブジェクト指向プログラミングも大事だが、オブジェクト指向設計も一緒に考える

👇例
・「よし、正しいObjectも決まったことだしコード書くか！ あ、その前に完成形は具体的に○○で、逆算すると必要になるものは○○で、こういう場合やエラーへの可能性も考えて、あとは他エンジニアにも見やすいコードも考えて．．．」
・「ねぇAさん。俺こういう感じでコード書こうと思ってるんだけどAさんも同じ考え？ あとコード書くうえで意識しておいた方が良いことってあるかな」
　・Subjectは成果物に対する「ユーザー」と「開発者」の2つで考える
　・「行動に移す前に理想を共有」という意識は必ず持つ
⇒「作った後に面倒くさいことにならない(=非効率を作らない)」危機回避に成功！
ーーーーーーーーーーーーーーーーーーーーーーーーー

👆コメント
・ガチで重要で俺に足りていない事じゃん。
・まとめてよかったわ。仕事始める前にマインドセット用でこの記事活用しよう

まとめ

オブジェクト指向設計とは「対象物へのSubjectとObjectを定義化(モデル化)して設計に組み込むこと」であり、ユーザーの満足度向上や非効率回避に有効である。

Aさんは筆者のこの思考が足りていないと判断し、「オブジェクト指向が足りていない」と評価した。

筆者が今後するべきことは以下のようになる
１．依頼側のObjectと自身の考えるObjectを共有しあい、全体で正しいObjectを定義化する
２．依頼側だけでなく開発側のObjectもできる限り定義化する
３．共有しあえる状況を作るための環境づくりを普段から行う

※４．「１．～３．」を習慣づけるためにも仕事前にこの記事を読む習慣をつける

おわりに

テーマにして本当に良かった。
まとめればまとめるほど自分に足りないものと改善するべき具体的行動が見えてきて嬉しい。

もしこの記事を見てくださった方で、「ここの認識違うよ」「こういう考え方も入れるべきじゃない」といった意見がございましたらコメントして頂けると嬉しいです。