【新人エンジニア必見】現場で重要とされるコミュニケーションって何?

※本サイトはアフィリエイトリンクを掲載しています。
新人エンジニア

この記事の信頼性

こんにちは。Web系エンジニアのカズです。数年前に未経験からプログラミング学習を始めて転職し、現在は単価80万円~90万円の案件を受注して活動しているエンジニアです。

エンジニア歴は約7年になります。使用言語やフレームワークは以下です。

・HTML 7年

・CSS 7年

・Javascript/jQuery 7年

・PHP 7年

・Typescript.js 3年

・laravel 5年

・Vue.js 4年

・React.js 3年

本記事では「新人エンジニア」のいわゆる「プログラミング学習をしてエンジニアになりたての方」へ向けて、お役に立つ情報を発信したいと思います。

プログラミング学習を経て現場に入る皆さんは、ポジション的には「プログラマー」として参入することが多いのではないでしょうか。

プログラミング学習をして「エンジニア兼プログラマー」として現場に入る方へ向けて、こんな呼びかけを見たことはありますか。

・エンジニアはプログラムを書くだけが仕事ではない

・エンジニアにはコミュニケーション能力が必要だ

この2点はどちらも大切なことです。
ですが、このコミュニケーションとは具体的に何を指しているのでしょうか
本記事では、現場で重要とされる「コミュニケーションとは具体的に何なのか」という点について触れていきます。
「私の思う」Web系エンジニア(プログラマー)に求められるコミュニケーションなので、参考までに見て頂ければと思います。
対象の方は、プログラミング学習をして現場に入る「新人エンジニア」と呼ばれる方々へ向けて発信します。現場のポジション的にはプログラマーに該当すると思います。(Web系)

本記事の内容

・よくありがちな基本的なコミュニケーションとは?

・現場で求められている「エンジニアに必要なコミュニケーション」とは具体的に何か?

 

よくありがちな基本的なコミュニケーションとは?

・挨拶をする

・相手の視点で物事を考える

・要点から伝え、話し方が上手である等

もちろん基本的なことですし、重要です。
ただ本記事で伝えたいことは、この類のことではありません。

 

「エンジニアに必要なコミュニケーション」とは具体的に何か?

前提として、新人エンジニアの皆さんがコミュニケーションをとる相手は具体的に誰でしょうか。
基本的にはチームのリーダー的位置の人と、チーム内のプログラマーの人とコミュニケーションをとることが多いのではないのでしょうか。
それを踏まえて、新人エンジニアの皆さんが出来るようになるべきコミュニケーションとは以下です。

・報連相

・質問力(仕様や要件について)

・提案力(仕様や要件や汎用的なソースコードについて)

 

報連相

ありきたりと思うかもしれませんが、具体的に書きますね。

報告とは主に下記です。

報告の具体例

  • 1日のタスクの進捗報告
  • タスクが完了するであろう見積もり
  • 自分のタスクとは別の範囲だとしても、画面のエラーが見つかった(原因もできれば添えて)

多くの現場では、進捗報告ミーティングが1日に1度あると思います。

その際に、タスクの進捗などについて報告すると思うので正確にお伝えしましょう。

それが例え、進捗が悪くてもです。

進捗がなかったのであれば、どこで詰まってしまったのかどこまでは理解できているのか何を調べたのかを伝えましょう。多くはプロジェクト管理ツールを使用しているはずなので、自分のタスクチケットに事細かに記しておきましょう。

そうしておくことで、どうしても解決できない場合にチームの方が手助けしてくれやすくなります。

連絡とは主に勤怠などでしょうか。これは基本なので、抑えておきましょう。

そして最後に相談です。どうしても、自分では解決できないこともあります。

その際は納期ギリギリではなく、スケジュール感を意識してチームの誰かに相談しましょう。

質問の仕方については、別の記事のこちらを参考にしてもらうと良いと思います。

 

質問力(仕様や要件について)

主に現場でエンジニアに求められているコミュニケーションで差がつくのは、この仕様についてのコミュニケーション能力です。

では適当に考えた例題を挙げてみます。例えば、あなたの現場がブログ投稿ができるサービスを開発していたとしましょう。(私は今ちょうど記事投稿をしているので参考に思いついた例題です。)

既にブログ投稿の機能は備わっているが、「管理者権限のアカウントを作成できる機能がないので作成してほしい」という新規開発のタスクが振られました。

しかし、このタスクには不明瞭な要件がいくつかあります。下記のようなワイヤーフレームと仕様が送られてきました。

ワイヤーフレーム(イメージ図)

要件①ワイヤーフレームのように項目を登録できるようにしてほしい

要件②権限レベルは一旦プルダウンで「システム管理者」だけ登録できるようにしておいてほしい

これ以外の要件は何もヒントもなく、分からない状況。と仮定しましょう。

権限レベルとはおそらく、レベルによって閲覧できる画面や操作可能な画面が異なるのだろうという推測は立ちます。それは本タスク範囲外として一旦置いときます。

それ以外で何か疑問に思う点はありますでしょうか。

 

私が思う、仕様の疑問点

①この画面はどこから遷移して閲覧できる画面か?
おそらく管理者アカウント一覧画面からくるのであろう。
それは今後作成する予定?

②一覧画面があると仮定すると、削除機能や編集機能もある想定?

③一覧画面があると仮定すると、登録完了したら画面遷移先は一覧画面で良いか?

④権限レベルは今後も増えていく想定?
であれば、DBを新規作成してデフォルト値を設定する必要があると推測。

一覧画面があるとすると、一覧画面から登録画面に遷移する時にkeyとなるパラメータ(例:ID)を渡して登録画面や編集画面を表示する形になるのが、分かりやすいやり方かなと思います。

そのkeyを元にDBにデータを新規登録、または編集、削除の処理を加えますよね。っていう構想が思い浮かびます。

これらの認識が合っているのか、slackのチャットや通話で会話して仕様が不明瞭な点をできるだけ事前になくしましょう。

この不明瞭な点について、仮設を立てて質問をしながらやり取りすることが必要なコミュニケーションだと私は認識しています。(あくまで一例です。)

仕様が固まれば想定されるプログラムやデータベース構成も見えてくるので、工数の算出もおおよそできて、大体これくらいにタスク消化できます。みたいな話もできますね。

 

提案力(仕様や要件や汎用的なソースコードについて)

仕様の提案については先程の「一覧機能」「編集」「削除」は付けるか?のような話とダブりますが、もし依頼者が想定していなくて工数に余裕があれば提案してみるのも良いと思います。

というのも登録機能しかない想定でプログラムしたのに後で、「一覧機能が欲しいです」となってしまう方が工数が逆に増えてしまうんですよね。

なので、依頼された画面への考慮漏れがないか。という視点を持って会話できるのが望ましいです。

ソースコードについては上記の例で言うと、例えばLaravelであれば権限レベルの情報を保持するDBを作成してSeederで初期データを挿入するのが良いでしょう。

今後権限レベルのプルダウン項目は「システム管理者」以外に増える可能性がありそうですからね。

みたいな提案ができると良いでしょう。提案というか「普通そうするよね」っていうレベルかもしれませんが。

アプリ開発を自分でしてみて仕様や設計を考慮する訓練をすると、これらの力が付きそうですね。

コメント