ISUCONは実務に役立つのか

ISUCONに参加する理由

私がISUCONに参加する理由はISUCONが自身の技術力を客観的に測ってくれる、かつ復習によって知見を得られる素晴らしい大会だからです。自分の実力が結果として明確に現れることは正直苦しいのですが、そういう思いをして成長した方が身になると考えています。

ISUCONは実務に役立つのか

ISUCONは実務に役立つのか、という点においてはYesでありNoであると思います。理由はシンプルでイメージとして以下の図のようにISUCONで必要なスキルは実務で必要なスキルに対して互いに部分的に交わっている関係だからです。

実務に必要でISUCONでは問われないスキル(青の部分)には、コードの保守性を守る技術力、インフラ構築スキル、セキュリティ対応のスキル、プロダクトマネジメント力、チーム間コミュニケーション能力など沢山あります。

ISUCONのみで必要なスキル(赤の部分)はベンチマーカー挙動推察力、などでしょうか。

実務とISUCON両方で必要なスキル(紫の部分)には、以下のようなスキルがあると考えています。

• ビジネスロジック理解力
• システム分析力 (課題分析力)
• WEB全般知識力
• システム問題解決力 (設計能力)
• アプリ＆ミドルウェア＆インフラ実装力

上記はエンジニアにとって実務で非常に重要なスキルです。"実務で必要なスキル"と言っても幅がとても広いのですね。

ISUCON12予選に参戦しました。

はじめに

昨年の参加メンバーから1人が参加できずの2人チームでISUCON12予選に参加しました。East Labというチーム名でした。

最終的な結果は9,760点の98位でした。

ので、上位の方のブログ記事より参考になることはなく、自己満足のための記録用記事という位置づけで、競技中にやったことと感想を書きます。 (ブログを書くまでがISUCON とのこと)

タイムライン

• 10:00~ システム概要確認。git設定、デプロイスクリプト作成、分析・監視系ツールを導入する。
• 11:00~ マニュアルを読み、アプリ画面を触りながらビジネスロジックの概要を確認。
• 11:30~ ベンチマーク後のAccess Log、MySQL Slow クエリ、topコマンドの分析をして何から取り掛かるかを決めようとする(が混乱する)。
• 12:00~ 頭を整理するため議論しながらコンビニへお昼ご飯を買いに行く。
• 13:30 GET /api/admin/tenants/billing のvisit_historyテーブルへのN+1クエリを修正 commit → 3,000点くらいになる。
• 14:45 MySQL側で実施されていて負荷になったいたランダム文字列生成をアプリ側にする改修 commit → 4,500点くらいになる。
• 15:30 POST /api/organizer/competition/:competition_id/score のINSERTをバルクインサートにする commit → 7,400点くらいになる。
• 15:45 GET /api/organizer/players/add のINSERTもバルクインサートにしてみるcommit → 変わらず。
• 16:20 GET /api/player/player/:player_id のcompetitionテーブルのN+1クエリを修正 commit → 8,000点くらいになる。
• 16:45 MySQLを別サーバに移して2台構成にする commit → 10,103点になる。
• 17:00 SQLiteテーブル操作時のファイルロック期間を短くする対応をしてみる commit → 点数変化なし。
• 17:20 GET /api/organizer/billing のvisit_historyテーブルへのN+1クエリを修正 commit → 点数変化なし。
• 17:40 GET /api/admin/tenants/billing のtenantテーブル取得にてLIMIT 10で絞るようにする commit → 点数変化なし。
• 18:00 競技終了

使った分析・監視系ツール

• top
• dstat
• kataribe(Nginxログ解析)
• pt-query-digest

問題の感想

多くの方がそうだったかもしれませんが、SQLiteとMySQLがミックスされた今回の問題に普通に面食らいました。SQLiteは業務経験が無くスロークエリの分析方法やEXPLAIN時の見方がわかりませんでした。

SQLiteをMySQLに移行することはすぐ考えつきました。しかし、その判断が本当に正しいのか、正しく移行できるか、に自信が無く結局実行することができませんでした。知見・経験における技術力不足に依るところで、どうやらここが上位者になるかの今回の問題の一番のポイントだったようです。

関連しているところで、SQLite操作をするにあたりテナントごとにファイルでロックをしていることは認知はできてかつベンチマーク結果と分析の状況的にボトルネックになっていると把握はしながら、具体的な対応が打てなかったのも技術力不足を痛感した部分でした。

アプリ仕様とコードからvisit_historyテーブルとplayer_scoreテーブルが共に最新のデータしか参照されていないことに気づくことはできました。テーブルスキーマを変更する必要があることも把握しましたが、どう変更するか、initializeでどうデータを入れるかの実装のイメージがすぐにわかず最後まで後回しにしてしまいました。このあたりは焦らず着実に実行する練習が必要です。

また、分析に関して昨年よりも成長はしたがまだまだ十分にできていないと感じました。NginxアクセスログのTotal時間順にエンドポイント改修する方針を取っていたのですが、システム分析でボトルネックになっている箇所を正しく特定し順に解消していくことがスコアアップに繋がると反省しました。予選を突破するチームは何が高得点の鍵になったかしっかり把握している(参考 ISUCON 事前講習2022 座学) のでシステムの知見と分析力を上げる必要があります。

これから解説記事や他の方の技術ブログを拝見しながら復習します。

おわりに

しんどかったですがなんやかんや楽しかったです。

運営の皆様、ありがとうございました！お疲れ様でした！

ISUCON11予選に参戦しました。

はじめに

3人メンバーのチームでISUCON11予選に参加しました。

決勝にいけるような好成績ではなかったのですが、それなりに健闘できたのでブログを書いてみることにしました。

はじめに投稿したのが予選から1日後です。公式の解説や他の方のブログを読んでチューニング部分に関して反省とかを更新していくと思われます。

時間の流れ (だいたい)

私視点での自チームの様子を記載しました。コミット見直したり覚えている範囲で記載してみた。まとめて思ったのは実装スピードが遅いなと。

• 10:00~ マニュアル読む。アプリを触る。
• 10:30~ デプロイスクリプト、分析・監視系ツールを導入する。
• 11:30~ 分析結果を基にマニュアルをもう一度読んだりして方針をそれっぽく議論する。
• 12:00~ お昼を食べながらモクモクとチューニングをはじめてみる。
• 14:00~ 「テーブルへのインデックス貼り」や「ユーザーのインメモリ化」などで16,000点(?)くらいになる。
• 14:30~ 「GET /api/trend のN+1クエリ対応」ができ、25,000点(?)くらいになる。
• 16:00~ 「画像のConditional GET 対応」をするも、もろもろ知識が足りていないせいでfailし続けてしまいスコアを伸ばせず。
• 16:30~ 「MySQLを2台目サーバへ移す」で34,000点くらいになる。

  

  スクショを撮っていた。このときは44位。後にどんどん追い抜かれる。

• 17:00~ 「POST conditionの非同期化」をするもスコアにそれほど影響せず、35,000点くらい。
• 17:15~ 継続してトライしていた「isuテーブルのインメモリ化」でもスコアが伸びず。
• 18:00~ 私「は？コンディションのグラフ？それは一体美味しいのでしょうか？(丁寧)」
• 18:30~ さらにスコア伸ばすこと叶わずそのまま終了。お疲れ様でした！

使った分析・監視系ツール

• top
• dstat
• kataribe
• pt-query-digest
• go tool pprof (1回しか見れていない)

ベンチを走らせるときはtopを見る癖を付けるようにしました。dstatでもちょいちょい見ていた。本当はNetdataを導入してイケてる画面で監視しようとしていたのですが準備が間に合わず。

kataribeはISUCONには欠かせない相棒に。alpを使う人の方が多いかもですが使い勝手はほとんど変わらないと思います。

スローログはpt-query-digest様、これも欠かせない。

担当したチューニング部分の中で、自分のためにブログに残す箇所

GET /api/trend のN+1クエリ対応

N+1クエリ対応において、SQLの割と基本的な知識が足りておらずバグが取り除けずハマっていました。

「SQLでグループごとにある最大値の行を取得する」をする必要があったのですが、以下の記事での"失敗例"のように集約していないカラムが適当に引っ張られてしまう状態でした。記事のように同テーブルでJOINして行を保証する必要があることに気づくのに時間をかけてしまいました。普通に修行が足りてません。

SQLでグループごとにある最大値の行を取得する - Qiita

メモとして残しますが結果的に以下のSQLになりました。複雑そうですがEXPLAINで見てINDEXは効いてました。

select i.id, i.jia_isu_uuid, i.character, ic.condition, ic.timestamp from isu i
  INNER JOIN
    (select icA.jia_isu_uuid, icA.timestamp, icA.condition from isu_condition icA
        INNER JOIN
          (select jia_isu_uuid, max(timestamp) as timestamp from isu_condition group by jia_isu_uuid
           ) icB ON icA.jia_isu_uuid = icB.jia_isu_uuid AND icA.timestamp = icB.timestamp
    ) ic ON i.jia_isu_uuid = ic.jia_isu_uuid;

MySQLを2台目サーバで動かす対応

ちゃんと効果ありました。アプリとMySQLが1台目サーバのCPUを食い合っていたのでそりゃそう。MySQLサーバをアプリケーションサーバから剥がすチューニングはどの過去問でも大体同じように効果が出ると思われます。アプリケーションのCPU負荷が見えてきたらひとまずやってしまうと良いと思っています。

画像のConditional GET 対応

ベンチマークが「Conditional GET のサポート」をしているとマニュアルに記載があり、対応を試みたのですがFailしてしまいうまくいかず自分の基礎的な実力不足を思い知りました。

マニュアルに貼られていた以下のRFCのドキュメントをこの際、上から読んで勉強しようと思います。

datatracker.ietf.org

POST conditionの非同期化 対応

今回のお題のISUCONDITIONにて、ISU(椅子)からやってくるデータ登録部分をgoroutineでサクッと非同期化しこれはコスパ良く点が上がるのではと思ったのですがあまり上がらず。やり方が良くなかったっぽい。

おわりに

運営の皆様、お疲れ様でした & 楽しく学びになる時間をありがとうございましたm( )m

現役CTOたちにイケてるCTOになれる方法聞いてみた

CTOってかっこいいじゃん？

なりたいなーって思ってるんだけど

最近だとVPoEとかいう役職もあってわからんけど名前かっこいいからそっちも捨てがたい

Meetyについて

今いる会社の強いエンジニアマネージャーの方がMeetyというサービスでカジュアル面談をOpen中と共有していて知った。

meety.net

このMeetyというサービスは誰もがリファラル採用の機会を増やせるようにゆるーく採用とは直接関係無い話からはじめて知り合い増やせるよーというサービスとのこと。

誰でもカジュアル面談募集できてMeetyで知り合いになってリファラル採用にこぎつければ所属の会社から報酬がもらえるという流れを作ってくれる。

ビジネスモデルはリファラル報酬の〇○%いただきますなのか？はっきりしてないけど所属の会社名は登録必須だし今後そうなるのではと思う。

サービスは開始されたばかりで運営者の人脈で何人かの強いエンジニアがOpenしている面談がいくつかあるっぽく、強い人が疲れてやめてしまう前にアプライしてみた。

"エンジニアのキャリア相談室"というカテゴリにスタートアップのCTO, VPoEの方の面談がOpenしていたので、そのときの6人全員にアプライしたら4人の方と話すことができた。

とりあえず聞きたかったこと

どうしたらイケてるCTOになれますか？()

今回の4名と話して自分の結論

• みんな特にCTOになりたくてなったわけではない。技術力&行動力により気づいたらなっていた。だからいっぱいコード書いて、いっぱい色んなチーム渡っていこう。
• 技術は幅広くやっていこう。
• 経営とか事業も気にしながら仕事しよう。詳細はいざのときに勉強すれば十分。

言われて印象に残ったことひとりずつ

匿名にしておく

E社 CTO Kさん

技術とマネジメントにおいてバランス型な印象

• 最新技術のみに触れていて常に素早く作れる人はスタートアップのみ活躍できる人。こういう人をスタートアップ症候群と呼んでいる。こういう人は会社が成長すると中途で入るエキスパートには勝てない。
• バックエンドを軸にして深めると良い。エンジニアマネージャーになるにはそこからフロント、インフラへ知識を広げること。

L社 VPoE Oさん

技術の知見の幅が一番広い方。とにかく色んな技術に触るのが好きとのこと。

• 触りだけでも把握することは大事。色んな技術をハローワールドしてみること。
• 知らない領域の技術書はとにかく読み切る。2周目か他の記事を読むことでわかるようになる。
• マネジメントの仕事はすべてに深い知識は不要。苦手な分野は得意な人に任せること。

H社 VPoE Kさん

エンジニアリング組織の評価とプロセスに関する分野が強い。この方は話し方も話の聞き方もすごく丁寧で話す内容もインパクトがある。いわゆるカリスマ性が高いとはこういうことかと感じた。

• ものづくりをする人格とビジネスをする人格を意識する。二重人格者になる必要があり、そんなメンバーで構成されたチームは強い。
• 自分の会社のIRの資料はちゃんと見よう。会社のIR(外向け)と会社の実態の乖離が今後会社が伸ばしたいところ。
• お金が稼げる業界にいることが大事。そういう業界にいないと優秀でも給料が上がらない。
• 経験した方が良いこと3つ。・デスマーチ・自分が設計したダメコードを1年後に見る・自分が開発したプロダクトのアラート対応
• 不確実性の解決の貢献度を給料に反映させるのが組織を強くする人事評価だと考えている。

(現在技術顧問数社) Bさん

学生のころからLinuxディストロのコミュニティで開発していたような特に技術力がバリ高な方。 このBさんが一番強烈であった。正直レベルが違い過ぎて終始圧倒されてしまった。

• 20代30代はボーナスステージ。この間に何か成し遂げた人とそうでない人で40代からのキャリアでとても差がついてしまう。
• 計画的に偶発性を起こせる特性を身に着けよう。楽観的・あきらめない・他の人がやらないことへ行動を起こす。
• 未踏プロジェクトやるといいよ。

業界的には古典『ピープルウェア』を読んだら名著だった

ソフトウェア界隈では有名なピープルウェアを読みました。本質的で普遍的なアドバイスがたくさん書かれており備忘録としてブログに残そうと思いました。

www.amazon.co.jp

感想

• 技術的にも知見が広いであろう筆者がソフトウェア開発の問題は社会学的と割り切り、課題とソリューションを提示していて面白い。
• 品質重視、チームビルディング、改善に関する考えは、リーンスタートアップやアジャイルの思想に対する先駆けであると感じた。
• 現在マネジメント職をやっているほとんどの人にとって耳の痛い話が多い。普遍的な課題として昔からあるが解決が非常に難しい問題を扱っているとわかる。
• 「 電話を減らそう」「メールでのやり取りTips」の部分に関しては時代をとても感じる。逆にギャップを感じるのはこの話くらい。

抜粋

備忘録として残したい内容を私なりにカテゴライズした上で以下に抜粋します。

ソフトウェア開発で起こる問題の正体は・・？

• ソフトウェア開発での問題の多くは技術的よりも社会学的問題である。
• 仕事の人間的な側面より、技術面に注意を多く払うのは、重要だからではなく、単にやりやすいから
• プロジェクトメンバーを結束させる能力のある人は、普通に仕事をする人の二人分の価値がある。

品質第一

• 大抵の人は自尊心を自分の作った製品の品質と強く結びつける傾向がある。
• プログラマーを満足させる最低基準は、今までに達成した最高の品質である。この水準は、マーケットが望み、金を払って手に入れようとするものよりも、ずっと高い。
• 品質至上主義は、世間一般からチームを際立った存在にするので、チームを一つに結束させる役割を果たす。

真のマネジメント、リーダーシップとは

• マネージャーの役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。
• 与えられたグループでやっていこうといったん決めたならば、最良の戦術は部下を信頼することである。ダメな部下でも成功を保証するために防衛的な手段を取れば、自体は悪化する。
• 本当の意味での自主性や自由とは、マネージャーとは違ったやり方で仕事を進められるということだ。
• 最大の成功は「マネジメント」などないかのように、チームがなごやかに一致団結して働いたときである。

開発チームと生産性について

• もし、彼らが最初の時点でその仕事に向いていなければ、ずっと向いていない。こうしたことは、最初に人材を揃えることが何よりも重要だということを意味する。
• 挑戦はチームのメンバーに一緒になって努力する目標を与えるからこそ重要なのだ。挑戦はチームを一つにまとめる道具である。
• チーム編成の目的は、目標を達成することではなく、目標を一致させることである。

退職率を減らすには

• 算出すると人材の退職が企業にとってマイナスでしか無いのは明らかである。
• 退職率が最も低い会社に共通した特徴は、生涯教育プログラムの充実である。
• 人への投資をきちんとマネジメントしている企業は、長い目で見ると繁栄する。

プロジェクトのリスクについて

• プロジェクトがリスクを抱えていることは、その価値を示す印かもしれないということは強調しておく意味があるだろう。
• 私たちがマネジメントし損ないがちなリスクとは、自分自身が失敗するリスクである。

改善について

• 以下に、人々にやり方を変えるように頼むときに、あなた自身に繰り返し唱える呪文を教えよう。呪文: 変化への基本的な反応は、論理的なものではなく情緒的なものである。
• 一般的に、どのような改善にも変化に巻き込まれる人たちがいる、ということを思い起こすのはいいことだ。

GitのコミットメッセージでCHANGELOGをいい感じに運用したい

移行しました。

momotaro98.github.io

新卒から2年7ヶ月お世話になった会社を退職しました

はじめに

2年7ヶ月お世話になった楽天株式会社を退職しました。 退職エントリを自分のために書きたかったので書きました。短く書こうと努めましたがかなり長くなりました。 楽天という会社について良い事も悪い事も色々書きたかったのですが「御社にとって不利益なことは発信しません」の内容が盛り込まれた退職時の誓約書にサインをしたので、私の会社への所感も含めここには書かないことにしました。 結果、私のための私の成果をアピールするだけのつまらない記事になっています。 楽天について知ろうと偶然にもこの記事を読んでいる方の期待には応えられないです。すみませんm( )m そういうこともあり、ここでは私が所属していた部署の事業内容、業務内容についても具体的には触れません。

なぜ転職を選んだ？

技術力を向上させたいと思い転職を決意しました。 私のエンジニアとしての1つの理想像が「技術コミュニティに対し有用なものを生産し配信し続けるエンジニア」だと自分の中で落ち着いたのでそれにより近づける環境に移ろうと思いました。

やってきたこと

はじめに

私は新卒入社からの2年7ヶ月、一度も異動はなく同じ部署のグループに所属しており、退社するときにはある程度の古参メンバーでした。 私が入社したときはグループのメンバーは少なかったのですが、徐々に採用が盛んになり3年目になる頃にはグローバル企業らしく国際色が非常に豊かになっていました。東西アジア圏、東西ヨーロッパ圏、南北アメリカ圏と様々な国出身の人たちが在籍するようになりました。日本にいながらそういった環境で仕事ができたのはとても貴重な経験でした。

1人での開発プロジェクト

入社してから10ヶ月くらいの間は業務機能追加のためのプロジェクトを単独で実施していました。初めのOJTでのプロジェクトを含めると3つのプロジェクトを単独プロジェクトとして取り組みました。1人といってもレビューは上司やチームメンバーにしてもらいます。 この頃はチームとしては完全にウォーターフォールの開発スタイルでした。プロダクトマネージャから要件定義を聞いてすり合わせ、DBスキーマ等を決める基本設計、プログラムの制御を記述する詳細設計、コーディング&単体テスト、結合テスト、QAを順にしていくという具合です。 とにかく一番はじめのOJTでのプロジェクトが大変でした。というのも業務としての開発は全くやったことがないのにいきなりDBスキーマの設計などをしないといけなかったからです。(もちろんメンターの方がしっかりサポートしてくれました。)実装フェーズにおいても学生のころには触れなかったプログラミング言語、フレームワーク、ミドルウェアに慣れる必要がありました。仕事の進め方、開発のやり方の2つのダブルパンチを受けながら必死に食らいつきました。このOJTが終わるころには確かに当初と比べるとレベルアップした実感が得られました。

運用 (システムトラブル対応と問い合わせ対応)

自身のためにも一番残しておきたいのが運用タスクです。前述のOJTプロジェクトが終わるころに運用タスクも他グループメンバーに混ざり行うようになりました。 運用というのはシステムのトラブル対応と問い合わせの調査タスクです。私が所属していたチームが持つプロダクトは業務機能が複雑であるということもあり(ここではこれが主な原因であるということにしておきます)発見することが難しい内在的な不具合が存在するかつトラブルがあると業務的なインパクトも大きいということで運用タスクが重要でした。 この運用へ時間を多くかけてしまうこと自体は問題であり私を含めチームメンバーで常に改善をしてきましたが、この運用タスクを行うことで、サービス提供者としてどのようにユーザにとってベストな対応ができるか、プロダクトを保守していくとはどういうことなのか、どのように開発すればヘルシーな運用をすることができるのか、といったことを学ぶことができました。 またカスタマーからの問い合わせ内容を調査する場合には、プロダクトのユーザは実際にどのような使い方をしているのか、どのような部分を不満に思っているのかを知ることができる場となっておりプロダクトというのはユーザのために作っているということを実際に考えることができるようになりました。(これは当たり前のようですが開発者は開発すること自体に没頭すると頭から離れがちになります。)

チームで開発プロジェクト

2年目になるとグループ全体として大きな変化がありました。既存のプロダクトと同じ業務機能を持つプロダクトをフルスクラッチで開発するという大きなプロジェクトが始まったことです。結果このプロジェクトは1年2ヶ月をかけてリリースがされました。 グループの中で各業務ごとに6つほどの小チームを編成しました。私は1つの小チームのリーダーを務めました。2年目のペーペーがリーダーをやった理由としてはグループには上記で述べた運用も行う正社員の雇用形態のメンバーと主に開発を行うパートナースタッフの雇用形態のメンバーが混ざっていたことにあります。私個人としては最後までこの雇用形態の違いによるロールの違いに違和感を感じていましたが、正社員がプロダクトオーナーとコミュニケーションを取りながら業務機能を理解し開発をリードする立場になるのはグループ全体として自然なことでした。 この大きなプロジェクトから実施されたのがアジャイル開発です。フレームワークとしては一般的なスクラムで実施しました。これによりアジャイル開発というものに曲がりなりにも触れることができいくつかの書籍を読むことでアジャイル開発の思想のファンになりました。 しかしどの現場でも似たようなことになっていると思いますが、スクラムマスターとプロダクトオーナーの経験がありリードしてくれる人材が少ないために実際にはあまりうまく回りませんでした。私は結局ロールとしてはスクラムマスターとプロダクトオーナーの兼任をしていました。各タスクの具体的な完了条件を記載しプライオリティを管理、デイリースクラムやレトロスペクティブといったスクラムイベント内では未経験ながらもチームが良い方向となるように建設的な対話ができるように努めました。 私個人の問題としてはまだ2年目のエンジニアでありながらコーディングをすることから離れてしまいがちになったことです。立場上コードレビューをすることはあってもコーディングをしなくなってしまったことに危機感を覚えました。そしてその危機感は最後まで続き転職に至ったという感じです。

その他

以下のことは上記以外で自分から積極的に取り組み貢献できたなと感じているタスクです。

CIツールの再構築

私が入社したときからグループのプロダクトが持っていたクリティカルな課題の1つにCI上で単体テストが走っていないという課題がありました (ちなみにCIツールはTeamCityと呼ばれるJenkinsと同様のオンプレミスCIツールです)。 開発現場を踏んでいる方ならばわかるようにこれは品質に直結する課題でありあってはならない状況でした。他の開発メンバーも良くない状況であると把握しながらもCIツール環境を構築したエンジニアがグループから離れているかつその設定が複雑であることから誰も手を出せていませんでした。 プロジェクト完了直後のちょうど時間に余裕ができていた時期だったこともあり上司にこの問題の対応のリソースを与えてもらうよう相談し経験が無いながらも取り組んでみました。確かにCIツールが複雑であり設定や自動化スクリプトも複雑であるため始めは面食らいましたが、公式ドキュメントやスクリプトを根気よく読み進め結果的に単体テストをCIツールで動かすことにコミットできました。 また、ビルド結果をBitbucketへプルリクエスト前に表示するようにしたり特定のブランチを定期的にビルドしデプロイツールへ繋げる仕組みの構築などにも貢献しました。

システムアラート通知の改善

上記にて言及した運用タスクでは業務後と休日中のトラブル対応は週代わりの当番制でグループ内で行っていました。 課題としてアラート当番の人とそれ以外の人がプライベートのスマホからでもアラート通知を気づくことができる仕組みが無いことでした。 そこでその当時自分が触ってみたいと思っていたパブリッククラウドでのサーバレスアーキテクチャの機能を利用した安上がりで作れるアラート通知システムを構築しました。 その詳細は以下のリンクにスライドとして公開しています。

https://speakerdeck.com/momotaro98/alertforviber-20171207

これは今でもちゃんと動いておりグループメンバーに利用してもらっているので作ってよかったです。

学んだこと

円滑な仕事の進め方

入社当初がある意味一番苦労しました。これは新卒ならば多くの人がそうだと思いますがそもそも社会人として仕事をするということに慣れるまでが一苦労でした。 以下は、入社直後のOJT期間中に上司やメンター、先輩からのアドバイスをもとに自分用のメモとして取った内容の一部です。

• 自身での判断に迷ったときはすぐに相談をすること
• 報告は事実を述べることに集中しネガティブな内容でも自信を持って堂々と伝えること
• 相談するときはなるべく漠然としたオープンクエスチョンになることを避け、自分の考え(選択肢の1つ)を持ってそれでは問題ないかといった形で相談すること
• 判断を上司に仰ぐとき、選択肢が複数あれば、それぞれの特徴を説明できるように準備しておくこと
• 提案をする際はメリットとデメリットを洗い出し、メリットが大きいこととデメリットの影響が小さいこと、デメリットの対策方法を説明できるように準備すること
• 新しいことを提案をするときは、その影響範囲を把握しておくこと
• レビュー依頼時にはレビュアーに対してレビュー対象のスコープを明確に示すこと
• 憶測で話すクセがあり相手を混乱させてしまうシーンがあるので、事実と推測を明確にして相手に伝えること
• 指示を受けて自分が具体的に何をするかイメージがつかなかったらその場ですぐに聞いて確認すること
• タスクを依頼されたら「いつまでに行えばよいか」のデッドラインの要望を確認し「自分がいつまでにできるか」を伝えること
• 人にタスクを依頼するときは、いつまでにやって欲しいかのデッドラインの要望を伝え相手からいつまでできるかの確認を取ること

報連相、提案のやり方、コミュニケーションに関する内容のメモを多く取っていました。まともなビジネスマンにとっては当たり前なことの羅列だと思いますが、上記の内容は今後もサラリーマンをやっていく上で常に守っていくべきことだと思いここにもメモとして残します。

技術力

この2年7ヶ月で職場で学ぶことができた技術スタック、技術的トピックを箇条書きすると以下の感じになります。

• Git
• C#
• デザインパターン (オブジェクト指向設計)
• クリーンアーキテクチャ
• RDBMS (SQLServer)
• SQL
• CI/CDツール(TeamCity, Octopus Deploy)
• パブリッククラウド(Azure)が提供するサービスのいくつか
  • PaaS環境構築
  • サーバレスアーキテクチャ (Azure Functions)
  • NoSQL型ストレージ (Cosmos DB、Table Storage)
• スクラム開発

仕事にて技術的に得た知識と経験はたまにQiitaの記事にしていました。 以下がそんな記事たちです。

https://qiita.com/momotaro98/items/460c6cac14473765ec14 https://qiita.com/momotaro98/items/3044a1a792eb58d3b6b2 https://qiita.com/momotaro98/items/c4fe0fff0c173e879f2d https://qiita.com/momotaro98/items/6c4d4a061a1d95d4c551 https://qiita.com/momotaro98/items/84fb1ba832f0d4f9f80b https://qiita.com/momotaro98/items/35fb835ce92e5d5bacb2 https://qiita.com/momotaro98/items/62f866433da1a8bcd8a9 https://qiita.com/momotaro98/items/5e37eefc62d726a30aee https://qiita.com/momotaro98/items/99d5ccdce0166ad4d73b https://qiita.com/momotaro98/items/ad859ec2934ee98540fb https://qiita.com/momotaro98/items/7be27447f5f4a5c8bac9

次はなにする？

次の職場では晴れてGo言語でのサーバサイドエンジニアのポジションを与えていただいています。チームへどんどん積極的に貢献していきたいです。 また、遅くともこれからの2年間の内に、Go言語関連のコミュニティの場で発表すること、メジャーOSSへのコントリビュートをしていきたいです。