れっぽんブログ

「渋谷ではたらく社長の告白」を読んで自分もできると思って代表と一緒に起業!→全く事業が当たらず、とはいえ投資家や顧客をはじめ多くの人を巻き込んだので、なんとか成果を出したいともがく日々を綴ります。

6/5<抽象化と具体化>

抽象化と具体化

 

最近良い本を読んだ

「具体⇔抽象」トレーニング 思考力が飛躍的にアップする29問 (PHPビジネス新書) | 細谷 功 | キャリア | Kindleストア | Amazon

 

自分が感じていた感覚を図式化、言語化してくれている本であり、

抽象化と具体化に関して再認識することができた。

 

<抽象と具体の違い>

抽象化とは共通点を見つける行為であり、定義された内容の範囲は広く、例外をある意味で切り捨てる。

具体化とは1つ1つ個別のものを見るため、定義された内容の範囲は狭く、例外にもフォーカスをしている。

 

<抽象化の度合いが人により差がある理由>

人は常日頃は具体の世界を見ているため、具体は意識しやすいが抽象の世界は考えないと出てこない。

 

<仕事の抽象化・具体化>

仕事は具体的に指示するほど、期待値とのブレがへる。

一見良いことのように思えるが、期待以下が発生しにくいというメリットもあるものの期待値を大きく上回ることも少ない。

これは指示が具体的であるため、依頼を受けた作業者が自由に仕事をする幅が減っていることに起因する。

 

プロフェッショナルの能力を生かそうとする場合には抽象度のレベルを上げた依頼をあえてしたほうが良い。逆に誰でもできるように仕事を標準化する場合には具体度のレベルを上げた方が良い。

 

前者の例で行くと実際に優秀なプログラマーが2つのことを言っていた。

1人は自分の上司、1人は業務委託で協力してくれた人だ。

 

①詳細設計書が既にあることが常に良い訳ではない。

→設計者の能力が低かったり、考慮不足だった場合に実装フェーズで余計な制限ができてしまう。もちろん認識合わせをすれば解消するがその時間や機会がない場合などは厄介。

 

②技術仕様やUIがイケてないものに決められた後に参画するのはいやだ

→受託会社が枯れた技術を使い、Reactならすぐにできる部分をめんどくさいやり方でやっているのはテンションが下がると言っていた。

 

<顧客要望の抽象化>

具体的な機能を顧客が要望してきた場合もそれをそのまま受け取って実装してはいけない。なぜならば、何か要望があった上でそれを実現する手段として、具体的な機能を提案してきてはいるのだが、他にも要望を実現するようなより良い機能は存在するかもしれない。その場合には「なぜ」その機能を要望するのかということを聞いて、要望を抽象化させた上で再度最適な具体案がないかを探すというプロセスを取るべきだ。

顧客の言うことをそのまま聞いて実装すると言うのは具体、抽象の観点からも浅はかだとわかる。