私の天鳳15年史
気づいたら15年経ちそうです。さすがに記憶が混ざってきているので、のどっちを頼りに簡単に振り返ります。
初期アカウント期（2009～2013）
麻雀歴3年くらいで天鳳を始めました。 半荘専門でした。 最初は四五段を往復している状態でしたが一生懸命勉強していたような気がします。 なんだかんだ2011年年末に初の七段に昇段しました。
当時のことは全く覚えてないですね。 まあ実力が通用するはずもなく半年かからずチャオりました。
2013年に五段で大きく減点割れし、打たなくなりました。 アカウント消そうと思っていたのではなく、いつの間にかなくなった感じです。
東風アカウント期①（2012～2014）
鳳南に参加できたので、今度は東風用のアカウントを作ろうと思い「俺と妖夢」が誕生しました。 妖夢が好きだったのと、たまたま「俺と海」という同人作家が周りで推されていた？のが由来です。 10年以上使うとは思わず、今となっては相当キショい名前となっています。
ちなみに鳳南では「ゆっくり妖夢」という方が長いこと活躍していて、勝手に意識していました。
で、作って割りとすぐ、2012年12月に最初の七段昇段を決めました。降段なしです。 鳳東は鳳南とは別世界の恐ろしい場所というイメージでしたので、震えながら予約ボタンを押していたと思います。
結局またしても通用せずすぐチャオりました。 が、諦めず2013年6月に再昇段、2014年2月に初の八段昇段を果たします。 これもあまり覚えていないです。まだ学生でしたが大学にノートPCを持ち込んで天鳳していましたｗ
その後はまたもふるわず、2014年10月にチャオります。
東南アカウント再作成、並行稼働期（2014～2018）
初期アカウントが五段原点割れの状態で消えたので、新しいアカウントを作ることにしました。 「雷神魔理沙」です。 雷神は東方二次創作の『東方適当録』内での魔理沙の異名から引いています。 早く再開してほしい。。
2015年の2月に七段昇段しますが、5月にはチャオ寸となってしまいました。（その後チャオ） ここから当時五段だった東風アカウントの方にスイッチして鬼打ちし、七段昇段を決めました。
ここからしばらくは並行稼働期間となっています。 すぐに東南アカウントが七段に復帰し、その後しばらくは両方とも七段でした。 東風アカウントはずーーーーっと低空飛行をたどります。多分1,000戦くらい七段3桁をさまよっていたと思います。 一方で東南アカウントは調子がよく、2017年4月に念願の九段昇段を果たします。
めちゃめちゃ確変であっという間に八→九を決めたのを覚えています。 レート1位にもなりました。
東南アカウントはいいところまでいったので保存体制に入り、東風アカウントで九段を目指そうとしました。 鳳東九段が達成できていないため、現在も保存です。
東風アカウント期②（2019～2021）
2018,19はそもそもあまり天鳳を打っていなかったようです。 多分リアルが忙しかったか、音ゲーにハマっていたからだと思います。
この頃は特上にいるときのほうが多かったです。 延々粘ったが実らずチャオ、もう一度上がるもすぐにチャオでした。 この時点で七段坂は1勝4敗です。
2021年9月に確変を引いて七段へ昇段します。
この時期から、PCではなくiPadメインで打つようになりました。タッチでプレイできるのでとても快適です。
鳳東専門期（2021～現在）
ここまでで鳳東の打数は4000強でしたが、そこから3000弱打数を積み上げて現在7000戦強となっています。 七八七八七 と推移しています。
二回目の八段は1000戦超えたので、九段昇段取りこぼしたなーという所感です。 七段坂は東風アカウント通して3勝4敗で、生涯安定段位も6.9台となっています。
2022年に雀魂アカウントを作りましたが、スローペースです。 この時期に入るとiPadメインですがスマホでも打つようになっています。
プレースタイル
いわゆるデジタル雀士だったと思います。ブクブクに構えて、テンパイ即リー。 逆にリーチを受けたらベタオリしていました。
ここ数年でようやくスタイルチェンジして、ヌルっと押し返すスタイルになったと思います。 「アガリ逃しは最大の罪」という考えがベースにあります。 若干門前寄りです。
NAGAなどのAIを用いた検討はやっていません。鳳南十段を目指すとなったらさすがに導入すると思います。 現状は娯楽でやっているので実戦譜で他プレーヤーをみるくらいですね。
ルールが異なるリア麻を打つことで、鳳東が相対化して成長につながっている気がします。 ただ、ここ数年は成長が止まっている気もします。下ぶれているだけかも。
まとめ
冷静に考えて15年も同じゲームもやっていて、かつ段位としては直近10年間あまり変わっていないのはヤバい気がしますが、人の出入り・流行り廃りを継続して見てこれたのでそれはそれで良かったのかなという気がします。
レビュー『プロダクトマネージャーのしごと』
大変お久しぶりです。久しぶりに本を読みましたのでレビューします。
プロダクトマネージャーとは
まず書中で前提とされていたことは、プロダクトマネージャー（PdM）と一言でいっても、明確な定義は存在しないということです。
つまり、会社によって何が期待されているかが異なります。そのため、PdMのポジションにある者は、会社（上長やステークホルダー）からその期待を確認しないといけません。
このように記載されると、かえってPdMは何をすべきか？ということをそこまで深刻に悩む必要がなくて良いなと思いました。
そもそも曖昧な仕事であるという指摘もなされています。
アウトプットよりアウトカム
続けて口を酸っぱくして述べられているのは、「アウトプットよりアウトカムが重要だ」ということです。 つまり、いくらスピーディーに機能を追加していくことよりも、それがユーザーの役に立っているかどうかの方がよほど大事だということです。
言われてみると当たり前のように感じますが、「ユーザーの役に立っているかどうか」を示すのは簡単ではないため、目先のアウトプットに走りがちだとも合わせて指摘されています。
それぞれの章で、コミュニケーションはどうするか？ロードマップはどうするか？ベストプラクティスは何か？といった話が展開されます。いずれの章でも、どうすれば優れたアウトカムを出せるかという観点で考えると理解しやすいと思います。
その他
アジャイルについても１章割かれていましたが、私がアジャイルに詳しくなくあまり読解できなかったのが残念でした。
唯一内容が浅いなと思ったのはリモートワークの章です。ググったらすぐ出てきそうな内容でした。
若干の翻訳物特有の読みにくさはあるかもしれません。このセンテンスは筆者は賛同しているのか反対しているのか、重要なのかそうでもないのかがよく読まないと分からない言い回しになっていると思います。
まとめ
PdMを行うにあたってこの本の内容が前提とされれば、より円滑に進められると思いました。
ストレングスファインダーやってみた
本屋にたくさん積まれていたのでこの機会にやってみました。
https://www.amazon.co.jp/dp/4532321433
性格診断みたいなアンケートに答えると、自分の強みや思考のパターンを提示してくれます。
これは一人でひっそりと抱えるより公開して他人と比較した方が面白いと思うので結果を記載します。
結果
1位 調和性
簡単に言うと、意見の対立があったときにそれをまとめようとする能力です。
言われてみるとなるほどで、あまり自覚はありませんでした。自分の意見を通すことにさほど興味はなく、参加者が納得できて先に進めばよしとする性格だと思います。
営業は向いていないらしいですw
ソフトウェアエンジニアとしては一長一短な気がします。自分で手を動かそうという方向のマインドになりづらそう。
2位 原点思考
過去を振り返ることを好む傾向です。
これは完全に性格ですね。歴史とか昔話が好きなので。 飲み会でエラい人がする昔話は人よりだいぶ好きだと思います。
3位 回復思考
問題解決を好む傾向です。
医者とかコンサルとかソフトウェアエンジニアとかに向いているようです。 これはもはや能力な気がしますが、まあ向いているのは良さそうです。
4位 公平性
ズルを嫌う性格です。大事とはいえ頭が固そう。
最近人よりこの傾向が強そうだということが分かってきました。
公平性が高い人は、抽象的な仕事が苦手らしいです。
5位 ポジティブ
文字通りですが、他人を褒めることが多いらしいです。
最近身につけた性格だと思います。
感想
回復思考あたりは顕著なのですが、これはエンジニアとして仕事をする中で伸ばしていった能力という自覚があります。
最初結果見た時はふーんくらいでしたが、よくよくみると生来の性格と最近身についた能力・性格があるようで面白かったです。
ただ、やってみて思ったのは、自己評価との乖離を把握するため事前に34項目のうちどれが当てはまりそうか予想してみた方がよかったかなと。正確に自己評価できるなら、診断を受ける必要性が薄くなりそうです。
自己評価との比較
項目がたくさんあるので、これは当てはまる・当てはまらないをやってみたいと思います。 ベスト５は結果が出たので挙げません。
当てはまりそう
達成欲、内省
微妙
アレンジ、学習欲、活発性、個別化、コミュニケーション、自己発信、収集心、司令性、責任感、戦略性、着想、適応性、分析思考、目標志向
当てはまらない
運命思考、共感性、競争性、規律性、最上志向、自我、社交性、慎重さ、信念、親密性、成長促進、包含、未来志向
当てはまりそうなのは少なかったです。
レビュー Udemy講座『米国AI開発者がゼロから教えるDocker講座』
dockerとdocker-composeを体系的に学んでみたくて、Udemyで講座を一つ通しました。 かなり良かったのでUdemyの講座としては初めてレビューします。 URLはこちらです。
米国AI開発者がゼロから教えるDocker講座 | Udemy
講座の構成
ざっくり以下の構成です。
- dockerを触ってみる
- Dockerfileを書く
- dockerとAWSを使ってディープラーニング環境を作る（筆者未実施）
- docker-composeを使って複数コンテナで動作するアプリ、CI・CDを作る
講座を選んだ理由
他と比べて*1、構成の筋が良さそうかなと思いました。 dockerコマンド→Dockerfile→docker-compose と学んでいくのは、自然な流れかと。
他に不要な寄り道もなく、ゴール地点としても適切です。
所感
最も学びたかったのはdocker-compose だったのですが、それ以前に自分がDockerfileのInstructionについて何も知らなかったことを思い知らされました。復習というか学び直しになって良かったです。
docker-compose（dokcer-compose.yml）についても、Instructionと対応して記載できることがわかったので、読み書きに対するハードルが薄れたように思います。
ただ、完全な網羅にはなってないと思います。実務に取り入れる際は試行錯誤して、より詳細な知見を取り込みながらになるでしょう。
*1:英語コンテンツも込みで
レビュー『モノリスからマイクロサービスへ』
年末年始の休暇を生かして以下の一冊を読み切りました。
モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド
- 作者:Sam Newman
- 発売日: 2020/12/26
- メディア: 単行本（ソフトカバー）
自分の立場
雑にいうとマイクロサービスを作るぞ！と言われてそうなんだーくらいのテンションでいたのですが、徐々に本格的に理解しないといけなそうなので読み始めた、という感じです。本書で訳もわからずセミナーに参加された社員が登場しますが、あれに似ています。
モノリスとは、マイクロサービスとは
デプロイを一緒にする必要があればモノリスだ、というふうに定義されています。 逆に、独立してデプロイできればそれはマイクロサービスといえます。
そう思ってこれまでの経験を振り返ると、やっぱりモノリスよりも（あまり細かくない）マイクロサービスの方が、開発者にとっては扱いやすいのではという気になります。
何度も確認されること
前半で何度も確認されるのは、「本当にマイクロサービスにしますか？モノリスでもいいんじゃないんですか？」ということです。いきなりアプリケーションもDBも割ると大体うまくいかないですよと強調されています。
何度も勧められること
小さく試して、失敗しても戻せるようにしようねということです。それには、そこそこ深い検討と念入りな準備が必要です。
細かい手法は忘れましたが、どういう姿を目指しますが、どういう手順でそれに向かっていきますか、という話がいくつかあり、参考になります。
トランザクション
それでもマイクロサービスやりますか？と何度も聞かれるのにYESと答え続けるとDB分割の問題に直面します。 たくさん問題がありますよというイントロなトピックで終わります。
ざっくりいうと、分散トランザクションをやめ、原子性を諦めるサーガを使いましょうと言っています。
終わりに
各ドメインへの理解が大事ですよとも書かれています。自分が担当しているシステムや、その利用者にあたるシステムの動きについて、もっとガッツリ情報をインプットしていこうかなと思いました。
架空の企業の話もありますが、７割くらいは実際の企業での取り組みが挙げられているので、話が入ってきやすいです。
レビュー 『AWS IAMのマニアックな話』
今回読んだ本はこちらになります。（リンクはアマゾンとBOOTH）
A5サイズで小さいので、ページ数の割にはサクッと読めます。
IAMに絞ることの意義
AWSのIAMについて特化した解説を出すのは、とても価値があると思いました。
- AWSを使うならば、必ず使う
- IAMの管理が不十分だと、セキュリティ上重大なリスクがある。アカウント乗っ取られるとか
- 枯れた機能である
- これ自身で完結している
枯れた機能であることは、書籍にしても陳腐化するスピードは低いということです。私は、これはAWSが生きている限り陳腐化しないと思います*1。
マニアックというよりは
私としては、マニアックとタイトルについていますが、基本的で重要な話が多いと思いました。特に2章と3章が体系的に基本を学べるので良いです。 2章では、以下の基本的な4機能を中心に説明しています。
- IAMユーザー
- IAMグループ
- IAMポリシー
- IAMロール
そして、3章のチュートリアルでは、最終的にクロスアカウントロールを作成しています。これは、IAMで典型的なユースケースで「7.7 マルチAWSアカウントでの運用」も、このチュートリアルをベースとしています。
補足
「3.4.クロスアカウントロールの作成」については、少しわかりにくかったので、調べながら読みました。その名の通り2つのアカウントで設定が必要ですが、本文中ではどちらのアカウントで設定を行っているのか読み取れません*2。
もちろん、ロールはスイッチ先のアカウントで作成します。そしてprincipalにある999999999999は、スイッチ元のAWSアカウントになります。
やっている事自体は単純ですので、調べればそのものズバリの記事が見つかります。例えば以下の記事を参照すれば問題ないと思います。
【AWS】IAMのスイッチロールの設定方法｜コラム｜クラウドソリューション｜サービス｜法人のお客さま｜NTT東日本
まとめ
IAMを使いこなせれば、AWSを多人数でも快適・安全に利用できることがわかる書籍になっています。手順書ではないので細かい説明を省いているところがありますが、IAMをより使いこなそうとするときのアイディアのネタになるのではないかと思いました。
先行レビュー
レビュー『アウトプット大全』 お気に入りの項目3点
巷で一時期話題になっていたような気がします。
本書を雑に要約すると、「アウトプットをするといいことがたくさんあるからどんどんやっていきましょう。アウトプットっていうのはだいたい話す、書く、行動を変えるの３種類です。」となります。
お気に入り項目×3
本書の中にもありますが、全部を頭に入れなくてもいいと思います。3つくらい参考にできればそれで十分元が取れていると述べています。私も全部の内容は覚えていませんが、特に勉強になったコンテンツを3つ挙げたいと思います。
「なぜ？」を解決する
P33です。インプットをアウトプットに変える段階で、疑問点が生まれます。その疑問点を、解消に時間がかかるからという理由で自分は放置しがちでした。しかし、その疑問を解消することが成長に不可欠とのことです。実際、調べてみるとすぐに疑問が解決することもありますし、解決しなくても問題への知見は深まります。
想定問答集を作る
「15議論する」の一部です。資料を作ってレビューしてもらうと、思ったよりも指摘があってもうちょっとちゃんと作ればよかった……と反省することが多いです。想定問答集を作って議論や資料作成に臨もうと思います。
少し試してみましたが、想定問答を立てるのは難しく、時間がかかります。これもスキルということなのでしょう。
時間を決めて、構成を決めて書く
「38速く文章を書く」に出てくる、文章を書くコツです。時間は決めるとは、「今日は30分で書こう」というレベルでOKです。
早速、今回のブログ記事でも使ってみました。メインにお気に入りのコンテンツ3点を書き、あとは前後にまとめを挟めばいっちょ上がりとしました。
オススメの読み方
本書は1項目2～4ページと細かく、スキマ時間で読めるのをウリにしています。しかし私は読めるときに一気に通すべきという意見です。読んだ中で、特に気に入ったものを次の日から実行していくのが効果的な本書の使い方だと思います。
微妙な点
微妙な点も挙げておきます。もともと、否定的な前評判も受け取っていて、その内容は「作者のドヤ感が強い」というものでした。確かに、ことあるごとに自著やメルマガ等の宣伝が挟まっています。最後の方になってくるとそれが顕著ですので、「この作者めっちゃ自慢してくるなあ」という感想で締めくくられることになります。私は気になりませんでしたが、それが鼻持ちならない人もいると思います。
ドヤ感が強いと言いましたが、作者自身が「継続は力なり」を体現しているので、その点は見習っていきたいと思いました。
