初現場でのわからないこととその対策を具体的に紹介！

#初現場でのわからないこととその対策を具体的に紹介！

はじめに

私が初現場で体験した「分からない」についてご紹介したいと思います。この記事を読むことで、未経験者として具体的にどういった準備をしておけばいいのかということを知ることができるようになるかと思います。できるだけ具体的に記載をすることで現場のことを少しでも想像できるように気をつけていますので、新しい発見をすることができるのではないかと考えています。
また、専門用語などはできるだけわかりやすく説明しますのでご安心ください。

初現場について

私の初現場は、発注システムのマイグレーション開発でした。ここで言っている「マイグレーション」とは、既に存在するシステム新しい環境に移行することを指しています。
私の現場では主に以下のような特徴がありました。

・既存システムと全く同じ作りではなく、お客様から新機能の追加や新しいデザイン等の要件があり、単純に過去の設計書をコピーするものではなかった
・既存システムを熟知している人が少なく、既存システムの正しい仕様について理解できている人が少なかった

そもそも開発には開発方法・工程がいろいろありまして、今回は、ウォーターフォール形式の開発で、工程としては、以下のような流れでした。ちなみに、ウォーターフォール形式は、上流工程から下流にそって順番に開発を進める手法のことです。

要件定義→基本設計→詳細設計→製造（プログラミング実装）→製造（単体テスト）→内部結合テスト→外部結合テスト→総合テスト

それぞれの工程について私なりに簡単な言葉で説明すると、

・要件定義
お客さんがどういったことをしたいか、その全体方針や、作ってほしい画面のデザインや機能を日本語で整理すること

・基本設計　
要件定義に基づき、具体的にどういったことができる画面かをフォーマット（画面定義書といったりします）に日本語で定義していくこと

・詳細設計　
基本設計をもとに、画面定義書をもとに、どうやってプログラミング実装するかについての詳細を設計書に定義していくこと

・製造（プログラミング実装）　
詳細設計をもとにプログラミングで実装すること

・製造（単体テスト）　
単一の画面で、ボタンなどがちゃんと正しく機能しているかを確認すること

・内部結合テスト　
画面間で、ちゃんと正しく機能しているかを確認すること

・外部結合テスト　
実際の業務での一連の流れが正しく行えるかを確認すること

・総合テスト　
お客さまが実際に使ってみて、正しく利用できるかを確認すること

開発工程など、詳細につきましては、こちらなどを参考にしてみてください。
現場によって開発方法・工程は異なります。「開発ではこんな流れでやるのかぁ」くらいの理解でとりあえずはいいかと思います。

私は、この中の工程のうち、基本設計と内部結合テストを主に担当し、訳１年間開発パートナーとして勤務していました。ここで言っている開発パートナーというのは、SESという働き方のことを指しています。SESとは、パートナーとしてクライアント会社（開発を依頼する会社のこと）が担う開発を代わりに請け負う働き方のことです。
SESの詳細については、今回は目的とは異なるため割愛します。
具体的な業務内容は、

・基本設計：要件定義署（画面のレイアウトや、表示されている項目の説明が載っているもの）や既存システムの設計書から、画面に表示される項目を一個一個、定義書に定義して、仕様を決めていく
・内部結合テスト：発注ボタンを押した時に、次の画面にちゃんと指定した発注数が正しく画面に表示されているのか？またはデータベースにその情報を正しく反映しているか？などの確認

などを行いました。

何が分からなかった？

・ツールの使い方が分からない
・定例ミーティングで話していることが何を言っているのかが分からない
・チャットで送られてきたことが何を言っているのか分からない
・お客さんに質問をする適切な文章の作成方法が分からない
・障害を発見した時の対処法が分からない
・手順書通りやったのにうまく環境設定ができない
・画面の仕様を決めたいが、どんな仕様にすればいいかが要件定義書や既存システムの設計書から読み取れない

などが挙げられます。
正直すべて分からなかったです。私はもともと飲食店でしか働いたことがなかった身でした。ある程度独学で学習は行なっていましたが、基本設計分野などの工程の学習は行ったことがなかったので、すべてのことが新しかったです。一番初めに躓いたのはZoomの使い方でしたね。私が作成した画面定義書のレビューをクライアント企業に説明する際、画面の共有方法がうまくいかずに、チョーテンパっていました（笑）。

何を感じた？

最初の１ヶ月は、分からないことを質問するのが怖かったです。怖くて分からないことを聞けなかったです。
聞くことで「そんなこともわからないの？」みたいに思われて、プライドが傷つくことを恐れていたんだと思います。それから、相手の時間奪ってしまうんじゃないかとも思っていましたね。
また、やったことがないから、自分がやってみてうまくいかなった時に、できないと思い込んでしまうことがよくありましたね。「できない」を前提にしてしまい発想の転換がなかなかできませんでした。
そのほかにも、どこまでやってよくて、どこまではやっちゃいけないんだろう？という裁量がわからずに苦しんだこともありました。あとは、お客様に質問するとき、わかりやすく伝えるために神経を結構使うことによる、質問することのハードルの高さがあってできるだけ質問したくないなぁと考えたりもしちゃいました。

対処法

問題解決のための第一段階は、聞くことです。

・ツールの使い方が分からない
→使い方を聞く

・定例ミーティングで話していることが何を言っているのかが分からない
→もう一度聞く

・チャットで送られてきたことが何を言っているのか分からない
→相手に自分が理解できていないと伝える

・お客さんに質問をする適切な文章の作成方法が分からない
→適切な文章内容を聞く

・障害を発見した時の対処法が分からない
→対処法を聞く

・手順書通りやったのにうまく環境設定ができない
→設定方法を聞く

・画面の仕様を決めたいが、どんな仕様にすればいいかが要件定義書や既存システムの設計書から読み取れ
ない
→既存システムを知っている人に聞く、画面の仕様をお客様に聞く

「わからないことは聞けばいい」なんてことは誰でもわかっています。そうじゃないんですよねー。
未経験者にとって、聞くことってとても怖いんですよね-。さきほどもお伝えしましたが、聞くって言うのは勇気がいることで、心理的ハードルが高いからです。

分からないことを聞く時のスタンス

分からないことを解決することの重要性を理解した上で、適切に対応しましょう。その上で、マインドセットを作り、質問する際の心理的負担を和らげましょう。

堂々と開き直ること！（バァーン！！）

がオススメです。
「俺の考え方は未経験なんだから浅い」「何も分からないんだから聞いて当然！」というスタンスですね（笑）

ただし、最低限の礼儀は必要ですよ！さすがに上司にずっと質問して不当に時間を奪うことはだめですからね。あくまで心構えということを注意してください。
私は、はじめの１ヶ月間の働き方を見直し、この考え方を採用しました。質問をバンバンするようになったころからうまく仕事ができるようになったと実感しています。

分からないことを適切に対応する

以下に気をつけることが大切です。

・できるだけ早く認識合わせを行うこと
・自分の認識を相手に伝えた上で聞くこと

できるだけ早く認識合わせを行うこと　 →　【分からないことを聞くことの重要性を理解する】

分からないことを解決することの重要性を理解しましょう。
分からないことを放置すると、進捗率に影響したり、大きな失敗につながる可能性があります。
例えばということで以下のようなケースがあります。

プログラミングの設計の早い段階で、分からないことがあったが、放置していた。その後、完成間近になって、エラーが発生していることに気づいた。お客様への納期はもうすぐだ。プロジェクトチームは、うまく動作していない部分について、障害表を起票して緊急対応を行った。
調査の結果、実は自分が設計していたプログラミングの設計ミスによるエラーであることが判明した。チームは設計を行った人（私）と設計ミスについての認識確認を行い、修正をおこなった。その後、修正したプログラミングのソースを新しいバージョンとして、リリースをし、修正されたことの動作確認を行うという対応をし、障害表をクローズした。

こんなことやってしまったら、自分が早期に聞いて、解決さえしていれば、こんなことやらなくてよかったのに・・・
とちゃんと後悔します。ハードウェアの設計であれば、最悪死人が出るなんてことも。
また、先ほどの例は設計の放置でしたが、認識のずれの放置などもあります。実は自分の考えていることと、上司の考えていることが違ったまま画面定義書を設計していたなんてこともあったりして、上司の画面定義書の指摘がうまく納得できなかったりなんてこともよくあります。

自分の認識を相手に伝えた上で聞くこと → 【問題解決に責任を持つ】

実は、質問をする際は、「対処法」で記載したことを行うだけではダメです。こちらの記載は質問する時の第一歩として、記載を行っただけです。
単純に分からないことを聞くだけだと、自分は問題を解決することに責任を放棄しているように上司に捉えられる可能性があります。以下を意識しましょう。

・ツールの使い方が分からない
△使い方を聞く
○使い方を試した上で分からない部分を聞く

・定例ミーティングで話していることが何を言っているのかが分からない
△もう一度聞く
○何が分からないのかを明確にした上で聞く

・チャットで送られてきたことが何を言っているのか分からない
△相手に自分が理解できていないと伝える
○自分の理解していることを伝えた上で聞く

・お客さんに質問をする適切な文章の作成方法が分からない
△適切な文章内容を聞く
○自分なりに文章を考えた上で聞く

・障害を発見した時の対処法が分からない
△対処法を聞く
○障害についての状況を確認した上で適切な対処法を聞く

・うまく環境設定ができない
△設定方法を聞く
○手順書通りやってみてうまくいかなったところを聞く

・画面の仕様を決めたいが、どんな仕様にすればいいかが要件定義書や既存システムの設計書から読み取れ
ない
△既存システムを知っている人に聞く、画面の仕様をお客様に聞く
○自分がどういう認識であるかを考えた上で聞く

まずは自分で調べてから聞いてみると言うことですね。適切な調べ方とかは今回は省略しますが、自分なりに調べたことが相手に伝わるように気をつけることが大切です。

※要件定義書をちゃんと見れば答えがわかるんだけど、特定のバイアスがかかっている時などは、「対処法」のレベルで聞いたとしても、有効なことがあるので、まずは「聞くこと」から始めるのもアリです。

アクションプラン

具体的アプションプランとして、「２割共有」を提案します。

タスクの進捗率が２割進む度に、報告をしようというやつです。こちらは分からないことを聞く際に利用できます。
使い方としてはシンプルで、分からないことに対して、まずは自分で２割程度考えてみる。その後、考えている大枠が合っているかを上司に確認する。
これを実践すれば、

・できるだけ早く認識合わせを行うこと
・自分の認識を相手に伝えた上で聞くこと

を実施できますし、上司のスケジュールの見直しにも有効です。
まぁ簡単に言うと、細かく共有はしようねってだけなんですけど。

私は最近まで「２割共有」のことを、はじめの２割だけを素早く共有することであると勘違いしていました（笑）
今後は、その後もちゃんと共有できるように気をつけようと思います

おわりに

ここまで、いろいろ書いてきましたが、
結論コミュ力大事って話ですね。未経験者にとてって、現場はとても緊張しますが、コミュニケーションを大切にすること。これだけやっておけば勝手に成長してきますので是非実践してみてください。
今後もいろいろ投稿していきたいと思いますのでよろしくお願いします！
ここまで読んでいただきありがとうございました！