信頼はずっと、挑戦はもっと。

お問い合わせ
TEL:03-3496-3888

BLOG コアテックの社員ブログ (毎週月曜~金曜更新中)

2019

14

11月

新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=

テクログ

新人プログラマーが仕事を振られた時にやった方がいいと思うこと =前編=


こんにちわ。パグと申します。

最初に、簡単に自己紹介をすると、私は新人PGではありません。

SIerに出向して5年ほどはスタンドアロン型のシステム開発をしていました。

WEB未経験から、WEBサイト制作をメインとしているコアテックに転職して、7年経過するSEです。


そんな私は、最近新人PGの進捗管理をする機会が多いのですが、

手が止まってしまう新人が多いのを目撃して、また、自分も同じように新人の頃、

手が止まることが多かったので、あの時、こうしてれば・・・と思ったことを前半後半に分けて書いてみました。


仕事って一言で言っても様々で、ツールの講習会開いて欲しいとか、システム(サイト)作って欲しいとか

SQL書いて欲しいとか、社内環境整備して欲しいとか様々なのですが、

今回は、WEBサイト制作に関して、自分の中でルーティン化しているものをまとめます。


(事前準備)

案件アサイン前に、その企業(チーム)の環境などを展開されると思います。

私の場合はどの現場(チーム)に行く場合も大体その現場の言語やツール関連の本を2〜3冊、

知らないフレームワークの場合はマニュアルをざっくりと読んでから、そのチームに参画していました。


1、まずは改修、新規作成のスコープをはっきりさせる


今渡されている作業が、細分化されているものの一部なのか、この案件の全てなのか、

つまり、これを作ったら案件完了なのか、自分が作っても他の人が終わってなければ完了にならないかを認識します。

初めての現場でドキュメントや引き継ぎ事項に「納品物」がはっきりと書いてない場合は、

直接関係者に聞いておきましょう。これは会社によっても会社内のチームによっても異なるからです。


(納品物の例)

・ソースだけで良い

→ソース管理ツールにPUSHしたら終わり

→物理的にファイルが欲しい

→サーバーにアップして欲しい

など

・テスト仕様書も欲しい

→Excelで欲しい

→特定のフォーマットで欲しい

→スクリプトが欲しい

・テスト仕様書にエビデンスも欲しい

→同上

など、納品物も案件によって異なります。


2、自分の担当部分のスケジュールをはっきりさせましょう


渡された期日が、コーディング完了日なのか、テスト完了日なのか、リリース日なのか、

顧客引き渡し日なのかは出向先やチームによって異なりますが、

勝手にスケジュールを引いて間に合わないとなると困るので、自分の作業を完了し、

渡す日がいつなのかって部分を、PM、PLまたは顧客ときちんとネゴって文章に起こしておくといいと思います。

文章に起こすっていうのはチャットでもメールでもいいんですけど、口頭でやり取りした場合

言った言わない問題が発生しないようにするため、

口頭で話をした後に関係者をCCに入れたメールなどで再確認した方がいいです。

それは相手を信頼していないからではありません。自分自身で期日が間違えていないかを再認識するためでもあります。

期日を入れる例は以下のとおり。

——

X月X日X時 コーディング、単体テスト完了

X月X日X時 受入テスト

X月X日X時 リリース日

——


3、大枠の作業の洗い出しをします


すごいざっくりとした作業工程の洗い出しをします。

今回はWEBサイト制作のPGのフェーズなので、簡単に以下のような行程に分かれるかと思います。

・詳細設計

・CD

→作成する機能の大枠を考える

・単体テスト

・結合テスト


4、現行システムを把握する


お見積もりを作るような立場の人だと、現行システムを把握するのは、スケジュールを切る前にやりますが

PGでしたら、案件開始前に把握できれば良いかと思います。

運用案件の場合、渡された仕様書以外に修正が必要な点がないかを把握することが大事です。

それによりスケジュールの達成可否が大きく変わるためです。


・現行システム全体を把握

→このフェーズでは全体像をざっくり捉えるのが大事です。

→インフラ構成だとか

→全体画面数だとか

→TBL構成だとか


・機能追加部分の現行ソースを読む

→コード規約だとか

→命名ルールだとか


・案件進行ルール


を把握しておきます


5、終わるのか終わらないかを考えてみる。


ここまでで、X月X日までに何を作らないといけないかってところが割と具体的になっています。


スケジュールが鬼のようにきつい案件も勿論たくさんあります。

その場合は、「できない」っていう勇気が大事です。

私が経験した企業は10社あるかないか(上場企業から20名程度の小さな会社まで規模は様々)ですが、

どの企業様でも、仕事なんだからできないっていうな、とか

体育会系的なことを言われることはありませんでした。


伝える際には、


・ここまでなら終わる

・X日あれば終わる

・なぜ無理なのか


を具体的に伝えてください。ただ「こんなんおわんないっす〜」では伝わらないのでダメです。

これとこれは終わりますが、この部分だけ、後出しにしてくださいなどの提案がないと、

PL(PM)もじゃあどれくらいやってもらえるのかな?というのを想像できないためです。

ちなみにこの工程は、残業時間を含めない状態で考えた方がいいです。

残業すれば終わる工数というのは、すでにスケジュールに無理があるからです。

————————

最後に

プロジェクトのリーダーは作業をふるときに通常、作業が終わらないことを想定して、

保険をかけながらスケジュール作成しますので、

自分で無理かもしれないと思ったときには、正直に伝えてもらったほうが予定を組みやすいです。

仮に、できる!と思って作業を始めても、終わらないと思った時点で、速やかに伝えることが大事です。

渡された仕事が仮に全て終わらなかったとしても、自分でそれを伝えられていれば、

あなたの評価が下がることはありません。周りの人が巻き取ったとしても、それはあなたの責任ではありません。

新人のうちは、他者と協力しながらでも良いので、自分でできることを、

できる限り順番にこなしていく、というのを意識して仕事をします。

もちろん、そんなに優しくない企業もシチュエーションも沢山あると思いますので、思い通りにいかないことも

理不尽なことも沢山ありますが、誠意を持って対応することで、理解してくれる上司や同僚は、多いと思います。



次回は具体的にコーディングや設計に入るところを記載していきます。

ではまた・・・。

この記事を書いた人

マスオさん

パグ

所 属:
WEBインテグレーション事業部
出身地:
田舎
仕事内容:
システム開発