今回お話を聞いたのはLTSの、鈴木大介さん（コンサルタント5年目※）です。コンサルタントはプロジェクトに入ると、そのプロジェクトに必要な業界やシステムの知識を習得します。鈴木さんは入社して初めて触れたSAPを5年にわたり勉強し、今では社内で「SAPについての質問があれば鈴木さんへ」と言われているそうです。どのように勉強したのか、気づきや学びをお話しくださいました。
（※取材当時）
LTS新卒入社後、化学メーカーの基幹システム教育展開/運用保守プロジェクトを経験。現在も運用保守プロジェクトを支援する傍ら、基幹システムの企画構想～要件定義プロジェクトにも従事している。（2022年8月時点）
インタビュー
プロジェクトに必要な専門知識をどう習得したか
―――まずは、入社してこれまでの業務歴を教えてください。
2018年に新卒で入社しまして、一貫してERPパッケージの一つであるSAPのプロジェクトに携わっています。
入社した当初はSAP運用保守のヘルプデスクを担当し、ユーザーからの質問に回答していました。2、3年目になるとヘルプデスク業務を通して、SAPやユーザーの業務に関する知識も増えたので、お客様の子会社に対するトレーニングを担当するなど自分の業務領域も広がりました。4年目以降は、2023年に保守期限が切れるSAPを刷新するための企画構想のフェーズに携わっています。今後、要件定義が始まる予定です。
―――確かに、一貫してSAPに携わっていらっしゃいますね。SAPのことを勉強し始めたのはいつですか？
入社前にはもちろん、SAPのことは知りもしませんでした。
LTSの新入社員研修のコンテンツの一つにSAPの研修があるのが恒例だったんですが、私が入社した2018年は別の研修と置き換わっていたのでありませんでした。次の年の研修には復活したらしいんですが…（笑）。なので、プロジェクトにアサインされて初めてSAPを知り勉強を始めました。
―――そうなんですね。初めはどのように勉強されたんですか？
まずは、基幹システム全般についての書籍で、基幹システムとは何か？どういったものがあるのか？を把握しました。そして、具体的にSAPにはどんな機能があり、どうやって動いているのかを学習するには、一般に公開されている英語版のeラーニングを活用しました。
その上で、SAPに触れる環境があったので、実際に触ってみて自分の中に落とし込んでいました。
―――プロジェクトの先輩社員からは何かアドバイスはありましたか？
はい、これまでのプロジェクトの経緯やユーザー側の業務内容などは教えていただきました。そこは、他の皆さんとも同じ、プロジェクトにアサインされたらまずはキャッチアップするイメージです。
それはありつつ、SAPなどの基幹システムについては、実際に動かしてみる・触ってみることが、一番身に付くなと感じています。
あとは、ヘルプデスクをやらせていただいたので、一般的な疑問から特殊な疑問まで触れる機会があり、実際に使っている人と一緒に理解を深めていけたのかなと思います。
一般的な知識か？プロジェクト特有の知識か？を識別する
―――難しいなと感じたところはありましたか？
これは、SAPに限らずだと思うんですが、プロジェクトで使われている用語がお客様先で使われている独自の言葉なのか、一般的なビジネス用語なのかの判断をするのが難しいなと感じたところです。
例えば、ある「管理会計に関する管理表」があったときに、これは一般的にどの企業も持っているものなのか、このお客様が持っているだけなのか識別が付かなかったところも結構ありました。
そういう意味では、SAPの知識の前に企業オペレーションを頭に入れておくとスムーズだったのかなとも思います。
Know whoを知っておくと、情報収集がスムーズになる
―――他に「こんなことをしているとスムーズに理解が進むだろうな」というところはありますか？
先程も先輩社員にキャッチアップのご協力をいただいたお話をしましたが、常に誰かに聞ける環境にあったことは大きかったなと思います。
ヘルプデスクでの回答を通じてお客様先の情報システム部門の方とつながりを構築したり、実際にユーザーにコンタクトを取ったりできました。また、社内では部内の勉強会で興味のある分野について理解を深めることができ、その場に参加していた方々とのつながりを持って、この質問であればこの人に聞いたらいいかなというKnow whoを把握できていることは重要だなと思います。
初心者にも分かりやすい書籍を活用する
―――周りに聞ける人がいない人もいるかと思いますが、その場合どうするのがいいと思いますか？
私が勉強し始めたころは、SAPに関する書籍もかなり少なかったんですが、今では『世界一わかりやすいSAPの教科書』など分かりやすい書籍もいくつか出ています。また、2021年に日本語版が出た『ファーストステップSAPシリーズ』は機能ごとに概要を説明しているものになります。体系的に学ぶためにも、これらの書籍はおすすめです。
あと、実践的なところで言うと、お客様の業務をしっかり把握することが、判断基準になることもあるかもしれません。企業の全体の業務の流れについてガイドラインや文書化されているものがあれば、それをベースに業務にフィットしているかそうでないかを確認でき、仕様の良し/悪しが判定ができるかなと思います。
自分にとっての「おもしろさ」を見出す
―――これまで5年近くSAPに関して勉強を続けられていると思いますが、継続できる理由やモチベーションはありますか？
大きく二つあるかなと思っていまして、一つは問い合わせを受ける環境にいたので疑問が尽きなかったところ。そして、もう一つは単純にどういう仕組みで動いているのか、なぜ動いているのかを考えて解を見つけるところが個人的に面白いなと感じています。
少しエンジニアの方の思考に近いのかもしれませんが、ある程度の事象を集めて疑問に対して仮説を立てて実際に組み立てて検証する…それを答え合わせして、という繰り返しが面白いなと。
―――そのあたりの「おもしろさ」は個人によって異なるかと思いますが、他の方のお話を聞かれたことはありますか？
正直、あまりないですね。
基幹システム全般で、個人的に興味を持って取り掛かる人って少ないのかなと思っていまして、恐らく業務上必要な知識なので学んでいる人が多いのかなと思います。
その中で、自分がどうなりたいのか？どこに楽しさを見出せるか？はそれぞれ異なると思うので、他の人がどう考えているか聞いてみたいところではあります。
―――勉強するときに大事にしていることはありますか？
単純に暗記をすればよい受験勉強等に代表される知識と、プロジェクトに活かすための知識では勉強方法は違うということは一つ考えていたことです。
プロジェクトでは課題を見つける/課題を解決するというゴールがあるので、ただ闇雲に覚えるのではなく、プロジェクトの背景や文脈、目的を理解した上で、関連するであろう知識領域の当たりをつける意識（そもそも必要な情報は何かという視点）も重要かなと思っています。
大海原で目的の島や方位磁針が無いと、遭難してしまいますよね。
専門知識＆一般知識は、セットで習得
―――これから新しいことを学ぶ人にアドバイスがあればお願いします。
そうですね、アドバイスといわれると恐縮ですが、まずは自分の担当範囲がどこかを確認して、それに即したインプットを書籍や経験者の方のお力添えで習得していくのが良いですかね。
それに加えて、SAPなどの専門知識と並行でその領域の一般知識を抑えておくのも大事だと思います。例えば、会計のところで言うと、その課題は財務と管理のどこの話なのか、管理の中の課題であれば標準原価管理を学ぶ。
とはいえ、そんなにうまくいかないことも多いと思うので、その場合は一つずつ疑問に思ったところを解消していくのが意外と近道なのかもしれません。点で散らばった疑問がいずれ線になると思うので、そこまではひたすら点を集める作業になるかなと思います。
―――ありがとうございました。
マネージャー層が考える「専門領域を学ぶコツ」
「知識を習得することは目的ではない」 M.Kさん（LTS 副部長）
自分に対する期待値や役割を明確にして、ステークホルダーの期待値を超えていく
プロジェクトで必要な知識を前提とすると、全てではないにしろ、学んだ知識を活用する場面や相手が存在すると思います。まずは活用する背景・目的を正しく捉えた上で、インプットしていくことをおススメします。そして、知識を習得することを目的とせず、社内社外問わずステークホルダーの期待値を超えていくことを忘れないでください。
期待値を超えることが出来れば、次はこの件お願いできますか？などと外部環境起因の知識領域の拡大チャンスにも繋がりますし、成果が認められると習得意欲にも繋がります。なので、そのような良いサイクルが作られたらいいなと思います。期待値については捉えることが難しいケースも多くあると思いますが、まずは①②を意識しています。
①できるだけ早く
➁初めは知識の深さではなく幅や量
時間を掛けるほど期待値はあがりますし（あがる面もありますが、早く達成すると評価を得られやすい）、また期待値の精度を上げていくためには、色々な話題に対応できるよう幅や量が大切だと考えています。
学んだ知識を意訳する＋実践する
頭では分かっていても、それを上手く伝えることはまた別の難しさがあると思います。言葉で伝える、文章で伝える、アウトプット手段は様々あると思いますが、学んだ知識をそのまま伝言ゲームするのではなく、本質的に重要な事項を考え相手や状況に応じて、伝え方を臨機応変に工夫できることが個人的に目指しているところです。
自分の言葉で人に語ることを意識して進めてきた結果、最低限抑えなければいけないレベル感について、自分の中に一定の目安が作られたと思います。そのためには実践を積み重ねていくことが、とても大切だと考えていて、意識的に実践する場を設定しています。
「プロジェクトに必要な知識のキャッチアップ、そのコツは2つ」 宮原 淳さん（LTS マネージャー）
新しいプロジェクトに入るといった点では、アサイン後すぐにプロジェクト内の資料を読み込んで理解できる部分はかなり限られていると思っています。経験豊富なコンサルタントであれば別ですが、若手ということで、プロジェクト資料に記載されている情報から仮説を膨らますことができないけど、どうやってキャッチアップしようといった観点でお話しようと思います。
顧客（やチームメンバー）の会話についていけている感を出す
一つ目は、「教えてもらえる状況を自ら作り出す。」です。”顧客（やチームメンバー）の会話についていけている感”を出すことで、一員として見られぐっと距離が近づきます。
実際のプロジェクトでは、業界の専門用語（これは書籍で習得）も多用されますが、顧客特有の用語も多用されます。顧客特有の用語がわからなければ、プロジェクト資料を読んでも吸収できる知識としてはずいぶん減ってしまう思います。（読み込んで不明点をピックアップしておくことも大事です。）
顧客特有の用語でも、業務的な用語は一旦おいておき、まずは、取り扱い製品や、事業所、関係会社です。新しいプロジェクトへアサインされる前は、隅から隅までとは言いませんが、顧客のホームページは読むべきだと思います。ホームページによっては組織図まで載っていますので、部署名や、工場なんかは（公開されている情報ですので）印刷していつでも見れる状態でアサインを迎えたほうが良いと思います。まずは少しでも会話についていけるように、これらを頭に叩き込みます。プロジェクトメンバーと共通用語を得られるわけですので、アサイン後、対面であれば会話の糸口になります。
アサイン後は人物。会議に出させてもらうと、こちらの状況などお構いなしに話が進みます。発言者の立場によって意味合いが変わることもありますので、この方はどの部署のどんな役職（立ち位置）なのかは気にします。
そのあとが業務的な用語という優先順です。プロジェクトに入って1か月くらいは、品定めされる期間です。こちらからの質問の質（顧客の用語で話す）によって、顧客（やチームメンバー）の会話についていけているか判断されることが多いと思います。
”私を育てると相手にとってメリットがあること（もしくはリスクが回避されること）を理解してもらう”
二つ目は、”私を育てると相手にとってメリットがあること（もしくはリスクが回避されること）を理解してもらう”です。
※プロジェクトによっては、受け入れる側が、そんな余裕（育てる）がない場合も多々あるとは思いますが、一旦今回のお話の中では置いておきます。
受入担当者が忙しいのであれば、自分が育つことで、いかに相手が楽になるか（本来したい仕事ができるか）というアプローチもありますし、上司／リーダーが忙しいのであれば、自分の活躍が上司にとって喜ばしい（期待していたこと）ことであるということを理解してもらうアプローチもあります。なかなか言いにくい顧客側であれば、顧客に取ってもらった1時間のレクチャーによって、納期が早められるかもしれない（本当にそうであれば）というアプローチもあるかと思います。
レクチャーを受ける時間を取ってもらうことになるため、プロジェクト資料を読み込み、不明点をリストアップし、できる限り仮説を立てて、質問する、などの準備は必要ですがまとめると以下のような点がコツかなと思います。
→ 相手の言語を少しでも理解し質問の糸口に。相手にとってわかっているね、わかってきたね、戦力になりそうだね、と思わせる。
”私を育てると相手にとってメリットがあることを理解してもらう”
→ お互いにメリットがあることを（リスク回避の場合もある）理解してもらい、協力してもらう。
ライター
自動車部品メーカーにて、グローバルで統一された品質管理の仕組みの構築・定着化を支援。産休・育休を経て、CLOVER Lightの立ち上げ、記事の企画・執筆を務める。現在、社内システム開発PJに携わりながら、アジャイル開発スクラムを勉強中。Scrum Alliance認定スクラムマスター（CSM）、アドバンスド認定スクラムマスター（A-CSM）、Outsystems Delivery Specialist保有。（2023年12月時点）
