１社目、大阪での製造業企業 アウトソーシングIT子会社での話の続きです。
前回、新入社員研修まではこちら
【１社目】大阪 製造業企業のアウトソーシング子会社(新入社員研修まで)
今回は配属からです。
4月から管理部門預りで新入社員研修に専念させてもらい、研修も終わりが見えた秋頃に各部門へ配属されることになりました。
私は大学時代に英語を専攻していたこともあり、また親会社は海外にも拠点があったことから、海外向けのシステムを担当する部門に、、、とも思ったのですが、しっかり国内拠点の担当でした。
(海外担当になったのは、帰国子女だったメンバーでした)
配属されたチームでは、メインフレームで構築された基幹システムを、まさにダウンサイジングし、サーバーシステムに置き換えよう、とプロジェクトが立ち上がっていました。
開発メンバーとしては、既にパートナー会社の方も含め、しっかり体制を組んでいましたが、そこに新人である私たちもプログラマーとして入り、開発経験を積む、という環境が準備されていました。
最初に入ったのは、ある特定業務領域の機能を開発するチームで、すでに作成済みの設計書を基にJavaでコーディングし、その単体テストを行う役割をもらいました。
Javaは研修でやってきたし、ちょっと自信もあったのですが、実際に進めていくと、設計を理解するところからつまづき、そしてプログラミングする時も様々な独自のコーディングルールやフレームワークの理解が足らず、事あるごとにチームのリーダーに質問しまくっていました。
わからないことをしっかり確認することは、SEにとって、更には社会人にとって必要なことです。
が、やり過ぎたのでしょう。。。
何機能か進めた後、リーダーから上位職へ、指導の負担が大きい、とエスカレーションがあり、別のチームに行くことになりました。
今考えると、わからないポイントを都度個別に確認するだけだと、前後左右とつながらずに、流れが理解できない、ちょっとズレるともうわからない、そしてまた確認する、という非効率なスパイラルに陥っていたのだと思います。
その学びは今、メンバーに要件を伝える時に役立っています。プログラマーの方が相手であっても、まずしっかり業務背景を伝え、流れを掴んでいただいた後で、特定の部分に入っていく、ということを心がけています。
相手が、自分は技術者なので業務についてはいいんだよ、というスタンスだとなかなか効果が出にくいですが、業務を知ることは日本のIT業界では良いことが多い、と思います。
開発するプログラマーの立場でも、共通化するポイントの勘どころになり、開発性・保守性の改善につなげられますが、それより効果が出せるところがあると思っています。
先日、某コンサルティング会社の社長さんのお話を聞きました。
問題は、業務背景も含めて技術者に伝えてみると良い。既存システムの詳細がわかるので、問題に対する解決策をきっと出すことができる、と。
プログラマーがシステムのロジックを抑えているので、ミクロの世界での１番の有識者、と見ることもできます。業務を知っていれば、そこから業務改革のきっかけを作ることもでき、自身の存在価値を高めることができます。アメリカなどではスーパープログラマーのように、技術のみで上がっていく方が多くいらっしゃるも思いますが、日本だとなかなか難しいのではないでしょうか。
上流工程に軸足を移していくことで、どんどん自分の市場価値を高めていく、という考え方もあるかと思います。
邪険にせず、ぜひ積極的に聞いてもらえたら、と思います。
一方で、パートナー会社への委託は、自分が出来るところまで落とし込んで、それを委託しなければならない、という話を私の周囲ではよく聞きますが、それはベストではない、と思っています。
自分、というか、個人で出来ることはたかが知れています。
スキルのあるパートナーさんに誰でも出来ることだけお願いする、というのはもったいない話です。
相手のスキルアップの場も削ってしまいます。
自分のスキルアップはいらない、とは言ってませんが、チームとしてどうしたらパフォーマンスを最大化できるか、というところに視点があってよいかな、と考えています。
自分はどこでとんがって仕事をしていくのか、それ以外のところは任せるところも大事です。
自身のブランディングとワークライフバランスにも目を向けましょう。
では✋