「できないこと」の重要性

システムの開発でも、会社の経営でも、学生団体の運営でも
はたまた一個人のキャリア形成や就職活動においても
「できないこと」を定義することは極めて重要だとつくづく感じる

ヒトはよく、何かの意思決定をするとき
「自分（たち）は何をするべきか・やりたいか」を考える
その結果、あれもやりたい・これもやるべきだ、という混沌に陥って
結局、何がやりたいのかわからなくことは多々ある

だからこそ、「できないこと」「やりたくないこと」をきちんと定義する

システム開発では、“実装しない”機能はあらかじめ排除するべきだし
会社の経営では、“アウトソーシングする”事業やタスク、“参入しない”市場を明確にするべきである
企業よりもリソースが限られている学生団体ならなおのことそうだ
就職活動でも、“やりたくない”仕事をあらかじめ考えておく

これは「できること」を考えるよりはるかに難しい
ある部分を棄てて、狭い分野に特化していくということは
リスクも高くなるし、そう簡単に結論を出せることではない

経験上、頭のいい人ほど、こういう意思決定は苦手なようで
拡張性、多角化、汎用性、ゼネラリスト…など
耳障りのいいフレーズにだまされる

こういう思考は、世の中のことを何も知らなかった小学校や中学校のころのほうができていたな…
もっと素直に「○○はやりたくない」と言えるようになりたいものだ

戦略と業務

思考　よりも　作業
戦略最適化　よりも　業務効率化
コンセプトメイキング　よりも　コンテンツメイキング
高尚なビジョン　よりも　目先のオペレーション

のほうに嗜好が偏っている僕。


だけど、ことシステム開発においては
コーディングやデバッグのフェーズよりも
設計フェーズのほうが楽しい。

不思議だ、、、

追記：
自己レスです。笑
“コーディング”という名の業務を効率化するという意味で、“設計”は業務効率化の一環だということに気付いた。確かに「きれいなコードを書く」ことが目的化する場合もあるけど、それは大学のレポートだったり、論文の執筆など「コード自体がさらされ、評価の対象となる」場合が多く、「コードが実行された結果与えられるサービスが評価の対象となる」ビジネスの場では極めて稀だったりする。
システム開発における“戦略”や“ビジョン”に該当するのは、(マーケティング的な意味での)画面デザインやユーザビリティの設計であって、確かにDBのテーブル設計やクラス図作成に比べるとおもしろくない。笑