ラベル 経営 の投稿を表示しています。 すべての投稿を表示
ラベル 経営 の投稿を表示しています。 すべての投稿を表示

2008年7月13日日曜日

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

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

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

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

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

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

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

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

2008年7月12日土曜日

戦略と業務

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

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


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

不思議だ、、、

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

2008年5月31日土曜日

テトリスと経営

最近、高専時代を懐かしむことが多く
ふとしたきっかけで、とある友人の日記をさかのぼってみた

高専時代に切磋琢磨したその友人の日記の中に
こんなおもしろい話があった(勝手に掲載してごめんね > 本人)

-----
1つだけ、ここに書ける面白い話が、俺とすえの思考パターンの違いをテトリスに例えた話。先生曰く

すえ→1段ずつ綺麗に消していく。途中に変な穴ができることはゆるさない。
俺→常に4段消しを狙っていく。多少変な穴が出来ても、長い棒をいれて一気に状況を改善してしまう。
-----

うーん、これ最初に読んだときも納得したけど
あらためて読んでも、非常に的を射た表現だ

高専在学中も、大学に編入学しても、会社を立ち上げてからも
この思考パターンだけはまったく変わってない気がする

もう少し、2段消し・3段消しを覚えて
効率よく仕事こなせるようにならないとね…

-----

会社はじめてから思うのは
経営者ってこれが両方できないといけない、ということ

1段ずつ綺麗に消していくのは
リスクは低いが、大きくあたることはないし

4段消しばかり狙っていると
なかなか長い棒が来なかったりする

多少変な穴ができても、それを覚悟で4段消しを狙うことも必要だし
長い棒が来ない(市場に好機がない)と判断した時点で2段・3段くらい消してしまうという判断も必要

経営って大変だなー