激務だけど夢もある

f:id:kazuyaengineer:20181005220843j:plain

こんばんは、カズヤんです。

今日は、自身の所属しているファームについて書こうと思います。

私はITコンサルファームなので戦略ファームについては書けないですが、コンサルってかなり激務ですね。最近は毎日10時まで働いて、食事して、お風呂はいって寝る生活です。大好きなYoutubeが見れないし、副業もできないwww

激務すぎて体調崩して辞める人が多い理由もなんとなくわかります。というのも毎日ひたすらドキュメント作ってお客さんと会議しての11h(9:00 - 22:00) × 5日続けていると幻覚見えそうになってきます....

続けられる人は基本的に2パターンで、

目標意識の高く、コンサル好きな人

単に高い給与がもらえるためやめられない人

かと思います。

私はどっちも当てはまりますね。

ただ、最近は仕事詰めすぎて精神的にきつくなっていたので、気分転換にと六本木ヒルズ開催の社内パーティに参加して来て、一気に気持ちが変わりました。

こういうイベントって毎回アワードが発表されるのですが、いつもお世話になっているインド人上司がアワードを受賞したのを観ました。普段一緒に仕事をしている方ですし、とても身近な人です。とてもスマートでかっこいいし優しいし、日本語のうまいかなり優秀なインド人のシニアマネージャでした。

その次の週に、仕事で彼にチャットしようとしてプロフィールのところにマウスポイントを乗せた瞬間驚きました。

 

ほよ!? ランクが1個上がってる!?

 

ディレクター!?  (本当は別の名前ですが、ファームがバレるのでアクセンチュア式で)

 

そうなんです。おそらくアワードがトリガーとなりプロモーションしていました。てか、単純に外資コンサルって単純な業界だと思って変に納得しました。

 

シニアマネージャからディレクターってことは、

年収も1200万とかから、一気に1500万以上のステージになるということ......

 

外資系には夢があります...

この出来事以降モチベーションが少し戻ってきて、最近かなりやる気やばいです。私はいつまでファームに残るかわかりませんが、海外勤務するまでにこういった外資系企業特有の側面に触れられたことは私にとって1つ有意義な体験でした。

 

たまにこういう話を聞くととてもやる気が出ます。

では、今日はここで失礼します!!

PMOの役割

f:id:kazuyaengineer:20181004221507p:plain

こんばんは、カズヤんです。

IT業界に入社したもののPMOを今だによくわかっておらず、友人がPMOをやっていたり、現在のプロジェクトでPMOに管理されていたりと最近やっとその実態が掴めてきたのでこれを機に整理して見ました。

 

目次:

1、PMOの役割

2、PMOの資格

3、PMOの現状

4、終わりに

 

 

 

1、PMOの役割

PMOとは、Project Management Officeの略語で、プロジェクトが適切にかつ円滑に進行するためのファシリテーションをするようなチームです。

通常のITプロジェクトでは、プロジェクトマネージャ(PM)がおりまして、1つのプロジェクトをリードしていくと言ったイメージですが、大規模のプロジェクトになるとこのようなチームが組成されてプロジェクトを統括することになります。

ITプロジェクトのPMOでは、クライアントサイドのビジネス担当者、アドミン、コンサルファームのコンサルタントにてチームが組成されることが多いです。

 

また、PMOにもアドミニストレータ、エキスパート、マネージャと異なるロールがあるので押さえておくと良いと思います。各ロールの役割は以下サイトを参照してもらった方が早いのですが、私の所感で書きますと、

www.npmo.org

 

アドミニストレータ

プロジェクトに関する社内プロセスの管理。会議室予約したり、勤怠管理したりといったすごく庶務的なポジションです。個人的には最も代替性の高いポジションでだれでもできるロールの認識です。

 

エキスパート

一気に専門性が高くなり、プロジェクトにおけるスケジューリング、コミュニケーション、ビジネス、ツールなど多くのスコープの管理を担います。ITプロジェクトの場合には、プロジェクトで利用されている技術を知らないと少し支障が出ます。

SAPはパッケージソリューションであるために、標準機能、アドオンなど特有の技術があり、プロジェクトのフェイズごとに必要な知識が変わってくるかと思います。

私の場合ジョブ設計をしていてバリアント設定とかするのですが、こういうところも技術専門のチームとPMOチームが共同で全メンバーに設計書スケジュールや作成方法などを周知することになります。

 

マネージャ

PMOの管理をするポジションとなり、PMOの全体統括を担います。ここに関してはプロジェクトマネジメントの経験が長い人が担当することになります。

大規模プロジェクトの場合は、上記エキスパートがかなり忙しくなりますので、このマネジメントポジションがしっかりPMO全体の進捗管理に専念する必要があります。

 

 

 

2、PMOの資格

Project Managementの資格といったらPMPですが、どうやら日本にはPMOの資格もあるようです。以下団体のページとなりますが、オンラインで教育を受けられてすぐに受験できるっぽいですね。もし興味あったら受けることをお勧めします。デリバリー専門の場合は、IT戦略にいかない限りはPMOが唯一のマネジメントスキルとなるからです。あとは、やはりIT業界はソフトスキルよりも資格といったハードスキル好まれるのでとって損はないはず。

www.npmo.org

 

一応、PMPのリンクも載せます。ただしPMPは職務経験が5年くらい必要で、メンテも大変な認識ですが、PMBOKを理解して、かつPM経験をアピールできる優秀な資格です。

www.pmi-japan.org

 

3、PMOの現状

現在のERP導入プロジェクトは大規模プロジェクトでPMOチームが存在します。クライアントサイドはいいとして、いくつかコンサルファームももちろんジョインしています。ただ、ITに弱いファームだといくら汎用性の高いPMOというポジションとは言えまともにマネージできないものだと思い始めています。

アドオンプログラムの詳細設計フェーズでも、またテストフェーズでも必要なドキュメントの書き方、期日などをアナウンスしてくれるのですが、期日に関しては本当に無理なものを要求してきます。これは、IT経験がないとレベル感とか一切わからないと思います。

また、PMOの質が悪いと厳しいクライアントだと他ファームに変更することも全然ありえるようです... とても怖いw

個人的には、今のPMOのチームはあまり好きではないです。インプリ側の状況全然把握してないっすwww 

ただし、未だにITコンサルティングファームだけでなく会計系ファームでもPMOのポジションはあるので、もし技術畑でマネジメントもやってみたいという人がいたら挑戦するのがベストかと思います。

 

4、終わりに

私の場合、会社の同期や先輩がPMOとして業務を行なっていた方がおりますが、私の同期なのでせいぜい2年目ですww

ITの技術がわからないからPMOにとばされることになると思うのですが、先ほど説明したようにPMOも技術わかっていないとあまり面白くないと思います。IT戦略がやりたくて現ファームに入ってきた若手コンサルタントでPMOをやっていた方は、別ファームに転籍して消えましたwww 本人曰くITスキルもないからプロジェクトの細かいところがわからないし、ただのけつ叩き係はごめんだということらしいですww

ただ、もし技術メインでやっている人がPMOやると楽しめるのではないかと思いました。私もプロジェクトマネジメントは経験したいと思っています。1プロジェクトに責任を持つプロジェクトマネージャとしてもそうですが、やはりSAP導入のPMOも経験してプロジェクトを回せるように今はひたすらファンクショナルを頑張ろうと思っています。

導入コンサルにABAPスキルは必要?

f:id:kazuyaengineer:20181003223426p:plain

こんばんは、カズヤんです。

今日は、SAPコンサルを目指す方の間でよく言われる

SAPコンサルってプログラミングのスキルいらないの?

っていうところ書いていきます。

 

私は元SAP Basis出身でしたが、就職活動のためにJavaの資格を取得していたため、オブジェクト指向型のプログラミング知識はある程度持っている自負があります。ただし、文法は似ていてもABAP特有の書き方というものを体系的に学んでいない分、正直コードが読めるレベルにまでは達していません。

 

今プロジェクトにてオフショアデリバリーチームのABAPコンサルタントリードのインド人がいるんですが、めっちゃ仕事ができます。詳細設計書は40パターンくらいありますが、ID言えば3秒以内にアドオンプログラム名を教えてくれます。超かっこいいです笑笑 

 

通常SAP導入コンサルは、アドオン要件定義のためにSAPの標準テーブルと標準トランザクションは最低でも理解する必要があるということはよく言われています。ただ、最近の業務を通して思うに、ABAPは絶対読めた方がいいです!! 勘違いしないで欲しいのが、書けるレベルにはなくても読めるレベルだと良いと思います。

 

というのも現在プロジェクトはテストフェーズなのですが、単体テストで欠陥が見つかった場合にはこのプログラムを修正する際にわざわざインドの開発チームに報告するのですが、その際にある程度自分で設計したプログラムのロジックをわかっておかないと円滑なコミュニケーションが取れません。

 

 

 

また、転職市場で見てもやはりABAP経験のあるSAPコンサルは大変需要が高いです(欲を言えば英語力)。採用される確率がかなり上がります。

 

まだ日本では国内開発の部隊がいてそこで開発をすることが大半かと思いますが、今後は大方インド・フィリピンへのアウトソースとなると思います。技術力のあるABAPコンサルタントと対等に会話するためにはABAPの知識くらいはつけたほうがいいと思います。(かくいう私も無くて泣いていますがwww)

 

そういう意味では、ABAPの開発経験は1-2年はあった方がいいと思います。私は今更補填することもできないので標準テーブルくらいは全て覚えられるように頑張っています。一方で、テクニカルなところも少しは知りつつ、本当に我々が出さなきゃいけないのは業務(ビジネス)レイヤーの箇所なので、そこを前提にもちつつの認識は忘れないように。

 

またこのような疑問ってたくさんあると思うので少しずつ共有していけたらと思います。今日はこの辺で失礼させていただきます。

 

では、また!!

SAP IDocについてのリフレクション

こんばんは、カズヤんです。

今日もひたすらジョブですwww

外部インターフェース関連のジョブが多くてかなり手こずっています。出荷伝票の送信時のファイル転送といったすごい単純なプログラムですが、この転送の仕組みを理解するのにものすごく時間がかかりました。SAPの場合、SAP PI(Process Integration)というミドルウェアでファイル転換が実行されます。ファイル変換はXMLデータとIDocデータの変換が多いです。以下、厄介なPIとIDocについてリフレクションしようとおもいます。

 

目次:

1、外部インターフェースについて

2、SAP IDocについて

3、IDoc関連トランザクション

4、終わりに

 

1、外部インターフェースについて

通常、システムって内部で完結するイメージですが、外部のシステムとデータの交換をする際には、外部インターフェースを作成することになります。内部ってのはアプリケーションがインストールされているサーバを指します。外部というのは、該当アプリーケーションサーバとは異なるサーバを指します。

インターフェースってよくIT用語として出てきますが、これは、異なるものどうしが交わるつなぎ目の箇所を指します。例えば、UI(User Interface)とか言いますよね? あれは、コンピュータと人が接するつなぎ目、境界をさします。コンピュータの場合はスクリーンやキーボードが該当します。

冒頭でも触れましたが、SAP内で処理したデータを外部システムで利用したい時って結構あるようで、その場合データフォーマットを変換しないといけません。SAPではIDocというデータフォーマットでデータが利用されているのですが、これをXMLファイルでみたいというケースが多く、IDocにて変換して外部システムで利用することができるようになります。逆も然りです。

 

2、SAP IDocについて

SAPのIDocはIntermediate Documentと呼ばれ、SAPの標準データフォーマットです。

またSAP IDocはそのデータ移動の方向によって、以下の2種類に分類可能です。

 

・Inbound IDoc

 外部システムからSAPシステムにてデータを受信するケース① IDoc→XMLなど

・Outbound IDoc

 SAPシステムから外部システムに対してデータを送信するケース② XML→IDocなど

    f:id:kazuyaengineer:20181003220523p:plain

SCM関連では、InboundとかOutboundとか耳タコで嫌なのですが、まあ覚えてくださいwww

 

3、IDoc関連トランザクション

SAPにおけるIDocのトランザクションの一覧を作りました。と言いたいところでしたが、死ぬほど先駆者がいたので以下ブログを参照してください。私もお世話になりました。

ameblo.jp

 

4、終わりに

SAP Basisをやっている時は、RFC(Remote Function Call)のトランザクション叩いたりしてクライアント移送をやったりしたのですが、IDocに関しては実は触ったことがなかったです。Basis構築経験のある人は触ったりするのでしょうかね? 

ちなみに、ファンクショナルコンサルタントはほとんど全員知っていてここを知らないとSAPコンサル失格です。私自身も初めて聞いた時はリアルタイムデータ変換とか何言ってるのかさっぱりわからなかったのですが最近になってようやくわかってきました。

今回はIDocの概要としましたが、個人的にIDoc探求しているので違った側面からかけるようにインプット深めます。例えば、SAP PIについてとか....

では、今日はここで失礼します!!

導入プロジェクトのカオス

f:id:kazuyaengineer:20181001220213p:plain

こんばんは、カズヤんです。

今日も相変わらずジョブ設計をしております。ジョブが少なくてもバリアントが100個近くあり、しかもみんな忙しいので完全に個人プレーで取り組んでいます。

 

私は標準プログラムとアドオンプログラムのジョブ設計をしていて、特にアドオンに関してはプロジェクトチームのコンサルタントが各プログラムの設計を担当しているのです。そこで、PMOが定める期日までにジョブ設計書を書いたのですが、ここにきてアドオンプログラムの詳細設計書が誤っているものがいくつか見つかり、私のジョブ設計にもかなり影響が出て、バリアント設定もやり直しなどかなり足止めをくらいました。

PMOから担当の私が注意されている状況です。

聞くところによると、そもそもこのプログラムの詳細設計書を書いていた担当者が退任して、引継ぎ者が書き直したらしく、前任者だけがメールベースで仕様を話しあっていたためだれも知らない仕様がいくつかあったようなのです。

このプログラムはかなり複雑で、1つのプログラムで日次8回実行する仕様で、バリアントが24個も必要な設計者殺しプログラムです。

しかも、プログラム詳細設計書を書き直したので、単体テストをもう1回するようですが、僕が個人的に勝手にプログラムを実行しましたが、全然期待どおりのアウトプットが得られませんでした。多分開発者がちゃんとコード書けてない感じです。出荷伝票ファイルの転送プログラムなのですが、該当ディレクトリに何も届いてないwww

前職の経験から思うに、導入プロジェクトは運用プロジェクトほどドキュメントの管理が行き届いていないです。運用プロジェクトにいた時は、誰でもファイルの格納場所がわかるようにドキュメントが整備されていました。導入プロジェクトでは、ある種職人芸的な側面が強く1人の担当者だけが知っている状態になってしまってます。

ドキュメント整備したいけど、時間がないwww

時間がないけどファイルみないと適切な設計ができないwww

というこのジレンマと日々戦っています。

まだ、本プロジェクトに加入して1ヶ月半なので意見出しづらいですが、適応しつつ色々ぶっ込みまくろうと思いました。今日は完全なぼやきですが、これがITコンサルの現実かと認識してもらえたら1つのバリューかと思います。

あ〜楽しいなあwww

では、また!!

【学生向け】ソフトウェアベンダって何?

こんばんは、カズヤんです。

最近、Linkedin、Facebookなどで学生さんからキャリア相談を持ちかけられることがあり、ソフトウェアベンダーってSIerやITコンサルファームとどう違うのか?といった疑問を問いかけられます。私自身SAPというソフトウェアに携わっているためきちんと答えたいと思います。また、SIerやITコンサルファームと比較して、ソフトウェアベンダーに就職することがどれほど価値あることか語りたいと思います。

 

目次:

1、ソフトウェアベンダとは

2、MicrosoftOracle、SAPの成功

3、ソフトウェアベンダに入るメリット、デメリット

4、個人的な見解

 

1、ソフトウェアベンダとは

ソフトウェアベンダは、自社製品を持つベンダのことです。通常のSIerなどの会社はお客さんの欲しいシステムの要件をヒアリングしてスクラッチ開発しますが、ソリューションベンダはもともとの自社で製品を保有しており、パッケージ製品とも言われたりします。ソフトウェアベンダの例としては、Microsoft社、Oracle社、SAP社が有名です。

 

 

 

2、MicrosoftOracle、SAPの成功

MicrosoftOracle、SAPを聞いて知らない人はほぼいないんじゃないでしょうか?

Microsoftは、Windowsを開発したことで、ほぼ全てのエンタプライズにて標準利用されるビジネスアプリケーションとなりました。一般向けと法人向けで幅広く利用されるアプリケーションですね。

Oracleは、リレーショナルデータベースの業界トップ企業であり、エンタプライズで利用されるアプリケーションにはほぼ必ずOracleが利用されているとも言われています。

SAPは、企業の基幹システムであるSAPを販売するERP業界トップ企業です。最近では、ERPだけでなくSAP HANAというインメモリデータベースをリリースしたことでも知られ、また、SaaSのソリューションも数多くリリースしておりクラウドの領域にも進出しています。

最近では、猛烈な勢いでSales Forceが日本でも有名になりましたね。

Sales ForceはCRM(Customer Relationship Management)ソリューションの世界を代表するベンダーです。大企業向けだけでなく、中小企業にも導入できることが強みで幅広いセグメントに対してアプローチできることが強みです。個人的にはデジタルソリューションとの相性もよく、ITキャリアとしては一番いい分野だと思ってますww

日本では、テレビCMもやってますし、今はイケイケどんどんのベンダーですね。

f:id:kazuyaengineer:20181001002409p:plain

 

3、ソフトウェアベンダに入るメリット、デメリット

では、これらの企業に入社するメリット、デメリットは何でしょうか?

 

▪️メリット

・ソリューションのエキスパートとみなされる

そもそも、IT企業の構造として、これらベンダーが作った製品を多くのベンダーが技術者を育成し、集めクライアント企業へソリューションを提供する形をとります。そのため、他SIerやITコンサルファームにいるよりも、そのソリューションの高い専門性を持っているとみなされます。これは、その製品が利用される限り最強の勲章となります。

 

・世界初の事例に触れられる

上記で述べたように、業界でベンダーが製品をリリースすることでその製品の経済圏は動きます。つまり、製品に新たな技術を搭載してリリースした際の導入事例はプライムであるベンダーからスタートすることになります。世界で最初の導入事例の経験者になれる機会がたくさんあるのは圧倒的な魅力です。

 

・グローバル経験

このような製品は現状では海外で生まれることが多く、アメリカが多数です(SAPはドイツ)。そのため、ソフトウェアベンダー企業は大半が外資系企業のため、超グローバル環境です。常に本部との連携が必要になるため、グローバルな経験が積めるでしょう。

 

▪️デメリット:

・その業界でしか通用しない専門知識

デメリットは正直ここしか浮かばないですww

この製品ベンダーに入社すると、その製品にしか触れないため、他の技術に疎くなる可能性があると思います。特にSAPに関してはSAP社のSAPコンサルタントとなった場合、SAPだけの技術に詳しいコンサルタント的な側面が強くなり、転職の選択肢が狭まります。この業界でずっとやると決めるなら問題ないし、給与は上がるでしょうが、他のこともやりたい場合には所属年数は長くない方がキャリアのためにはいいのではないでしょうか。

 

4、個人的な見解

いろいろ述べてきましたが、ソリューションベンダーも当分は絶対なくならない企業が多いので、個人的にはソリューションベンダーに入社するスペックがあるなら是非入ることをお勧めします。給与もいいですしね。それで他のことがやりたいなら2年以内に消えることをお勧めします。

また、学生の方はこれらの企業は採用基準がかなり高いので、相当な対策をすることをお勧めします。SAPキャリアに関しては、私がいつでもご相談にのりますのでいつでもコメント等いただけると幸いです。最後宣伝みたいで恐縮ですが、この辺で失礼します。

SAP導入メソッドActivateの疑問

こんばんは、カズヤんです。

今日は、SAP S/4導入フレームワークのActivateについて書いていきます。私が現在携わっている導入プロジェクトでは、お客様側で利用されている固有フレームワークにて導入がされており、実を言うと、まだSAPの既存のフレームワークにも触れたことがないのですが、SAP社のHPにて新しい導入フレームワークの記事をたまたま読んでいたので、共有します。

 

1点気になるのが、

以下SAP Activate Methodologyのページなのですが、

Modular and agile framework for implementation or migration of SAP solutions that provides content and guidence for project teamsって書いてあって、アジャイルをめちゃくちゃ押している点です!!

 

f:id:kazuyaengineer:20180929215720p:plain

 

SAP導入を経験された方ならわかると思うのですが、SAPなどのERPって通常はウォータフォールで要件定義、設計、開発、テスト、保守・運用という流れでやっていくものですよね!?

アジャイルの場合って、要件の変更が当たり前と想定して、設計、開発、テストを何回も繰り返して製品をリリースできるレベルまで持っていく手法と認識しています。

ただ、これってTechベンチャーなどが開発するようなアプリケーションで適していると思うし、ERPでこれやってたらスコープがでかすぎるし、お客さん承認遅いしでプロジェクトが永遠に進まないのではないかな!???とすごく疑問に思うのです。

まあ、私自身が今初めて導入プロジェクトにいるからそう思うのかなと感じる反面、やはり経験者の方の意見欲しいです。

SAPのフレームワーク自体は元からみんな信用していないのかな?と思ってしまいます。経験者の皆様、そもそもSAPのフレームワークって有用なのか、それともActivateおかしいのか?今後のS/4移行を考慮する上で意見欲しいです。

お待ちしております!!

では、きょうはここで

 

SAP Tennis Analytics デモに参加

ご無沙汰してます、カズヤんです。

先日、3連休で東レパンパシフィックオープンテニスの準決勝を観戦してきたのです。その後体調不良になりこの記事書けなかったのですが...

 

本大会はSAP社がオフィシャルスポンサーをしており、SAP社によるSAP Tennis Analyticsのデモイベントとしての側面もあります。

 

最近、スポーツ関連のソリューションで本田圭佑選手を起用して大々的にマーケティングをしているあれは、SAP Sports Oneというソリューションです。今回のは、SAPが傘下に収めるHawk eyeというセンサー(というよりカメラの会社)とリアルタイムアナリティクスを可能にするインメモリデータベースのSAP HANAを搭載したテニス解析ツールのデモです(以下リンク)。

www.sap.com

 

今回は、準決勝ということで日本の大坂なおみ選手とイタリアのカミラ・ジョルジ選手の試合です。

f:id:kazuyaengineer:20180928000613j:plain

また、SAPブースでは、試合観戦用モニターとは別にSAP Tennis AnalyticsのGUIが映し出されているモニターも用意されており、リアルタイムで情報が更新されていきます。しかも、自由に触ってOKです。

f:id:kazuyaengineer:20180928000815j:plain

冒頭でも触れましたが、会場にHawk eyeというカメラが10台設置されており、そのカメラにてボールの着地点の座標を取得して、SAPのクラウド環境にWEB送信されるそうです。また、DBにはSAP Hanaが利用されているため、取得したデータをリアルタイムで解析してインサイトを導くということです。

会場モニタもリアルタイムで更新されていて見ていてすごく楽しかったです!!

女子選手の基本情報、試合ごとのパフォーマンスデータ(サーブ成功率、サービスエース本数など)などが確認できるということで、戦術のために指導するコーチや選手が利用するようです。

www.sapjp.com

 

普段は完全にSCMを担当しているので、また違った側面でSAPを楽しめたのはよかったです。また、SAPはERPベンダーというイメージが大変強いですが、現在はDB、クラウド、アナリティクス、センサーと多種多様な領域まで踏み込み革新的なソリューションを提供しているというのを直接知ることができてよかったのが何よりの収穫。また、SAPコンサルとしてやる気充填されました。

 

今後はロジ系のインプット共有します!!

では、また!!