【ITコラム】プログラミング言語をマスターしたら次に覚えること

初めまして、IT事業本部のいもぽんと申します。244さんのお誘いがあり記事を執筆させていただくことになりました。よろしくお願いします!

今回は、新卒・若手の方向けに記事を書いてみました。ITにあまり詳しくない教育担当の方でも参考になるように書きましたので、ぜひいろんな方に読んでいただければ幸いです。

プログラミング言語を覚えても覚えることがある

新卒でIT業界に入って専門研修を行うとまずプログラミング言語を覚えさせられる、という方が多いかと思います。言語を覚えたら満足していませんか?業務知識とプログラミング言語さえあれば仕事をバリバリ回せるようになる?残念ながら、答えは限りなくNOなのです。

いまどきソフトウェアを一人で設計して、コーディングして、テストして完成! みたいなことはほぼありえないのです。ソフトウェア開発は必ず他人とのコミュニケーションが必要なのです。

コミュニケーション技術を勉強しましょう。

あ、ちょっと待ってください!人と話すのが苦手だから自分は無理とか思わないでください。いわゆるコミュ症だと思っている人でも、勉強すれば得られる普遍的な技術ですので、ぜひ覚えて仕事に活用してくださいね。

コミュニケーション技術とは

お客様とのコミュニケーション

■お客様の作りたいシステムをヒアリングするコミュニケーション能力

お客様向けにシステムを開発する場合、お客様がITに詳しい場合とそうでない場合があります。ITに詳しくない場合は特に注意深くヒアリングする必要があり、聞き出した要件を理解した内容で聞き返し認識にズレがないことを確認します。
そして重要なのは会話をドキュメント化しておくことです。一般的にこれらのドキュメントのうち納品に使えそうなものを要件定義書と言います。

基本的には「ドキュメント作りなんて興味ない」と思っている人が多いのが、開発者のある意味美徳ではあるのですが、ドキュメントを作っておくとエビデンスになるので言った言わない問題という謎の脅しに屈する必要がなくなります。身を守るためにも備忘録としてドキュメントは作っておきましょう。

ところで、なんでビジネスでは何でも横文字にするのでしょうか?「エビデンス」なんて特に、会社から一歩でも離れたら発しない言葉ですよね…

海老でんす?

海老でんす?

■お客様の本当に欲している内容を提案する

お客様は開発側の事情は知りませんし、知る必要もないため、開発リソースを考慮していない場合が多々あります。また、お客様が本当にやりたかったこととヒアリング時に聞き取った内容が意図せず食い違い、結果的にヒアリング内容が嘘になってしまうことがあります。

この場合、業務知識やヒアリング内容全体を俯瞰して少しでも疑問に思うことがあれば、聞き返しや提案を行い、「お客様がやりたかったことはこうではないですか?」と問い合わせなければなりません。お客様が言ったことが必ず正しいとは限らないです。お客様が言ったことだけやればいいと思っていては信頼関係が生まれません。生まれないどころか信頼は崩壊してしまいます。

上記のようなやり取りでしばしば起こりうることをイラスト化した、 IT界隈では有名な風刺画があります。

https://www.businessballs.com/amusement-stress-relief/tree-swing- cartoon-pictures-early-versions/

開発者同士のコミュニケーション

■デザインパターン

システム開発は、大きいシステムになればなるほど複数の会社の開発者が多数集結して、共同開発することがしばしばあります。共通の概念がなければ「これこれこういう処理で、こういう制限があって便利なやつで~」などと⻑い⻑い説明が必要になりますが、デザインパターンを知っていれば、考え方や実装方法が相手に一瞬で伝わります。
世界中の開発者がいろんな場面で何度も実装するような機能は、だいたいデザインパターンの体系で整理されていたり、フレームワークや言語レベルでサポートされていたりすることもあります。
先人の知恵は有効活用しましょう。

singleton1

singleton2

■モデル

こちらはデザインパターンほどプログラミング言語に依存した話ではなく、システム構成の概念を表した用語です。
有名なものにMVCモデルがあります。 基本的な考え方は表示と主処理は分離しようというもので、表示と主処理を繋ぐ制御を合わせた、Model、View、Controllerの3要素でコーディングするモデルをMVCモデルと言います。
プログラミング初心者からの疑問でよくありがちなのが、なぜわざわざ処理を分離する必要があるのかわからないというものです。やり取りが多くなると処理が遅くなるのでは ないか、と。

この疑問も当然のもので、1人で開発できるレベルの小さなプログラムだとなかなか恩恵を受けづらいからです。これを複数人でかつ大規模なシステムを作ることを考えると利点が見えてきます。ざっと利点を挙げると以下の通りです。

  • Modelは複数のControllerが必要な機能をModelで共通化できる。
  • Viewは表示に特化し機能がどのように実装されているか意識することなく利用できる。
  • ControllerはViewからの入力に対して妥当性チェックなどModelに渡す前の処理を行ってどのModelのどの処理を呼ぶか制御する。
  • 上記の各機能は分割しているので分業して作業可能。
  • 修正を行った場合でもほかの機能は修正の影響を受けにくい。
MVCモデルの図

MVCモデルの図

最近ではMVVMモデルの方が耳にする機会が多いかもしれません。こちらも非常によく考えられたモデルなのでぜひ調べてみてください。

■フレームワーク

最近はプログラミング言語と併せて一緒に使うと便利な有名なフレームワークが多数登場し、フレームを使用することが前提となっているプロジェクトも増えています。フレームワークはプログラミング言語の作法とは別にフレームワーク独自の作法があり、フレームワークそのものの学習コストが大きくなっているほどです。
そうなってくると、開発者は「プログラミング言語を知ってます」だけでなく「フレームワークもマスターしてます」というレベルでのアピールが必要なっています。

逆にフレームワークを使うとこれまでより低コストでシステムを提案できます、となると膨大なフレームワークの中からお客様のシステムに最適なものを選択するための情報収集と選択・判断するためのセンスが必要なってきます。これまで手書きで何千行と書いてきた処理がフレームワークを使えば数行で実装できると、開発コストが減るわけです。

最後に

プログラミング言語を覚えた後もプロジェクトに参画するには覚えておかなければならないことが多くあることがわかりますね。
もし、現場でOJTさせれば勝手に技術を覚えてくれると考えている教育担当者がいるようであれば、そういう人を見かけたら今すぐ考えを改めさせましょう。お客様とのコミュ ニケーション、第一印象はとても大切です。
お客様との最初のプロジェクトでしっかり対話を繰り返して認識齟齬をなくし、無事に開発完了すれば次のお仕事にもつながります。逆にコミュニケーション不足でお客様や開発者同士で会話もできなければ技術者としても会社としても信頼を失うばかりです。

新卒の方、若手の方はコミュニケーション技術を習得する絶好のチャンスです。まだ失敗が許される時期です。話す側も聞く側も無駄な時間が減りお客様とも開発者ともコミュニケーションがスムーズになりますし、先人のノウハウをそのまま開発に生かせます。
経験が浅いとつい、開発でも製造部分にばかり目が行きがちな視野が狭くなってしまいがちですが、視野を広げることを意識して仕事をしてみましょう。

そこからいつか、「あっ、それ○○でできるよ!」「そのシステムだとこのアルゴリズムが最適だよ」と言えるようになればもうこっちのものです。

いもぽん
九州生まれだけど地元のことより九州外のことの方が詳しい謎の人。
静かで趣のあるところへ旅行するのが好きです。