$yanutetsu->{blog}

プログラマ三大美徳なPM

2020年に読んだ書籍

書籍

やぬてつです。

この記事は備忘録です。 プロジェクトマネジャーとして一人前になるためにと思って読み始めました。（去年から） 何を読んだのかを忘れてしまうので、年単位で記録しておこうと思っって書き留めました。

2020年に読んだ書籍一覧

  • ドラッカーさんに教わったIT技術者が変わる50の習慣
  • ライト、ついてますか
  • アジャイルサムライ
  • Manage It!現場開発者のための達人式プロジェクトマネジメント
  • 熊とワルツを　ー　リスクを愉しむプロジェクト管理
  • エンジニアあのためのリスクマネジメント入門
  • 一億人の英文法
  • ITILはじめの一歩　すっきりわかるITILの基本と業務改善のしくみ
  • プロジェクトマネジャーが知るべき97のこと
  • まんがでわかる　理科系の作文技術
  • The DevOpsハンドブック　理論原則実戦のすべて
  • Team Geek　ーGoogleのギークたちはいかにしてチームを作るのか
  • 予定通り進まないプロジェクトの進め方
  • 会議後、みんなの行動が加速する議事録の取り方
  • みんなが知っておくべき運用設計ノウハウ
  • 対話型マネジャー部下のポテンシャルを引き出す最強の育成術
  • 「プロになるためのWeb技術入門」ーーなぜ、あなたはWebシステムを開発できないのか
  • 曖昧性とのたたかい
  • UNIXという考え方ーその設計思想と哲学
  • ソフトウェアアーキテクトが知るべき97のこと
  • 人に頼む技術
  • プロジェクト実行完全ガイド
  • 予定通り進まないプロジェクトの進め方
  • リモートワークの達人
  • メンタルヘルスマネジメント検定公式テキスト
  • ビジネスマネジャー検定試験公式テキスト
  • アドレナリンジャンキー
  • CTO・エンジニアリングマネージャー養成読本
  • 鬼滅の刃全巻

ドラッカーさんに教わったIT技術者が変わる50の習慣

６年ぶり２回目の読了 改めて読むと学びが多い。PMやっているので中盤以降が特に有益。 今は他にも良い本があるかもしれませんが、読みやすいですしとてもおすすめです。

ライト、ついてますか　ー問題発見の人間学

読みかけになっているのを思い出して、最初から読み直しました。 問題を見つけるための物事の見方を教えてくれるような感じでしょうか？読んでいて色々と気づきがありました。 言い回しが少し難しくて私は解釈に時間がかかりましたが、頑張ったんだけどなんだか振り回されちゃったなーとかいうことが多々ある人は読んでみると良いかもです。

アジャイルサムライ

プロジェクトへのアプローチの違いなのかな？ 自覚していなかったけど私の開発スタイルは割とアジャイルな感じで開発してたんだなーと思いました。 散らかっていた知識が整理されてとても有意義でした。 まだ読んでないのであればおすすめです。

Manage It! 現場開発者のための達人式プロジェクトマネジメント

アジャイルよりだけどアジャイルに限らずいろいろな方法によるプロジェクトマネジメントのことを学べました。 様々な場面で基準が必要であり、基準があることで舵を取る方向が決まり、プロジェクトをどうするかというところにたどり着くのかなーと思いました。 プロジェクトを運営していて「どうしたらいいかわからないぞ」って時は割とこういう基準がない時なのかなーと思ったり思わなかったり。 そこまでおすすめではないですが世の中アジャイルだけではないのでアジャイル以外のアプローチも押さえるって感じで読むと良いかもです。

熊とワルツを - リスクを愉しむプロジェクト管理

9年ぶり2回目のトライで読了 リスク管理の必要性について有名なプロジェクトを持って説明してありとてもわかりやすかったです。 リスク管理とはなんとなくリスクヘッジばかりに考えが言ってしまったが、リスクヘッジにもリスクがあることやコストが増えるなど学べました。 リスク管理ってなんだろう？意味あるのかな？とフワフワっとした印象がある方は読んでみてください。 全編を読んでから付録Aを読むととても有意義です。あ、本編ももちろんすばらしいです。

一億人の英文法

3年ぶり2回目の読了 英文法を学校の英文法学習とは違った切り口で学んで行きます。コアとなる考え方から少しずつ機能を足して行って気がついたら（書籍の最後の方）には複雑な文も読解できるようになるイメージでした。今まで英文法の学習は苦手だなーと思っているのであれば読んでみると良いと思います。以前に比べてだいぶ英文解釈が良くなったと実感しています。 今回は読書として読んでみました。結構ボリュームがあったのですが割とサクサク読み進められた印象でした。 おすすめです。

ITIL はじめの一歩 スッキリわかるITILの基本と業務改善のしくみ

豊富なストーリーでITILを説明してくれます。とても入りやすいです。まずはこちらで全体像を押さえてから本格的な学習を始めるのも良いかと思います。 多分私がやりたかったのはこれだと思う。

プロジェクト・マネジャーが知るべき97のこと

結構刺さる記事があってよかった。刺さらない記事もあったけど。 PMで集まってお酒飲みながら話している感じ。 共感する部分とか学びがあったので、今年上半期では1番のインパクトだった。

まんがでわかる　理科系の作文技術

良い文章とはどういうものかをシュッと確認するのに良いと思う。 具体例がもう少しあると助かる。

The DevOps ハンドブック 理論・原則・実践のすべて

DevOpsってDevとOpsが合体することが目的ではなくて、リードタイムを減らして、フィードバックを速やかに伝えて、自己学習も促進するような感じ。 TGからお客様に対してのCI/CDなどは弊社では普通の開発スタイルとして定着しつつあると思いますが、お客様からTGへのフィードバックとナレッジ共有などの学習面が足りていないのかなーと思いました。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

7年ぶり2回目の読了 謙虚・尊敬・信頼の三本柱を軸にしてチームについての話。 すごく重要だと思う。

予定通り進まないプロジェクトの進め方

「プロジェクトはそもそも思った通りにいかないようにできている」「プロジェクトは未知と想定外だらけ」という前提に対して、勝利条件・中間目標・施策・廟算八要素などを設けて、都度軌道修正しながら勝利条件に向かってプロジェクトを進める方法という感じでした。 前提条件の言い切りが衝撃的でよかったです。 あとは定量的に目標を設定すると動きが取れなくなるという記述があって考えさせられました。定量的だと0か1かと言う状態になって膠着してしまうことが発生するとか。そして目標達成を諦めて目標を変更する。なんかどこかで聞いたことあるシチュエーションですよね。定性的に設定して幅を持たせることも最終的な目標達成のためには必要であると記述されていました。 全体的にざっくり言うとPDCA大切ですね。

会議後、みんなの行動が加速する議事録の取り方

議事録をちゃんと作成しようと思いました。 最近議事録の取り方って何が正解なのか迷っていたので読んでみました。自信を持って議事録を作成できそうです。

みんなが知っておくべき運用設計のノウハウ

やらなければならないことはなんなのかがわかったきがする。 安いから読んでください。おすすめです。

対話型マネジャー 部下のポテンシャルを引き出す最強育成術

具体的にどうやって話すのかのサンプルがわかりやすくてよかった。 1on1のやり方の一つとして良いと思う。

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

Webアプリケーションについて基礎から発展していく形で説明されていて、なぜその技術が必要なのかというところがわかってとても良かったです。 今はこの書籍に書いてあること以上の技術が既に存在していてこの書籍を読んだだけではまだ足りないものがあるかとは思いますが、基礎固めとしてはとても良いと思います。 Webアプリケーションの基礎に不安がある方や新たにWebアプリケーションを作成することになった方に特におすすめです。

曖昧性とのたたかい

とても良かったです。 ソフトウェア開発しているエンジニアは全員読んだ方が良いです。 当時からプロジェクトマネジメントの勘所は変わっていないのだなと驚きます。 筋トレなら体幹を鍛えるイメージ。

UNIXという考え方―その設計思想と哲学

とても良かったです。この先机のすぐ手の届くところにおいておく本になりそう。 自分のソースコードに自信がない人は一読した方が良いと思います。 こちらの本を読むことで設計が良くなると思います。

ソフトウェアアーキテクトが知るべき97のこと

良かったです。私はそうだよねーって感じで読みました。 将来のキャリアパスがマネジメントではないのであれば必読だと思います。 正直言うと、鈴木雄介さんが監修ということで慌てて読みました。

特にインパクトを感じた書籍

  • プロジェクトマネジャーが知るべき97のこと
  • 人に頼む技術
  • 曖昧性とのたたかい
  • UNIXという考え方ーその設計思想と哲学

プロジェクトマネジャーが知るべき97のこと

一つ一つのエッセイを噛み締めながら読んだ本の一つ。 いろんなエッセイが入っているタイプなので、必ずどこかにヒットする的な感じ。この本に何度助けられたことか。

人に頼む技術

プロジェクトマネジャーになって結構キツかったのが、人に何かを頼むことだったので読んでみました。 とてもロジカルに記述がしてあって納得しながら読みました。こちらの書籍を読むことでかなり人に物事をお願いすることに対する抵抗を和らげることができました。 プロジェクトマネジャーになると一人で全てをやることを求められていなくて、チームを動かすことが求められるので、どんどん人にお願いすることが必要になってくると思います。お願いすることが苦手な人は一読してみると良いと思います。

曖昧性とのたたかい

プロジェクトマネジメントの本。当時から本質は変わらないのかな？と考えさせられるもの。今年のタスク振り分けの根本はこの本を参考にしていました。そして、その効果は絶大。 最近出版された新しい書籍ももちろん良いですが、こういった昔からある書籍も良いですね。

UNIXという考え方ーその設計思想と哲学

こちらも当時から本質は変わらないのかーと考えさせられた書籍。 ソースコードレビューをしたときに、なんとなく感じる違和感に対してこういった哲学があると説明がつくのかなとか思ったり思わなかったり。 この本を読んだことで自信を持ってレビューできるようになりました。 自分のソースコードに自信のない若手には読ませようと思っています。

まとめ

物事を始めるのであればまずはインプットということで、今年はかなりのハイペースで書籍を読みました。身についてないものもあるかと思うので、来年は2回目3回目にも挑戦しようと思います。 でも、まだまだ読みたい本があるんですよねー

ERGO M575

ガジェット

親指トラックボール買いましたー

いろんな人からお勧めされていたのですが、なんやかんやで買ってなくて、ほとんど食わず嫌い状態でした。 まだ使い始めて半日ですけど感想を書きます。

握った感じがとても自然な感じがします。良いです。肩こりがひどいのでこれで肩こり改善になれば良いなと思っています。効果があるかは検証が必要です。

親指トラックボールは全然慣れないです。もう少し時間が必要そうです。

クリックは静音ではないですが、しっかりクリックした感があって良いです。

ホイールもクリック感？があるタイプです。好みの問題かな。

トラックボールが静かでマウス移動が静音です。他のマウスでもマウスパッドを下に敷けば静音になるかもですけど、そのままで静音です。良いです。

スタンディングデスクとの相性が良いような気がします。手首が固定されているせいか無駄な力がいらない感じがします。座っている時は普通のマウスの時もトラックボールでもアームレストを使っているので差がわからなかったのですが、立って操作すると違いがわかりました。トラックボールの方が腕や肩に力が入っていない状態で操作できる感じがしました。本当に肩こり改善に効果があるかもしれないです。

MagicMouse2と比べるとすべての操作をマウスだけでやろうとするとイライラっとすることがあります。まだ操作に慣れていないというのもあるかもしれません。ですがこれが左手も使うかって思考になって右手だけに負荷が集まらないかもしれないと思いました。

まとめ

面白いデバイスを手に入れることができたと思います。まだ使い始めて1日目なのでこれから印象は変わると思いますが、まずはファーストインプレッションということで残しておきます。

www.amazon.co.jp

Design It! プログラマーのためのアーキテクティング入門　読了

書籍

結構難しかった。 アーキテクチャってどうやって作成するものなのか体系的に学習したかったので読んでみました。 アーキテクチャの必要性やアーキテクトの役割など今まで具体的には意識していなかった部分がだいぶクリアになった気がします。

もし、今プログラマーで将来のキャリアパスとしてマネジメントを選択しないのであれば、これは絶対に身につけておいた方が良いと思いました。

もちろんプログラマーでなくてもとても有益な情報がたくさんです。

www.amazon.co.jp

MagicMouse2

ガジェット

やぬてつです。

この記事はMagicMouse2を語りたいがために書いた記事です。

MagicMouse2気になりますよね。私なりのメリットデメリットを書きたいと思います。

メリット

クリック感が良い

とても気持ちの良いクリック感です。満足感が半端ないです。無駄にクリックしたくなるほどです。まずはクリックしてみてください。

Macの操作にマッチしている

縦スクロールと横スクロール、さらに画面切り替えやアプリケーションの切り替えの操作がタッチやスワイプでできるのでとても良い体験を得られます。

世界観にマッチしている

Apple純正ということで完全にマッチしています。気分が良いです。ユーザーの所有欲をくすぐりそれを満足させてくれるUX最高です。購入した理由の半分がコレだったりします。

デメリット

クリック音が大きい

最近の静音マウスを体験してからだとクリック音が気になります。 最近はオンラインMTGが増えいていて、このクリック音を拾ってしまうことが、私としてはとても気になります。ただし、会議に参加していた他の人にクリック音が気になるかと尋ねたところ、ほとんど気にならないという回答をもらいました。そこまで気にする必要はないかもしれません。

充電時がかっこ悪い

充電する際にひっくり返してケーブルを接続する必要があります。この格好がとてもかっこ悪いです。 今まであんなにかっこ良かったのに1ヶ月に1回くらい見せる顕な姿、ある意味ギャップ萌えです。

まとめ

機能面だけでなく、体験としても、とても満足感が高いデバイスです。Macを利用しているのであればぜひ使ってみてください。

GitHub CLI 完全に理解した

GitHub

やぬてつです。

この記事はGitHub CLI を何に使ったら良いか迷っている方の一助になればと思い書きました。

みなさん GitHub CLI ご存知ですか？CLI好きにはたまらない機能ですよね。 でもですよ。正直言ってWebでもいいですよね。操作慣れてますし。 そんなことを考えていたら結局WebでIssueを大量作成するPM作業が日々続いていました。

私のプロジェクトでは一つの課題につき3つのIssueを作成しています。メインである課題、テストレビュー、テストの3つです。これをスプリントごと7課題〜10課題、つまり多い時で30Issue作成します。

1つの課題につき3つ作るだけでも面倒くさいし、定型文章も多いので、マウスによるコピペが大量に発生します。テンプレートを利用していてもめんどくさいです。これは自動化したいですね。

そこでCLIですよ。

早速使ってみる

今回はIssueを作成するコマンドを作成します。 Issueを作成するコマンドは以下です。

(///ᴗㆁ✿) < gh issue create

タイトルを追加します。

(///ᴗㆁ✿) < gh issue create --title "タイトル完全に理解した"

本文を追加します。

(///ᴗㆁ✿) < gh issue create --title "タイトル完全に理解した" --body "本文完全に理解した"

ラベルを追加します。

(///ᴗㆁ✿) < gh issue create --title "タイトル完全に理解した" --body "本文完全に理解した" --label complete

プロジェクトを追加します。

(///ᴗㆁ✿) < gh issue create --title "タイトル完全に理解した" --body "本文完全に理解した" --label complete --projects understand

マイルストーンを追加します。

(///ᴗㆁ✿) < gh issue create --title "タイトル完全に理解した" --body "本文完全に理解した" --label complete --projects understand --milestone asap

３種類を並べてみる

私のプロジェクトでは3つを同時に作成するので、タイトルと本文、タグを変更して作成します。 作成してまとめたものが以下になります。

(///ᴗㆁ✿) < gh issue create --title "タイトル完全に理解した" --body "本文完全に理解した" --label complete --projects understand --milestone asap

(///ᴗㆁ✿) < gh issue create --title "テストレビュー_タイトル完全に理解した" --body "テストレビュー完全に理解した" --label test_review --projects understand --milestone asap

(///ᴗㆁ✿) < gh issue create --title "テスト_タイトル完全に理解した" --body "テスト完全に理解した" --label test --projects understand --milestone asap

シェルスクリプトでいい感じにする

これを実行しただけではコピペがまだ必要な状態でミスが発生してしまいます。 シェルスクリプトでゴニョゴニョしていい感じにしましょう。 出来上がったのがこちら。

project=understand
milestone=asap

title=$1;
main_body=$2;

main_title="${main_body##*/}_${title}"
log=`gh issue create --title $main_title --body $main_body --label enhancement --project $project --milestone $milestone`

review_title="テストレビュー_${main_title}"
review_body="テストレビュー完全に理解した　#${log##*/}" # メインIssue番号を取得
gh issue create --title $review_title --body $review_body --label test --project $project --milestone $milestone

test_title="テスト_${main_title}"
test_body="テスト完全に理解した　#${log##*/}" # メインIssue番号を取得
gh issue create --title $test_title --body $test_body --label test --project $project --milestone $milestone

タイトルと簡単な本文だけで、定形文付きで3つのIssueを作成することができます。

(///ᴗㆁ✿) < zsh complete_unserstand_github_cli.sh "GitHub CLI 完全に理解したタイトル" "GitHub CLI 完全に理解した本文"

CLIの無限の可能性を感じますね。

大量のIssue作成にぜひ GitHub CLI を利用してみてください。

まとめ

GitHub CLI (issue create) の使い道完全に理解した！

プロジェクトマネジメントの違和感

プロジェクトマネジメント

やぬてつです。

プロジェクトマネジメントの書籍を結構たくさん読んで、適用できるところを適用してきたつもりなんですが、ずっと違和感が解消されない。

アジャイルなプロジェクトの場合、プロジェクトマネジャーって配置されても一般的なプロジェクトマネジメントの枠にあってない気がしていて、実際板挟み状態でどうしていいかわからない毎日です。

なんかわからんけど、もしかしてプロジェクトマネジメントと捉えるのではなくプロダクトマネジメントと捉えて行動するほうが良いのかもしれないって思ったので、まずはプロダクトマネジメントを学習していこうと思います。

熊とワルツを - リスクを愉しむプロジェクト管理　読了

書籍

やぬてつです。

熊とワルツを - リスクを愉しむプロジェクト管理　9年ぶり2回目の読了

リスク管理の必要性について有名なプロジェクトを持って説明してありとてもわかりやすかったです。 リスク管理とはなんとなくリスクヘッジばかりに考えが言ってしまったが、リスクヘッジにもリスクがあることやコストが増えるなど学べました。 リスク管理ってなんだろう？意味あるのかな？とフワフワっとした印象がある方は読んでみてください。

全編を読んでから付録Aを読むととても有意義です。あ、本編も有意義です。

www.amazon.co.jp