こんにちは。西日本テクノジー&イノベーション室所属、入社 1 年目の岡﨑です。
最近ボーナスが入ったため、新しいキーボードとマウスを購入したのでテンションを上げながら記事の作成をしています。
私は学生の頃は情報理工学を専攻しており、簡単なプログラミング経験はある状態で入社をしました。そこで、1 年間仕事を行った中で感じた学生の頃との違いと学んだことについて、ここでお話をしたいと思います。

はじめに

  1. この記事に書かれていること
    学生としてプログラムを作ることと、仕事としてプログラムを作ることの考え方の違いを私が実際に体験した 3 つのエピソードを交えてお話をさせていただきます。それぞれのエピソードで得た教訓は下記の 3 つです。

    • QCD(※) 全てを考慮した最適な選択を取る必要がある。
    • 誰が読んでも意図が分かるコードを書く必要がある。
    • 自分の状況を周囲の人へ発信する必要がある。

    (※)QCD とは・・・ビジネスで重要な要素を挙げた標語の一つで、“Quality” (品質)、“Cost” (費用)、“Delivery” (納期)の頭文字を繋いだもの。-IT 用語辞典 e-Words より引用

  2. こんな人におすすめ
    ・ 学校で情報技術を学んでいる/プログラミング経験があるが、学生時代の開発と仕事の開発の違いを知りたい方
    ・ 仕事における先輩や上司とのコミュニケーションの具体的なイメージを持ちたい方

    プログラミング経験が無い学生の方におすすめの記事
    (新人 SE が 1 年で経験したこと・躓いたこと・学んだこと:https://fintan.jp/?p=5187)

QCD 全てを考慮した最適な選択

私が初めてプロジェクトに参加した時の話です。△△△ という問題を解決するための案を考えてほしいと言われたので △△△ を解決できる XXX という案をチームリーダーに提案しました。こちらはその時の会話です。

私「△△△ を解決するには XXX を実装すると良いと思います」
チームリーダー「たしかに XXX は良い案だと思うけど、時間がすごくかかるよね?」
私「(良い案だったら OK じゃないの・・・)」

この時、私は案を考える際に、その案を実現するための時間やコストを全く考えていませんでした。その結果、私が提案した案はユーザーの使い勝手を考えると良い案でしたが、時間やコストを考えると使い勝手はあまり変わらない他の案の方が適切な内容になっていました。

行ったこと

案ごとの特性を表にまとめ、どのような点で良いか、また、どのような点で悪いかを可視化しました。

使いやすさ かかる時間 コスト 難易度
案 A
案 B × ×
案 C

表にまとめることによって、どの案が一番適切かを客観的に分かるようになり、また、提案する際にもなぜその案にしたのかの説得力や納得感が上がりました。

学生の頃との違い

学生の頃は時間を気にせずに、プログラムの作成を終わるまでやり続けるということができました。しかし、仕事になるとお金が発生するため、限られた費用と納期の中で最大限品質の高いプログラムを作成することが大事になります。

以上のことから、品質だけを気にするのではなく、QCD 全てを考慮した最適な選択を取る必要があることが分かりました。

誰が読んでも意図が分かるコード

私が初めて仕事でプログラムを作成した時の話です。プログラムの作成が終わり、設計書通りにプログラムが動作していることが確認できたので、チームリーダーに作成したプログラムを見てもらいに行きました。こちらはその時の会話です。

私「よし、設計書通りにプログラムが動いている!!」
私「チームリーダー、プログラムを作成したので確認お願いします。」
チームリーダー「設計書通りに動いているけどこれじゃあ意図が他の人に伝わらないね」
私「(意図ってなんだ?)」

この時、私はプログラムを作成する際に、動くか動かないかでしか考えておらず、無駄なコードを書いていたり、処理を記述する位置が悪かったりしました。 その結果、私が書いたコードを他の人が読んだ時に何をしようとしているかが伝わらないプログラム(保守性(※)が低いプログラム)となっているため、やり直す必要が出てきました。

(※)保守性とは・・・保守性とは、機器やソフトウェア、システムなどが備える特性の一つで、所定の条件で修理や交換などの保守作業を実施することで、機能や状態が維持される性質。また、その容易さ。-IT 用語辞典 e-Words より引用

行ったこと

保守性が高いプログラムを書けば良いことは分かったのですが、その書き方が分からなかったので、先輩たちにコードの書き方について質問する場を週に 1 回作ってもらうことにしました。そこでは、私が書いたコードについて説明を行い、先輩たちならどのように書くかを聞いたり、コードの書き方に複数の選択肢があり、どの選択肢を選ぶのが良いか聞いたりしました。

例:css を書く時にかたまりごとにクラスを作成するのか、クラスを作成してから各かたまりに割り当てていくのかではどちらの方がよいか

① クラスでまとめる ② クラスに付与していく
HTML
<dic class=”title”>登録内容</div>
<dic class=”content”>メールアドレス</div>
<dic class=”content”>パスワード</div>
HTML
<dic class=”fs20 fw700 colorRed”>登録内容</div>
<dic class=”fs16 fw400 colorBlack”>メールアドレス</div>
<dic class=”fs16 fw400 colorBlack”>パスワード</div>
css
.title {
font-size:20px;
font-weight:700;
color:red;
}
.content {
font-size:16px;
font-weight:400;
color:brack;
}
css
.fs16 {font-size:16px}
.fs20 {font-size:20px}.fw400 {font-weight:400}
.fw700 {font-weight:700}.colorRed {color:red;}
.colorBlack {color:black;}

① はかたまりに対してクラスを設定するため、同様の箇所に修正があった際に一つの css クラスを修正すればまとめて修正することができる。それに対して、② の場合はクラスを設定しておき、かたまりに対してクラスを付与しているため、同様の箇所に修正があった場合は全ての html に書かれているクラスを修正する必要がある。そのため、この場合では ① の方が適切である。

学生の頃との違い

学生の頃はプログラムの作成を行うのも自分一人、プログラムを使用するのも自分一人だったため、とりあえず動けばそれでいいという気持ちでした。しかし、仕事でプログラムを作成する際には複数人で作成を行う上に、自分が作成した部分を今後、他の人が修正することがよくあります。なので、誰が読んでも理解できるプログラム、つまり、保守性の高いプログラムを作成することが大事になります。

以上のことから誰が読んでも意図が分かるコードを書く必要があることが分かりました。

自分の状況を周囲の人へ発信する

私がチームで作業をしている時の話です。チームで 1 つの web サイトを作成することになり、同一ページを複数人で作成することもありました。こちらはその時の会話です。

私「XXX の部分完成しました!!」
先輩 A「そこはもう終わってるよ」
私「・・・分かりました。」
~別の日~
私「XXX の作成が終わりました。チェックお願いします!!」
先輩 B「XXX の部分は共通化してあるから、共通化しているものを使おう!」
私「・・・分かりました。」

私「(なんか無駄が多い・・・)」

この時、チームメンバーとコミュニケーションをあまり取っていなかったため、私が何を行っているのかが先輩に伝わっていなかったし、先輩が何をしているのかを私も分かっていませんでした。その結果、お互いが同じ作業をしていることもあり、無駄な作業が多くありました。

行ったこと

チームメンバーと状況を共有して無駄な作業を減らすために以下のことを行いました。

  • 自分が行った作業を文面で残す
    → 自分が行った内容や口頭で話した内容を文面で残すことで、勘違いを防いだり、後で見返すことができるので話した内容を忘れることを防いだりすることができます。
    具体例:作成したプログラムを先輩に見ていただく際に、依頼のメッセージと共に、修正した箇所や作成した内容についても文面で送りました。
  • 質問の仕方やタイミングを工夫
    → 気になることや分からないことは後回しにせずにすぐに口頭やチャットで質問を行うことで、やり直しの回数を減らすことができます。また、質問をする際は事前に現在の状況、疑問を解消するために行ったこと、自分の考えをまとめておき、回答者が答えやすいように質問をすることを心がけていました。 具体例:業務を進めていく上で気になることがあればその日のうちに先輩に質問チャットを送ったり、zoom で会話をさせていただく時間を確保していただいたりしました。
  • 朝会(※)でチームメンバーに共有
    → 個人間でのやり取りでも、チームメンバーに共有しておくべき内容は朝会時にチームメンバーに話をしました。そうすることによって、チーム内での認識の齟齬を防ぐことができます。
    具体例:先輩と個人間で相談した内容のうち、チームメンバーにも共有しておくべき内容(業務を行う中でのルールなど)を朝会の時にチームメンバーに説明を行いました。

(※)朝会・・・朝会とは、学校や企業などで朝に行われる集会。朝礼(ちょうれい)ともいう。-weblio 辞書より引用

学生の頃との違い

学生の頃は主に一人での作業が中心だったため、自分の好きなように、自分の好きな順番で作業を進めれば良いのですが、仕事になると、一人で作業をすることはほとんどありません。チームで作業をする時はコミュニケーションを取りながら、無駄を減らす工夫をすることが大事になります。

以上のことから、チームメンバーに自分の状況を周囲の人へ発信する必要があることが分かりました。

おわりに

私がこの 1 年間で感じた「仕事としてプログラムを作る」ということを 3 つのエピソードを交えながらお話をさせていただきました。
少しでも皆さんの参考になれば幸いです。

以下、学生の方向けの参考情報として、新卒 1 年目の 1 年間のスケジュール例を記載します。1 年目をどのようなスケジュールで過ごすかをイメージするのにお役に立てれば幸いです。
細かい日程と研修の内容、案件の内容は年度や配属部署によって異なります。