システムアナリスト試験に役立ったこと
私はシステムアナリストの試験に合格はしましたが、
普段の業務でシステム化計画の立案などの
最上流工程にあたる仕事はしていません。
割合でいうと7ppbくらいだと思います。
プロマネやアプリケーションエンジニアの試験では
普段の業務で学んだ知識を役立てることができましたが、
ANの試験ではそのように行きませんでした。
それでは何が役に立ったかと言うと、私は大学で
マーケティングを専攻していたため、その時に学んだことが
もっとも役に立ったと言えます。
午後1試験では、長い問題文から企業の課題と目標を探し出します。
問題文を読んでいくと、課題はたくさん見つかります。
全体を通して「この企業はこの方向性に進むべきだ」という目標を
見つけることができると、課題の中でも解決すべきものがはっきりします。
システムを導入すれば効率化が図られると思われる部分について、
その部分の効率化は他の部分よりも優先度が高いのか？
という視点から問題を眺めると良いでしょう。
午後2試験では、自分がシステム化戦略や計画の立案を行った経験を
論文にして述べます。必ずしも経験していることを書く必要はありません。
もし経験が厳密に判定されるのであれば、職務経歴書の提出などが
求められても良いはずです。それがないということは、
「自分ならこうする（こうした）」という論文を書いて出せば良いのだと思います。
さて、システムアナリストがシステム化計画の立案を行うとして、
何が重要になってくるでしょうか。
私は一番に現状の調査・分析を行うことが重要だと思います。
競合他社の様子、代替市場の様子、新規参入企業の様子、
お客様の様子、部品供給元も様子、政治、経済、環境など
様々な視点から自社の置かれる環境を分析します。
また、過去数年に渡ってどのような変化があり、
この先どのように変化していくかを眺望します。
そしてその企業がどのような未来を描くべきかを判断します。
もし経営戦略が確たるものであり、それに沿ったシステム化だけを
計画するのであれば、調査・分析の作業量は減少します。
しかしEAという言葉のあるとおり、システム抜きで企業の未来を
描くことができないという企業・業界も少なくありません。
そういった場合は経営戦略の立案フェーズからANが参画します。
そして将来像が見えてきたら、それを実現するためのシステム像を考えます。
昨今ではフルスクラッチの開発が減り、優秀なパッケージソフトウェアが
数多く登場しています。また、SaaSのようにサービスだけを受けるという
形態もあります。企業の描く将来像に即したシステム化を考える必要があります。
こうしてどのようなシステムを作っていくかが決まっていきますが、
そのうちに予算と期間も決定されていきます。
最初から予算と期間をガチガチに固めると、その枠内で何とかしようという
思いから発想の自由度が低くなります。予算内の計画はもちろん作成しますが、
別に予算越えの案も作成してみて意思決定者の決済を仰ぐ形も良いと思います。
このようにして作成したシステム化計画は、経営者の意思決定により
実現するか否かが決められます。修正が入ることもあるでしょうし、
やーめた、となることもあるでしょう。
ここで重要なのは、ANはそのシステム化計画が有効であることを説明する責任を負うということです。
たとえば10億円かかるシステムがあるとします。
一般的な減価償却期間として5年を想定すると、
1年あたり2億円です。一般に、社員を養うのに給料の3倍かかると言いますので、
一人の社員を養うのに2000万円かかるとすると、10人を5年間養うことができる金額です。
基幹系システムを構築するとして、現行システムがボトルネックになって
仕事がはかどらないような現状があれば、10億でもそれ以上でも払って
ボトルネックを取り除くという計画もあり得ます。
一方で、社内の間接業務を削減するという場合、削減される業務の量が
コストに見合ったものであるかどうかが重要になります。
ひょっとしたら人間を新しく10人雇って人力で対処したほうが良いかもしれません。
確かに人間を採用すれば退職金の引き当てや社会保険など
様々な経費が発生します。一方でシステムは稼働させ続けても
勝手に成長することがありません。システム部門の人間が
スキルアップすることはありますが、勝手に処理性能が上がることはありません。
しかし人間は成長します。人間の事務処理性能は上昇します。
このようにして考えると、何でもシステム化すればよいとは言い切れません。
システム化の費用を人件費に回したとしても、
断然システム化したほうがコスト的にお得だとか、
コスト的には負けるが財務的にメリットがあるということを
経営者向けにアピールする必要があります。
その結果として、経営者側はシステム化する気でノリノリでも、
ANとして「システム化は不要」という決断を下す場面もあるでしょう。
これはプロマネやアプリケーションエンジニアでは考えられない場面です。
「このプロジェクト、最後まで持ちません」ですとか、
「このモジュール、動きません」ということはあり得ません。
プロジェクトは完遂、モジュールは完成以外に目標が無いからです。
一方、システム化についてはシステムを作ることが目的でなく、
企業があるべき姿に近づくことが目標です。
ですのでシステム化が適当でないという場合は
「やっぱ作るのやめましょう」と言って周囲を沈静化しなくてはなりません。
それもANの仕事のひとつです。
実際にANの試験で「システム化が不適当だと思われたのでやりませんでした」
などと書いたらまず不合格になると思われます。
しかし論文の中で、「システム化しないということも視野に入れ、
システム化した場合と比較したところ○○という点で有利だった」
ということを書くと深みが出ます。世の中、システム化の松竹梅の案だけではありません。
システム化をやらないほうが儲かる、
フルスクラッチ＋商用アプリケーション勢ぞろいで作ろう、
LAMP構成にオープンソースのフレームワークで作ろう、
ERPにできるだけ手を加えずに作ろう、
SaaSでやろう、
自社のシステム部門でEUCしよう、
などの様々な選択肢がある中、なぜその計画が正当であるか、
それを経営者相手にプレゼンする気持ちで挑むのがANの論文だと思います。
私のゼミでは教官を相手にして10分ほど「自分がこの会社ならこの時こうした」
というスタイルで発表がありました。誰が指名されるのかわからないため、
課題が変わるたびに準備して挑む必要がありました。
10分の発表のあとには他のゼミ生や教官から20分ほどに渡り
ツッコミが入ります。ブランディングについて熱く語っても、
「資金調達はどうする？」という突っ込みや「既存の○○というブランドの
ラインナップとどのように棲み分けるのか？」などという質問が来ることがありました。
これに慣れると、自分で事前に質問を想定しながら批判的に作戦を練るようになります。
結果として、完成する発表内容も良くなりますし、突っ込みにも動揺しなくなります。
ANの論文で回答するときは、読む側が心の中で突っ込みを入れそうなところについては
フォローしながら論述すると良いと思います。
「この計画の課題は○○であったが、経営者の判断を仰いだところ
システム化のメリットのほうが大きいとの結論に達した」などです。
論文の最後には総括をするところがありますので、
「当初課題とされた○○については、計画中で対策を固めることができたため
表面化することなくシステム開発を終えることができた」というような感じでしょうか。
以上、システムアナリストとして働いたことのないシステムアナリストからの
助言ですので、ものすごい斜め上な感じのところもあるかと思いますが、
ご参考にしていただけると幸いです。
（関連エントリ）