Just blogged

元SIerの今はWebビジネス中心なヒトが日々のトピックを綴ります。

アカウントSEとのぶつかり合い(上)

マネージャと喧々諤々な議論をしました。
彼は現在アカウントSE(顧客担当上級SE)として、各々のプロジェクトを
監査しています。


僕の上位上司(元上司)にあたる彼は社内でも有数な広範囲にスキルフルな
エンジニアであるし、彼なりの回答を持っているのだろうと思い、
あえて率直に向かい合いました。
反面、どうも僕は世渡りが下手なのかもしれないと思いながら。


上の層とここまで深く、そして激しく議論したのは、
入社以来かもしれません。
また、議論を通して、自分のコンセプチュアルスキルが、
かなり上昇した事が今日はっきり分かりました。
それをもって、彼の貴重な時間を1時間半程度使わせていただきました。


NDAにひっかかる部分もあるので、すべては記述できませんが、
上・中・下の3回に分け、出来る限り書いてみようと思います。


現場のSEなら少なからず直面するであろう問題だから。


3つの僕なりの主張を投げかけました。

  1. 暗黙知形式知化をもっと積極的に推進すべき
  2. ITSSにおけるITアーキテクト:アプリケーション・インテグレーションアーキテクトを戦略的に育成すべき
  3. 職務とPJにおける役割と責務の開示と明確化を行うべき


実はもっと詳細レベルで議論を行ったのですが、NDAにかかるためもっと上のレベルで記述します。
この主張に対し、議論の末に行きついた答えは以下。

  1. 組織として該当するOUTPUTは多数存在するが、それが体系化されていない(現在、体系化される途上)
  2. 本当に必要な粒度のOUTPUTが存在しない

ちょっとNDAにかかるので、多少ぼやけさせているけど、
これはかなり難しいレベルの議論をしました。


粒度といったものは、現場で体で体感しないとなかなか分からないものが多い。
しかし、はっきりとわかっているのは

適切な粒度で作成されたOUTPUTは何者にも勝るほどの資産価値を生む

ということ。


そして、そのテンプレートをつくるスキルこそがどの業界でも通じるコアスキルだと思います。
コンサルタントで言うと、SWOTなどのフレームワークをつくるスキルも素晴らしいけれど、
もっとニーズが高いのは、そのフレームワークを現場レベルで適用することです。
IT業界だとPMBOKをつくるのは至難の業だろうけど、僕らに必要なのは現場レベルにそれをうまく適用・実行すること。
もちろん、それだけでは足りないので、様々なメソドロジーや経験知を加える。


その間のGAPを埋めるものが「知恵」であり、コアスキルだと思います。
これは、アウトソースできない。


そうして、明確な回答と共に出てくるOUTPUTこそ、PJに必要なもの。
これはシステムを様々な粒度から俯瞰する必要のある
ITアーキテクトの思考に通ずるものだと思います。


議論の末に、僕が必要だと考えているOUTPUTの粒度とマネージャが意識を合わせた粒度が一致し、
そのOUTPUTはいまだないという事で合意しました。


であれば、そのレベルのOUTPUTは自分に対するミッションなんだろう。
自分にはその粒度が(ある程度)見えているから。


2番目の主張以降、ちょっと長くなりそうなので、
次回以降に内容を引き継ぎます。