Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

未だになかなか解決しないこの問題を再検討してみます。

色々と書き出してみると、殆ど経営的な内容になってくる。
また、Twitterで観測できる末端の愚痴などもココの要素で説明できる。

慣例

信用・信頼の問題

信頼関係の構築

SIerは基盤に対するリスク感度が高く、基盤の信頼性が重視される。

  • 「F2Fの信頼関係が構築できれば浸透する。」ことは解っている。
  • 「F2Fの信頼関係を構築する機会をどうやって増やすか?」が課題。
  • これは、コストのかからないインターネット展開ではなかなか実現できない。

※ 基盤の信頼性と言っても、実際は、人の信頼性が重視される。

安心社会と信頼社会

  • 日本式の安心社会では、
    相互監視・相互規制などで、信頼ではなく信用の構築するが、これには多大な、
    「機会費用」を必要とするため変化の早い時代にそぐわなくなってきている。
  • 一方で、大陸型の信頼社会は、
    多様な人種、文化、価値観から構成される集団で、
    迅速にプロジェクトを立上・実行するため伝統的に養われてきた。

保守的、変化を嫌う風潮

フォーブスにも、以下の様な記事があるので、
日本人だけが保守的という話ではなさそうだが、

以下の観点では、より、変化を嫌う節がある(保守的である)と言えそう。

長寿企業

  • 平和が長く続いた。
  • 異民族による全面的な侵攻と殺戮がなかった。
  • 永続性そのものを尊ぶという考えがある。
    • 利益の短期的増大よりも長く存続することに価値を置いている。
    • 企業活動が投機を自制している(大手財閥の家訓など)。

安心社会

上記の安心社会から、信頼社会へのシフトに時間がかかっていることから、
安心社会スキームからの脱却が難しく、変化が起こりにくくなっていると言える。

終身雇用

終身雇用は、上記の

  • 長寿企業が多い
  • 安心社会的スキーム

の結果だと思われるが、昨今、崩壊と言う事で、
曲がり角に差し掛かって来ていると言う事だと思う。

日式的儒教観

技術に疎い経営層

社長がITネイティブか、CEOを置くかしないと経営はITに詳しくならない。

基本は経営は専門職

  • 日式経営層、技術に弱い問題がある気がする。
  • なんとなく、

    日式では多くの事業が過当競争でスケールしないので、
    スケールする技術より労働集約的マネジメントを重視した結果、
    自然とそうなった。みたいな分析ができるんじゃないか?

なんて考えたりした。

  • 下記の参考のような情報もあるので、
    経営はITに詳しくないのが当たり前っぽい。

エンジニアと経営のクロスオーバー

  • 連載|gihyo.jp … 技術評論社
    https://gihyo.jp/lifestyle/serial/01/engineer-x-manage

    エンジニア出身で社長になるのは,相対的にあまり得策ではない。

    • 一般的には「社長が専門職」という認識があまりないのではないかと思いますが,
      たとえば欧米だとCEOとして各社を渡り歩くというのはめずらしくありません。
      日本でも「プロ経営者」という言われ方をすることがありますが,
      これはだいたいネガティブなケースで使われることが多い気がします。
    • エンジニア出身・非エンジニア出身
      • エンジニア出身社長
        エンジニアリングについては精通,
        それ以外については各分野ハードルが高い
      • 非エンジニア出身社長
        エンジニアリングに精通するのはかなり難しいが,
        それ以外についてはエンジニア出身より優位といえる

垂直統合型事業

オープンアーキテクチャ型に比べて変化に弱く、保守的と言える。

フロントでマネタイズしないと予算獲得が困難

  • 某弊界隈で「工場文化」と言われてるモノの影響と思われるが、

    工場リソースの有効活用 = 受注の強化で、潜在的な課題の解決は、
    品質マネジメントのQCサークルの範囲内で行われてきた慣例もあり、

潜在的な課題を解決するための予算が付き難いという側面はあるかなと。

  • 要するに、プロフィットの明確な製造活動に紐付いていないと予算が認可されない。
    ...と言う事だが、昨今の、経営戦略 → ポートフォリオ・プログラム → プロジェクトと
    言う流れを考えると、時代錯誤も甚だしい感ある。

ポートフォリオ・プログラム・マネジメントの欠如

自社事業に必要となる各種プロジェクトをポートフォリオ・プログラムとしてマネジメント出来ていない。

  • 前述の「受注の強化」となると、組織的には、ラインナップを揃えるという方向性で動く(単独の事業)。
  • しかし、特に、ポートフォリオ・プログラム化しないと結果が出し難い、全社系のモノが上手く行かない。
  • ポートフォリオ・プログラム系が苦手だと、全社系のプロジェクト選定もできないし、ステークホルダーも立たない。
  • このマネジメントの欠如により、ステークホルダー・エンゲージメント・マネジメントは難しくなる。
  • ポートフォリオ・プログラムを理解するプロジェクト選定委員会を持っていない
    • 役職付きに相談しても、ほぼ例外なく、個人的な感想でリターンされる。
    • 機能部門も自分のドメインを超えたモノとドウ連動するか?については、殆ど知識を持っている感じはしない。

対立

対立によってスタックしない問題が発生する。

サプライサイド・デマンドサイド対立

以下、「サプライサイド・デマンドサイド対立」を中心に分析をしてみた。

対立の概要

  • デマンドサイドは、良いモノを安く調達したい
    (出来るだけサプライサイドを買い叩きたい)。
  • サプライサイドは、自助努力による生産性向上をしたくない
    (出来れば、楽してデマンドサイドに高く売りつけたい)。

デマンドサイド都合

  • SIの技術面のプロセス資産が無いので良し悪しの判断基準を持たない。
  • このため、どのような開発基盤を採用すべきか?の判断ができない。
    (この情報の非対称性から、良いモノを安く調達できない。)

サプライサイド都合

  • サプライサイドがプロジェクト型ではない定常業務型のため。
    プロジェクト型にならないと、大きな組織では、なかなか横串が通らない。
  • 生産性向上プロジェクトとしないと、なかなか浸透しない。
    (自助努力したくない -> 生産性向上しない -> 働けど働けど我が暮ラクにならず)

フロントオフィス・バックオフィス対立

経営と事業

  • 大手のサラリーマン社長は、
    • 経営と事業を区別していない可能性。
    • 出身部署以外の事をあまり知らない。
  • この場合、全体最適化やトランスフォーメーションは苦手になる。
    • 数を絞って、マーケティング、設計、調達、生産、物流、販売を一体でやる事業と、
      商材やアカウントSEが多すぎる事業を比べると、後者は労働集約的と言えるかも知れない。

利益の追求

  • フロントオフィスは、売上、収益を問われるが、
    その他の部分(コンプライアンス、CSR、ES/CS)が手抜きになる。
  • バックオフィスが不要に見える。
    • 経営層からはそう見えていないが、事業部門からはそう見えている。
    • 日本型雇用では、シュリンクした事業の荷物置き場と化す事もありそう。

KPIに問題がある。

バックオフィス系のKPIは明確でなく、且つ、フォローが緩い事が多い。

  • 仕事は、できるだけ楽な方がイイと判断される。
    • KPIが無いか、KIGとの関係が明確でない。
    • ベネフィットという考え方が無いか、
      プロフィットとの関係が明確で無い。
    • 従って、定常業務が多く、プロジェクトが少ない。
      (評価されない定常業務 → 楽して早く帰るダケがインセンティブ)
  • 難易度の高い、ミッションに沿った価値創造のマネジメントより、
    難易度の低い、役割分担上の機能部門の管理業務を重視するようになる。

手段の目的化

  • バックオフィスは、
    • 機能部門の機能(ミッション)の設定と、
    • それに伴う専門性を問われるが、

その「ミッションと専門性」(手段)が目的化してしまう。

  • 単一の機能(ミッション)では
    • 目的達成の戦略を体系的に考えるには、狭すぎる。
    • 他の機能部門と戦略面で連動していないことが多い。

「利他的な人」は嫌われる

バックオフィス系の仕事はKPIが売上ではないので、
コンプライアンス、CSR、利他的行動、に終始するが、
フロントオフィスから見ると、これは煙たくもある。

(例えば、X個人が体制の協力を得ずに、
生産性を5%改善させた。となると、これは煙たい)

※ 参考:「利他的な人」は嫌われる:実験結果|WIRED.jp

内部抗争・セクショナリズムなどの対立

組織構造がプロジェクト型ではなく機能型。

機能型組織ではプロジェクト運営に関してPMの権限が低い。

デマンドサイド内

...。

サプライサイド内

  • フロントオフィス内
    部門間で売上競争をしている状態がセクショナリズムを産み、
    セクショナリズムによって、信頼が横展開(浸透)されなくなる。
  • 伝統的な垂直統合型メーカ、「XXX部ばかり儲かるから」等々で、
    商材を絞れない感がある(なんて、新しいSaaS商材を見ながら考えた)。
  • 自称パッケージのSIテンプレートって、
    営業 / 受注 / 囲いツールになってて、逆に生産性が下がってないか?

※ 全社施策は、フロントが受入可能な最大公約数なモノでしか打てないので、
  フロントの種類が増えると、船頭多くして船山に登る的に難しくなっていく。

  • バックオフィス内
    内部抗争・セクショナリズムにより、施策自体がリソース面での競合を起こす。
  • マーケットがフロントオフィスの営業範囲に限られるので、
    バックオフィス内で施策選択時に縄張り争いが発生する。
  • 売上から開放され本質的な価値に注力できる筈が、価値が追求されない。
  • 施策やプロダクトの良し悪しに関係なく縄張りの広いほうがKPI的に勝つ。
  • その他、KPI数値の出易い(アピールし易い)施策が選択される。

※ バックオフィスの施策は、本質的な価値(企画品質レベル)がなかなか上がらない。

その他

SNSなどの反響を用いた分析

課題と解決には、ほぼ関係が無く、反響は結果のごく一部。
そう言うこともあり、ビジネス・インパクトはあまり無い気がする。

人間の悩みは、すべて対人関係の悩みである

目的があって、手段があって、その結果のごく一部に「承認的な何か。」がある。

  • 目的の達成を最重要視すベキ。
  • SNSの反響などは、手段や結果に対するモノなので、無視して良いレベル感。
  • 目的・手段の周辺にエコシステム(自己受容・他者信頼・他者貢献)を構築する。

※ 参考:「嫌われる勇気―――自己啓発の源流「アドラー」の教え」の要約

誹謗中傷記事には大きなニーズがある

ニュースリリースの際にtweetを & 分析して思ったことは、
肯定的なtweetが8割で、否定的なtweetは少数派だったが、
数年後、再エゴサしてヒットするのは、否定的なtweetが大多数で、
肯定的情報より、否定的情報の方が情報のニーズが高いコトが解る。

  • 参考

余談だけど、2015/06/08から放置されているこのブログ、超迷惑。
(「また元気が出たら試したい。」とか書いてあるケド、その後をフォローしないなら最初から書くなよ)。

SES, 派遣, 個人事業主の特徴

  • 武器商人は兵器を開発するが、傭兵は兵器を開発しない。
  • 個人のスキル向上に注力し、組織の生産性向上に寄与しない。
  • 開発基盤の開発と展開は組織的な取り組みになるので、個人との相性は悪い。
    (組織間を動く個人にとって、組織の施策に対する機会は少ないため)
  • と言う言葉を造ったりしましたが、
    SES, 派遣, 個人事業主が尊ぶのは前者になる。
  • また、Dry系の話もこれに近い話になる。

総括

翌々、見てみるとコレって、

上の課題と言えそうです。

参考

開発基盤のプログラム・マネジメント


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-08-07 (水) 09:27:00 (14d)