スクー様からご依頼を頂きまして、先日の下記エントリで作成した資料について、講義をさせて戴くことになりました。
エンジニアのための経営学という資料を公開しました - GoTheDistance
4/15 19:00〜22:00で、３回に分けてお話をさせて頂きます。
あの資料は読み物として仕上げたため、講義となるとかなり行間が空いておりました。それを埋めるためにステップ by ステップでじっくりと話ができたらいいなと思っています。
生放送です。リーチ一発生放送でございます。
どうぞよろしくお願い致します。
著者の羽生章洋さんより献本御礼。
本書の特徴を一言で言うなら、「これ以上に必要なことはないが、足りていないことは何もない」という絶妙なバランス感です。サラッと読める分量にしているのに、各章を良く読み込んでいくと気付かされることが多く、豊かな行間があります。
要件定義というテーマはとても扱いが難しくバランスをとるのが難しいのに、本書は170p弱でまとめあげている。しかも、イラストも結構多い。この分量で大丈夫なのかと勝手に思ったが、最後のほうではDB設計の話も出てくる。データ設計も要件定義の範囲として捉えているのも、実装を重んじる羽生さんらしいアプローチだし、そこまで考えないと要件として不十分だよねっていう。
以下、僕自身の要件定義のアプローチと照らしあわせてながら、重要だと感じたポイントを書いていきます。
11pに書いてあるのですが、皆さんこれちゃんと意識されてます？ これすげー重要な絵ですからね。羽生さんのOK出たので、キャプチャ画像貼ります。
まとめると、こんな感じになります。
| 要望 | システムによって叶えたい思い・未来像 |
|---|---|
| 要求 | 要望を叶えるために必要な能力や成果物 |
| 要件 | 要求を満たすために必要な条件 |
要件定義が出来ているというのは、この「要望⇔要求⇔要件」が分割統治されていることが大切です。つまり、要件に落としこむまでに然るべき理由がそこに存在しているか、その要件でなければならない理由は語られているか、そういうことをチェックするには分割統治するしかないからです。やりたいことと、やらねばならない理由と、要求を満たすためにやらなあかんことが分けて考えられていないと、要求自体の間違いに気が付かないことになります。
最悪なのは、間違った要望に対する正しい要件や仕様です。間違った前提ほど怖いものはありません。
要件定義はそのシステムに関わる「全ての」ステークホルダーの要求を可能な限り実現する必要がありますが、その全体像をこうまとめると簡単だよって絵がありました。これはわかりやすい。
システムを中心とし、ステークホルダーでレベル１を作り、その要望をレベル２として書いているマインドマップ、と言いますか。要求一覧表なんかよりもわかりやすい。そのシステムを使うことで別のステークホルダーの負担が増えたり、何かが犠牲になったりするということが、要件定義の過程で結構あります。大抵それが地雷になりますので、早めに地雷を摘むためにも全てのステークホルダーの要求をキチンと整理しましょう。
全体図だけでは設計に移れませんので、ドリルダウンして実際の作業とシステムの関係を明確にしていく必要があります。羽生さんは「行動シナリオ」の作成を薦めています。業務フローとの厳密な違いは正直良くわからなかったのですが、僕の理解では下記の情報が整理された実際のお仕事の流れをまとめたものです。
- その仕事を行う人(役割)
- その仕事の判断・完了基準
- その仕事の受け渡し先
特に自分の仕事が終わった！と判断できる基準が最も大切。知りたいのは行動を決めるための判断基準。その基準を満たせない場合は例外処理やバリデーション対象になる。要件定義の時点でそこまで見ていく必要があります。また、下記の２つも考慮ポイントです。
- 差し戻される場合はどういう時か
- やり直したい・中止したい場合はどうしているのか
この２つも重要なので考慮して下さい。前者は例外処理やバリデーション、後者はCRUDが発生した場合に仕様として足りていないものがないかを確認できます。バリデーションが通っても次の作業に渡せないってこと、あり得ますからね。キャンセル発生とか。受注取って在庫引き当てたけど訂正入ったんで引当を戻して再度引くとか。
この設計したシナリオを元にユースケースが生まれて要件が見え、要件を満たすための仕様を考えるフェーズに移っていく、と。
僕もこのアプローチに大賛成。まずはUIをスケッチしないと。UIが先、データが次。そのUIからこのデータになるには何の処理が必要だっけってのが、プログラム。それは最後。
UIを作りながら作業に必要なデータを洗い出して構成をまとめ、仕事に必要な情報を定義してまとめていきます。一語多義にご注意を。最終的に、必要なのはレイアウトとアクションと生み出されるデータ。これが定義されていないとシステムの機能が正しいかどうか、ユーザーが判断できない。
| レイアウト | UI部品。タブ、コンボボックス、テキストボックス、ボタン、表など。 |
|---|---|
| アクション | クリック、スワイプ、キーダウンetcのUIのイベント。 |
| データ | その画面で最終的に作られる or 表示されるデータ。 |
どの作業中に何をして欲しいかを明確にして、ユーザーが何を判断してどんな仕事を完了したいかを詰めていくのが良いと思います。これがこう出来ていればあなたのお仕事は完了できますよね〜っていうアプローチ。
UI設計は入力系の画面から。まずは何を入れるかを先に決めないと。マスタメンテじゃなくて、行動シナリオの中で受け渡して流れていく情報を作って保存するための画面のUI設計からはじめて下さい。いきなり帳票設計とかやめてくださいね。インプットが決まらないのに検索項目の話とかしないでね。
UIを決める→データを決める→そのデータを作り出すためのプロセスを決める、という流れで僕はいつも考えています。
読み進めていく内に、僕自身の要件定義のアプローチを再考したことで、書評の半分が「オレはこうやって要件定義を進めている」話になってしまいました。要件定義は困難な作業だってことを改めて思い知らされましたが、楽しい工程です。
要望から最終的にシステムに落とすためにはこれだけのことを考えないといけないってのを最大限コンパクトにまとめてあり、UIもデータも定義していなければエンジニアに実装の依頼が出せないよねって「しっかりと」書いてあるのが誠実で良いと感じました。
エンジニアの方には「この要件定義は出来損ないだ、何も作れねぇよ」と間違った要件定義をガツン！と是正して欲しい。ユーザーの方には、エンジニアがシステムを作るに何が必要なのかを知って欲しい。共通言語がないと善し悪しが伝わらないので。そのために、本書をあたってもらいたいと思います。
皆さんのプログラムが最大の効果を発揮するために、良い要件定義が出来ますように。
小悪魔女子大生のサーバエンジニア日記の著者、aicoさんが「こあくま スタンプ」を作られました。こあくまがOK返したり、Forbidden返したり、SSHしたりしてますｗ かわいいです。
coakuma sticker - LINE Creators' Stickers
僕のお気に入りはこれ。カシャカシャターン！のドヤ顔スタンプ！ エンジニアでなくてもブロガーさんでも原稿書いたあとにでも使えますよー「進捗どうですか」のリプライにお使い下さい。直リンごめんなさい。
2015年3月25日(火)です。空けておいてくださいよー。
たぶん、日本初の野球系IT勉強会です。あくまでIT勉強会なので、プログラミングの話もあります。今年もやってしまいます。佐藤社長の英断に感謝申し上げます。
皆さんも御存知の通り「BPStudy」といえばIT勉強会の元祖であり、今もなお定期的に実施されている歴史のある勉強会です。今回ばかりは、BeProudをBaseBallProudに見立てまして、野球が好きと自負されている皆さんで盛り上がろうじゃないですか。
今回の僕のテーマは「配球」です。キャッチャーがピッチャーに「これを投げろ」と指示をするアレです。配球はですね、OODAを高速で回しているんですよ。なにせ1球ごとにOODA回してますからね。意図次第で、結果は天国にも地獄にもなる。面白くないですか？
僕は出不精でIT系勉強会に行かないので、折角の機会に色んな方とお話したいと思っております。
では、当日お目にかかれることを楽しみにしています！よろしくお願い致します！
![Software Design (ソフトウェア デザイン) 2015年 01月号 [雑誌]](http://ecx.images-amazon.com/images/I/51sv-OIQh%2BL._SL160_.jpg "Software Design (ソフトウェア デザイン) 2015年 01月号 [雑誌]")
Software Design (ソフトウェア デザイン) 2015年 01月号 [雑誌]
先日書いた、永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistanceに端を発した特集記事Part2、ソフトウエア開発の未来というテーマで10ページ寄稿しました。
SI崩壊を乗り切ろうとしている３つの方法と謳っておりますが、立場の違う３人の人間がどうやって今を生きようとしているのかを書いています。
トップバッターは、上述の価値創造契約のマネージャー、木下さん。会社として様々な契約形態を駆使してリスクを極小化しながら堅調にビジネスをしているものの、どういう形態にせよ人月という単位から逃れることが出来ない。労働集約的モデルからの脱却への挑戦の一環で、価値創造契約という新しいスキームに挑戦された一部始終が書かれております。
２番手は、ノーチラス・テクノロジーズの代表である、神林さん。木下さんの流れを受け、「いや、請負型のSIが無くならないから。請負でやるか止めるか、その善し悪しを踏まえてちゃんと考えようよ」という論陣を張って俯瞰的にSIビジネスを解説されています。価値創造契約等も含めた新型のSIについても言及されています。
３番手が、私です。ソフトウェア開発の現場からだいぶ離れた位置にいる私が、ユーザー企業にエンジニアが入る意味やその成果って一体どういうものなのか、開発の現場から離れてもエンジニアとして食っていける場所があるのかどうかとか、そういう話を書いています。ここ３年の集大成といった位置づけの記事です。
ソフトウェアが当たり前になったことで、ソフトウェアを使って仕事をする・会社の業務を変えるということも当たり前になってきていると思うんですが、最も大切な仕様を決定できる人間が圧倒的に足りないように感じます。
簡単に言うと、
「ITで解決したいことがある人 >>>>> 課題解決をITでデザインできる人」
っていう図式です。ITを入手して何かをしたい人は増えても、ITで課題解決を「デザイン」出来る人が全然足りていない。デザインと書いたのは課題解決を行うには実装だけでは不十分なので、要件定義や更に上の事業戦略等にもある程度知見が必要なことがあるので、総合的な視点を踏まえてデザインと書きました。
その根本にあるのは技術の目利きであり、それは最低限のプログラミング経験がないと絶対身に付かない。プログラミングが出来るというスキルをテコにして、色んな所で「越境」していく事例が来年以降は増えたらいいなーと思います。
事の発端はこの記事ですか。
関係者からすれば個人が特定される情報を散りばめておいて匿名で記事を書いてしまう卑屈さに驚きを隠せません。代表からメール来たけど代表いねぇじゃねえか舐めんなよおおおおおってブチ切れて５分で帰るって超絶微妙ですし、ふつー採用担当者がいるもんなんだけど... リクナビのスカウトメールとか見たこと無いのかな？「代表です！よろぴく！面談で僕と握手！応募してね！」を真に受けちゃうのも微妙。
百歩譲って、期待の裏返しから来る些細なすれ違いからブッチーン！って来るのは誰もあるよね、'`,､('∀`) '`,､ って終わる話なのにって思ってたら、これですよ。はまちちゃんがDISりたい時は直リンはダメって言ってた(PVが発生すると更に拡散する恐れがあるから)ので、googleキャッシュで御覧ください。
この悪質な書き方は一体何なんでしょう... 全く関係のない第三者なのに何様のつもりなんですかね。
上記のキャッシュを見てもらえればわかりますが、僕がカチーンと来たのはこの記述。
株式会社Retty（2010年設立、スタッフ30名、資本金4億5千万円）、法に反しなければ何でもありの精神でけっこうな黒いことをやっているではないか。詳しく調べて叩けば真っ黒な埃がもっと出てきやしないだろうか。
おいおいおい、お前ら何様のつもりなのこれ。スカウトメールの行き違いからRetty社が「法に反しなければなんでもあり」ってなんでそんな話になるの？ それは何の因果関係があるわけ？ 悪質なのは些細なすれ違いをした当事者なのか、全く関係ないけどボロクソに非難した第三者なのか。火を見るより明らかでしょう。
Retty代表の武田さんは(出すまでもない)謝罪文を出して説明責任を真面目に果たしているのにも関わらず、「真っ黒な埃がもっと出てくるぞ」と非難中傷をして不当にRetty社を貶めるのは、場合によっては名誉毀損として訴えられてもおかしくないと思うんですけど。
採用プロセスの些細な行き違いをダシに何の裏付けもない拡大解釈をして、この会社はブラックだ何だと悪魔化するのは下衆の極みです。恥を知りなさい！！！！！！！！
それに不必要に代表者の顔写真をバシバシ貼り付けて晒しあげるっていう書き方も、すごく下衆い。匿名で記事を書いて叩く→バイラルメディアとして拾って拡散というのはお約束ルートなのでしょうか。上記の匿名記事すら自作自演だったのではと... だとしたら、すごいね。
詳しく調べて叩けば真っ黒な埃がもっと出てきそうなのは、いやーどちらなんでしょうか。あのような下衆い記事を鵜呑みにするようなことがあってはならないので、黙っていられなかったというわけです。
僕にはバイラルメディアとネットイナゴの違いがわからないので、検索してみました。「バイラルメディアはゴミじゃねぇ！」とおこでいらっしゃるブログが見つかった。そこにはこう書いてあった。
まずはじめに、「バイラルメディアとは何か」というところから整理したいのですが、僕個人としてはこの定義は簡単だと思っています。
「FacebookやTwitterなどのソーシャルメディアからの流入がトラフィックの中心になっているメディア」
これだけです。記事が画像や動画の引用で構成されているだとか、おもしろ系・感動系のコンテンツが中心みたいな話は関係ありません。
バイラルメディアはゴミじゃねぇんだよ
流入経路が第一優先でコンテンツの質は一切問われない定義に吹いた。ソーシャルメディアでシェアされるコンテンツは公序良俗に反する物、スパムアプリ、デマ情報もたくさんあるし、上記のような非難中傷にまみれたコンテンツも含まれます。僕のブログもFB/Twitterからの流入が中心なので、バイラルメディアと言えちゃいます。勘弁して下さいよ。
「価値があるのに埋もれてしまっているコンテンツを発掘するのにシェアが有効→バイラルメディアは価値を見出しているので、ゴミではない」という理屈らしいのですが、バイラルに伝わるインフラとなっているTwitter/Facebookがすごいだけで、お前らやっぱそれに寄生するだけのネットイナゴじゃね？ 情報ソースの拡散なら、それRetweetでよくね？ 何の付加価値があるの？
良いニュースで良い人生を送りたい読者諸氏におかれましては、下記のサイトの情報をあてにしましょう。その情報が確かであると信ずるに値する実績と信頼。これこそがメディアの価値でございます。
安心と信頼のまなめオチでございました。
この辺りの議論が面白かった。
ロリポップでホストしたこと無いんですけど、wp-login.phpに対してIPアドレス制限をさせるたりログイン回数に失敗すると業者サイドでロックするのには驚いた。今すぐにロリポップ捨ててさくらのレンタルサーバ スタンダードを使おう！安くて速くて安心だ！
WordPressで作れるサイトは多種多様ですので最近ではWordPressで作りますの内容がピンキリで取扱注意ってのはわかるけど、そこでうまく手綱を捌いていくのが腕の見せどころ。その辺の押し引きはキッチリ線を引きつつ、何にカネがかかるのか、何にお金をかけてもいいのかをバランス取らないとねぇ。時には、現実は少しも甘くないことを伝えるのもプロ。
お問い合わせフォームだけ必要であとはHTMLで放置でOKなら、HTMLをAmazon S3にあげてお問い合わせにGoogleフォームを使えば10円コーポレートサイトの完成。それもまたひとつの形。それに、WPの管理画面ってそんなにとっつきにくいかなぁ・・・投稿と固定ページの違いがわからんとかそんなことじゃないの。
HTMLとCMSの区別がつかないお客さんは多いんでしょうけど、自分で記事を作成してコンテンツを更新するってことは、それ自体にプログラムが内包されているので「車のように持ってるだけでカネがかかる」という現実をありのままにお伝えしようよ。レンサバと契約する理由にもなるから、ページ規模に関係のない話だと思う。
僕もたけさん(@take_it02)と一緒で「なるべくコストをかけずに自分で更新したい」顧客ばっかりです。でも、乗りっぱなしでメンテ無しでも行けますけど、車って老朽化しますから一種の怖さがあるのはわかりますよねっていう話はしています。
HTMLはファイルでしかないけどPHPはプログラムであり、プログラムには実行環境が必ず必要になる。HTMLを作ることにカネがかかることはみんな理解してくれるんだから、もう１歩それを進めてプログラムを動かすって少しも甘くないわ、と。そこをキッチリ詰めてから管理費等の話をしますので、毎月管理費を払ってくれるお客さんもいれば限りなく放置でいいので管理費無しのお客さんもいます。
コードを書けば書くほど、メンテナンスコスト比例して積み上がっていく。HTMLが自転車だとすれば、WordPressは自動車だ。両者の違いは免許が必要なこと。WPを使う免許は要らないけど、使うには専門性が必要。その違いを誤魔化しちゃいけない。
プラグインを使えばやりたいことがすぐに手に入るけれども、お客さんからすればプラグイン適用したのか標準機能なのかはどうでもいい。プラグインが提供している機能についての改修依頼が来た場合、みなさんどうされているんでしょう。プラグインがフィルターを用意してくれていない場合は、直接書き換えたこともあった。基本的にはコードを書いて対応しています。
僕は自社サイトをWPで運用してて、その中で取引様専用ページを作っています。そのページの中でお取引様だけに製品のカタログPDF等を配布しており、ファイルのダウンローダープラグインを使ってます。そいつがファイルの情報を登録する時にjson_decodeで日本語ファイル名がエスケープされてしまいダウンロード出来ないとか、レスポンス返す時にUTF8でファイル名がエンコードされるからWindowsで日本語ファイル名が文字化けするというクソみたいな問題にぶち当たりました。この程度で済んでよかったｗ
HTMLだけでいいのってランディングページぐらいじゃないかなぁと思います。会社案内等も修正することもあるし、単なる文字をちょっと更新する度に業者に頼むほうがめんどくさいんじゃないですかね。素人が文章を書くようにHTMLを更新できるっていうメリットは大きい。ペライチじゃない限り、僕は基本的にWordPressを使って構築しています。
SIerをDISってブログを書きはじめ、気がつけばプログラマの定年の歳になってしまいました。まだ実感がわかない。Paiza開発日誌のSIerのDISり方が品がないのでちょっとイラついています。DISられるには充分なネタがあるからしょうがないんだけどね。
10年前は自分はコードを書くことは無いなとか思ってたら、ほぼ毎日しょうもないコードを書いていることにびっくりしている。平凡な誰でも書けるようなもんだけど。解決している問題が平凡だからね、LINEのインフラ作ってるわけじゃないからね。しょうがないね。どうでもいいけど、スーツとギークって完全に死語だね。肩身狭いわ。'`,､('∀`) '`,､
で、最近５年間を見て思うんですけど、これからIT業界(システムインテグレーションの業界という意味)のマーケットの成長は鈍化すると思います。ITの世界って、オーダーメイド(受託開発)、既成品の買い切り(パッケージ)、サブスクリプションの３つしかビジネスモデルがございません。大きく言えば。
上記の３つのビジネスモデルの中で伸びる可能性が高いのはサブスクリプションですが、サブスクリプションが当たり前の世界になると、業界内で食っていける人が減る可能性が滅茶苦茶高いです。なんでかといえば、Webサービスでフリーミアムだイエーイという世界と同じように、業界内競争が熾烈になって共食いが発生するからです。共食いの結果生き残った所がコモディティ化の進行に伴い価格を下げていきますので、生き残れる業者が減ります。
そのような状態で業界全体の成長が加速するかなぁ・・・と。
クラウドが当たり前になることで、クラウドの上でソフトウエアを作ることも当たり前になった。その結果、いかにクラウドの上のサービスを組み合わせて最適解を産むかというビジネスが増えた。今現在、SIで元気のある会社ってそーゆービジネスをやっている所が多いように感じます。AWSのサービスを組み合わせるとか、KintoneみたいにPaaSやるとか。
個人レベルでは、ソフトウエアがコモディティになりましたので、高度なプログラミング技術を求められる案件よりも、普通のアプリやWebを作る案件の方が圧倒的に多くなっていると思います。コモディティになるってことは入手しやすいってことですからね。でも、その普通のアプリやWebを作ることが出来る人を育成できる会社が、どんどん減っているのが気がかりです。IT業界を志す方々の裾野は広くなっていくけれども道は細くなるというか。入学するのは簡単だけど卒業する(進級する)のは難しいというか。素人++みたいな人は３年持たずに消えていくような、そんな世界になりそうです。
コードで回りを動かせたらどこでも食って行けることは間違いないので、コードで回りを動かすために何を実装すれば世界が代わるのか、何を身に付ければ作りたいものが実現できるのかを、愚直に考えて行きたいと思います。僕も。
それでは、また。
トップやリーダーがこういう考えで物事を判断するとろくな事にならず経営状態が良くならない。そんな「あるある」ネタが５個たまったので、シェアさせて頂きたく思います。
やったことがないことをやる意味はすごくある。やったことがないことができるから成長できる。けれども、やってみて失敗した時の影響範囲によってはものすごく高い授業料を払うことになります。
運営上の課題を整理して走り続けるのはOKなんですが、やる前にダメだった時の終わり方を必ずシミュレーションする必要があります。ここまでやってダメなら次を考える「撤退ポイント」がないと、いつかは辿り着ける症候群に陥ります。この疾患は感覚で物事を判断するタイプに非常に多く、逆算して物事を考える習慣がありませんのでやってみないと気がすまないという。
「やってみないと分かんない」の対極は「やる前から終わってる」です。ゴール(到達点)は近づいてくるものであって、追いかけるものではありません。
売上が無ければ何も始まらない。売上がすべてを癒す。それは正しい。
でも、安定した経営をする為に必要なのは売上を最大化することではなく、利回りを最大化すること。かけたコストに見合うリターンがどれだけなのか。そのリターンを組織力で得るため為にはどうすべきなのか。そこから逸脱していくと、環境の変化にとても弱くなります。
売上原理主義に侵されてしまうと、下記ポイントが蔑ろにされがちです。
1000万の売上でかけた経費と仕入が800万、500万の売上でかけた経費と仕入が300万。どっちがいいかと言えば後者です。残る額が同じなら支払いが少ないほうが(損益分岐点が低いほうが)良い。でも、1000万の売上が減るとただ怯えるケースが多い。利益率を悪化してまで掴んだ売上の未来は、大抵暗いものです。会社のキャパやビジネスモデルに依りますが、安定した基盤を作るために売上を減らすのが最適な場合もあります。
より早く、より安く、より細かく。より利便性の高いサービスを提供する。大変素晴らしい考え方です。
お客様が注文しやすいように障壁を下げようという話は一見素晴らしく感じますが、敷居を下げ過ぎると足元を見られます。ま、あそこならこの程度の注文でええか、と。顧客の中でのランクが下がり、自分で自分を安く売るのは身売りにしかなりません。必要以上のサービスを提供すると過剰な負荷がかかり、自社の営業利益を圧迫します。
全ての顧客に対して、各々の望む形に合わせることは出来ません。必ずどこかで意味のないサービスを提供することになります。言い方悪いですが、どの会社も明確な判断基準を持って顧客を選ぶ必要があります。「ここまでしか出来ません」という線を引く。その線の引き方が顧客管理そのものです。経営者の腕の見せどころ。
これは1番のアンチパターンにも似ているのですが、10の力しかない組織が20のことを達成するのは無理です。10の力で20の重さの石を押し続けるのは無駄。押し続ければいつかは20の重さの石をずらすことぐらいは出来ますが、その負担を別の所でしわ寄せしてるだけです。同じことを繰り返して異なる結果を期待することを、アインシュタインは「狂気」と表現しています。
努力で最も大切なのは方向性です。寿司を上手に握れるようになりたいのに、ラーメンを茹でる努力をしてもしょうがない。極端な例を上げましたが、その努力を続けても全く状態は良くならないだろっていう話は結構多いです。人の動き方が正しい方向に変われば会社はガラッと変わるものです。
経営における「クソジーコ問題」とは / 佐藤 裕介 | STORYS.JPと少し似てる。
創業者は凄腕の営業マンであることが多いです。誰よりも多くの情報を引き出し観察し洞察した上で、その顧客との商談を成立させます。が、洞察という行いは非常に感覚的です。言語化するとマニュアルになっちゃうというか。その嗅覚がある前提で営業マンに指示を出すからどうしようも出来ず、結局自分でやっちゃう。そしてミドル層が入れ替わり立ち変わり、振り出しに戻る。
誰かの能力に依拠して何かを立ち上げることは何の問題もないですが、会社組織は常に変革をしていかねば現状維持すら難しくなります。組織変革を阻害する一番の理由は、属人性です。その人がいないと回らない場合と、その人が足を引っ張る場合があるんですけどね。極端に言えば後者だったら切ればいいだけなんですけど、前者になると一筋縄ではいかない。
色々と書きましたが、強いて共通点を挙げるとすれば「意味の無いことをやっていれば、必ずどこかで歪みが生じる。」ってこと。その辺りがマネジメントが求められる大きな理由の１つだと思いました。
