« 2018年9月 | トップページ

2018年10月

2018/10/09

組織文化はトップが作るのか、ボトムアップで作られるのか

僕はアジャイル開発が好きなので、組織文化はメンバーから自然発生的に作られるものと思っていた。
でも、組織論を勉強していたら、そうではないらしい。
今の自分が理解できたこと、考えたことをラフなメモ書き。

【参考】
制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

【1】トップがリーダーシップを発揮しすぎている場合、メンバーや社員は言われるがままの存在で自発的になっていない状況が多い。
トップがリーダーシップを発揮せざるを得ない組織文化になっている。
そういう組織文化を作った責任は誰にあるか?

組織文化を生み出す責任は社長にある。
もっと社長が汗をかけ。

従業員の意識変革は、従業員ではできない。
社長が自ら説明し、共通目標を掲げ、貢献意欲を引き出し、コミュニケーションを円滑化させなければ、組織文化は変わらない。

つまり、組織文化はそう簡単に作れないし、変更もできない。
その会社の歴史から生まれた側面の方が大きい。
いわゆる、経路依存性。

組織文化は、今までの会社の経営の中で、こんないいものがあったではないですか、と社長に気づかせる方が大事。

一方、組織構造は思い切って変更できる。
たとえば、会社の特徴として商品企画が弱いなら、思い切って商品企画の部署を作る。

たとえば、生産工程ごとの機能別組織では、市場の変化に即応できないならば、事業部制組織へ思い切って変更してみる、とか。

つまり、組織文化は社長に優しくアドバイスし、組織構造は思い切って変更して下さい、と社長に諫言する。

この発想は、マッキンゼーの7Sフレームワークがよく当てはまると思う。
組織のハード部分は思い切って変革できるが、組織のソフト面は、浸透に時間がかかる。

【2】企業における人事施策は、会社全体の人事施策として策定してはいけない。
従業員層ごとに人事施策を細かく分けて策定する必要がある。

たとえば、正規社員と非正規社員では、人事施策が全く違う。
正規社員には能力向上や人材育成、非正規社員にはすぐに辞めさせないような仕組みとして、衛生要因の対応やモラール向上、人材の確保の観点になる。

たとえば、女性社員と新人社員では、人事施策が全く違う。
新人社員には人材育成の観点で能力開発、女性社員には人材確保のため、時短制度や出産後の仕事復帰の支援制度など衛生要因への対応が重要になる。

あるいは、管理職とヒラ社員でも違う。
管理職には、社長が考える経営戦略を理解してもらい、自分の持ち場で部下にその内容を伝えて共有してもらう、という制度的リーダーシップを発揮する役割がある。

【追記】
門屋浩文@redmineparty🌅さんのツイート: "製品特性で組織体系が変わるから 例えば鉄道会社がボトムアップで文化が作られるのは個別の部分ではあるかもしれないけどトップダウンが多いでしょう 芸術系ならトップダウンは絶対ないでしょう… "

akipiiさんのツイート: "芸術系でもソフトウェアベンチャー企業でも、社長が、社員個人が自由に能力を発揮できるような環境(ファシリティ)を作っているから、とか、自由にコミュニケーションを取っていいよ、と言う組織文化を許しているからでは? 組織文化は社長が作っている、という気が最近してます。… https://t.co/3qSXWFqhMO"

門屋浩文@redmineparty🌅さんのツイート: "なるほど、そうかもしれない 理解があるから環境、文化を作るような… "

akipiiさんのツイート: "川端さんの会社や倉貫さんの会社を見てると、社長がソフトウェア企業に合った組織文化を知っていて、あえてそういう組織文化を作り出してる気がしました。それを知らない社長はたぶんソフトウェア開発に向いた組織文化も組織形態も理解できてないのかなと… "

やっさん🍶さんのツイート: "私もそう思います。ボトムアップな組織は、トップが権限を移譲させてボトムでも意思決定出来るように、ボトムを信頼出来る文化がもともとあるような、初期の段階からトップが文化を形成してそれを「貫き通した結果」だと思います。 また、ボトム→トップへの移行は簡単に出来るけど、(続く)… https://t.co/xzGUYkgqum"

やっさん🍶さんのツイート: "トップ→ボトムへの移行は、ボトムからは起こすのはとてつもなく難しいと思います(&痛感してます。多分無理。) ボトム→トップを気づかせるのは、もともとボトムが出来てる文化じゃないと実行までは行かないかなぁと思います。自分の持ってる既得権益を手放せなんてトップ思考では出来るのかなと。… https://t.co/21O1quS1Xp"

| | コメント (0)

第66回IT勉強宴会の感想~データモデリングに数多くの流派が発生している理由

先週土曜に、関西IT勉強会に行ってきた。
渡辺さんの話を聞きながら、日本で、なぜ、データモデリングに数多くの流派が発生しているのか、そんな理由が垣間見えた気がした。
以下は、とりとめもないラフなメモ書き。

【参考】
予算テーブルと実績テーブルを分ける?: 設計者の発言

方法論科学研究会(情報システム学会) <第66回IT勉強宴会in新大阪> | IT勉強宴会blog

【1】渡辺さんのデータモデリングの最大の特徴は、ER図に描かれるデータモデルは、関数従属性だけの観点で書き切ること。
つまり、あるべき業務イメージやあるべき業務フロー、あるべき組織構造とは全く無関係である点。
また、現状の業務フロー、現状の組織構造の観点も入れない。
あくまでも、関数従属性だけの観点でモデリングする。

こういう基本に忠実なデータモデリング手法は、実は普通ではない、という事実が、パネルディスカッションで明らかになったのが面白かった。

どうやら、熟練のデータモデラーも含めて、一般人も、関数従属性だけに従ったデータモデルを更に細かく分割するのが普通らしい。

例えば、小関さんのモデリング手法では、最初にAsIsの業務フローをヒヤリングしながら、頭の中ではデータモデルの項目群を関数従属性の束でまとめながら、ER図をイメージしていく。
そして、ToBeの業務フローを描く時に、データモデルを具体化して確定させる。

たぶん、普通のモデラーならば、小関さんと同じように、AsIsとToBeの業務フローを描きながら、ToBeのデータモデルを描くという同時並行スタイルが普通だろうと思う。

でも、渡辺さんのデータモデリング手法である三要素分析法では、業務フローのヒアリングはしない。
データモデルを描くためのヒヤリングに限定し、業務の問題点や課題、ToBeの業務イメージは聞かず、あくまでも関数従属性の情報だけを集めることに注力する。

【2】では、なぜ、渡辺さんは、そういう手法にこだわるのか?

なぜなら、データモデルをその場で聞きながらモデリングするためには、関数従属性の観点だけに絞った方がやりやすいから。
そこに、ToBeの業務イメージやAsIsの業務フローの話が混じると、モデルを描くという目的とズレた議論になってしまいがち。

聴衆の方からも、渡辺さんのライブモデリングを側から見ていると、切れ味が鋭くて気持ちいいくらい。
なぜなら、ユーザは自分が抱えている課題や問題点を他人に話したい習性があるので、モデラーにそれらをぶつけたい気持ちがあるが、それを表に出すと、渡辺さんはそれは議論の範囲外です、とバッサリ切ってしまう、と。
面白い。

また、そういうライブモデリングにこだわるもう一つの理由は、データモデルさえ確定すれば即座に画面UIが決まり、プロトタイプのシステムが作れるから。
そうすれば、ユーザにプロトタイプを見せて、早くフィードバックがもらえて、より明確なシステム像が見えてくるから。

【3】では、渡辺さんのデータモデリング手法では、あるべき業務やあるべき組織構造はモデルに表現できないのか?

実は、渡辺さんのデータモデリングである三要素分析法では、データモデルは関数従属性の束の観点に絞るが、業務を担当する組織構造や業務フローの要件は、機能や業務という別の側面で捉えて分析する仕組みになっている。
たとえば、三要素分析法では、「業務」「データ」「機能」の3次元の絵で説明される時が多いが、それらの次元の軸がそれに相当する。

つまり、業務システムは3次元の軸で実現されるものであり、データ軸はあくまでも関数従属性の束だけでよく、それ以外の要件はそれぞれの次元の軸で捉えれば良い。

この分析手法のメリットは、データモデルの構造とデータモデリング手法そのものがシンプルになること。
つまり、渡辺さんがこだわる「ライブモデリング」に大変適しているし、モデリング手法も関数従属性の束だけ考えれば良いので、業務知識を知らなくても描けるメリットがある。

一方、パネルディスカッションの議論を聞いてみると、TM手法(T字型ER)やTH手法では、データモデルにあるべき業務イメージや業務フローの要件も組み込んでいる。
おそらく、一般のデータモデラー、普通の設計屋もそういう手法を取るだろう。

しかし、そういうデータモデリングは多分、初級者や中級者には難しい。
あるべき業務イメージや業務フローを描くには、その業界の業務知識、あるいは簿記1級レベルの会計知識が必要にならざるを得ない。
また、そういう業務知識とデータモデリングの整合性を取るのは、相当難しいのだろうと思う。

【4】渡辺さんのデータモデリングを見ると、システム設計を多少でも知っている人ならば、違和感を感じる所がある。

たとえば、直近のメーリングリストでは、予算実績テーブルという、予算と実績の2つのデータが1つのテーブルにまとめてもよいのか、分けた方が良いのか、という議論があった。

渡辺さんのモデリング手法では、関数従属性の束の観点だけなので、ユーザのヒヤリングでそういう要件だけならば、予算と実績のテーブルに別々に分ける必要はない。
だから、他のデータモデラーから見ると、すごくFatなテーブル、太ったテーブルのように見えて、とても違和感がある。

予算テーブルと実績テーブルに分けるべきではないか、と。
疎結合の設計思想、クラウドとの親和性、データ管理のライフサイクルの観点では、予算実績テーブルで一つにまとめるのはおかしいのでは、と。

しかし、関数従属性の束だけの観点だけのデータモデリング手法の立場であれば、関数従属性がないのに、テーブルを別々に分ける方がおかしい。

渡辺さんが描くデータモデルでは、太陽系みたいに、トランザクション系のFatなテーブルが中心にあって、その周囲に関連するマスタ・イベントのテーブルが配置されるシーンをよく見かける。

たとえば、佐野さんもブログに書かれているように、商品マスタに在庫数という導出属性が混じっていて、すごく違和感を感じた、というのと同じ。
普通は、商品マスタから在庫数は外し、サマリ系テーブルに在庫数を入れて、定期的なバッチ処理で集計するのが普通だろう。

しかし、渡辺さんの商品マスタのモデルでは、倉庫がない中小企業の事例なので、そういうモデルになった。
今後、倉庫を新たに持つのであれば、在庫数を持つ倉庫テーブルが出てくるのでしょう、と。

でも、そういう考え方を知って、渡辺さんが描いてきた過去のデータモデルを振り返ると、なぜ、すごくFatなテーブルが多いのか理解できた。
そして改めて、そういう技法にあえてこだわる理由も理解できた。

【5】そのパネルディスカッションの中で、@sakaba37さんから、こんな質問があった。

我々システム屋は、分割統治の手法が身に染み付いているので、何でも細かく分割して最終的に組み合わせるという設計手法に慣れている。
だから、渡辺さんのデータモデリング手法では、分割統治されていないように見えるので、違和感を感じるのではないか、と。

また、そうは言っても、渡辺さんの頭の中には、過去の経験を踏まえて、業務パターンのような暗黙知があるので、ライブモデリングのように素早くモデリングできるのではないか。
その業務パターンを形式知化できるといいですね、と。

その話を聞いて、確かに、モデリングでも分割統治して、モデルの対象となる粒度は細かい方が良いのだ、という先入観が強すぎるのかもしれない、と感じた。

【6】他に、パネルディスカッションでは、関数従属性の束でまとめたとしても、それら項目の中で特別な属性で、何かしら強いイメージを持つような「強属性」のものはありますか、という質問があった。

意図としては、項目の関数従属性でテーブルとして洗い出した時、主キー以外にも、特別な役割を持つ項目があるのではないか、ということ。

渡辺さんの回答では、ありますね、と。
たとえば、この属性は主キーではないが、参照は可能だが更新は不可である、という特徴を持たせたい時があります、と。
たとえば、サロゲートキーが主キーであっても、複合キーを主キーとして同格に持たせたい時に使いたい場面が考えられる。
渡辺さんが作ったX-TEA Modelerには、そういう機能をあえて作っている。

データモデリングしてますか? - TECH BLOG | 株式会社テラスカイ

Salesforceのデータモデリング手法の記事のリンク: プログラマの思索

【7】そんな話を聞きながら、日本でデータモデリングに数多くの流派が発生している理由は、渡辺さんのようなシンプルなデータモデルに、あるべき業務イメージや業務フロー、組織構造などを入れ込む手法の方が多いから、その入れ込む観点や手法で数多くの流派が生まれているのだろう、と思った。

初心者の僕から見れば、データモデラーとは、渡辺さんのように関数従属性の束だけに着目してデータモデルを描くのが普通の人なのだ、と思った。
けれど、実際はそうではなく、色んな考え方を持つ人が多い、ということは分かった。
あるべき業務、あるべき組織構造を考えるには、それなりの業務経験や業務知識が必要で、データモデリングそのもの以外の内容も含まれるだろうから。
そこにコンサルティング会社としての価値もあるのだろう。

だからこそ、たぶん、データモデリングの初心者がモデリングを習得するには、渡辺さんのようなシンプルな技法に特化した方が良いのだろうと思う。
業務知識を知らなくても、関数従属性だけにこだわって、データモデルを描くことに注力すればいいから。

そんな話が聞けて面白かった。

| | コメント (0)

« 2018年9月 | トップページ