ひよっこエンジニアの独り言

メーカー勤務ソフトウェアエンジニアのブログ

【エンジニアリング組織論への招待】読んだ

感想

会社でメンターになったので、メンタリングテクニックを学ぼうとした際にここのサイトでおすすめされていたので読んでみた。 https://developer.hatenastaff.com/entry/2018/05/30/173000

第二章がメンタリングの記載になっていて、第三章以降は1on1におけるメンタリングコミュニケーションを組織論へ徐々に広げていくような記載になっている。 アジャイル開発の記載等も基本的なところ(プランニングポーカー)からあるため、エンジニアだけでなくソフト開発にあまり関係ないマネージャークラスも目を通してみると良いと思う。

勉強になったところをまとめると、

- メンタリングでは、他者説得ではなく自己説得を重視する
- メンターはメンティーの問題を解くのではなく、メンティーが解くことが可能な問題に変換する。
- 内心は見ることができないが、行動は見ることができる

メンタリングをした結果、相手の行動が変容したかどうかを観察することが大切。 もし行動が変化していればメンタリングの意味があったわけで、行動が変わっていないのであれば何も伝わっていない可能性が高い、ということ。 「伝えたはず」だと思っても結局伝わったかどうかは行動を見ないとわからないので、そこに着目してメンティーを見ていこうと思う

【書評】達人プログラマー第二版

書評

ネット記事などでは、どこでもお薦めされている本の第二版です。 私は第一版は読んだことはなく、この第二版が初めてでした。

エンジニア個人としての哲学から始まり、ツール(SCMやIDEなど)への考え方、設計・実装・テストスキルやチームの立ち上げ方など広範に渡って、 特定のエンジニアリングスキルに依存しないことが書かれており、組み込み・WEBなどエンジニア種別に関係なく広くおすすめできる良書だと思います。 またそれなりに経験のあるエンジニアが普段意図せず習慣化しているであろうこと(ゴムのアヒルちゃんなど)が言語化されているのは、非常に面白く感じました。

本書のバックグラウンドには、アジャイルマニフェストがあり、その考えを前提にした部分が多く出てくるな、というのが個人的な感想です。 (二人共考案者なので、それはそうですが…) 各章がそれぞれ独立した章になっているので、開発時に脇に置いておいて、時折パラパラめくり自分の現状に当てはめて考えてみる、といった使い方が良いな、と思いました

【書評】Web API The Good Parts

Web API: The Good Parts

Web API: The Good Parts

書評

MQTTのAPIのDesignを少しすることになったけれど、API設計をしたことがないので勉強のために読み始めました。 この本自体はいわゆるHTTPプロトコルを用いたAPI設計(not gRPC)の開発になっています。

バージョン管理や運用のところまで実例を踏まえた記載があって非常にわかりやすかったです。 公開APIを作る際に考慮するべき広範な点が書いてありました。

MQTT

MQTTでバージョン管理をする場合、topic pathでのAPIバージョン指定(RESTでいうURIへの挿入)かuser propertyで独自型を定義してそこでAPIバージョンを指定(RESTでいうクエリパラメータへの挿入)のどちらかになるのかなぁ

MQTTの情報と比較して思うのは、本書で言うWebAPIは非常に多くのケースで使用されていてpractiveがしっかり溜まっているなーと思います。MQTTは、外部公開するようなプロトコルではないので、仕様以外の情報がほぼない感じ。

【書評】リーンスタートアップ

書評

スタートアップ界隈で著名な本を読みました。

仮説の話が非常に面白かったので、簡単にまとめておきます。

最初にビジョン(やりたいこと)を2つの観点から仮説に分解します。

  • 価値仮説:製品やサービスが顧客に価値を提供できるかどうかを判定する仮説。単純に言えばそもそも売れるの?の疑問を解消する仮説
  • 成長仮説:新しい顧客が製品やサービスをどう捉えるかを判断する仮説。単純に言えば、スケールするっけ?アーリーアダプター以外にも売れるかな?の疑問を解消する仮説

ボランティア制度を例に取れば、 価値仮説は「ボランティア制度を使った人はリピートするはず。」 成長仮説は「ボランティア制度を使った人は良い口コミを書いてくれるはず。」などが考えられます。

スタートアップのはじめは大量に仮説があるわけですが、全部検証しきれるはずもないので、リスクが高い部分を選んでいきます。 これが本書で呼ばれる「挑戦の要」になります。

これらの大量にある仮説ですが、もう既に市場にある商品から仮説検証が行なえます。これが類例と判例です。 類例の場合、例えばジョブズiPodを出そうとした時に「人は歩きながら音楽を聞くか?」という仮説に対しては既にウォークマンが答えていたことになります。 反例はこれの逆になります。

これら仮説が仕分けできて、本当に挑戦の要となる仮説が出てきた際にMVPを開発します。 このMVPを出したら、計測=>学習=>再開発のループが回り始めることになります。

まとめ

スタートアップをどう始めるか?であったり、立ち上げるに当たっての基本的なアプローチが書いてある良い本だと思いました。 具体的なプラクティスなどは載っていないので、基本的には考え方を学び、それを現状にどのように活かすかアプローチ方法は会社ごとだと感じました。

Joy Incを読んだら、実現したい「喜びに満ちて開発したい」が全て書いてあった

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

経緯

Regional Scrum Gathering Tokyo2020で好きなAgile/Scrum本ランキングなるものが行われていたそうです。 iwakiri.hatenablog.com

一位がアジャイルサムライなのは同感ですが、多くの世代で2位に「Joy Inc」という本が上がっています。 どんな本なんだろうか、と思い早速Amazonでぽちっと購入しました。

最近

最近は職場環境で色々と部内政治毎に巻き込まれつつ、気持ちよく開発が行えない状況でした。 いわゆるメテオフォール型開発のメテオが降ってきた状況です。 もうモチベを完全に失ってしました。 深海の底に縮こまって、「ただただ幸せに開発がしたい」と思ってました。

読んで

イントロダクションから惹かれて、一気読みしました。

ちゃんと日の目を見られて、楽しんで使ってもらえて、意図した人々に広く普及するものをデザインし、作り上げること。それが喜びである。

もう感動です。言いたいことが具現化されて出てきた感じでした。

チームが長いあいだやる気を持続する方法として僕が納得しているのは、仕事で意義ある仕事を成し遂げることだ。始めるだけでなく、話すだけでなく、誰かに依頼するわけでなく、実際に仕事を終わらせる、完了させる、完成させる。そして、届けること。タスクが簡単だろうが難しかろうが関係ない。どれだけ時間がかかったかも関係ない。完成させると、エンドルフィンが出る。自然な脳内麻薬だけど、中毒的だ。完成。本当に完成。価値があり、その価値を認めてもらえる成果を生み出した、大変な日々を思い出し、喜びにつながる。

多くのアジャイル本はプラクティスや考え方にメインフォーカスが当たるものが多いですが、この本は筆者の原体験をベースに、喜びを中心に据えた組織の物語です。 プラクティスの解説はあるものの、全てが原体験ベースであり非常に感動的でした。

多くのプログラマが一番最初に体験したであろう

print("hello")

の出力結果が出たときの感動を改めて思い出させてくれました。

おわりに

アジャイルと組織について、改めて考えさせられる本でした。 今までスクラム系のイベントって参加したことなかったですが、Global Scrum Gathering出席してみようと思います! Global Scrum Gathering New York City 2020

【書評】ソフトウェアファースト

久しぶりに紙媒体で読みました。 やっぱりKindleとかで読むより頭に入る気がする。

書評

前職の管理職全員に読ませてやりたいような内容。

ソフトウェアファーストの言葉からバズワードのDXの中身、またそんな情勢の中でどうキャリアを描いていくかなど多岐に渡り書いてあります。 管理職だけでなく、現場のエンジニアも一度は読むといい内容だと思います。

ソフトウェアエンジニアとして

ソフトウェアエンジニアとして生きる上で、同列に並んでくるエンジニアリングマネージャーやプロダクトマネージャーとの比較も記載してありました。 多人数を束ねるマネージャーと異なり、ソフトウェアエンジニアとしてどうプロダクトに貢献するかは、キャリアプランの中で考えないといけないですね。 言われたとおりにコードを書くだけなら誰でもできますし。

Sansanの藤倉さんも記事、ビジネス・プロダクトへの貢献が一番大事だと書いています。 やっぱりシリコンバレーでは、こういう考えが当たり前で、今まで多重下請け構造でITを軽視していた日本企業にはこういう考えが根本から抜けてるんだと思います。

【書評】スクラム

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

書評

Scrum Inc.さんのCertificated Scrum Master Trainingを受講したついでに、この本を頂きました。

元々アジャイル開発チームに所属していたので、スクラムの運営は身に付いていると思うのですが、改めて方法論の裏側にある考えを復習できて良かったです。 この本自体が、ソフトウェア開発エンジニア以外もターゲットにした本となっているので、教育現場や政府などの事例も幅広く挙げられていました。 スクラムってなんぞや?って人々にも基本を学ぶのに良書だと思います。

スクラム立ち上げ

スクラムマスターとして、会社でスクラムチームの立ち上げをやっているのですが、習得が難しいと言われるスクラムの難しさを改めて体感しています。 メンバーの多くが、スクラム研修を受けているものの、チーム開発経験が乏しくどうしてもタスクが属人化し、チームとして成果をあげよう、というよりも個人でいかに成果を上げるか、というところにフォーカスが言ってしまいがちです。

色々考えた結果、スクラムという理解は簡単だけれども習得が難しい、フレームワークを型にはめずにやっていることが原因だと思いました。 チームメンバーが私を除きスクラム経験がなく、なんとなくで実践してしまっているのではないかと仮説を立ててみました。 そこで検証として、一回仕切り直しを行い、守破離の守を大切にチームメンバーにスクラムの習得をしてもらうところからやろうと思います。

スクラムマスターって難しい!