いつもお世話になっております。
RfromLです。
今回はSEとしてシステム開発現場に参画したばかりの初期時点で実施するとのちのち役立つ習慣について記載します。
初期時点だけでなく、その現場に参加している間も継続してやった方がいいですが、参画したての頃にに実施しておくと、その現場の文化に慣れる速度に影響するので「現場参画初期」としました。
CONTENTS
1.はじめに
2.ファイルサーバ上の資料を見まくる
3.資料は新規作成で開く癖をつける
4.本番稼働中のソースコードを見まくる
5.開発環境のソースコードも見る
6.おわりに
1.はじめに
SES企業でSE、IT作業員をやっているとシステム開発の現場異動というのは必ず経験することです。
同じIT業界であっても、企業ごとどころか現場ごとに文化が違ったりします。
新人SEの頃で初めて参加した現場が長いと、その現場の文化に気付かないうちに染まっていることがあるので初めて現場異動した時は、少し戸惑うこともあると思います。
今回紹介する習慣を実施していると、新しい現場の雰囲気・文化に早く慣れるようになります。
習慣としてはいくつか紹介しますが、全体的な結論・共通していることは
「その現場で他の人が作成したものを見て自分に取入れる」
です。
2.ファイルサーバ上の資料を見まくる
どこの現場も様々な資料が格納されたファイルサーバが存在します。
このファイルサーバ上に格納されている既存の資料を漁って読みまくるようにしましょう。
理由
ファイルサーバ上には実際に作業している人達、過去に作業していた人達が自身が理解する為に作成した備忘録、メモ的な個人用資料も格納されて具体的な資料が多く実作業レベルで役に立つ情報が残されている。
現場参画してすぐは、その現場に関する説明があるのが普通ですが概要的な話がほとんどです。
これは説明してくれた人が悪いわけでも現場が悪いわけでもないです。
具体的なことは実際に手を動かしながら調べたり、経験したりしていくうちに身についていくものなのでしょうがないことです。
ですが、ファイルサーバ上に格納された資料は、実際に作業している人達自身が理解する為に作成した資料なので、具体的で実践的な内容が書いてあることが多いです。
もともとが個人用資料なのでちゃんと整理されてなかったり、作成した本人が「自分が分かればいい」レベルで書いてあったりもするのですが。
それでも生の資料です。
その現場で必要な業務知識辞典が格納されていたりもして、現場参画初期には役立ちます。
端末ごとに権限が付与されていて閲覧可能なフォルダが制限されている場合もありますが、制限がかかっていないところだけでも漁ってみる価値はあります。
3.資料は新規作成で開く癖をつける
MS-Offce（Word、Excel、PowerPoint）の資料での話ですが、ファイルサーバ上でも自分の作業端末内の資料でも、資料を開く理由が「読むだけ」でそもそも編集する予定が無い場合は「新規作成」で開く。または、一度ファイル自体を自分の端末のどこかにコピーしてコピーした資料の方を開く癖をつけます。
理由
閲覧するだけの資料を誤って更新してしまうのを防ぐ為。
自分の作業端末内の資料もですが、特にファイルサーバ上の資料は沢山の人が閲覧する場合があります。これが誤って更新されていると、影響してしまう人も沢山いるので、誤更新を起こさないように対策をしておく必要があります。
ファイル自体に「常に閲覧モードで開く」を設定されていればいいですが、全てがその設定になっているわけでもないです。
自分で誤更新をやってしまわないように個人でも対策するようにしましょう。
コピーについては説明不要ですが、新規作成で開く方法については以下に記載しておきます。
①開きたいファイルを右クリック
②メニューから「新規（N）」を選択
これで、ファイルが「新規作成」というモードで開かれます。
「新規作成」モードで開くと[Ctrl] + [S]ショートカットキーの上書き保存をしようとしても強制的に「名前を付けて保存」として扱われ、必ず自分で保存操作をすることになるので内容を変えてしまった場合でも誤って上書き保存してしまうことを防げます。
4.本番稼働中のソースコードを見まくる
説明に入る前に注意点として本番環境に接続して実際に稼働中のプログラムを直接見るわけでは無いです。
大体の現場が本番環境のプログラム・ソースコードを本番環境とは別にミラーリングとかで同期・バックアップしています。
見る時はそちら側を見ます。
とにかく、本番ソースコードを読み漁ります。
理由
これは理由として複数あるので、まず以下に列挙します。
- 既存処理修正の際、解析がしやすくなる
- 自分がコーディングする際、現場のルールにあったコーディングがしやすくなる
- その現場で用意されている関数、共通処理などが把握できる
- 他の開発者のソースから使える処理ロジックを発見できる
- 他チームの処理も把握しておくとなにかと有利
それぞれ以下に詳細を記載します。
「既存処理修正の際、解析がしやすくなる」
「はじめに」で現場によって文化があると記載しましたが、プログラムに関しても記述のお作法（ルール）が現場独自であったりします。その現場のソースを沢山みているとそれが頭に入って、修正・障害対応時にこのルールで書かれたソースに見慣れていると解析がやりやすくなるというメリットがあります。
「自分がコーディングする際、現場のルールにあったコーディングがしやすくなる」
現場にもよりますが、コーディングルールがしっかり資料化されているところはいいですが、暗黙的のルール的なものもあるので、自分でコーディングする際は、実際に稼働しているソースから「こういう時はこう書くんだな」とちょっと知っているだけでも、やりやすくなります。
「その現場で用意されている関数、共通処理などが把握できる」
SQLserverの例でいうと、ストアドプロシージャや、ストアドファンクション（以降「ストアド」と記載）などです。
データ調査時でSQL文を考える際にある情報を得るには、結構複雑なSQLを組まないといけないなぁと思っていたら、既に用意されているストアドに特定の値を渡してあげれば複雑なSQL文を組まなくても簡単に済ませられるというパターンは結構あります。
しかもストアドなら本番でも使用されている処理だったりするので、誤ったロジックはよっぽどなく信頼性が高いので、データ調査の精度も担保できます。
「他の開発者のソースから使える処理ロジックを発見できる」
これは現場特有というよりは、自分より開発経験のある人のプログラムは参考になるので、みていると新しい発見があるので、メリットしかないです。
結局どんな本よりも実現場に勝る教材は無いです。
「他チームの処理も把握しておくとなにかと有利」
システム開発は規模が大きくなればなるほど、たくさんのチームに分かれています。
大体が業務（スーパーなどの小売りで言えば、配送を行うセンターとデータやりとりする物流側、取引先とデータをやりとりする受発注、店内で調理する惣菜のラベル印字データを管理する業務 etc…）単位でチーム分けされていますが、色んな業務のデータが絡み合ってシステムが成り立っています。
プログラムを開発する際、自分のチームが担当する業務内だけでなく、上記のような様々な他業務とデータをやりとりするのが普通です。
この他業務とやりとりする際、打ち合わせをしたりして連携をとっていくことがあるのですが、この際に相手側の処理をなんとなく知っていると相手側の説明が理解しやすかったりします。
この理解しやすいというのは、単純に自分の中に情報を落とし込みやすくなるというだけでなく、連携がうまくっていることが継続していくと、その業務との信頼関係も築けます。
（会話が通じないっていうことを嫌う人って結構いますから・・・）
システム開発では他業務に作業依頼とか修正依頼とかする場面もあるので、信頼関係が築けていると依頼とかもし易かったりします。
IT業界に限らずどんな仕事も、人間同士の信頼関係って結構重要です。
5.開発環境のソースコードも見る
これは開発中のソースコードをみるというよりも、開発環境に格納されているツールを見るという意味です。
理由
開発環境には実際に開発しているSEさんが、作成した自分用ツール、チーム内で使用するツールなど様々なツールが格納されていることが多いです。
せっかく便利なツールがあるので、これを活用しない手はありません。
ツールそのままでは自分の作業に使用できなくても、ツール内のコードを見れば流用できるロジックがあったりします。
6.おわりに
今回はぱっと思いついたままに書いたので他にもあったかもしれませんが、思いついた段階で書いてみました。あとでまた思いついたらここに追記するか、追加で記事を書くかするかもしれません。
ファイルサーバの資料を見るだったり、他業務のソースを見るだったりは仕事をしに会社に行っているのでいつもはできないです。仕事の合間に隙を作ってみるようにします。
過去に「新人SEがまず身につけるべきIT業界内ポータブルスキル」という記事を書きましたが、作業を早く済ませて「隙」を自分で作れるようになれば、現場で情報を吸収しやすくなるので、作業を早くするのはこういった所にも影響します。情報が吸収できればより作業も早くなりいい循環になります。
一応、全体の結論については「はじめに」で書いた通り「その現場で他の人が作成したものを見て自分に取入れる」のが大事ということになります。
このブログが新人SE向けにほんの少しでも役立つ情報を！と思って運営しているので、システム開発の現場を想定した記事として書いていますが、上記の結論は基本的になんにでも当てはまることだと思います。
この方針をどこか持っていれば、SEを続けていくにしても仮にSEを辞めたとしてもなんとかやっていくこと、生きていくことは出来るんじゃないかなと思っています。
以上です。
宜しくお願い致します。