Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

経営者の仕事 ~長文御免

「経営者は技術者であるべき」…そうあって欲しいですが、『十分条件である』いう持論は変わりません。
頂いたコメントのなかに、評価は「獲得した領土の再配分」であり、経営は「どうやってどの領土をぶんどる」かであるとありました。
「ぶんどる」行為には疑問があります。「領土の安堵」と解釈すれば納得できます。
第一線の技術者であり且つ経営者であり得る人は小数でしょう。ともに中途半端になるよりかは、どちらかに秀でたほうが良いと考えます。

経営=「領地の分取り」と定義するのも画一的見方だと思うのです。世にある法人は種々の形態があります。ルーチンワーク化していて、なんら意志決定が不要な安穏とした法人もあります。
しかし、働きがいとか充実感などは無いかもしれません。それはトレードオフなもので仕方の無いことでしょう。充実感より安定を望む人もいます。
未来が暗い法人や存在意義がなくなった法人もあります。それでも無理やり仕事を作って必要性をアピールして延命を図ってる特殊法人はマスコミの餌食です。
法人の在りようが違うと、経営者に求められる技量や資質は全く違う能力を要求されます。

IT会社も種々様々です。制御系開発社、科学技術計算開発社、業務アプリ開発社といった分野別に分類できる一方で、資本関係の分類もされます。大手企業傘下のIT会社、と独立系IT会社では全く異なります。
大手企業傘下の場合、親方日の丸で、口を開けて待っていると、親会社が仕事をくれるというメリットや赤字になっても泣きつける安定があります。反面、温い体質になり、不満を感じる職人も少なからず存在します。
独立系では、後ろ盾がないので、緊張感があります。これが活力になっています。
資本関係の強い法人では、親会社の出向扱いであったり、同じ組合に入らされたりします。そのうえ、給与等の待遇は親会社を超えてはならないという、暗黙の規定があったりして、IT会社とは思えない待遇だったりします。経営者といえども従わざるを得ません。
資本関係のある法人の経営者は、権限が恐ろしく制限されていて、人事権すら無いケースがあります。都度、親会社にお伺いを立てているのを見ると、哀れ感も沸きます。
 「経営者=支配者」という見方は単純すぎて、実態とは乖離してます。経営者をスケープゴートにしても、構造的矛盾はなくなりません。
会社のビジョンを示せない経営者はダメだとは思うのですが、平凡な雇われ経営者にそれを求めるのは酷な場合も多いです。

Sier業者も要件定義力と作業員の管理能力は長けているのに、自社の開発力が無かったりするのはご承知の通りです。

会社の性質に見合う、経営をすれば、従業員の糊口はしのげます。経営者は、預かった会社の安定と成長を第一の仕事とするのは義務だと思うのです。(成長不要や成長放棄も含む)

自分のやりたいこと成すために起業したり、技で勝負する会社では、技術系経営者は有利です。専門分野なので意志決定も瞬間でしょう。
「作物を知らない八百屋は駄目だ」というのは一理ありますが、無知な分野は、その道の専門家を配置して、委譲するのも方策でしょう。
「鋸を使った事のない設計者」とは違う問題だと思うのです。こちらは、製造者の内輪の話であって異質と考えます。
ただし、委譲しておきながら、無知な分野に口出しすると、ワヤになります。

「その専門家を識別するには、専門知識が必要なのでは」とも言われます。機能を見極めるには専門知識が必須ですが、要件を見極めるには不要です。逆に専門知識が害になることもあります(些細なことに囚われてしまう)。
前述しましたが、経営は、発展しなくっても現状維持でも従業員の糊口の確保を大事にするのは避けられない面があります。一度雇うと、無能だけではクビにできない事情もあります。(このあたりは組合に文句があるのですが)
経営者が儲のために、社員を搾取したり、偽装や不正をするニュースは目立ちますが、数は少ない気がします。

現状維持と雇用の確保という責務のために不正に走るケースのほうが多いと感じるのです。 社会的モラルより我が社優先という我儘経営者が目立ちます。
中高年の分別ある大人がそういった行為をするということは哀れです。「近頃の若者は」という資格すらありません。

開発プロジェクトでも、実工数と請負金額の乖離や、受注後の要件変更を引き受けてしまう問題は、経営者の仕事というより、PJの仕事の範疇です。赤字ても経営的にメリットがあると踏めば、GOサインを出すこともあるでしょう。
当然、短期的には、赤字でも、将来は黒に結びつくと判断してのことですから。評価はそれを踏まえてすれば、労使とも納得するでしょう。そのはずなのに短期的赤字面だけで評価したりするからおかしな事になって、不満が溜まることになってしいます。
この場合は、PJと経営者は、理解し合って一枚板にならないと、現場は混乱します。

少数精鋭の開発者ばかりの会社は例外的で、2割の優秀技術者 3割の普通の技術者、3割の指示待ち技術者,2割のダメ技術者という社員構成の法人が多いと聞いたことがあります。このような法人の場合。
日銭が入る派遣業を行ったり、開発要員を外部に求めて、チーム編成するのを非難するのは簡単ですが、それを行わなかったら、明日の飯に困るケースもあるでしょう。

商品を知らないと評価できないのか
 自分の扱っている商品知識はある程度必要ですが、深い知識や技術背景の理解は必要でしょうか。
 私は、エンジンの仕組みは 2cycle/4cycle/ロータリーの区別しかできません。EGIエンジンやハイブリッドになると理解できてません。ベルト・トルコンも今一解ってません。
しかし快適に運転はできます。使い易いか、使いにくいか、居住性の善し悪しは分かります。
  製品を知るとデメリットを生むこともあります。以前書いた、SeedsとNeedsの問題で、作り手のお薦め品が顧客の求めているものとは一致しません。
 顧客ニーズを感じる力は、技術力とは違う能力です。

 私には、吉兆の料理より吉牛のほうが美味しいです。銀座や新地のクラブより、居酒屋で飲む酒のほうが美味しいのです。(接客員に気を使ってしまうので逆に疲れます。)
 商売上で必要になる商品知識は、性能知識ではなく、もたらすメリット知識でしょう。

新技術だけでは仕事が来ない面があります。
 OOPやWebアプリ全盛ですが、既存のシステムの改善や、改変の場合は、旧版での開発になります。
 新規案件であっても、手慣れた、旧版で確実な開発スタイルを選択することもあります。
  自社開発用にフレームワークを作っている会社も多いですが、1~2世代古いケースも多いです。確立して枯れるまで数年以上要するのは不可避です。

このように、会社によって様々な背景があるので、一様に従業員や経営者、会社を計る尺度はありません。
就職した法人が自分の尺度に会わなければ、どんどん移るべきでしょう。革命を起こすのも方策ですが、同士を集めて一揆を起こすエネルギーで起業できます。
従業員も会社に不満を抱きながらも、現状維持を選ぶという選択肢もあります。革命を起こすことは、その人に多大な影響を与えることになります。

最初にどこに就職する、就職時期は何時か、旬の技術は何か、自分のやりたいことは何か、これらが一致するか、齟齬を来すかは運であり、相性でもあります。
「運も実力の内」とは言いますが、個人ではどうしようもない宿命もあります。
不思議なもので、これをやりたいと努力すれば道は開けます。私はそこに大いなる力の存在を感じるのです。精神論とは違う感じのものですが、この辺は、いずれまた。

投稿日時 : 2008年7月10日 1:19

Feedback

# re: 経営者の仕事 ~長文御免 2008/07/10 22:24 Pasie.

一問一答をすると長くなるので、個人的に感じることをまとめておきます。

経営とは…を説明するのは面倒なので以下を参照してください(ぉひ ^_^;
>http://www.smbc-consulting.co.jp/company/solution/training/training_960.html
ここでは三要素と言われていますが、重要なのは「お客様から見て価値ある特徴を作ること」だと思うのですね。これを実現するために、残りの2つ(と自己の利益?)が必要になってくる、のだと私は理解しています。
なので経営者とは「お客様から見て価値ある特徴を作ること」のできる人物だと思うわけです。私はここには自社の売り物を構成する技術を全く知らない人は座れないと思っています。故に経営者=技術者だと思う所以です。
# 最初書いたら長くなったんではしょっちゃいました。意味不明だったらごめんなさい(汗

あと、領土の件とか誤解がありそうですがそれはまあよいとしても、ルーチンワーク=充実感が無い、はちょっと暴論だと思います。ルーチンワークをしてくれるひとが舞台を支えてくれているから役者は舞台で踊ることが出来る。逆にみれば、舞台で安心して踊ってもらえるための仕事をしているのだから充実感がもてない理由はないのです。充実感がもてないのだとしたら、それはルーチンワークそのものが原因なのではなくて、別の理由が原因だと思います。

# re: 経営者の仕事 ~長文御免 2008/07/11 0:59 Ognac

コメントありがとうございます。
ご指摘、感謝します。軽はずみで不適切な表現でした。ルーチンワークを別扱いにしたつもりではないのです。ルーチンワーク=>充実感がない。 と取れる表現でした。訂正します。
ルーチンワークは慣れてくると慢性的になり、気が緩みがちでその結果、充実感が薄れそうに感じるのです。知恵を働かせて、労働改善の余地はありそうなのに、惰性で働いている人を珠に見かけます。
>別の理由が原因だと思います
こちらの問題は偽装につながりそうな問題ですよね。奥が深い。
 示して頂いたURL は参考になります。私の見方も偏っていたと思います。

>自社の売り物を構成する技術を全く知らない人は座れないと思っています

うーん。そうなのですが、使い方の技術と商品技術の差で言えば、使い方の技術でカバーできると思うのですが。どうでしょうか。

# re: 経営者の仕事 ~長文御免 2008/07/11 23:32 Pasie.

使い方の技術とは?
商品の使い方?それとも従業員の使い方?

いずれにしても価値の創造がない、というかなんというか、企業としての付加価値は生みそうにないのでだめかなあという気がしてしまいます。

# re: 経営者の仕事 ~長文御免 2008/07/12 0:19 Ognac

>従業員の使い方?
面白い見方ですね。考えたことなかったです。
>価値の創造がない
もちろん価値のない行為はそうですね。
付加価値で利益を生むという事は、使い方に価値があるともいえるのかなぁ。再び頭がLoopしてきました。

# re: 経営者の仕事 ~長文御免 2008/07/13 0:37 Pasie.

使い方、の具体例って提示できますか?

# re: 経営者の仕事 ~長文御免 2008/07/13 2:35 Ognac

>使い方、の具体例って提示できますか?
改めて考えると、戸惑うものですね。主張していることが、言えないと看板に偽りあり???

・RDB
Oracleでは以前からあって、ようやくSQL_Serverで実用になった、パーティション分割。
(売上データを期間別に別FileのDataBaseに格納しているが、SQL文としては一つの文でアクセスできる仕組み。)
これは、実装技術で論ずれば、Partition構築で、Table設計し、実行プランと睨めっこして、最適なTable設計して提供します。しかし、実装技術は裏方であって、ユーザーから見れば、一つのTableに見えれば、業務的にはOKですよね。
 開発者視点では、Partition分割の方法やDB設計を論じたくなるのですが、マネージャや経営者/プレゼンレベルでは、一つのtableとして、業務機能が満足できるか否かを判定できれば、十分だとや思うのです。

・一般的な.net.業務アプリケーション
.netアプリケーションは CLIに則って開発されます。製品性能としては、CLIに則っているか否かが問題になります。
開発言語が VBであるか、C#や他であるか、業務アプリとしては、無関係です。開発レベルでは言語の選択は大きな問題ですが、使う側の価値は、財務会計だけの範囲なのか、管理会計まで応用が可能なのかが重要になります。
経営者としては、必要な資料が即座に出てくるシステムが良いシステムです。
同じ結果の日計表が、1分で出る(汚いソースの)システムと1時間で出る(綺麗なソースの)システムを比較した場合、経営者と開発者では、評価基準が異なります。

 どこかのBBSで話題になっていたのですが、八百屋さんは、商品の作り方を知るべきか。という問題に通じると私は思います。
トマトやキュウリがどの畑でなんの肥料で水をどのように与えて作るのかは、農業者の範囲の知識です。
八百屋さんの必要な知識は、無害の野菜や、味の識別知識です。場合によっては、調理の知識がいるかも知れません。
顧客の知識は、味と価格の相対的な関係の知識と、調理知識です。
 このように、立場によって、必要な知識の種類が違うと考えます。

正確な知識を活用できず、ブランドというか肩書きにしか目が向かないので、昨今の食品偽装が多発するのだとみてます。
これは、いつか書こうと思うのですが、過激になりそうなので、考慮中です。何れ又。

# re: 経営者の仕事 ~長文御免 2008/07/13 14:09 Pasie.

パッケージ開発と業務システム開発、それと八百屋はそれぞれ基本となるビジネスモデルからして違うので同列に論ずることはできないと思いますが、簡単にまとめてみ…ようと思ったのですが、長文になったのでやめました -_-;

要は昨日の市場と今日の市場は違う。つまり、利益を確保するためにはWindowsやOracleがバージョンアップしていかなくてはならなかったってことだと思うのですね。それではバージョンアップすれば利益は確保できるのか?という問いにちゃんと意見を持つ人が経営者だと思うわけです。みたいなことを書きたかったのですが断念 >_<;

>八百屋さんは、商品の作り方を知るべきか
少なくともこれはIT業界にあっても当たらない。
例えばOracleや.netの(利用する上で必要な)構造や機能を知る必要が、それを買う側(開発者)にもあるかも知れませんが、それがMS社内でどのように作られたのかまでは知りうる必要がないように。

反面経営者としてはどうか?無農薬有機野菜を作るとして考えると?経営者が実現可能な道筋をちゃんと作れないと、手数とコストばかりかかって付加価値をつけて売れなかったり、それ以前に作物が出来るかどうかも疑わしいかったりしそうですよね。なので製造業における経営は製造のための技術力とは無縁でないと思うわけです。

# re: 経営者の仕事 ~長文御免 2008/07/14 1:06 Ognac

>長文になったのでやめました -_-;
読みたいです。良ければ投稿してください。

>バージョンアップすれば利益は確保できるのか
>に作物が出来るかどうかも疑わしいかったりしそうですよね
うん? 同じ主張のように思います。

>製造業における経営は製造のための技術力とは無縁でないと思うわけです
ここも同意するのです。

経営者が自社の商品を知り尽くす事に異論はないのですが、小規模で事業の種類が限られている会社なら可能でしょうが、
規模が大きくなれば、知り尽くすのば無理になると思うのです。業務アプリからインフラや情報系まで、知って且つ、労務管理や客先提案までこなすのはスーパーマン性を要求していると感じるのです。
それゆえに、経営者は、裏付けのある、利用技術の提案力と評価力があると考えています。

# re: 経営者の仕事 ~長文御免 2008/07/14 23:24 Pasie.

>読みたいです。良ければ投稿してください。
すみません。消してしまいました。TextBox直入力だったもんで…

>知り尽くすのば無理になると思うのです
意図がうまく伝わってないのはここなんでしょうね。
規模にもよりますが、ぶっちゃけた話経営者が作れる必要はないのは同意です。コードに一語に至るまで理解している必要はないわけです。たとえばジョブズにしたところでiPodは作れないと思うわけですよ。(実際はどうか知りませんが)

ただ、自分の会社の強みを知り進む方向性を決め、そして実際に進めていくのは経営者の仕事だと思うわけですね。これが出来る人ってどんな人?って事だと思うわけです。

仮に、今の社長が「有機野菜は儲かる。おまえら来期からは今の仕事にケリつけて有機農場をやるぞ。ついてこい!」って言われたらついて行けるのかと。
もうちょっと現実味を帯びた例だと「我々は業界No1の受託システム開発会社になる!皆そのために努力して欲しい」とか言われたら頑張れるのかと。
その頑張れる。イケる。やってやる。やってみようじゃないか。ってまずは思わせることができるのが経営者だと思うわけですが、そのやる気にさせる相手(社員)は特定の分野の技術者なわけで、そういう人たちを<s>効率よく踊らせて</s>奮い立たせることの出来る人ってだれだ?ってことだと思うのです。

# re: 経営者の仕事 ~長文御免 2008/07/15 0:30 Ognac

>意図がうまく伝わってないのはここなんでしょうね。
意図の伝達は難しいですね。
私の、汲み取り力が乏しかったのも原因です。..orz
論旨は、左程、差がなかったですね。
経営者の視点は、高くあって欲しいものです。

タイトル
名前
Url
コメント