入門書と実際の業務の違いとは。
はじめに
プログラミングを覚えるにあたって、皆さんはどのように勉強してきたでしょうか？
私は自費で入門書を買って勉強したり、ドットインストールという動画サイトに課金して勉強していました。
最近はYoutubeの動画配信で勉強することも多いです。
プログラミングスクールに通ったり、専門学校で習う方もいるでしょう。
どんな教材であれ、プログラマーとして採用された皆さんは何かしらの言語を多少なりとも身につけ、教材どおりのプログラムを動かすことができるようになっていることと思います。
さて、数週間の研修期間を終えたあなたは出向の面談に受かり、ついに業務案件に携わることになります。
そこであなたはいくつかの大きな壁にぶつかるかもしれません。
非常に小さな案件ばかりに当たる方もおりますので全員ではありません。
環境構築ってめちゃくちゃ難しい。
入門講座だと、はじめから仮想環境が用意されていたり、プレイグラウンドといって、好きにコード書いて試せる環境があったり、そもそも環境構築が不要だったりします。
また、環境構築が必要な場合でも、まっさらな状態からなので、講座の通りにやれば動かせる場合が多いです。
講座の対象OSがwindowsなのにmacユーザとかだと苦労しますが。
しかし、業務では他人がこれまでつくってきた環境に合わせて、秘伝の味付けのような、そのプロジェクトの関係者しか知りえない設定ファイルやデータベースの値の変更などが必要になります。
特に出向者は自分の慣れしたんだパソコンが使えず、エディタを含めた全てのツールが会社指定だったりします。
大きな会社だと環境構築マニュアルが用意されています。
安心してください、その通りやっても動きません。
なぜなら、マニュアルができた時とは状況が変わっていたりしますし、パソコンを使い回すので引き継いだ時点で既にインストールされているアプリやライブラリが汚染したりしているからです。
ですから、日頃から環境を作ったり、壊したりしてトラブルに慣れる訓練をしておかないとパニックになります。
あと、環境構築はものすごく難しくて、動かないのが当たり前だと知っておくことです。
一人で抱え込まずに、ある程度やってだめなら先輩やリーダーに聞きましょう。
規模に圧倒される
入門書と、業務の一番の違いは物量です。
ファイル数、ディレクトリ数も１関数あたりのコード量もまさしく桁違いです。
例えば入門書に載っているSQLはこんな数行のものが多いです。
SELECT name, age, city
FROM employees
WHERE department = 'Sales';
でも業務では数十行とか、100行以上とか、バンバンでます。
記事が長くなるので50カラム程度を例にしてみましたが、どうでしょう？
急に難しくなってきた気がしませんか？
項目増やしただけなんですが。
SELECT
M_store.store_name, M_store.tel1, M_store.tel2, M_store.tel3,
M_location.address, M_location.city, M_location.postal_code,
M_store.opening_hours, M_store.manager_name, M_store.num_of_employees,
M_store.created_at,
M_location.latitude, M_location.longitude, M_location.region,
M_store.category, M_store.rating, M_store.website,
M_location.country, M_location.timezone, M_location.created_at
FROM
M_store
JOIN
M_location ON M_store.location_id = M_location.id
WHERE
M_store.created_at > '2024-10-05'
AND M_location.city = 'Tokyo';
JavaBeanなども1ファイル500行以上とかになるので、大したこと書いてなくても難しく見えてアレルギー出ます。
これに慣れるには、キーワードを抜き出して入門書に近い量に減らして考えてみることです。
そうすれば1000行のSQLも恐れる事はありません。
嘘です。大変です。
修正箇所をうまく検索するスキルが必要です。
デバッグが難しい。
規模が大きい事からの派生になりますが、入門講座とはデバッグ難易度が全く違います。
そもそも講座では正解のコードがあって、自分が一字一句書き写せばいいわけで、動かない原因は写経のミスです。
しかし、実際の業務案件では答えなどありません。
なぜなら、その答えを作るのがあなたなんですから。
というわけで、デバッグスキルを身につける必要があります。
私もまだまだですし、どんな高レベルプログラマーでも、そのレベルでの壁があります。
とはいえ、コツもあるので、そういう知識や経験を増やすことで詰まる箇所を軽減することは可能です。
これについては別記事に書こうと思います。
※たまに、ものすごく誤字脱字の多い著者もいます。ひどいことにLaravelやVue.jsの入門書でトップクラスの販売数を売上ている著者が間違ったソースコードを大量に掲載している。
コーディング作法がある。
入門講座では、自分の好きなようにログを出力したり、変数やクラス名も好きなように命名しても問題ありませんでした。
しかし、業務案件では出していいログは決まっている場合があります。
変数名やクラス名は命名規則の通りにしなければいけないし、似たようなコードが既にあるなら先輩たちのコードに合わせて命名しなければいけません。
コメントの記法も決まっていたり、
高いコミュニケーション能力が必要
エンジニアに必要なコミュニケーション能力ってなんだと思いますか？
スポーツやゲームで一緒に遊んだり、飲み会にいったり、雑談したり？
一般的には、それも大切なコミュニケーションですね。
でも、ここでいうコミュニケーション能力とは以下のようなものです。
- 相手の要望を正しく理解できること。
- 認識がずれないよう、体系的・論理的に説明できること。
- 相手が理解できるように噛み砕いて伝えられること。
- 相手が理解したかすること。
などです。
例えば何か質問やお願いをするとして、
「昨日いってたアノ件ですが・・・」とか、「アレ、どうなった？」とか。
アノってどれ？アレって何？
ってなりますね。
じゃ、これなら？
あの -> slackでAさんから来ている、xx月xx日の13:54分の指示
あれ -> BプロジェクトのBacklog課題番号150万
どうでしょう、認識のズレを抑制できそうに思いませんか？
ようするに、話の範囲を具体的に特定して、指示代名詞は控えましょう、ということです。
株式会社ONE WEDGE
【Serverlessで世の中をもっと楽しく】 ONE WEDGEはServerlessシステム開発を中核技術としてWeb系システム開発、AWS/GCPを利用した業務システム・サービス開発、PWAを用いたモバイル開発、Alexaスキル開発など、元気と技術力を武器にお客様に真摯に向き合う価値創造企業です。
Discussion