保守の視点からコンサルの成長を考える（後編）

プロアクシアコンサルティングでビジネスソリューション事業部に所属しています F.T です。
前編に続き、システム保守の活動がエンジニアのスキルの向上に寄与する点について延べます。

前編では、保守が我々コンサルにとってのどのような位置付けなのか、そしてユーザーの利用にどのように貢献するのかについて、システムライフサイクルに照らし合わせて述べてきました。

後編では、システムライフサイクルとそれに伴うコンサルの成長サイクルと、その中で保守の果たすべき役割・意識すべき点について述べたいと思います。

システムライフサイクルとそれに伴うコンサルの成長サイクル

前編でも記載しましたとおり未経験からの脱却や次のステップアップの場として、保守は有用だといえます。

そこで得られた経験やスキルは、保守を継続する場合においても稼働中のシステム・業務の理解へフィードバックされますし、新規導入プロジェクトへ異動となった際にも、保守で得られた経験を武器に稼働をイメージした設計・開発が進められると思います。この際、保守性も意識した設計まで行えるとなお良いです。

ただし、次の自らの成長へつなげる為には、次のような点を意識して活動することが必要と考えます。

保守内プロジェクトで自分のスタイルを確立

我々の成長の視点から見れば、小～中規模程度のプロジェクトの方がプロジェクト全体の動きや企業活動の全体感を把握するにはちょうど良い、と常々考えています。
一方、SAP を導入するような企業は規模の大きな会社が中心ですから、プロジェクトに参画しても全体の一部に関係することになりがちです。

保守における機能拡張は、前述したプロジェクトの全体感を把握できるちょうど良い規模感であり、実業務と本番稼働中のシステムを意識して取り組める良い ”プロジェクト” と考えます。
加えて、既に初期構築時に利用したプロジェクト運営のフレームワーク、例えば進捗管理や品質管理、課題管理・標準化等がを活用することができるので、プロジェクトの運営・管理面といった点においても学べることは多いです。

また、保守には導入時のような要員も割り当てられませんから、少ない人数で様々なことに対処する必要があるため、おのずとモジュールの壁を作らずに対応する広い視野も求められます。

(視点のチェンジ：自身の担当範囲 → 隣接するモジュールの理解 → 複数モジュールの関連範囲 → システム全体)

他チームの業務仕様や仕組みを理解・考慮して、モジュールをクロスしてつなげることができる能力は導入プロジェクトにおいても重宝されます。

こうして学んだスキルや経験は、次以降のプロジェクトにおいて自らの行動をイメージしたり、決定することにフィードバックされることになります。この保守 ⇔ 構築のサイクルの中で、インプットと自ら考えてアウトプットすることを通じて自分の仕事のスタイルを作り上げてゆくことになる訳です。

追記になりますが、ライフサイクルの観点からいうと、次システムへのマイグレーションまでが一連の活動となります。我々導入コンサルの立場としてはシステムを次へ引き渡しを経験することは稀ですが、保守の中で引き渡し側の経験もしておくことで、新システムへデータ移行を行う際に移行元/先双方の視点を持っているのも面白いかもしれないです。

経験を次の活かすために意識すべき点

経験が次につながるとは述べてきましたが、経験しさえすれば良いかといえばそうではないです。

自らが関与したユーザー業務がどのような業務形態なのか、プロジェクトの進め方やシステム化のモデルを自分の中で整理・抽象化しておくことで、別のユーザーの導入・保守を行う際にユーザー業務やシステムの形の想像やTo-Beモデルの仮説を立てることに繋がってきます。

仮に100社の導入案件に参画することがあったとしても、100社の業務を個別に事細かに把握することはできず、過去の経験から仮説を立てる必要があります。

この仮説構築力は、特に経験の少ないコンサルには身に着けて欲しいスキルです。

ただ、業務多忙な中でセルフフィードバックを行うような時間もなかなか取れないと思いますので、例えばセルフフィードバックすべき内容についてフレームワークを会社で用意しておいて、業務の区切りのタイミングで会社への報告やプレゼンテーションを行うようにする仕組み作りをする等の工夫が可能です。

上記のような、設計・構築 ⇔ 保守のサイクルを通じて、実業務の経験の蓄積と業務を意識したスキルの獲得が期待されます。

時には環境の変化が必要なケースもある

保守を中心とした成長サイクルについてお話してきましたが、その過程において成長が見込めない状況に直面した場合には環境を変えてみることも必要です。

スキル向上が見込めない環境

例えば、特定のデータチェックやメンテナンス作業等の繰り返し作業が続いたり、新しい改善プロジェクトが立ち上がりにくい環境については要注意です。

スキル向上が見込めない環境となる訳ですから、その見極めは大事です。現場からの要望の声を頂くこともあるかと思いますが、長い目で見て自己の成長につながりにくいようであれば、環境を変えることも選択肢の一つです。

居心地が良すぎる環境

長期で関わっていたりすると、システムのことがわかる人間が自分だけだったりすることもあったりして、他者からのフィードバックが受けにくい状況だったり、安易に対処できる範囲の仕事に落とし込んでしまったりなどといった状況になりがちです。

このような環境下でも自ら未経験分野に取り組んだり、適度な難易度の仕事に取り組めるようなら構わないと思いますが、そうでない場合は一考してみる必要があります。
スキルアップの為には、別の環境に飛び出す選択肢を持つことも大事なことだと思います。

なお、ここでいう ”居心地” とは、”対人関係の居心地” の話ではなく、”ストレッチ目標” の話となります。人間関係で悩むことが成長につながるとは思いませんし、人や社風等の居心地の良さはお互いに切磋琢磨したり、助言しあったりする上で重要な部分だと思います。

全体を通じて

保守にかかわることの有用性とその後に期待できることを述べてまいりましたが、現実の仕事のかかわり方として、前述のようなシステムライフサイクルにキレイにはまって関われるとも限りません。

前章でも記載しましたが、実際には単調な保守作業ばかりが続いたり、同じようなアドオン開発の繰り返しが続いたりなど、中々自身の成長につながらないこともあるかと思います。そのような場合は、自分のキャリアパスについて上司と定期的にコミュニケーションしながら、ジョブチェンジにより常に成長できる環境に身をおくことが重要です。

自分の成長のためのロードマップをイメージし、現在の自分の位置を把握しておくことで、その時々の成長に必要なスキルの判断もできるかと思います。