Step10. 仕事の流儀
仕事を始める上で、大切なことがある。
プロジェクトの納期と、自分の担当箇所を確認すること。
そして、忘れてはいけないのが成果物の整合だ。
プログラマは、最小限のものを作ろうとし、依頼者は最大限のものを期待するのだ。
ポールさんとジン先輩と自分の3人で、OJTの説明ミーティングが開催された。
「このプロジェクトは、国立図書館の本の管理システムを開発しています。わが社にとって大きな仕事で、失敗することは出来ません。サワタリさんには来て早々で申し訳ないですが、非常に期待しています。よろしく頼みます」
ポールさんは説明の後、頭を下げた。
プロジェクトの内容は、以前ジン先輩から聞いていたものだった。
「はい、分かりました。微力ながら尽力いたします。早速ですが、ご質問よろしいでしょうか？」
「どうぞ」
「プロジェクトの納期と現在の進捗、そして私の作業範囲について教えてください」
「納期は一か月後です。進捗は80%とといったところでしょうか。残念ですが、スケジュールは2週間ほど遅れているので取り返さなくてはなりません。サワタリさんにお願いしたい部分は、ジンさんから説明をお願いします」
「おう、サワタリに任せたい部分は、本にユニークな番号を振って、その番号の書籍のタイトル、著者、発売年月日を表示する部分だ。2週間で頼みたい。どうだ出来るか？」
「初めての環境での開発なので、出来るかどうか即答はできません。ひとまず1週間頂けないでしょうか。その時点で進捗報告と厳しければ相談させてください」
ここで根拠なしに出来ますと、即答してはいけない。
言ったら最後、死んでもやり遂げるしかない上に、出来なかった場合には、開発チームに多大な迷惑がかかる。
自信がない部分をはっきり伝えることも開発には大切なのだ。
「「………」」
2人は沈黙している。
このやり方は駄目なのか？死んでもやれ案件のやつか？
「ガッハッハ…いいぞ、それで。そんな事を言った奴は初めてだ。たいていのヤツは、怯えて出来ませんと言うか、虚勢を張ってできます！ といって間に合わずに、尻ぬぐいさせられるパターンがほとんどだ。実に正直で誠実な回答だ。信頼できる！」
ジン先輩は目を鋭くして、関心して答えてくれた。
ポールさんも驚いて目を見開いていた。
ふーっ、ドキドキしたが、良い方向の沈黙だったようで安心した。
地球での開発経験は、生かせそうだ。
「続けてご質問なのですが、本は今後も発刊されていくことを加味して、10億冊程度の本の番号が管理できる仕様でよいでしょうか。またタイトルと著者の制限として、最大255文字までとさせていただきたいのですが、問題ありませんか？」
「「！？」」
さらに2人に驚かれた。
「お恥ずかしい限りですが、確認できていませんでした。国立図書館に確認して回答します。とりあえずそれで作っていただいて問題ありません。……よね？ ジンさん」
「お、おおう。それで頼む」
「国立図書館への確認は、いつまでにしていただけますか？」
「……！？ 今週中にさせていただきます！」
上司が、自分の納期を言わなかった場合は、きちんと確約させておく必要がある。
これを怠ると、仕事そのものを忘れられたり、重要度を認識してもらえない。
「ありがとうござます。では、ミーティングの内容は、メモ用紙にまとめてお渡ししますので、内容に間違いがあればご指摘ください。あとジン先輩、他の細かい部分の仕様については、個別に教えてくださいね」
「承知いたしました……」
「承知したぜ……」
あれ？なんか2人の様子が変わった？
こうして滞りなく、ミーティングは終わった。
しっかりしたコミュニケーションが取れて大満足だ。
このあと、ミーティングの内容をまとめたメモ用紙を3枚作成した。3枚とも同じ内容だ。
決して、観賞用・保存用・布教用ではない。
2人に内容を確認してもらって、間違いなければサインを貰う。そして、自分を含めた3人のサイン入りのメモ用紙を、それぞれに渡しておく。
後で言った・言わないの問題を発生させないための証拠資料だ。メールがあれば楽なのになぁ……
