seri::diary

日常

あなたのdocumentation力はどこから?

転職して2ヶ月が過ぎた.7社目である.

転職すると毎回色々と発見がある.前職で発見したのは「自分は英語をしゃべる時に別人格になる」とか「リモートワークは得意だと思っていたけど実はそうでもなかった」といった点である.割とどうでもいい.

今回も新しい発見があった.「自分はソフトウェアエンジニアにしては文章を書くことに抵抗が薄いタイプである」という発見である.
当然,技術書を書くようなレベルの人たちと比べれば遠く及ばないレベルだろうが,どうもticketやPRのdescritpionからDesign docに至るまで,自分は文章を書くことの抵抗が非常に低いということが分かった.

実際,今関わっているprojectの中では一番JIRA ticketのDescriptionが長い自信がある.
全く説明がないものを見つけると自分で分かる範囲で加筆してしまうこともある.Design docも書いたが社内では多分第一号だったらしい.そんな事あるか?俺なんかやっちゃいました?と思ったが,そうなのだそうだ.設計に関するdocumentはもっと増えてほしいので,周囲のSWEにdocuemntation活動を啓蒙し始めたが,これがなかなかうまく行かない.時間がないのもあるだろうが,あまりモチベーションが沸かないようだった.

なぜ自分はdocumentationに抵抗が薄いのだろうか?
多分,文章自体は上手くない.しかし,文章を書いて他人に知識を共有することについてはまぁまぁのスキルがありそうだと自負している.

恐らくはこれまでの経験が関係しているのだろうと思い,過去を振り返ってみる.

前職

前職はバリバリのdocumentation文化だった.
公用語は英語だったがnative speakerはそこまで多くはなく*1,かつ複数タイムゾーンという環境だったこともあり,コミュニケーションの中心は非同期のテキストコミュニケーションだった.

個人差はあったが,SWEはちょっとした小さな機能であってもDesign docをバリバリ書き,JIRA ticketのDescriptionにモリモリ説明を書き,それらのコメント上で非同期に議論を繰り広げていた.また,PRのDescriptionの記述力も非常に重要だった.自分が寝てる間に海の向こうにいる同じチームの同僚にPRをレビューしてもらうためには,十分な量の説明は欠かせないのである.朝起きたらPRが質問コメントだらけだった,では仕事が進まないため,テキストだけで正確に意図を伝えられるかどうかは結構死活問題だった.

SWEだけではなく,product managerも「ちょっとしたshort paperかな」ってぐらいの量の文章を頻繁に書いていた.自分が入社した時は大量のdocumentがあったのでそれらを読むだけで開発に必要な知識のinputが出来てしまうほどだった.当然そういう環境ならば自分もdocumentを書かねばならぬし,なにせ英語を喋った経験がほとんどなかったのでdocumentationでコミュニケーションを図る他になかった.だから,この会社にいた頃に長文を書いて相手に伝える能力はかなり伸びたと思う.

しかし,Design docを書いたのは前職が初めてではない.

前前職

その前の会社でも,日本語だがDesign docに類するdocumentは頻繁に書いていた.タスク管理はGitHubのissueでやっていたがdesciriptionもまぁまぁ書いていた方だと思う.非同期処理をよく書いていたので,自然言語の文章よりはシーケンス図をよく使っていた.

前前前職

その前の会社はフルリモートで受託開発をしていたが,長く常駐していた会社が社内ナレッジの共有とその手段としてのdocumentationを大事にする文化だったので,SES的なポジションだった自分もDesign docは書いていたと思う.

前前前前職

その前の会社ではDesign docに類するような長文はほとんど書かなかった.しかし,当時redmineで管理していたチケットの文章についてはそれなりに気を遣っていたようだ.当時の経験を元に書いた,チケットの書き方に関するエントリがある.

serihiro.hatenablog.com

これを書いたのはもう7年前になるが,結構面白いことを書いている(自画自賛).
何の目的で作られたのか分からないチケット 意味がわからないチケット 後になって振り返ると全然分からないチケット たちと格闘していたようだ.まだ20代の若者だった筆者青年は,これらのチケットと格闘する日々の中で社内におけるテキストコミュニケーションの重要性に気づいたのかも知れない.

恐らくは当時の経験が原点だろう.その前とその前はビジネスメールぐらいで,知識共有のためのdocumentationはしていなかったと思う.まだ大学院にも行っていなかった時期なので論文も書いていなかった頃である.

当時のチケット達の格闘がなければ,今の文章を書く習慣は身につかなかったかも知れないと思うと,まぁなんであれ苦労はしておくものだと,30代も折り返しとなったおっさん臭いことを思う.

ただ一方で,SWEとしてはいくら文章を書いて社内の情報共有に努めた所で大して評価はされないという問題がある.なので,やっぱコスパは良くないスキルなんだよなぁと思う.ただ,まだ顔も知らぬ未来の同僚が,自分が書いた文章で必要な情報をinputすることに貢献できたら嬉しいのが本音なので,これからも必要があればdocumentationに時間をつぎ込んでしまうんだろうなぁと思う.

*1:といっても,普通に英語ができる人ばかりで自分の英語スキルは相対的にクソザコナメクジ以下だった

2020年は色々な意味でリスタートの年だった

総括

仕事

細かい仕事をかなりこなしており,あまり目立った成果は何も残せなかったと思う.プロジェクトを転々としながら,最後に残ったピースを埋める仕事を淡々としていた,という印象である.

人出が必要なプロダクトの環境マイグレーションとかのinternalなタスクを多くこなしていたので,会社としては重要なタスクである一方,会社の事業に与えるインパクトは小さかったと認識している.大企業ではないがスタートアップでもない,という規模の会社で働くのは初めてなせいか,個人のSWEとしてどういった成果や立ち回りが求められるのかを手探りで働くような1年だった.また初めて外国人のマネージャの下で働いたが,常に言語の違いによる壁は感じていたので,来年以降はそういった障害も乗り越えなければならない.

技術的にはインフラ系の仕事が多かった.具体的にはTerraformのconfigを更新したり社内独自の設定ファイルを更新すれば済んでしまうものがほとんどだった.一方で,production環境のためにAWSを触った経験がほとんどなかったため,イチから勉強しなおす良い機会にもなった.あとAmazon ECS on EC2を多用するプロジェクトに参加していたためECSには大分詳しくなった.ネットに出回っている情報のほとんどがFargateを前提としていてEC2クラスタを自前で運用するパターンのパブリックな情報がほとんど無かったため,いつか役に立つかもしれない.

上記のようなインフラ仕事を多くこなしていた関係で,今年はアプリケーションのコードは大して書いていない.Kotolin + DropwizardのWeb APIのメンテ,RubyでちょっとしたスクリプトRails applicationのメンテ,JavaでECS APIを叩く処理などを書いたが,前職時代と比べると圧倒的にコードを書いていない.プロダクトのフェーズが全然違うので当然であるが,運用改善がメインになるとこうもコードを書く機会が減るものかと少し驚いたりはした.要するに,前職はプロダクトの機能が足りなくて次から次へとコードを書いてデプロイする必要性が高く,一方で現職はビジネスに必要な機能は一通り揃っているのでそれをステーブルかつスケーラブルかつ低コストで運用できるようにマイグレーションする必要性の方が高い,というのが自分の見解である.あくまで自分がいるチームが関わっているプロダクトはそのように見えた.

プライベート

勉強

今年はcovid-19で自由に行動できずにストレスが常に高い状態だった.そのせいもあってか独学での勉強の成果は早々に諦めた.元々図書館やカフェで本を読んだり作業するのが好きだったのだが,それらが一切できなくなるストレスは想像以上だった.基本的には仕事を問題なくできているだけえらいと思うことにした.

今年はかろうじて深層学習のオンラインコースを修了するのが精いっぱいだった.現場で使えるディープラーニング基礎講座というJDLA認定講座を受講して修了した.すべてオンラインで,3カ月ぐらいかけてすべての講義と課題を修了させた.内容的には「ゼロから始めるディープラーニング」の内容が半分,残り半分がオリジナルといった感じだった.「ゼロから~」は最初の巻を読んでいたので知っている内容がほとんどだったが*1,GAN周りについてはほとんど知識がなかったので良い勉強になった.この講座は基本的な機械学習線形代数情報理論の知識が前提になっているためか,他社のコースに比べて少しは安くはなっているようなのだが,それでも模試込みで30万円近くしたので何ともしてもE資格に合格しなくてはならない.

あとは競プロもやっていたが,情けないことに時間の確保が難しくて7月ぐらいから中断している.今年中の茶色脱出を狙っていたのだが,思っていた以上にcovid-19の影響は大きかった.

趣味

勉強の代わりといってはなんだが,Overwatchを本格的に再開した.2020年12月31日現在でレートは以下の通りである.

f:id:serihiro:20201231202052p:plain

基本的にタンクとサポートしかやっていない.今年の5月時点ではタンクもサポートもたまにブロンズに落ちするぐらいのレート(1500~1600付近)だったので,そこから考えれば成長はしているようだ.

反省用にプレイ動画をYouTubeにアップしている.最近はゆっくりボイス入れて適当に編集したりもしているがいい気分転換になっている.

www.youtube.com

各月の出来事

1月

プライベート

大学院

  • 修論を提出した
  • 修論を発表した

2月

仕事

  • 今の会社で働き始めたが入社即リモートワークとなる
  • いきなり自分しか日本人がいないzoom mtgに放り込まれて死ぬかと思った

プライベート

  • 株価が世界的に下落していたので積み立てNisaとWealthNaviを始めた

3月

大学院

  • 修了した

プライベート

  • 15年振りにケースからWindows PCを組んだ
  • CourseraのMLコースを始めた*2

4月

プライベート

  • 新アカウントでOWを本格的に再開するがヒラタンが即シルバー落ちする
  • ジャンプ連載中のチェンソーマンが面白くなり連載を追うためハンターハンター連載時以来のジャンプ電子版の購読を始める

5月

プライベート

6月 - 7月

何の記憶もない

8月

プライベート

  • 深層学習のオンラインコースの最終課題をクリアし,無事修了する
  • 自分の振り返り用にYouTubeでOWの動画配信を始める

9月

プライベート

  • OWでタンクゴールド
  • このころから在宅勤務が嫌になってきてストレスが溜まっていた

10月

プライベート

  • ほとんど覚えていない
  • 本をたくさん買った気がする

11月

仕事

  • 在宅勤務がつらくなった旨を会社側に相談して週3日のオフィスワークを再開する
  • その結果体調は改善した
  • 一方でこの時期仕事は忙しかった

12月

プライベート

  • Go Toトラベルで長崎に行き,念願だったカピバラとの対面を果たす

www.youtube.com

仕事

  • 一区切りついた

*1:過去に書評も書いた https://serihiro.hatenablog.com/entry/2016/12/22/000000

*2:7週目まで課題を終えたが8週目でとん挫して以来止まっている

仕事のストレスを緩和するのに有効だった行動

在宅勤務やストレスフルなプロジェクトが原因で,今年の9月〜11月の間はストレスが高い状態が続いていた.その結果,仕事に集中できなくなったり,軽い入眠障害に陥って心療内科に通ったりしていた.それらの症状は複数の対策によって緩和され,現在は問題なく労働している.

本エントリでは,今後のために自分が行った対策をメモしておく.以下,効果が高かったと思われる順に記す.

  • 週3日オフィスに出社して勤務する*1
  • 6時間以上寝る
  • 昼休みは近所を散歩する
  • 週2日ぐらいスタバに行ってコーヒー飲みながら本を読む
  • 食費を気にせずに食べたいものを食べる*2
  • 予算上限を決めずに欲しい物を買いまくる*3
  • 自分の感情の起伏とその原因分析を文章に残す
  • 無限に独り言を言って自分の思考を整理する
  • 自室を掃除する
  • 気が済むまで無限にFPSをやり続ける

*1:会社と交渉して週3日までのオフィス出社の許可を得た

*2:Uber Eatsを活用した

*3:マンガをkindle大人買いしたりiTunesで曲をダウンロードしまくったりした

楽しめるものがなくなった

気がつけば趣味らしい趣味がなくなってしまった.

かろうじてFPS(OW)は続いているのだが,趣味と言われるとどうなのかという感想になる.ランクマでの一定の目標を持ってやっているとはいえ,どこかのコミュニティに所属している訳でもなく,野良で一人黙々とランクマを回し,たまにプレイ動画をYouTubeにアップロードしているだけである.そのような活動を趣味と呼べるのかどうか甚だ疑問である.10年以上前にFPSのクランに所属して夜な夜なクラン内で紅白戦をしたり他クランとの試合をしていた時期があったが,あれはそれなりの時間と労力をつぎ込んでおり,かつ人との交流もあったことから趣味と呼ぶに値する活動だったのではないだろうか.

FPS以外だと,過去に6年間ぐらいアマチュアマンドリンオーケストラに所属していた時期があった.クラシックギターのパートだったのでこの間はクラシックギターが趣味だと言えた.クラシックギターだけで見ればその前にも大学のクラシックギターのサークルに所属していたので,結構長い間やっていた趣味と呼んでも嘘にはならないだろう.しかし,今はどこのオケにも所属しておらず,プライベートでも一切弾いていない.住んでいるマンションは楽器禁止だし,近所に練習場所を確保しにくい地域に住んでいる.そもそも純粋に音楽をやるモチベーションも無くなってしまった.

趣味プログラミングも気が付くとほとんどやらなくなってしまった.今は仕事以外でコードを書く機会がほとんどない.つい1年前まで狂ったように謎のOSSを量産していたり半年前まで競プロもやっていたはずなのだが,何かもう何もする気がしなくなってしまった.せいぜい機械学習Computer Visionの本を読む程度で,コードは数式の定義を確認したりするのに使う程度になってしまった.

どうしてこうなったのか理由は分からない.今は何をやっても「心から楽しい」と思えなくなった.「少しは楽しい」はそれなりにあるが,すぐに空しくなる.鬼滅の刃のテレビシリーズも劇場版も観たが,その話題性に反してどこかで観たような要素の詰め合わせ*1に「一回観たら二度と観なくていいや」という気持ちになった.ジャンプ連載中のチェンソーマンも読み始めたころは純粋に楽しめていたが*2,今は惰性で読んでいるに過ぎない.

*1:ジョジョの1部と2部を足して0.15をかけたものに3部に0.7をかけたものを足したような感じ

*2:しばらくレゼ編の喪失感を引きずるぐらいにはハマっていた

自分の強みらしい強みが30代半ばにしてようやく見えてきた

tl; dr

自分の年代,つまり30代半ばでプライベートで新しいことを継続して勉強できているのは「自分の強み」と捉えていいようだ,という話.

本編

自己啓発本とかを読むと「自分の弱みと強みを知りましょう」といったアドバイスがよく書いてある.

弱みを列挙するのは自分にとって簡単だ. 怠けやすい.飽きやすい.ダメそうになるとすぐ諦める.現状維持を極端に嫌がる.頼んでもないのに上から目線でアドバイスしてくる人をすぐ嫌いになる*1.よくこんなんで会社員をやっているなと思うぐらい弱みは沢山ある.

一方で強みを列挙するのが昔から苦手だった. 20歳を過ぎてから,ストレングスファインダーとかで自己分析をする機会は何度かあったが*2,そこでハイライトされた項目が自分の強みかというとなんとなく納得できないものが多かった.
自分で過去の経験を振り返ってみても言語化できなかった.これは自分の経験の範疇でだが,仕事において誰かから褒められたことがない.社会人を通算9年+やってる*3にも関わらず,自分の上司的な人から何か自分の特徴について褒められたことがない.上司から好かれないタイプの人間だからかも知れない.逆に上述したような弱み+αはさんざん言われてきた.しかし,褒められたり長所を指摘された記憶は全くない.過去に勤務していた企業の社長に「お前はいつかどこかのベンチャーのCTOになりそうだ」と言われたことはあるが,それは長所でもなんでもなくただの「特性」に過ぎない*4

そもそも強みとは何か?weblio辞書で検索してみても,いまいち良くわからない.しかし,「同じような属性の人間があまり持っていない武器」と考えれば多少は心当たりがあった.それはほぼ趣味でやっている勉強である.2020年3月で大学院を卒業して日常から研究活動がすっぽりなくなってしまったため,CourseraのMLコースを受講したり,せっかくなのでE資格も取りたいと思ってディープラーニングのオンラインコースの受講をしていた.最近では画像処理エンジニア検定エキスパートの勉強をしている.新しいなにかを勉強するのは自分にとっては自然な行動で,大学院入学前にも数ⅡBレベルの高校数学を勉強し直して数学検定2級を取ったりしている.その前は,具体的な資格ではなく新しいプログラミング言語フレームワークの使い方を勉強している時間が長かったような気がする*5

こういう勉強を苦だと思ったことはなかった.もちろん好きでやっていたので苦ではないのは当然なのだが,こういう行動を取れる人は,自分の同業者かつ30代半ばという狭いクラスタにおいては,どうも珍しいタイプであるらしいということが分かってきた.

同年代の同業者と話をすると,プライベートの時間で何か自分が知らないことを継続して勉強しているのは自分以外にほとんどいなかった.例えばE資格を取るためにディープラーニングの講習を受けたとか,TOEIC/TOEFLで具体的なスコアを達成するために英語を勉強しているとか,オンラインのコースで高校数学を勉強しなおしているとか.そういう人は自分が20代の頃は身近に結構いたものだが*6.しかし,どうも30代半ばになるととてもレアになるようだ.もちろん,自分と同年代で自分よりも沢山資格を取りまくっていたり,競プロでめちゃくちゃ結果を出してたり,自分よりも何倍も技術書を読んで知識が豊富だったり,国際会議にガンガンに論文通している化け物みたいな人や,起業してCxOをしている人,などなど,何人も知っているので,自分が同年代の中ですごいとは全く思っていない.とは言え,平均値よりはマシな方なんじゃないかな,程度の感触を得つつある.

何が言いたいか分からなくなってきた.とにかく,もし今自分がどっかの会社の面接を受けるとして,そこで自分の強みについて聞かれたら,

  • プライベートの時間を使って業務とは関係ないけど何かを継続して勉強していて
  • それぐらい新しいものを覚えることに関してはモチベーションはあるし
  • 取得した資格や業務経験によってその成果も客観的に示せるよ

ぐらいのことは言ってもバチは当たらないんじゃないかな.
30代半ばにして初めてそういう発見をしたよ.散々色んな人にボロクソに言われて否定されてきた自分の人格と人生だけど,少しは自分で自分を肯定できそうな要素を見つけたよ,という話.

*1:上から目線でアドバイスできる人は,自分よりも会社における立場が上であることが多いので本来であれば仲良くしておいた方が得することが多いと考えている.

*2:不思議なことに20歳の頃にやっていたPCを教えるバイトでもやったことがある

*3:2009年4月に学部卒で就職から無職になることなく働き続け,2018年4月-2020年3月は大学院にいたので11-2=9年

*4:なお,経営にも関わるタイプのCTOポジションには全く興味がない

*5:例えばRubyRailsを独学で覚えて自作webサービスPHPからRubyにmigrationしたりしていた.

*6:一番すごいと思った人だと,フルタイムで働きながら公務員試験を受けようとしているやつがいた.

プロダクトは運用フェーズの方が圧倒的に長いという事実とどう向き合うか

現職を含め,これまで3社の自社サービス企業*1で働いてきた*2

1社目ではメインのプロダクトがすでにサービスインしていた.主要な機能は大体完成しており,徐々に新規ビジネス案件のプロジェクトが減って運用フェーズに移行し始めるタイミングだった.最初の仕事は社内向け管理画面のちょっとした修正とかだったと思う.当時,20代半ばの若手で経験も少なかった自分は,そういう最後まで残っていた重要度の低いタスクを担当していた.入社して半年ぐらいでデカい新規開発プロジェクトを担当した後は,本格的にチームの人数が減り始めて運用フェーズに移行していった.

2社目では入社時点ではサービスインはしていたものの,割とやった方がいい残タスクが結構残っている状態で,バグも結構残っていた.自分の入社直後の仕事は,開発体制の見直し,バグの可視化,バグつぶしがメインだった.別にそれをやってくれと言われた訳ではないが,まずは体勢を整えないと安心して仕事ができなさそうだったのでそれまでの知見を活用してどんどん改革していった.それまで雑多にWeb APIをリリースしていたのが,決まった曜日,決まった時間帯の週1回になったのは自分がそう決めたからである.ただ,それらを片付けて綺麗にした途端,ビジネス要件的にはもう十分といった感じになってしまい,割とヒマになってしまった.幸いにもその後いくつか難しめのプロジェクトも経験できたが,やがてビジネス起因のタスクは発生しなくなり,Web API本体のリファクタリングバグフィックスやライブラリのバージョンアップ,それもやり切ってしまうと社内データ分析基盤の整備や他プロジェクトの手伝いに精を出していた.それが最後の1年間ぐらい続いた.

3社目は現在の会社だが,サービスインしてからの時間はこれまで経験した会社の中では最も長い.現在所属しているチームでは運用をいかに安定させ,内部コンポーネントリファクタリングにより開発コストを低下させる作業に注力している.自分の場合,現在は自社サービスのコンポーネント間だけで使われるプロダクトを改善している時間が大半を占めている.

これまで経験して思うのは,ゼロベースで新規にプロダクトやcustomer facingな機能をゴリゴリ開発しているのはほんの一瞬で,その後は長く運用フェーズが続くというライフサイクルである.運用フェーズが長く続いているというのは,言い換えればビジネス的に成功している,もしくはクローズするほどひどくない,等のポジティブな事実を示している.そのため,経営視点で見れば良い状態だと言える.実際,自分の収入も運用フェーズが長いプロダクトの企業ほど改善されてきている気がする.

ただ一方で,運用フェーズが長いと技術的に新しいことを試す機会が減る,やることが同じことの繰り返しになって単調になる,という事実と向き合わなければならなくなる.

技術的に新しいことを試す機会が減ること自体は,収入を得続ける点においては問題ではないと考えている.例えば,同じ会社の同じプロジェクトに居続けるなら,同じ技術を使って仕事を続けていてもすぐに問題になることは少ないだろう*3.実際,自分も前職では2年3カ月の間ずっとRailsのWeb APIのメンテナンスを続けていたが,それで仕事を失いそうになることはなかった.その前はJava + Springだったが同様である*4

一方,「やることが同じことの繰り返しになって単調になる」問題は,未だに自分にとって深刻な問題として残っている.多分,一般的なソフトウェアエンジニアと比べても自分は相当な飽き性なんだろうと思う.もしくは,プライベートで楽しみを見つけることが下手で,仕事に楽しみを求めすぎてしまっていたことも原因の一つであると考えている*5.先に書いたように,プロダクトはいずれ運用フェーズに移行する.Webサービスは永遠のベータ版*6なんて言われていた時代があったが,本当にそうだろうか.足りないものを片っ端から作らなければならない,毎日のようにコードを書かなければならない,そんな夢の日々は一瞬で終了する.ベンチャーで働くソフトウェアエンジニアというのはそういう生活をしていると想像する人もいるのかも知れないが,そんなフェーズはどんなプロダクトでも一瞬だと思う. *7

この傾向はAWSやその他便利なサービスを活用することで近年さらに顕著になっていると考えている.インフラエンジニアがいなければherokuに重課金すれば十分で,サーバを持つにしても当然のようにIaaS*8で,メールを送信するのに自前でメールサーバ立てるなんてのは大抵の場合は不要で外部サービスに丸投げすれば十分で,GitHub ActionやCircle CIでリッチなCI/CD環境を最初から低コストで整えて開発をスタートできる*9.バックエンドエンジニアがいなければFirebaseで代替してフロントエンドだけを開発すれば場合によってはサービスインも可能な時代で,もはや自分のようなほぼWeb API開発だけを専門としてきた人材は,自社サービスを運営するベンチャーにとって必ずしも必須ではないと考えている*10

このような状況下で,自分は今後どうすればいいのかと頭を抱えることが増えた.今後も同じ問題に遭遇したら,これまでのように「開発フェーズ」にあるプロダクトを作っているベンチャーを探して転々とするのか,勝負する領域を変えて長く戦える場所を探すか,できることを増やして*11運用フェーズに入っても開発を続ける機会を生み出す別の能力を身に着けていくか.何が正解なのか分からないが,このままだと過去と同じことを繰り返すだけになってしまう.転職自体はそこまで苦ではないが,いい加減それ以外の手段も持ち合わせていきたい.

*1:この言い方もう死語かも知れないけど,いわゆる受託開発専門じゃない会社を指している.

*2:なおSIer + 受託開発も3社経験している.

*3:2年7カ月以上同じ会社にいたことがないダメ人間なので実態は良く分からない.けど別に4年いようが5年いようが,会社がメインで使っている技術スタックが変わらなければ本人の技術スタックが変わらなくてもすぐにその人の評価が下がる,プロジェクトにありつけなくなる,といった事態は起きないのではないだろうかと考えている.

*4:ソフトウェアエンジニアとしての評価と使える技術の幅はそこまで比例しないものである.

*5:反省してプライベートでいくつか何の役にも立たない個人プロジェクトを積極的にやるようになったのはつい3年前からの話だ.

*6:https://gigazine.net/news/20060823_beta/

*7:なお自分はWindows NTの開発記である「闘うプログラマー」やFaccebookの立ち上げ時期の様子について書かれた「フェイスブック 若き天才の野望」に出てくるデスマ話が大好きで,なんで自分はこれらのプロジェクトに参加できなかったんだと読む度に悔しい気持ちになる.

*8:これも死語かも知れない.AWSとかGCPとかAzureの仮想サーバ等の計算リソースを指す.

*9:昔はJenkinsってやつを社内で飼ってた企業が多かった.

*10:これが自分が仕事辞めて大学院に進学した理由でもある.https://serihiro.hatenablog.com/entry/2018/04/23/213418

*11:例えば今年に入ってからDLを中心に機械学習を勉強している.最近は畳み込みフィルタを適用する本来の意味について知りたくなってComputer Visionの勉強も始めた.

ダメージの実力差に応じたタンクの戦い方

シーズン24においてシルバー・ゴールド帯では以下のタンク編成をよく見る.

  • ハルト・ザリア
  • ロードホッグ・ザリア
  • D.Va・ザリア
  • ウィンストン・ザリア

当たり前だが,これらさえピックしていれば勝てるという保証は全くない.2盾時代はオリシグ以外にほとんど選択肢がなかったようであるが,今や2盾コンビを見る試合は稀になった.

自分がタンクを選ぶ基準は主に味方の他ロールの実力や余裕の有無である.

特にダメージの実力差が重要だと考えている.味方ダメージが強ければタンクは火力を出す必要はない.フォーカスを集めるタンクの基本動作を忠実にこなせばよい.しかし,味方ダメージが圧倒的に弱い場合は,タンクだけで火力を出さないと味方ダメージが何もできない状況に陥りがちである.
タンクが火力を出さないといけないケースがあることを知らないタンクの場合,永遠にハルザリで盾を貼ってガッツリ守っていてボロ負けする試合をクイックではよく見る.*1

味方ダメージの方が強い場合

味方ダメージが相手を圧倒している場合は無理して火力を出さなくて良い. この場合はダメージの編成によるが,大体ハルザリで味方サポートをしっかり守りながら戦うことが多い.裏方の仕事さえキッチリやっていれば勝てる.

ただ,あまりに圧勝していると,たまに相方タンクが敵陣に特攻し始めて無駄死にして逆転負けするケースもある.例えば敵陣に不要なロングチャージを繰り出し始めるラインハルトをよく見る.経験上,こういうタンクには何を言ってもしょうがないので黙っているのだが,「勝てる試合でふざける」のは絶対に止めるべきである.勝てる試合はさっさと勝ってレートを上げて次に行けばよい.

味方ダメージの方が弱い場合

この場合の試合で勝てるかどうかで勝率が50%を超えるかどうかが決まってくる.以前の自分の1シーズン間における勝率は50%を割っていたが,その頃はこのケースの試合で全く勝てていなかった.

このケースにおいては,相手ダメージにプレッシャーを与えて味方ダメージに活躍してもらえれば打開できる可能性が生じる.*2

例えば,相手ダメージがフランカーで味方ダメージよりも強い場合,味方ダメージを瞬殺もしくはスルーして裏取りして味方サポートを狙いに来るケースがある.
味方ダメージが強ければそのまま追い返してくれるのだが,味方ダメージが弱い場合はタンクがその役割を担う必要がある. 具体的には,タンクは相手フランカーに何waveか積極的に絡み,相手がサポートを狙いに来なくなるまで相手をしなければならない.こちらのタンクが十分に機能していることが分かれば,まともなフランカーなら狙いを変えるはずである. この場合,ピックするのに良いのは近距離でも中距離でも火力が出せるロードホッグやシグマなんかが良い.ハルザリだと中距離での撃ちあいに勝つのが難しい場合がある.伝統的な2盾もダイブ編成に強とされているが,経験上低ランク帯で2盾をやると連携がうまくいかないことが多いので相方タンクには期待せず自力で何とかした方が良い.

相手フランカーを無事追い返せたとしよう.もう相手フランカーや味方サポートを狙って裏どりしてこなくなった.何ならピックをヒットスキャン系に変更してきた.そうなれば次に攻撃に転じる必要がある.
ここで問題なのは味方ダメージが相手ダメージと直接当たると高確率で負けてしまう点である*3.だからまずは味方タンクが相手ダメージに当たる必要がある.そしてなるべく早くキルを取らなければならない.
この役割として適任なのは,瞬間火力が高いロードホッグやシグマである.もしくはウィンストン・ハモンドといったダイブ系.それ以外は瞬間火力に乏しいので出さない方がいい.何とかしてタンクで1 pick取れれば戦局は一気に有利になる.こうなれば味方ダメージも活躍できる.味方タンクが前線で頑張っている間に味方ダメージにウルトを貯めてもらい一発逆転してもらう流れも期待できる.

とにかく味方ダメージに活躍してもらうことだけを第一に考えて戦う.この間にサポートが犠牲になってしまうケースもあるかもしれないが,それよりも前線を押し上げられないと試合には絶対勝つことができない.時には相手のキルに徹する必要がある.

味方サポートがタンクに回復を回せない場合

これも味方サポートの実力差問題みたいなものだが,味方ダメージの回復に手いっぱいで味方タンクを回復できないサポートがたまにいる*4.上述した通り,味方ダメージに余裕がなければタンクで火力を出して戦うのが良いと自分は考えているため,タンクにも常にある程度回復を回して欲しいところではある.しかしそれができないケースもある.

この場合,自分はタンクはロードホッグかハモンドをピックする.ロードホッグは自己ヒールができるし,ハモンドは回復パックを取りに行くまでの移動時間が短く,こまめに前線を離れて回復パックを取りに行っても素早く戻って来られる.このようなヒーローを使って回復不足を補うと良い.

逆にこの状況下で出してはいけないヒーローとしてはラインハルトだと考えている.ラインハルトはヒールもザリアからのバリアもなければ,前線でシールドを張っておくぐらいしかできなくなる.ゴールド帯に来てこの傾向が顕著になったせいか,ハルザリ以外でのラインハルトのピック率は低くなったように思える.シルバー帯だと頑なにラインハルトしか出さないタンクが結構いて,自分が味方フランカーに合わせるためにウィンストンをピックしてもずっとラインハルトのままだったりしていた.ピックプールが狭いとこういう時に明らかに勝率を落とす要因になると自分は考えている.

*1:もちろんランクマでも見られるが,自分がタンクをやっていればこういう事態は避けられる.

*2:一方で何をやってもダメなぐらい実力差がある試合もあるのでその場合は潔く諦めよう.スマーフが蔓延るOWのマッチングは諦めが肝心である.

*3:リスポーン直後に繰り返し死んでいるダメージを見たら「ダメージ負けしている」と判断すべきだ.

*4:キルを取ることに執念を燃やすアナ,相手に突撃するイキリモイラ/ルシオ,パーティー組んでる相方のダメージブーストしかしないマーシーなども含む