RECRUIT

お客様の基幹システムの更改プロジェクトに参画しています。
約20年かけて業務に合わせて拡大されていったシステムの運用費が膨大な額となっているため、システムの集約・再構築・基盤移行など経て大幅に抑える事を目的としています。

参画してから約1年となりますが、まずは「基盤移行」から担当しました。
オンプレからクラウドにシステムを移行する際に大手SIerの協力依頼を行うためのRFPをまとめるという作業の時には短期間で多くの業務システムを基本設計レベルまで把握し資料化しなければならず、なかなかハードな仕事でした。

そして今は「集約」の担当となり、全業務システムのデータ分析システムの再構築をしています。現在1,000以上の機能がありますが、これを10分の1以下に集約しなければなりません。
利用側との要件定義を行いながら、外部開発ベンダの調整を行っています。基盤更改で得た業務システムの知識に加え、今までの開発経験をフルに活かし、課題を一つずつクリアしています。

開発工程は川の流れに例えられますが、これは本当にその通りで上流が氾濫した場合、これが小さなものであっても下流では大災害になります。
その事象を防ぐために、決めるべき事は必ず関係者とひとつひとつを明確に決めきる必要があります。
知識としては、お客様の業務知識や関係システムの知識が基本として必要になりますが、個人で全てを把握する事は困難です。そのためお客様社内の中で詳しい人を見つけて関係を構築しておき、相談させていただく環境を整えておく事も必要だと考えています。

曖昧な要望は扱いに苦労します。パワーを掛けて具体化したとしても、コストと時間をかけてまでやるべきものではなかったりします。そのため、まず何故この要望が挙がったのかの背景をお客様自身に調査や聞き取りをしていただきます。
その結果、重要なものであれば要望とその背景を分解し、ひとつひとつ調査やヒアリングを重ねて曖昧なものを明確にしていきます。「粘り強さ」や「しつこさ」が必要であり、お客様から面倒がられる時もあります。
要件定義の担当になったのならば、面倒がられて初めて一人前ですね(笑)

学んだこと、特に失敗から学んだことを明確に説明することは難しいと思っています。
重要な物事ほど、また、具体的な内容なほど説明も膨大になり、それが足りなければ皆さんに誤解を与えてしまう可能性があると思っています。具体的なお話は入社後、ということで（笑）
漠然とした言い方になりますが、己の勝ちパターン・法則・ルールを作ることがとても大切ではないかと思います。また、新たな経験から修正して精度を高めていく事も必要です。
まず、ひとつひとつ、己の勝ちパターンを作ってみてください。
困った時、悩んだ時のひとつの指針となるはずです。

「好きこそ物の上手なれ」という諺にある通りです。 が、技術自体を好きになったのではなく、自分の好きなものにIT技術を活用して身に着けてきました。趣味に関するホームページには仕事で得た技術を組み合わせてみたり、趣味上で必要なデータなどを集計・分析するツールを自作してみたりと。
趣味に技術を組み合わせる事によって、楽しみながら幅広く知識やスキルを身に着ける事が出来ました。
仕事で学んだことを好きになることは難しいと思うので、皆さんも好きな事に活用してみてはいかがでしょうか。