アジャイルという言葉が世に出てきてもう随分たつ。一時期は自分も傾倒し、アジャイルプロセスを実践している企業に決め打ちで応募して転職したこともあった。ただ現実とのギャップの中でいつしか従来のウォーターフォールを如何に効率よく行うかってところにマインドが向いていた。これは開発行程で開発側のみがアジャイル的なやり方を実践したとしても、所詮顧客を巻き込めないと結局自己満足に終わってしまい、定量的な効果につなげるのがとても難しいって実体験から来ている。しかし今の会社は文化的にも顧客との関わり方的にも顧客を巻き込むことが従来のSIerよりもやりやすいので、もう1度身の丈に合ったアジャイルというものを突き詰めていこうかと検討中。こういうことは個人でやっても浸透しないので、社内で分科会をたちあげて皆でストーミングを起こすに限る。さてまずは今時点の動向をトレースしてみるか。
企業合併などでシステム統合を行う場合、システムアーキテクチャ観点で、まず最初に目指さなければならないのは統合方式を確定させること。スクラップ＆ビルド型、吸収型、片寄型、並存型とあるわけやけど、では何をもって統合方式を確定させれば良いのか？ってところが焦点になってくる。ただなかなかシステム統合の方法論やアプローチを解説してる書籍とか記事ってなくて、唯一自分が通っている大学院の先生が共著で執筆された書籍に事例を含めて書いてあるが、まず軽視してはならないのがIT資産評価、つまりデューデリね。M&Aや事業譲渡などでは当たり前の世界で、世の戦略系コンサルの方の十八番の1つなんだろうけど、ことITの評価となると過分にIT知識が要求されてくる。まぁ往々にして残存簿価ベースで積み上げていそうだけど、本来的にはIT資産をコスト以外のマルチな視点で評価するITデューデリって、ググってもあまりやってるところはないみたいなのよね。ビジネスアーキテクチャとシステムアーキテクチャの両方が要求されるITのデューデリってニーズとしてはどれくらいあるのだろうか？ビジネスになるかなぁ〜とか考えみる。まぁいい、ちょっとノウハウを現場で徹底的に身に付けてくるとしよう。
ここまで無敗のマンチェスターユナイテッドですが、とうとう土がついちゃいました。相手が最下位のウルブスってどういうこと？と言いたくもなるが、去年も昇格組のバーンリーに2戦目で負けたし、リーガでもバルサが今季2戦目で昇格組に敗れていたような。まぁ心理的な余裕というか油断をついてくるところはさすがにあちらもプロってことなんだろう。
まぁ負けたとは言え現在2位のアーセナルと勝ち点差は4もあるので、これを教訓にして下手な取りこぼしをしなければ優勝は間違いない！だろう。2月からはいよいよチャンピオンズリーグもはじまるし、忙しくなってくるなぁ〜。
心理学者のタックマン氏は、組織というのは形成して直ぐに機能しはじめるわけではなく、形成(フォーミング)して混乱/対立(ストーミング)を経て、統一(ノーミング)されてからようやく機能(パフォーミング)しはじめるというタックマンモデルを提唱した。例えば炎上しているプロジェクトにせよ、会社組織にせよ、この中の特にストーミングを省略してしまうと、もう組織が機能することはない。
実は前職時代に自分もこれに気付いた時期があって、ただ上層部に単身で直接言うのもちょっとねって時に開催したのが社内討論会だった。あれ自体は自分としては実験的な取り組みで、その次の段階で社内中を巻き込んで討論会の名のもとに徹底的にストーミングをしてやろうって思惑があったのよね。そういえば自分よりも数か月前に退職したメンバーも若手メンバーに対してもっと混乱を起こしていけと言っていたな。まぁ言葉とアプローチは違えど、思いは同じだったのかもしれない。
そしてこれは炎上プロジェクトでも言えることで、ただ新規にメンバーを投入だけしてもなんら組織の強化にはならない。新旧のメンバーを集めてまずは思いのたけを本音でぶつけさせて混乱させる、そこから組織が再統一されて真の活きる組織が作られるのだと思う。まぁとはいっても日本人ってのは兎角なーなーで終わらせる文化でもあるので、なかなか難しいって事情もよく分かるが、これがやれるかどうかがリーダーの資質ってやつだろう。
ツイッターで面白いツイートがあった。
○正義の味方の特徴
１自分自身の具体的な目標をもたない
２相手の夢を阻止するのが生きがい
３常になにかが起こってから行動
○悪玉の特徴
１大きな夢、野望を抱いている
２目標達成のため、研究開発を怠らない
３日々努力を重ねる
４失敗してもへこたれない
５よく笑う
確かにヤッターマンのドロンジョ様しかり、バットマンのジョーカーしかり、何度敗れてもくじけることなく冷静に敗因を分析し、入念に再戦に向けての準備や謀略をめぐらしている。孫子も「兵は詭道なり」と説いているわけだし、まぁたまには勝っても良いものなんだけど、結局はいつも敗れてしまう。これは何故だろう？って考えると、そこは正義の味方に理不尽に存在する愛やら友情やら奇跡やらの不確実性要因によって悪玉の入念な準備も謀も最後にはぶっとんじゃうからだ。つまりリスクまでは対策できても不確実性までは読めない！ってところから、結局悪玉は負けちゃうのよね。他にあるとしたら、正義の味方は変化に対して柔軟に対応してくるが、悪玉は計算から外れると途端に脆さを露呈する。つまり正義の味方は変化に対してとっても柔軟に対処できる柔軟性をもっている。
さすがヒーロー、なんか理不尽に凄い！
今日は前職のお客さんらから誘われて飲みに行くことになったのだが、今振り返ってみるとあのプロジェクトは苦い思い出も多い。その中で大きかったのが、あらやるステークホルダー間のコンフリクトの解決に向けてあまり有効な手を打てなかったことだ。経営層-IT部門、IT部門長-IT社員間、顧客-ベンダー間、ベンダー間、自分-自分が所属する会社など。システム開発は上流にまわればまわるほど難解なコンフリクトに衝突することが多くなってくる。そのためにファシリテーションが存在するわけだが、人がガチで絡むコンフリクトを原理原則やロジックだけ解決することはできない。出来たとしても１つ誤ると後に大きな禍根を残す。ここは人が相手である以上は感情のマネジメントについても重要な要因になるだろう。ってことでこの手の書籍も読み漁っているが、やはり最後は実地で学んでいかないとね。一度ちゃんとセミナーとかでも学んでみたいんだけどね。