IIJの新人ってどんなことやってるの？

【IIJ 2019 TECHアドベントカレンダー 12/21（土）の記事です】

挨拶

こんにちは、新人連合(5人組)です。

今回の記事ではIIJの2019年度新入社員である私たちで、「IIJの新人って何してるの？」をテーマに、各員が入社後に触れた技術や取り組んでいる事について書き、IIJ 2019 TECHアドベントカレンダーの1ページとしてまとめました。

長文となりますが、最後までお付き合いいただければ幸いです。

三好 貴大：Ciscoルータ導入してお蔵入りした話

システムクラウド本部パブリックリソース1課に配属された三好と言います。
(過去にはこのような記事も書いています)
今回は、自宅にCiscoのルータを買ってみたのでその報告(小話)をしたいと思います。

Ciscoを買うことになった理由

その1、新人研修でCiscoを触った
弊社の今年度新人研修ではCiscoのネットワーク機器を利用して、5日間かけてシステムを構築するメニューがあり、
研修後にはCisco機器にも親しみが湧いて、いつか自宅でも触ってみたいと思っていました。

その2、サーバを友人に公開したかった
自分はMinecraftというゲームのサーバを自宅に建てて、よく友人とマルチプレイで遊んだりしていたのですが、4月に引っ越した先にあったルータではDMZなどの機能がなく、サーバが公開できない状態でした。
そのような経緯から、ルータを探していたところ、Ciscoの892Jというルータを秋葉原の中古ショップで見つけ、DMZ構成も出来る、お値段も6千円ほど、Cisco製という理由で購入しました。

Ciscoを導入した

購入したのが研修直後だったのもあって、PPPoEやDMZの設定はさほど時間もかからず完了して、当初の目的だったサーバの公開も達成できました。

コンフィグの一部

インターネットへの接続

Cisco 892Jは三つのネットワークセグメントを利用することができるので、

最終的にはこのような構成を作り、2ヵ月ほど使っていました。
各インターフェースは次のような配置に。

• Gigabit Ethernet x1 (インターネット足)
• Fast Ethernet x1 (DMZ足)
• Fast Ethernet Switch Port x1 (自宅LAN)

まとめ

Ciscoのルータを購入してみて

• 良かったこと
  • 研修の復習が出来た(一番のメリット)
  • サーバを公開できるようになった
• 悪かったこと
  • 寝るときにファンの音がして気になる(ルータと同じ部屋で寝ているので)
  • 電気代が上がった(波はあるが体感で3000円ほど)
  • 帯域が100Mbpsまで(Fast Ethernetを経由するので)

Ciscoルータを使い、研修の復習が出来て良かった反面、トータルで見ると消費電力などのデメリットが大きく、自宅環境には合わないと感じたので、Cisco 892Jは押し入れの中に移動しました。
ですが、サーバの公開機能はやっぱり欲しいので次なるルータを探求中です。
次は今回の反省を踏まえ、1Gbpsの帯域、低消費電力、静音タイプなルータを検討中で、気になっているのはEdge Router Xというルータ、お値段も安くて性能も良さそう。
ということで、次回の記事では、Edge Router Xの導入レポートを書きたいと思います。
来年もどうぞよろしくお願い致します。

韮塚 凌平：IIJ Bootcampで学んだこと(Docker)を検証で使ってみた

こんにちは、2019年度に新卒入社した名古屋支社技術部の韮塚凌平です。 (にらづかと読みます。)
今年の8月ごろ、IIJでは全体で行われる新人研修とは別にIIJ Bootcampという「様々な技術に触れることを目的とした大ハンズオン勉強会」が開かれました。（IIJ Bootcampについての詳細）

この記事では、IIJ Bootcampで学んだ知識を実際に現場の検証で使ってみたので、そこで気づいたことなどを紹介しようと思います。

(ちなみに私は地方勤務で、かつスケジュールが思うように調整できなかったためIIJ Bootcampの講座を本社にて直接受講できませんでしたが、心優しい運営さんがTeamsライブで共有してくれたため遠方からでも受講できました。)

リバースプロキシソフトの検証環境をDockerで構築してみる

Dockerとは

IIJ BootcampではDockerの入門からDocker Compose構築の基本までを学びました。
Dockerの講座を選んだきっかけは「Dockerが巷で話題になっていること」と「イラストのクジラが気に入ったから」です。

～かわいいクジラの絵～

Dockerとは「Docker 社が開発している、コンテナ型の仮想環境プラットフォーム」のことです。
ここで出てきたコンテナとはあたかも仮想サーバであるかのように振る舞う(ホストOSから分離された)プロセスのことです。(Dockerの詳細は公式HP参照)
簡単にいうと、コンテナはアプリケーションを実行する機能だけを付けたサーバで、Dockerはそれを動かすためのプラットフォームです。
Docker上で動かすコンテナは、LXC(Linuxコンテナ)とは仕組みが若干異なるため、Dockerで使うコンテナのことをDockerコンテナと言ったりします。(この記事ではコンテナというとDockerコンテナを指すものとします。)

コンテナ型仮想マシンは(ホスト型やハイパーバイザー型の仮想マシンと比べて)オーバヘッドが少ないため、非常に軽量で動作が高速です。
ホスト型やハイパーバイザー型の仮想マシンが「PC電源の起動から終了まで」を仮想的に再現するのに対して、コンテナ型は「プロセスの実行のみ」を再現します。

https://www.docker.com/resources/what-containerから引用

Dockerを使って検証

このDockerを使って検証環境を構築してみました。

まず、検証したいことは「とあるリバースプロキシソフトが、各サーバからの様々なリダイレクトを通しても、ユーザにコンテンツを表示することができるか」という内容です。
リダイレクトの種類はHTTPステータスコードによる302リダイレクト、JavaScriptのlocation hrefを利用したリダイレクト、HTMLのmetaタグを利用したリダイレクトの3つで、いずれもコンテンツを表示させるサーバへリダイレクトするような設定です。
この検証の具体的な目的は「リダイレクトすることによって、リバースプロキシソフトにある機能が欠損しないか」「コンテンツを正しく表示できるか」を知ることです。

「コンテンツを表示するサーバへリダイレクトさせる」というたった1プロセスのために1台ずつサーバを構築・管理することを考えると、想像するだけで目が眩むような検証です…。
この検証には他にもいくつかの方法はあったとは思いますが、せっかくDockerを習ったということもあったので、本検証においてDockerを使うことにしました。

実際の構成は以下の通りです。

構成自体はとてもシンプルで、青い部分は「コンテナを跨いでリダイレクト」、赤い部分は「同じコンテナ内でのディレクトリを跨いでリダイレクト」を行うような構成になっており、今回構築したコンテナは全部で5つです。
以下、リダイレクトの動作について説明します。

①ユーザがコンテナ1内のコンテンツを取得するためにリバースプロキシソフトに(HTTP)アクセスすると、リバースプロキシソフトがコンテナ2のコンテンツを取得しに行く。
②リバースプロキシソフトはコンテナ2のコンテンツを取得すると、ユーザにその内容を代理応答する。
③コンテナ2内のコンテンツはコンテナ1へリダイレクトさせる内容なので、ユーザは再度リバースプロキシソフトにアクセスし、コンテナ1に代理応答してもらう。

コンテナ5に関しては、ほぼ同じことがコンテナ内のディレクトリで行われています。

このような多くのサーバを構築したい場面でも、Docker Composeを使って40行弱のコードで構築・管理ができてしまうのは、Dockerの素晴らしいところだと思います。
ちなみにDocker Composeとはコンテナを複数構築・管理しやすくするツールです。
また、この検証用のコンテナはローカル環境以外でも簡単に同じ環境を構築できるため、急遽クラウド上に構築することになってもスムーズに移行できます。

結果、検証はこの構成で問題なく完了しました。
検証中、必要に応じてコンテナに随時機能を追加したり、破棄したりすることがあったのですが、そういった変更に素早く対応できたのはDockerならではだと思います。

Dockerを使ってみた感想

今回初めてDockerを使いましたが、やはりコンテナというものに慣れるのにとても苦労をしました。
VMといった普通の仮想サーバとは違い、起動してから必要なアプリケーションを入れたりconfigをいじるわけではなく、起動する前にある程度必要なアプリケーションやconfigが設定されている状態でなければなりません。
そのため、最初から完成に近いビジョンを意識して設定しないと、まったく何も動作しないことが多々ありました。
特にネットワーク設定でのポートの空け口、configファイルのマウント場所など、何度もコンテナを立ち上げては破棄を繰り返し、構築していきました。
このようにいろいろ設定をいじったりしても、ホストの環境には一切影響がないのはDockerのいいところだと思います。(今まで何度再インストールとインストールを繰り返したことか…)

完成までに紆余曲折ありましたが、Dockerは触ってみるとすごくたのしいです。
「たった数行コードを書くだけでサーバ(コンテナ)が立つ」というだけで感動しますし、それだけでテンションが上がります。
今後はもっと複雑な構成を構築、運用できるようになりたく、最近はKubernetesについて興味を持ったりしています。

記事にできなかった最近取り組んでいること

最近読んだ書籍「退屈なことはPythonにやらせよう」の影響で、スクレイピングを使って運用業務を自動化しようと試行錯誤しています。
記事にしようとは思っていたのですが、Selenium(Webブラウザをコード上で操作できるようにするフレームワーク)の扱いに慣れず、2019年のIIJアドベントカレンダーには間に合いませんでした…。
来年に期待！

おわりに

Dockerについてわかりやすく説明できたか不安ですが、私の記事は以上になります。
今回記事にできなかった部分も含め、(チャンスがあれば)来年のアドベントカレンダーではもう少しボリューミーにしたいと思います。(できればDockerやKubernetes、IKEについて語れるようになりたい…)
拙い文章にここまでお付き合いいただき、ありがとうございました。
続いての記事は高岡さんで「勉強会の開き方」です。

高岡 奈央：勉強会の開き方

こんにちは、高岡（naot）です。

私はセキュリティ本部セキュリティビジネス開発部システム開発課で働いています。
以前は同じ部の基盤運用課で働いていました。

4月から今まで、以下のようなことをしてきました。

• 4～6月中旬：新人研修
• 6月下旬から8月初旬：仕事を覚える
• 8月中旬から9月：実際に検証等の業務を行う。新人面談が行われ、開発をやってみたいということで10月から異動することになる
• 10月～現在：異動。C-SOCサービスの開発に取り掛かるために、サービス理解やコードの理解を進める

さて、本題は「勉強会の開き方」です。

勉強会とは、あるテーマなどに沿って人を集めて、自分が勉強しているものを共有したり、またはもくもくと作業をしたりするような会です。

私は9月に社内新卒向けの勉強会を開催しています。
このときの体験について書いていきたいと思います。

社内で新卒向け勉強会を開きました

新人研修が終わると、それぞれ配属された部署で働き始めます。
研修中は誰が何をやっているのかは比較的すぐにわかりましたが、研修後は話さないメンバーも多数おり、何をやっているのかわからないというのが問題だと思いました。

そこで、新卒メンバーで集まって自分が何をやっているのかを淡々と話す会があれば、会社の理解にもなる上ほかのメンバーが何をやっているかもわかって良いのではと、新卒向け勉強会を企画しました。

思い立ってすぐに、次のものを準備しました。

• 会議室
• アンケートフォーム
• 新卒全員が入っているメーリングリストに以下のようなメールを送る

各位
お疲れ様です、naotです。
同期勉強会を企画してみようと思います。
時間は9月12日（木）19時からを予定しており、
場所は***を押さえました。

出来得る限りTeams会議をするなど頑張ってみようと思います。

内容は基本的には自由です。
今部署で何をやっているかや、はまっている技術、
飯田橋のおすすめ情報でも良いかと思います。
ご参加いただける場合やそうでない場合も含め、
下記Formにぜひご回答ください。
(ここにFormのリンク)
よろしくお願いいたします。

それでは、暑い日が続きますが
体調にはお気をつけてお過ごしください。

FormにはMicrosoftのFormsを使いました。これは回答結果をExcel形式でダウンロードできるため、統計等とりたいときに便利です。
19時からの開始だと、昼勤務の人はちょうど仕事が終わる頃で、夜勤の人はこれから仕事が始まる時間ということで都合が良いかと思いました。

Formには19名からの回答があり、7名が勉強会に参加してくれました。
課の紹介や使っている開発手法、自分のデスク紹介などがあり、にぎやかな会となりました。

こういった社内勉強会は会議室さえ空いていればすぐに開催することができます。

勉強会を開くときに気を付けていること

今回の社内勉強会や社外で勉強会を開いた際に感じた、勉強会を開く際に気を付ける点について挙げてみます。

参加者目線の勉強会か

勉強会を開きたい！と思って勉強会を開いても、参加者が集まらないと始まりません。参加者が参加したいと思えるような勉強会かどうか確認する必要があります。
そのためには、市場調査が必要かと思います。開きたい勉強会と参加者層が求めている勉強会がマッチするかどうかを今後考えていきたいです。

ほかのイベントと被っていないか

どんなにいい勉強会を開いても、ほかの重要なイベントと被るとそちらを優先される方が多いかと思います。
社内勉強会だともちろん業務が優先されます。社外だと大きなカンファレンスなどと被ると集客は厳しいです。
参加者が余裕をもって来ることができる日時がベストです。

人数に見合った会場であるか

私はよく少人数の勉強会を開くのですが、少人数に対して大きすぎる部屋だと寂しさがあります。また、その逆は窮屈になります。
当日に参加者が増減する勉強会となると厳しいですが、ある程度参加者数を予測できるのであれば部屋もそれに準じて用意するのがいいでしょう。

コンセプトを決められているか

もくもく会（淡々と個人作業を進める会）を開いた際、何の作業なら許可されるか等が見えづらく参加者に戸惑われてしまったことがあります。
何かコンセプトがあると勉強会としてまとまりやすく、参加者にとってもわかりやすいです。
今回は2019年の新卒が集まるというコンセプトを立ててみました。

遠隔参加は可能か

今回は名古屋支社から遠隔で参加してくれた人がいました。IIJには各拠点とテレビ会議ができる会議室があり、そこで画面共有をしながら勉強会を進めました。
私自身地方出身であることが影響して、遠隔参加やサテライトがある勉強会を開いていきたいと思っています。
社外の勉強会では、画面共有をする際はZoomを使ったり、ドキュメントを書く際はGoogleドキュメントを同時編集したりすることで遠隔参加を実現しています。

まとめ

今回は勉強会の開き方をテーマに少し文章を書いてみました。
まだまだ経験不足ではあるので、IIJ Bootcampなど先輩方の取り組みを見ながら、社内・社外で勉強会を開いていきたいです。

続いて、山元くんの「Power Automateで会議室予約自動化」です。

山元 大輔：Power Automateで会議室予約自動化

自己紹介

こんにちは。ネットワークサービス部で閉域系サービスの企画/開発部署に所属する山元です。
新卒として入社して以来、簡単にまとめると12月まで以下のことをしてきました。

• 4～6月中旬: 新人研修
• 6月下旬から8月初旬：IIJ Bootcampなどの研修と社内システムなどを覚える
• 8月下旬: 部署の仕事を覚える&人事が学生向けに行っているネットワークインフラのインターンシップの担当
• 9月上旬から12月: サービス開発や問い合わせ対応やドキュメント作成など幅広く

さて、新人ということで今までやってきた内容の他にPower Automateがあります。

会議室予約の自動化です。

なぜ会議室予約なのかというと、私の参加する打合せでは誰かが手動で会議室を予約していました。
そのため新人としてできそうな小さな仕事として、「会議室予約は私がやります」と仕事を集め、自動化してみました。

自動化って楽でいいね!

Power Automateで会議室予約自動化

Microsoft Power Automate (旧Microsoft Flow)とは

2019年11月のMicrosoft IgniteにてPower Platformが発表され、それに合わせてMicrosoft FlowからMicrosoft Power Automateへと名称が変更されました。

Microsoft Power AutomateはLow-Code PlatformとしてGUIで自動化を組み立てることができ、Office 365を始めとする、様々なWebサービスと連携し、自動化 (RPA)ができます。

Microsoft Igniteで発表されたUI flowsはなんと! GUI操作を記録、実行させることができます。
詳しい情報はドキュメントや、こちらの非公式ブログを参照ください。

つまり、新人でも簡単だね!

Power Automateでは以下のようにテンプレートが豊富に用意されているので、自分で組み立てるときの参考にもなります。

サンプルが多いって嬉しいね!

ということで、次は実際に会議室を自動予約してみようと思います。

Power Automateでやってみよう

注意事項

• Power Automateでは処理によってはループ処理になる場合があります。
  • 特にTeamsの通知などを行うと、ループするフローになりやすいのでご注意ください。
• Power Automateではライセンスの種類で1日のAPI実行回数が制限されています。
  • 詳細は以下からご確認ください。
    https://docs.microsoft.com/ja-jp/power-platform/admin/api-request-limits-allocations
• 以下の紹介内容を実行して損害を被っても責任は負いかねます。

前提条件

• Office 365が使える
• Office 365の管理者からPower Automateの利用が許可されている
• 会議室の予約がOffice 365にて行える

目的

• 毎週金曜日に行われる定期的な会議の予定を3ヵ月 (90日) 前に自動で作成する
• 予約時に、会議室も予約する

今回の設定内容

• フロー名: 会議室自動化
• フローの実行トリガー: 毎週土曜日10:00
• 予定
  • タイトル: 金曜日にカレーを食べる会
  • 時間: 毎週金曜日 12:00 ～ 13:00
  • 会議室名: ほげほげルーム
  • 会議室のアドレス: hoge@example.com

やってみよう

大まかな流れ

a. スケジュールされたフローを組む
b. 定期的に予定を作成する
c. 動作をテストする

これだけ!

組み立て

a. 実行されるタイミングを考える

90日先の予定を作成したい場合を考えます。
90 (日) = 7 (日/週) * 13 – 1(日) なので、金曜日から1日後の土曜日に毎週実行すると上手い具合に予定を作成できます。

b. 「マイフロー」 > 「新規」 > 「スケジュール—一から作成」の順で進むと以下のような画面が表示されます。

ここではフロー名に「会議室予約自動化」と入力し、「作成」を押してみます。
設定内容は後から変更できるので、とりあえず好きに設定しましょう。

c. Recurrenceの変数を設定します。

この設定内容でフローが実行されるタイミングを指定します。

d. 「+ 新しいステップ」→ 「Office 365 Outlook」と進み

「イベントの作成 (V4)」を選択します。

e. 以下の手順とスクリーンショットを参考にして適当に「イベントの作成 (V4)」の必須項目を埋めます。

i. 時刻
「開始時刻」と「終了時間」は以下のように関数を入れます。
これにより、実行時点から90日先の12:00に開始する予定が予約されます。
「イベントの作成 (V4)」ではタイムゾーンを日本に設定しても入力する時間はUTC基準です。詳細はMicrosoftのドキュメントを参照ください。

1. 1. 「開始時刻」は以下の内容を式に入力する (赤文字部分が時刻に対応する)
      addHours(addDays(startOfDay(convertTimeZone(utcNow(), ‘UTC’, ‘Tokyo Standard Time’)), 90), 12)
   2. 「終了時刻」は以下の内容を式に入力する (赤文字部分が時刻に対応する)
      addHours(addDays(startOfDay(convertTimeZone(utcNow(), ‘UTC’, ‘Tokyo Standard Time’)), 90), 13)

ii. 会議室予約

1. 1. 「リソース出席者」に会議室のメールアドレスを入力します。
      (会議室のメールアドレスは連絡先などで検索するなりして事前に把握してください。)
   2. 「場所」はカレンダーに表示される場所の表記です。必須ではありませんが、わかりやすいように入力しましょう。

iii. (推奨設定) カレンダーを他の人から見た時に予定が「空き時間」とならないように「表示方法」を「busy」(予定あり)に変更しましょう。

iv. これで設定項目は完了です。「保存」しましょう。

f. 次はフローの動作テストをしてみましょう。

i. 「テスト」をクリックします。

ii. 「トリガー アクションを実行する」を選択し、「保存 & テスト」をクリックします。

iii.では実行してみましょう。
実行すると、実行履歴が確認できます。

日付をクリックして意図する動作をしているか、詳細を確認してみましょう。

iv. 以下のスクリーンショットのように、「入力」と「出力」結果が確認できます。
実行日時から90日後の日付で「金曜日にカレーを食べる会」の予定が作成確認できました。
成功ですね!

g. Outlookの予定表でも下のスクリーンショットのようにみなさんも確認できたことだと思います。
いかがでしたでしょうか?

フローを作るときのコツ

• コツは簡単なことをやってみる!
  最初から完璧な自動化を目指さず、最初は小さく作ってみましょう。
  小さな部分が動いたら、変数や条件分岐などを使い、より複雑で高度なことを実現してみましょう。
• 悩んだらMicrosoftのドキュメントを読もう!
  ドキュメントには関数の実行例などが掲載されているので、使い方の分からない関数に遭遇した際はドキュメントを読んでみましょう。

まとめ

Power Automateはコードを書かず簡単に自動化を実現できるので、新人にとって強力なツールになると感じました。
新しいツールを使いこなして、自動化についてちょっとデキル新人を目指してはいかがでしょうか。

ここまで読んでいただきありがとうございました。

栗原 望：新人プログラマーが考えた コードレビュイー としての心得

my_profile = {
    '名前': '栗原 望',
    '所属': 'IIJ GIO P2 プライベートリソースの開発部隊',
    '領域': 'サーバーサイド',
    '年数': '1 年目',
    '一言': '最近、靴磨きにハマっています'
}
   
for k, v in my_profile.items():
    print(k, ':', v)

こんにちは、新人の栗原 望です。

構想から実装まで、約 5 ヵ月かけたプログラムが、12 月頭にようやく本番リリースを迎えました！ 無事にリリースすることができてホッとしています。

その中で、メンターの方にコードレビューをしてもらうことが何度かあったわけですが、そのときに、「ただレビューしてもらうだけじゃなくて、レビュイーとして何かできることはないだろうか？」と考えました。

今回は、その考えた結果を記事にしました。

※ 以下、レビュワーとレビュイーのやりとりは、基本的に GitHub 上で行われることを前提としています

それでは早速どうぞ！

レビュイーとしてやるべきこと

理想は、相手がコードレビューしてくれることに対して、自分からも相手の為に何かすることですが、なかなか難しいですよね。

いろいろ記事を見て、自分なりに勉強してみましたが、現段階の結論としては「レビュワーの気持ちになって (視点に立って)、レビュイーとして振る舞う」ことが、レビュイーとして最低限やるべきことだと考えています。

具体的には「どうやったらレビュワーの負担を減らせるかを考え、実行すること」です。

このような相手意識を持った上で、私がやったことは、大きく分けて 3 つあります。

① プルリクエストするとき

(私の場合、レビュワーとしての経験は無いのですが …) プルリクエストに対してレビュワーが期待していることは「レビュイーの意図が可視化されていること」だと思います。

具体的には、

a. なぜ、このプルリクエストを出したのか (目的 / 背景) を書く

• • • • プルリクエストを出した 目的 / 背景 が分かると、レビューする際の指針を決定しやすい

b. どのように / どの部分を、レビューして欲しいのか (レビュー箇所の合意) を書く

• • • • レビューする箇所を決定することで、レビュイー / レビュワー 共に、スケジューリングしやすい

の2つです (他にもたくさんあるかもしれませんが)。

↑ 例えばこんな感じです。

これだけでも、レビュワーは「そうか、高速化することがポイントなんだな」と考え、このプログラムをより高速化する為のロジックを提案してくれるかもしれません。

また、実際にレビューする際も「そうか、ロジック部分を重点的に見てほしいんだな」と考え、コーディング規約のような細かな指摘をする可能性が小さくなります。

このように、レビューが始まる前にレビュイーの意図を共有しておくだけで、レビュワーの負担がグッと減るのではないでしょうか。

② コミットするとき

コミットするときに意識していることは「とにかく分かりやすいコミットにする」ことです。

具体的には、

a. 1 つのコミットでは、たった 1 つのことだけを実現 (解決) する

• • • • これによって、それぞれのコミットを小さく保つことができ、さらに、コミットの内容が明確になるので、分かりやすい、つまりはレビューしやすいコミットになる

b. どんなことを、なぜ、コミットをしたのかを書く

• • • • a. に加え、コミットメッセージに「コミットのタイトル、そのコミットをした理由」をそれぞれ一言で書くことで、実際のコードを読む前にコミットの全体像を掴むことができるので、理解の助けになる

の2つです。

「コミットの粒度をどうするか」は、難しいところですが、例えば私の場合は下図のように、コミットをメソッド単位でまとめていました。

このようなまとめ方に加え、なぜそのメソッドを実装したのかをコミットメッセージに書けば、分かりやすいコミットになりそうですよね。

適当に何も考えずに行うコミットは、レビュイー視点で言うと楽チンで良いのですが、その分、レビュワーの負担が増えることになります。

そのため私は、”git add -p” などを駆使して、分かりやすいコミットを心がけています！

③ 議論するとき

気をつけるべきことがたくさんありそうですが、私の場合はシンプルで「会話を殺伐なものにさせない」です。

具体的には「絵文字をたくさん使う、”いいね！” をたくさんする」です。

文字だけで議論をしていると、どうしても殺伐になりがち (見えがち) ですよね。そのため私は、絵文字だったり感嘆符だったりを多めに使っています。

↑ 例えばこんな感じです。些細なことですが、これだけでちょっと雰囲気変わりますよね。

# この間、父から「今度、母の誕生日ですが、どうするつもりですか」というメッセージが来て、なんだか問い詰められているような気分になりました (笑)

# 本当に問い詰めたかったのなら話は別ですが、例えば「誕生日だけどどうする〜？」とか「何か考えているかい？」とかにするだけでも雰囲気変わりますよね。これに絵文字とか入れたらもっと明るい雰囲気になると思います 🙂

1 人だけバンバン絵文字を使ったりしているとちょっと浮くので、多少相手に合わせますが、コミュニケーションするときの雰囲気作りってとても大事ですよね (というより、雰囲気を作ることもコミュニケーションの一部だと思います)。

暗い雰囲気で仕事をするのと、明るい雰囲気で仕事をするの、生産性が高まるのはどちらでしょうか。私は後者だと思います！

# もちろん、文字だけでやりとりすると必ず雰囲気が悪くなるとは思っていません。あくまで、比較したときの話です

特に、この「③ 議論するとき」に関しては、レビュワーの立場でも同じことが言えると思うので、レビュワーになった際にも意識すべきことだと思います。

まとめ

私なりに考えたレビュイーとしての心得を 3 つ述べました！ 整理しますと、

a. プルリクエストを出すとき: その意図を明確にする
b. コミットするとき: とにかく分かりやすいものにする
c.議論するとき (チャット): 会話を殺伐とさせない、明るくする

といった感じです。

こうやってまとめてみると、レビュワーに何か与えることはできなくても、負担を減らしてあげることは難しくなさそうですね。心がけさえすればできるはずです。

私は今後とも、レビュイーになることは多いと思うので、この3つを大切に、意識してやっていきたいと思います。

おまけ (Oracle Certified Java Programmer, Silver SE 8を取得しました！)

毎日の通勤時間 (往復40分程度) を利用して、約4ヵ月間、勉強しました (黒本と呼ばれている本をひたすら読みました)。
Java での開発経験は0でしたが、毎日コツコツ勉強すれば、そこまで難しくない内容だったと思います。
# この手の記事は、既に書いている方がたくさんいらっしゃるので、詳細はそちらに譲ります

また、業務時間中にも、合間を縫って勉強していました。
資格取得は「将来の業務に活かす (技術力を向上させる) 為に行う」という位置付けですが、そうだとしても、業務時間中に勉強をさせてくれたこの環境に、とても感謝しています 🙂
# ちなみに、合否の境界線は 65% で、私の正答率は 92% でした！

おわりに

ここまでお読みいただきありがとうございました。
2019年度新卒入社の5人組が執筆した本日分のアドベントカレンダー記事は以上となります。
いかがだったでしょうか。

改めてそれぞれの記事を見てみると、5人とも技術系の新人なのですが、内容が全て異なっています。
各々に個性があり、また、各々の興味も異なるということが、ここから少し分かりますね。
IIJ の社風の1つ (個性ある人たちが、いろいろなことに興味を持ちながら、働いていること) が少し垣間見える、そんな雰囲気の記事にうまく纏まってくれたかなあと感じます。

今回は、オムニバス形式での記事となりましたが、来年は、各々が独立した記事を書けるよう、より知識と技術を身につけることのできる1年にしたいと思います。