【コラム】社内SEの幻想と憂鬱と未来
社内SEに対して思うところ。
システム開発に携わっていると、必然的に
・SIベンダ
・ITコンサル
・社内SE
と何かしらの形で携わる。直近、社内SEの立ち位置に非常に違和感を感じるため、記事にしてみた。
AI、DX(デジタルトランスフォーメーション)などなど、企業の躍進にはITの活用が不可欠であり、事業会社含めIT人材の確保が急務になっている。
（既存の仕組み、システムを活用できていないのに、新しいことができるとは思わないが、、、）
事業会社において『社内SE／社内コンサル』の数がここ最近急増していると感じている。
＃裏取りできるデータがないのだが、、、
社内SEとして即戦力を採用するのであれば、システム開発の経験が必須であり、SIベンダやITコンサル出身者を採用するのは正しいと思われる。
が、この考えがそもそも間違っていると考えている。
『スコープ恐怖症が治らない、治せない、治す気がない』からである。
ベンダの人は、何よりもスコープを大事にする。
・100%できると判断できないとYesと言わない
・1行の追加修正でもYesと言わない
・チームが違えば違う会社。外にはでない。
新卒の時から叩き込まれている習性であり、しかも『それ以外の仕事』を見たことも触ったこともないので、『そもそも、スコープを外すものは悪だ』と思い込んでいる。
もはや、宗教のレベルである。
そんなコリに凝り固まった人を採用したところで、ベンダの人が『社内』に来ただけで何も変わらない。
社内SEではなく『社内ベンダ』なのである。
しかも、中途採用の場合、業界、業務、会社の政治／文化をよく知らないケースが多い。成果を出すには自分の経験に頼わざるを得ない。
結果、『自分のできる仕事＝ベンダの仕事』となり、悪循環に陥る。(見た目上は仕事をしている風に見えるかもしれないが。)
ベンダは、いくら動かなくても、いくら使われなくても、いくら文句を言われても検収してもらえば勝ち。売上になるからだ。
『不満感』をいかに小さく見せ、クライアントに気持ちよくなっていただきつつ、いかに継続的に仕事を貰うかが重要。
しかし、事業会社の考え方は違う。『本質的に必要なものなか』が何よりも大事である。スケジュールを守っても、予算内に抑えても、それが会社にプラスにならなければ無価値。逆に、スケジュールを超過しても、コストがオーバーしても、会社にプラスになればいいのである。
事業、ビジネス視点でシステム開発を推進できる社内SEをほとんど見たことがない。
- やれユーザー(他部門)が要求をださないからだ
- やれ顧客の使い方が悪いからだ
- やれ予算がないからできないのだ
などなど、口を開けばネガティブなことしか言わない。
旧来の、ゆっくりしたビジネスであったら社内ベンダ型の社内SEでよかったと思うが、今はそうではない。
『前進するか、撤退するか否か』の迅速な判断が担当レベルに求められる。会社にとってプラスになる道筋を立て、関係者を巻き込み仕事を進める必要がある。
もちろんシステム的な視点も必要であるが、何より重要なのは、ビジネス視点。
ビジネス視点を持った『社内SE』はどのように調達、育てればいいのか。。。
これまた難しい課題である。。。理想論しか思いつかない・・・
＜＜案①＞＞
ベンダ出身者を『社内SE』として採用した場合、2～3年現場に放り込む。
営業、整備、事務、コールセンターなどをやるべき。システムの使われ方を把握できるだけでなく、『現場とのコミュニケーション』が取れるようになるのが、一番のメリット。
『社内ベンダ』の人は、他部門の人を『同じ会社の人として接すること』ができないケースが多い。まるでお客様かのように扱う人もいるが、同じ会社ならもっとストレートなコミュニケーションを取るべき。
いちいち言質を取るようなことは今すぐやめたほうがいい。
自分の身を守っているつもりかもしれないが、そもそも守ったところで何も生まれない。ただただ、言い訳、人を糾弾するための材料を集めているだけである。
もし、現場に放り込んで活躍できないような人材なら、スキルアンマッチと考え、裏方仕事に回すべき。表に出してはいけない。そんな人が、ビジネス視点でプロジェクトを推進できると思えない。
＜＜案②＞＞
『社内SE』は『職務限定社員』のような形で、一般的な総合職と待遇の差をつけ、『できなくて当たり前、ユーザー側でどうにかすべき』との文化にする。要は、ビジネス主導でやるってことである。
社内SEはベンダとの契約手続き、保守運用の窓口など、最低限必要な定型化した仕事をしてもらう。
技術的な視点も確かに必要であるが、結構なエキスパートでないと、結局はベンダの言いなりになる。（会話ができても、代替手段や他に取りうるアーキテクチャは提案できない。）
中途半端にかかわるぐらいだったら、初めから丸投げし、『本質的に何が必要か』を考えることに注力したほうがいい。
今回も結論なくだらだら書いてしまったが、結局何が言いたいかって、
・社内SEって思ったよりいいものではない？？？？？？？
ってだけ。( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)
以上。
【コラム】BABOKとeラーニング～ためになったフレーズ集～
前回の続き。少し、奮発してe-learningを受講することに。並行して、CBAP受験方法を調査。結果、受験は一時保留にすることに( ﾟДﾟ)
理由はシンプル。申し込みがちょいちょい大変だから。(ぶっちゃけめんどくさい)
参考までに、受験申込のポイントを紹介。
＜CBAPの受験資格のいろいろ＞
１、10年間／7500時間のBA(ビジネスアナリスト)としての経験が必要
→年数はおいといて、7500時間分の実務登録がまあまあめんどくさい。
２、推薦人が二人必要 →しかも英語での対応が必須。
３、申し込みだけで100ドル以上必要 →審査に人手がかかるのは理解するが・・・
４、日本語対応の参考書がほとんどない →あるけど古いのしかない。。。
ただ、e-learningで学んだことはそこそこ実務で使えそうなので、その点は良かった。せっかくなので、印象に残った内容を紹介する。
＜＜印象に残ったリスト＞＞
最終的なソリューションの定義の責任はそれを必要としている母体組織が持つべきである
うん。そう思う。丸投げはやめよう。
BA(ビジネスアナリスト)は全工程に関係する
やり逃げ厳禁！！！！！！
ブレーンストーミングは質より量
面白いことを言わないといけないって空気をやめてほしい。テレビがすべることに対する恐怖を植え付けすぎ。
優先順位づけに必要な要素は、便益・ペナルティ・コスト・リスク・依存性・時間依存性・安定性・規制やポリシーの遵守
順位付けは大事だけど、順位付けが終わったときは時すでに遅し。
ゴールと目標の精緻化 SMART
S具体的（ Specific ）：何らかの観察可能な結果を記述できる。
M測定可能（ Measurable ）：成果を追跡し、測定できる。
A達成可能（ Achievable ）：作業の実行可能性を調べられる。
R関連している（ Relevant ）：エンタープライズのビジョン、ミッション、ゴールと整合している。
T有限時間（ Time-bounded ）：ニーズと合致するような時間枠を定義している。
だぶんMができているプロジェクトは1%以下。
読み手にドメインの知識があると思い込んではいけない。
能動態で書き、要求を満たす責任を負うのはだれまたは何であるかを明確に記述する。以下禁止用語。大きい、小さい、近い、約、おおよそ、適当な、適切な、より多くの、より小さい、ほとんど
いい言葉。社訓にすべき。
検証(verification)と妥当性確認(validation) の使い分け
検証：要求が品質基準に満たしているかの確認
妥当性確認：要求がビジネスニーズに合っているかの確認
検証に時間とコストをかけすぎ。結果、誰も使わないサービスが生まれる。
エンタープライズによる限界の要素
『文化』って明示されているのは面白い。文化のしがらみは万国共通なの？
埋没コストはあきらめろ
まずは、自分のいらない本を捨てるところから。それができないなら、永遠にあきらめられない。
組織で使用する専門用語や用語体系を理解している。
組織が提供するプロダクトやサービスを理解している。
組織の当該分野専門家（ SME）が誰かを特定できる。
組織の関係や政治力学を調整できる。
そろそろビジネスの世界から政治って言葉なくさない？これも万国共通なのか。。
積極的傾聴をやりなさい
これはほんとに思う。『いい質問ですね』が流行ったせいで、質問ができなくなっている人急増中。質問しないでしったかぶる方がよっぽど恥ずかしいし、何より迷惑。質問すること自体を褒める風潮にしてもらいたい。( ﾟДﾟ)( ﾟДﾟ)
ーー
BABOKはガイドなので、教科書的な内容が多いが、年をとったせいか共感できることが結構あった。海外の事情は正直よくわからないがBABOKの記載を見る限り、
日本企業と同じ悩みをかかえているのではないか？
と勝手に親近感がわいた。
ただ、『ガイドにも書かれてることだし、基本に忠実にやりないさい』とか言った時には老害認定されそうで言いたくない。(´・ω・`)
【コラム】SE、ビジネスアナリスト、データサイエンティストとBABOKとCBAP
登録っしっぱなしの転職サイトから、最近？『BA(ビジネスアナリスト)、データサイエンティスト』の求人メールがよく来ている気がしている。
個人的には、両方ともSE(システムエンジニア)を今風の呼び方にしているだけと思っているが・・(一昔前から営業ではなくコンサルタントやディベロッパーって呼び方が増えたのと同じ？？)
・データサイエンティスト＝BIツールを構築する人。パッケージベンダの人。
・ビジネスアナリスト＝要件定義をする人。
ほぼほぼ思い込みと独断と偏見であるが、こんな感覚。
ビジネスアナリストで思い出したのが、2009年～2012年ごろの『BABOK』ブーム。
- プロジェクトの失敗の原因といえば、要件定義の失敗。要件定義を確実に進めるために、BABOK使おうぜ！！
- ビジネスアナリシスを体系だって学ぼうぜ！
って流れが、一瞬だけあった。気がしている。googleで『BABOK』って検索してみるとわかると思うが、掲載順位が高いページが結構古い。関連書籍の発行年月もちょい古い・・・気が付いたら『BABOK』って言葉を誰も発さなくなったので、私の記憶からも消えていた。
しかし、ここ最近の『ビジネスアナリスト』ブームに便乗？して、『第二次BABOKブーム』が来るのではないかと勝手に予想。(日経コンピューターとかで『今、再度注目されているBABOKとは？』てきな記事とか出ちゃうんじゃないかと。もちろん根拠は０！！！）
第一次ブームであったときは、THEシステム屋さんで全く興味がなく、学んでいなかったので、思い立ったら吉日、せっかくなので学んでみることに。
ちなみに、Wikipediaによると、BABOKの資格であるCBAP保持者は、2015/10時点で日本で94名とのこと。少ない( ﾟДﾟ)( ﾟДﾟ)( ﾟДﾟ)
→→→→→→→→→→→→→→→→→→
2015年に3.0版の日本語版が発行されているが、対応している日本語の書籍がほとんどなさそう。早速躓く。。。さすがに、2.0版となると2009年発行になるので古すぎ。古典を勉強したいわけではない。
3.0版を勉強するためには、
- BABOKを管理／運営しているところから『ビジネスアナリシス知識体系ガイド Version3.0』を購入する。約7000円。http://store.iiba-japan.org/
- 集合研修に参加する。約150,000円～
- eラーニングで学ぶ。約10,000円～
の3つの方法ぐらいしかなさそう。集合研修は、個人で払うにはちょと高すぎる。費用が工面できるなら、eラーニング、できない場合はガイド購入って感じで、始めてみます。
具体的な勉強方法が決まったら、次回紹介します～～～(´・ω・`)
データサイエンティストの話は次々回あたりで・・・・・
