オブジェクト指向の恩恵
が、その有益さを「プログラミングから離れて」説明している資料が少ない
より成長・事業推進するにはレバレッジが効く施策が欠かせない。 レバレッジを効かせるためにはオブジェクト指向が欠かせない
ITにおけるオブジェクト指向 とは
オブジェクト指向とは、コンピュータプログラムの設計や実装についての考え方の一つで、互いに密接に関連するデータと手続き（処理手順）をオブジェクト（object）と呼ばれる一つのまとまりとして定義し、様々なオブジェクトを組み合わせて関連性や相互作用を記述していくことによりシステム全体を構築していく手法。
なるほどよくわからん。
IT領域に特化した書き方をしている。
ので、適当にtsawada.iconなりに言語化していく
オブジェクト指向でモノを捉えられると、
「精緻に作り込まなくても全然問題ない」ケースに気付くことができる
「Aじゃなくて、ちょっと機能が違うA"を作ると、来年作ろうとしている機能B作らなくても済む」とか気付ける。
すごくシンプルな1機能が、様々なケースで役に立つ。という例
オブジェクト指向はシステム思考するために必須の考え方
共に、モノやコトといった要素間の関係性・繋がりにfocusする考え方。
ロジカルシンキングだと、「aはAを分解した一つだよね」という話をする
システム思考だと、「（Aの要素として、a1とa2があった上で、）a1とa2はBという関係性だね」という話をする オブジェクト指向で捉える「車」
ある家族がaudiを持っているとする
audiと家族との関係性を見ていく。
父にとってaudiは「所有欲を満たしてくれるかっこいいもの」
母にとってaudiは「（公共機関が発達していないこの地域で）大事な移動手段」
娘にとってaudiは「（ドライブ中に）80年代のCDを聞く場所」
というふうに、「audi」という車自体は変わらないにもかかわらず、家族それぞれがaudiをどう見ているか？は全然違う
母親以外、「それ、実は車じゃなくてええやん…」って感じ
どう見ているか…「どんな働きを期待するか」ですねtsawada.icon
今回は、わかりやすく「人とモノ」で例えてみたが、これは「モノとモノ」でも「コトとコト」でもこれは整理できる
例えば「新卒研修」をオブジェクト指向で整理して、考えてみる
私は研修担当。研修チーム3名のなかで、私は新卒研修を担当している。
新卒研修では一般的に「新卒がOJTに入る上で必要な知識・スキルを得る」ことが期待されている
期待からみると、レクチャーやワークショップである必要もない。
中途研修で期待する「中途がこの会社独自の風習・風土を知り働きやすくなる」も同時に満たすコトを考え、コンテンツにすると…レバレッジが効きそう
中途研修も、新卒研修も「風土を知ってもらう」ことは両方で求められている
結果としてカルチャーブックを作って配布することにした。
実は…「経営陣と既存社員の間で、風土理解度の差がある」ことに途中で気づいたため。
新卒にinputしたいマナー等の社会人基礎を新卒数人のためにコンテンツ作りからするのは他での転用も効かないので、外注することにした
この一連の動きはとても良い動きなので、どんな流れだったか整理する
1. 自分の責任範囲より広く、関わる業務・役割を洗い出してみる
2. 洗い出した業務をそれぞれオブジェクト指向で捉え直し、「今任されている業務と似ていないかな？」とチェックして行く
3. 似ているものは一気にまとめて解決できないかな？と考えてみる
この時、自分の最初に任された業務（責任範囲）の成果を最大化させようとしない
「似ている」場合は、「似ているけど違う」部分をちゃんと洗い出しておく
上の研修の例だと「新卒研修で必要な社会人基礎」部分は他と違った。
違うから、「これって本当に必要…？」と考え、必要じゃなければ捨てる。必要であればちゃんと対応する。
今回は必要と考えたので、外注することで担保したtsawada.icon
4. 似ているものを同時に解決できるアイディアを実装する
世の中のモノ・コトは相互に影響しあっている。
例えば、店舗売上。
ロジカルシンキングだと「来客数」x「客単価」と整理して、「客単価をあげよう」と考える
ロジカルシンキングでは、要素を分解することで「来客数を考えない」ようにしている。
考える内容が複雑だと…とても考えにくいため、こうやって「考えないポイント」を見つける作業自体は大事。
だが、「来客数」を考えないようにしたのは悪手。
「客単価」をあげることで、「来客数」が減る可能性があるから。
システム思考だと「来客数」と「客単価」の関係性に注目する。
今回だと来客数と客単価はトレードオフの関係性がありそう。
トレードオフの関係なのに、「客単価（来客数）だけを考える」と結局店舗売り上げが上がらなさそう。
このポイントに「ロジカルシンキング」だと気付き損ねる。
だから、この因数分解の仕方は問題だと気付く。
違う分け方をしてみる「ユニークユーザー数」x「来客頻度」x「客単価」と分けてみる
………と考えていくと、「この分解の仕方だと、問題が考えやすくなる」ケースが存在する。
このケースを見つけることができれば強い。
「目的思考」と「オブジェクト指向（システム思考）」は違うと思っているtsawada.icon 目的思考だと、「今見ている要素a」の目的までしか考えない。
目的思考だと考える範囲が狭くても許される感じ
今見ている要素aがより大きな要素Aの一部であり、その中でどのような役割を担っているか？
より大きな系において、要素aは本当にその役割を担っていていいのか？
というのは、目的思考では全然論点として上がってこない。
システム思考、オブジェクト指向では、「要素a以外の要素」がたっくさん出てくる。
オブジェクト指向では「その目的で良いのか？」は要素aと関係する要素b, c, dからの見え方（期待される役割）によってしか決定しない
他の要素がないと、目的が定義できない。より大きな領域を考えないと「正しいか？」が判断できない
オブジェクト指向で細かく「モノ同士の関係性」を見る癖がつくと、
「あんまり関係していない部分」が見えてくる。
見えたら、分けちゃう。分けてから「別々に考える（なんとかする）」方が簡単だから
結果、タスク分解がとてもうまくなる。
関係が深いところは一気にやってしまわないとだめ。
タスクA→B→Cとやって、CのタイミングでAの内容に影響が出たら、やり直しになっちゃう。
先にやったことが後で覆されないように、タスクは分解しないといけない。
B、Cの作業がAに影響（関係）しないか？をタスク分解時点で確認するのだ。
PMBOKはこのタスク分解がうまくできている。から、PMBOKを参照すると、どんでん返しが少ない 世の中にすでにある業務プロセス・作業フローも、研究されきったものはどんでん返しが少ない。
誰かがぽっと作ったものは、どんでん返しが発生しうる。
タスク分解…がうまくできると、業務分解…つまりどう組織・チームを作るべきか？もわかる
チームAが何かすると、チームBに悪影響…という業務分解すると悲惨。
チームAがいろいろ試しても、チームBには極力影響がないようにチームを分ける。
（完全に分けられるわけじゃないから…情報共有はもちろん大事だけど）
「思ったより浅い関係じゃん」が見えてくる。
作り込まないで良いことがわかる
「上司に期待されているのがExcelで表を作るだけ」ならば、表を作るだけでいいのだ。
自分は作れるから…！と「表をグラフに変える」「色を見やすく変更する」「値をパーセント表示にする」はしなくて良いのだ。
期待されている以上の作り込みはしないのが吉。
時間としてもそうだし。
作り込めば作り込むほど、一般的には「果たせる役割」が減っていくから。
表だけであれば、そのままcsvデータをプログラムに読み込ませて処理ができたかも。
グラフにしてパーセント表示に変えた結果…プログラムに読み込ませられないかも。
良かれと思ってやった作業が全然いらないものになるね
「あれ、この要素Aと要素B……他の要素との関係性を見るに、同じものでいけるのでは？」が見えてくる
同じものでいけるのであれば、同じものに差し替えちゃう。
一つしかモノを作っていないにもかかわらず……いろんな箇所で役に立つね。お得。