待望のずっきー色100%、ツール＋マインドセットでチーム開発の解像度を上げる本
エンジニャ～のみんな！ 二段階認証と display: none は正しく使ってますかニャ～？（挨拶）
えー中断していましたが技術書典の同人誌の感想を上げるシリーズでもうひとつ、『チーム開発1年目の教科書』の感想エントリです。
さてテック系Podcast「しがないラジオ」でも編集を担当し比較的バックエンド方面をしっかり支えているパーソナリティのzuckeyさん。同サークル名義での技術書典5での前作『完全SIer脱出マニュアル』でも後半部分を担当し、こちらも裏方に徹している感はありました。大きな反響を呼んだこの本の感想では、中にはずっきー色が薄いことを残念がるブログもありました…… さァそんなzuckeyさんが技術書典6では自分名義で本を出しました。今度こそずっきー色マシマシ、産地直送の濃厚なずっきーイズム、待望のずっきー色100%なのであります。主な対象は転職や就職でモダンなチーム開発の現場に飛び込むエンジニア、そこで疲弊せずに成果を上げる最短ルートを辿り、しがないライフを送れるようチーム開発の一式を解説する本となっております。 白ベースに微妙に黒と違う色がメイン、アクセントの黄色がちょうど本の帯のようになっていますね。本屋の技術書コーナーのWeb制作関連、HTML/CSS/JavaScriptやWebデザインの本の隣あたりに置いてあったりしても違和感がない、クリーンでオシャンティな感じになっています。 最初に、文脈によってニュアンスが微妙に違ったりする「Webエンジニア」や「チーム開発」の、本書での定義がしっかりと示されています。 そしてzuckeyさんの実体験を元に、転職を成功させたはいいがGitやSlackなどの最新技術や文化、環境構築、Markdownの文化や溢れる謎の英略語に最初は途方に暮れてしまったことが語られています。特にWebエンジニア界隈は時としてやたらキラキラ感が強調されがちですが、現実にはこういうこともあるのだなあと思います。 そして一番高い始めの壁を越えた後、徐々に慣れていってコードを書くようになっても不安になったりすることはよくあり、この壁を超えるのに重要なのはテストとレビュー、フローの理解、ドキュメントだと本書では論じています。図入りで知識の分類が説明されています。 このへんはSI寄りの開発でもだいたい同じだなと感じました。これらを効率的に身に着けていくのが近道で、チームごとに異なる知識を得るには「コミュニケーション」と「業務ツール」が必要だ…ということで2章へ続いていきます。 この「楽しさ」をベースにやろうという流れはzuckeyさんたちのしがないラジオを始め、インターネットでも活動しているエンジニア界隈の様々な人に共通している気がします。最近だとAWS Summitで聴いた学習のコツのセッションでもAWSの中の人が同じような話をしていました。エンジニア流の仕事のやり方が業界全体でこういう方向に進んでいくと良いですね。 チームの一員として活動する上での人間の心の話。開発を円滑に進め、メンバに安心感を与えるやりかたの章。 本章で「エンジニアはすぐ否定から入りたがる」という話題が出ていますが、一時期Twitterでも話題になっっていましたね。「Yes, But...はWeb系開発で言いやすい」という話が実例つきで説明されているのですが、なるほどなーと思います。 ここで『驚き最小の法則』、一番自然で驚かないようにするのがアプリのインターフェースでも人とのコミュニケーションでも大事だよという話が述べられています。 人間相手の驚き最小の法則の実践例としては、まずいことはなるべく早く事前に伝える、チームの慣習や価値観に沿うこと(命名やドキュメント、果ては金曜午後にリリースしないなど)が紹介されています。 ITエンジニアならみな興味あるツールの話。カスタマイズしたりプラグインを入れたりいろいろ工夫したりはどこのプロジェクトでも見かけます。本書でもツールの話題は盛り上がりやすいよと記述があります。注釈に、約束のVimとEmacsの宗教戦争に注意の話が添えられていて笑いますｗ チームによって違ったりもするツール、チケット管理やデザイン系のツールは本書では割愛し、まずはコミュニケーションツールの要、チャットから。zuckeyさんの経験からも本書ではSlackを今の主流として解説しています。よく話題に出ますしここは自然でしょうか。 リアルタイムにコミュニケーションが取れてログも残る、検索性も進化中、定型文がなくて効率が良い……などおなじみの長所も述べられていますが、一方でチャット特有の欠点もあり、本書ではずっきー流の対応策も解説しています。せっかくなのでちょっと紹介しますと、 などなどなどのテクニックが解説されています。 続いてドキュメント共有ツールの話。本書では代表的なツールとして以下が紹介されています。 teams.qiita.com
kibe.la
esa.io
www.atlassian.com]
docbase.io
www.dropbox.com しがないラジオのゲスト出演者との情報共有はDropbox Paperでしたが、zuckeyさんは仕事以外のプライベートでもKibelaをよく使っているそうです。 なお本書と直接関係ないですが、似たような話としてチーム開発より若干個人寄りかな、ドキュメント共有サービスの比較記事が最近Qiitaに上がっていました。 僕はむかーしライフハックが流行ったころは一時期全情報Evernote化を試したりしたのですが、アプリもだんだん重くなるので止めて、結局シンプルなのが一番ということに行きついて個人ベースではSimplenoteをずっと使っています。 そして章後半はバージョン管理ツールの話。著名なツールとして載っているのはGit/CVS/Subversion/VSS/Mercurialで、ここは妥当なところ。 HTMLと似ているけど違うマークダウン。WWWの基本思想のハイパーリンクの話はなくて、文書を階層構造にして各部分の役割を明確にするのが主な目的だ……として、モダンなチーム開発で主流のMarkdown形式のドキュメントを活用していく章。 紹介されているMarkdownエディタとしては、*.md形式で保存できるおなじみVisual Studio Code。ほか Typora というオンラインエディタが紹介されています。これは初めて知りました。 書式としては最低限、見出しの ここでずっきー流テクニックとしてMarkdownのテンプレートを用意して活用していく手法が紹介されており、実例が載っています。 この実例は分かりやすくて良いですね。障害報告書で僕が普段見るSI寄りのプロジェクトと違うところというと、項目に「検知経路」があったり、影響範囲に「ユーザ数」があったりして面白いです。 エモいタイトルで始まるバージョン管理ツールの章。GitHubまで含めると、プルリクのレビューが入るのでコミュニケーションツールとしての特徴も備えるよということでエモタイトルを回収しています。 わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉
はじめに & 第1章 楽しいはずのチーム開発でぶつかる「壁」とその乗り越え方
対象の企業はITを用いたビジネスモデルを開発している集団で、そして開発や運用には様々な人が関わってくるのでこれをチーム開発と呼び、その中で主にエンジニアリングやプログラミングで価値を生み出している人々をWebエンジニアと呼ぶと。おっこの定義に従うと、SIerでWeb開発をしているワイも半分Webエンジニアに入るっぽいぞ……？
ちなみにここで転職当時謎で困ったらしき英略語の例がいくつか紹介されていますが、僕はLTVだけ分かりませんでした(笑) ググったところマーケティング用語のLife Time Value(顧客生涯価値)のようですね。くっ、SIerマンは修業が足りないぜ……
そして最後は、最初に息苦しさを感じるのはあなたのせいではないと題して、転職してチームにジョインしたりしても最初はみなここでぶつかるのでそれを乗りこえ、楽しいものに思える状態に進もうという話で締めています。第2章 チーム開発のマインドセット
そこでYes、Andだということで、技術懸念点に気付きやすいのはエンジニアの長所でもあり、現状と目的を把握して落とし所を見つけていこう、まずは肯定から始めていこうと本書では推奨しています。
この法則はプログラミングやエンジニアリングの原理原則、名言の話でもよく出ていますね。確か、かのプログラミング言語Rubyの言語仕様の当初の思想でも重要視されていて、その後経緯があってなんか薄まっていったと聞きます。
また、この手のチーム作業で必ず出てくるルールの話。本書では必ずしもルールを作ることは正解ではない、なぜなら一旦決めると変えるのにエネルギーが必要になるからだと述べています。
そしてずっきー流のテクニックとして、厳密なルールまで至らない段階の「実績のある手順としてログを残しておく」手法が紹介されています。なるほど次に同じケースに直面したメンバは助かるかもしれないし、頻発したらルールに昇格させたりするわけですね。このへんは柔軟でアジャイル的でよいですね。第3章 ツールを効果的に使い倒す
日本の伝統的大企(ryである僕のところですとチャットツールは大昔はIP Messengerとかも、一時期IRC、今は全社標準はSkype for Businessですが活用度合いは社内でもばらばらで、やはり伝統の電子メールが基本、全社でSlackなんて夢のまた夢というところです。
その一方で僕も過去にチャットツールが開発進行の阻害になったプロジェクトで苦労したこともあり、トレンドとしてはだいたいSlackがもてはやされてるけどエンジニア以外もいる組織で上手く使えるのかな？と思っている面もあります。本書はツールの紹介だけでなく欠点や対策まで解説しているのがよいですね。
情報がどんどん蓄積されていくWikiのようなものを「ストック情報」、その時々のブログや週報などは「フロー情報」として区別するとよいこと、時としてドキュメントが軽視されがちなことの話などが述べられています。
なんとなくドキュメント重視の話はSIer批判の文脈でよく出てきて、Web系はドキュメント書かないからイケてるよね！みたいな安直な論旨も見かけますが、本書にあるようにサービスの追加実装の妥当性判断にも使えるし、調査のログとして残しておけば「ドキュメントは武装だ」と言えるわけで、ドキュメントの重要さはどんな開発の現場でも変わらないのですね。
動作の速さとGitベースのバージョン管理サービスGitHubの流行により今の主流はGitだとし、別章で詳しく述べています。本書がターゲットとしているモダンなチーム開発の本としてはまあ当然の選択となるでしょう。第4章 構造化されたドキュメントを支える技術「Markdown」
Webエンジニアの開発でもドキュメントは大事であり、かつ難しく、構造化された文書を書くことに慣れていくのにMarkdownは向いている……と章を割いて解説していきます。#と箇条書きの - と 順序付き箇条書きの 1. だけを紹介し、コツとしては階層構造に従って概要と文書の目的をまず決めてから詳細に移っていくと良いという話が述べられています。上の階層→下の階層の流れは、論文の書き方や同人誌の作り方と同じですね。
あとはVSCodeでスニペットとしてMarkdownテンプレートを保存するやり方も解説してあります。実体はテキストのフォーマットではありますが、こうして改めて俯瞰するとMarkdownにもいろいろ工夫できるところがあるのだなと思います。第5章 「Git」は想いを伝えるツール
本書でおススメしている解説書は『わかばちゃんと学ぶ git使い方入門』『サルでもわかるGit入門』。
また「Git 初心者 本」でぐぐると出てくる『入門Git』はGit内部の仕組みの話で難しいので目的に沿わない……という話が書いてあり、実際にググったら確かに3位ぐらいに出てきました。こういう情報もチーム開発これから1年目の人には地味に重要です。
- 作者:Travis Swicegood
- 発売日: 2009/08/12
- メディア: 単行本（ソフトカバー）
内部ではコマンドが多くてけっこう難しいGit、本書ではチーム開発に踏み出していく人のために「とりあえず生きていくためのGit」として仕事での必要最低限のコマンド、リポジトリやコミット、インデックスやブランチ…などをインストール手順から丁寧に掲載しています。
実際の例としてはGitHub内のGistというサービスを利用して、Markdown文書を上げていくチュートリアルが掲載されています。前回との差分を確認したり一歩一歩、丁寧に進んでいます。
僕もGitの理屈は理解して完全新規プロジェクト立ち上げに関われる時は今度こそ……と思いつつ、社内では周りでまだまだ伝統のSubversionが多かったりする状況です。
本書のチュートリアル前半のmergeしてからpushの流れは同じく分散型バージョン管理システムのMercurialとほぼ同じなので分かったのですが、後半のrebaseしてからpushとの違いがよく理解できませんでした(笑) くっ、わかばちゃん本で復習しよう……
第6章 GitHub 上での働き方入門
エモタイトルの5章を受け継いで、コミュニケーション基盤となったGitHubの活用方法を紹介する章。GitHub登場当初からあり、人気の元となったプルリクエストの機能のうまい使い方を解説していきます。
コミット単位でレビューして品質を高めたり属人性を排除したり、技術をチームメンバに伝承したり、コミュニケーションが活性化したりと利点はよく語られるところ。
GitHub活用の工夫の為のルールなどはよくブログなどでも語られますが、本書はここでもMarkdownのテンプレートを紹介しています。レビューしてほしい重点ポイントを事前に書いたり比較画像を入れたり、テストコードを添えたりと、いろいろ工夫できるんですね。
ふつうにタスク分を実装してレビュー依頼を出すだけでなく、「軽く実装してみて質問する」というやり方もあって、こういう進め方もあるのかと思いました。
そしてGitHubが備えている課題管理機能のIssue。これもMarkdownテンプレートが使えるとのことで、機能追加要求とバグレポートのテンプレートが紹介されておりイメージしやすいです。こちらも画像を添えたりいろいろ工夫できるんですね。
こうしたGitHub上でのコミュニケーションを補助するため、意図を伝えやすくするTipsとして以下が解説されています。
- 画像や図、動画、硬いUMLより手書きの図を使う。
- emoji を導入して絵文字を使うと柔らかくなる。
- 表を使って整理する。
- シンタックスハイライトを活用する。
- 画像は横に並べてdiffを取りやすくする。
僕もチケット管理ツールのRedmineなどで似たようなことをやったことはあるのですが、そもそもコード自体を社外に置くとか基本的にインポッシブルなので、GitHubでのやり方がだいぶイメージできました。
第7章 コミュニケーションを Hack する
ツール以外、人間の力をメインにコミュニケーションをしていく上でのTipsの章。
- 組織が50人以上の規模になるとチーム以外と話す機会が減るので、雑談する。
- 議事録を取ると理解が進んでキャッチアップが早くなる。(これはよく新人がやらされますね)
- 日報や週報を「分報」としてチャットツールで共有すると周りに伝わりやすかったり、アドバイスがもらえることもある。
などなどの話。分報の話はよくTwitterなどで見聞きするものの実際にはやったことがないので、なるほどこれをSlackに流したりすると効用があるのだなあと思います。
第8章 まとめ、そしてチーム開発に慣れたあと
というわけでチーム開発の要素を一通り解説。チーム開発に大事なのはコミュニケーションであり、そのためにツールを使う。目的や使い方を理解して前進していこう……というまとめになっています。
本書では言及がないというかもう１冊ぐらい書けてしまう内容ですが、この先はCI(Continuous Integration)やCD(Continuous Delivery)、チケット管理、スクラム開発などに順次進んでいくのが推奨されています。
エンジニアという職業を選んだ以上、課題は次から次へと出現してくるものである。焦らず1つ1つ身につけて行けば良いよ、それがエンジニアとして楽しく働くことなのだよ……と締められています。ここでも根底に「楽しく」が掲げられているのがしがないラジオ的でよいですね。
まとめ：モダン環境でのチーム開発を包括的に知ることのできる本
本書が主にターゲットにしているのは、冒頭で解説してあるようにチーム開発で成果が出ず疲弊してしまう人、主には転職でWeb系エンジニアを目指していて働き方の解像度を上げたい人で、より実際に近いチーム開発のイメージを知ることができると思います。
そしてそれ以外にも、
- 比較的モダンな開発現場にこれから入る新社会人や学生さん向けに、どんな働き方をしているのか雰囲気を伝える本
- 既にチーム開発の現場にいる方には、自分たちのやり方との差分を再確認する本
としても役立つと思います！ ツールもあれこれ紹介されているので、そのへんを調べたりいろいろ試すのが好きな方にも役立つでしょう。
僕の場合はまさに後者の差分を確認する側なのですが、自社サービス系の開発の現場などなどは伝聞でしか知らないこともあるのでだいぶイメージが湧きました。
個人的にもっとも参考になったのは、割と軽視されがちなドキュメント回りにもしっかり焦点を当てているところですね。Web系開発はドキュメントを書かないのかといったらそんなことはないし、そもそも「アジャイル≠ドキュメントを書かない」が誤りなのはアジャイルをきちんと回してる方たちも言っていることですし、ちゃんと自社開発をしてる会社さんならドキュメントを書かないはずもないのでこのへんどうやってるのかな〜というのは前から不思議に思っていました。
Excelか、Markdownのテキストベースかのフォーマットの違い、ツールなど手段の違いぐらいで、SI寄りの開発とも根本的なところはそれほど違わないし、ドキュメントが重要であることも違わないのだなという感想です。
単体でのGit入門やMarkdown入門の話などならそれこそブログやQiitaなどあちこちに散らばっていますが、チーム開発に加わる人のマインドセット、コミュニケーションの分を含めて包括的に解説している記事や本というのは意外にない気がします。そうした意味でも、教科書として役立つ本です。
リンク集
電子版はいつでも1000円で入手可能です。技術書典6 終了直後時点で物理本200部見事完売、PDF53部ほどが売れたとのこと。 booth.pm
Twitterのハッシュタグは「#チーム開発1年目の教科書」です。1年目の数字は「一」でなく「1」です。最近スタディストに見事ジンジニア転職を決めて話題になったてぃーびーさんより「zuckeyさんはシャイ」との情報を入手していますが、本書を読んだら呟くとzuckey神も喜ぶと思います！ twitter.com
購入するとしがないラジオの限定エピソードがダウンロードできます。最初の構想時はCI(Continuous Integration)に向けてテスト自動化の話などの案もあったものの、それより前段の話を一度まとめることにして本書に至ったのこと。一度読んでから聴くと、なるほど～となれます。
下は限定版ではなく普通に聴ける、本書の話題もあるep.34。
本書の表紙デザインもzuckeyさんの会社のツクルバのデザイナーの方が担当したとのことです。どおりで最初から同人誌感があまりなくて、商業本としても違和感ない感じに仕上がっていたわけですね。ハッシュタグに流れていたWantedlyの募集記事。
www.wantedly.com www.wantedly.com
著者のzuckeyさんご自身へのインタビュー記事。執筆にあたりタスク管理ツールはTrelloを使っていたとのこと。
タスク管理系のツールもいろいろありますがTrelloは見た目が綺麗なこともあり、Web制作系や自社開発系の現場で割と名前を聞きますね。
本書を読みながら僕もなんとなく連想していたのですが、『チーム開発実践入門──共同作業を円滑に行うツール・メソッド』。
しがないラジオの限定エピソードでもzuckeyさんが似たような立ち位置の本を意識したとの話があり、こちらもなるほど～と思いました。(リピート)
2014年の本なので、まだ今ほどはモダンなバージョン管理といえばGit一択だよね！と言われていない頃の本ですね。GitやGitHubを用いたバージョン管理の大事さ、チケット管理、継続的インテグレーションにはJenkins、ほかビルドツールやデプロイや自動テスト、サーバ構成管理ツールなどなど包括的に全体を解説しています。
構成管理ツールで出てくるのがRedhat AnsibleでなくまだChefだったり若干ツールが古めのところもありますが、チーム開発の全体像を知る上では今も役立つ本だと思います。
rmaruon さんのscrapboxによる感想。校正箇所含め詳細な感想メモが掲載されています。『非エンジニアのためのJavaScript』や『完全SIer脱出マニュアル』の感想もあります。しがないラジオのリスナーとのことで、いろんな回の感想も載っています。僕が出演したsp.53abも詳細にメモがあって、ありがたや…ありがたや…🙏
上の感想記事の校正箇所の話にもありますが、本書に登場する『プログラマ三大美徳』の「怠慢」「短気」「傲慢」の「短気」が「短期」に誤変換されちゃった誤植は短納期みたいでちょっとイヤンですね。(笑)
英語だとlaziness, Impatence, Hubris。rmaruonさんの感想にもあるように、lazinessの日本語訳は「怠慢」だとネガティブイメージが強いので「怠惰」の方がニュアンス的にはしっくりくるのかな～と個人的には思ったりします。
日本語で読めるエンジニア関連の本や情報でも「怠惰」「怠慢」両方の訳がありますね。調べたところ『プリンシプルオブプログラミング』では「怠慢」でした。Wikipediaだと「怠惰」、ネット上の資料だと両方ありますね。
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則
- 作者:上田 勲
- 発売日: 2016/03/23
- メディア: 単行本
ちなみにこの手の３つ並べる格言では、僕は『Team Geek』にあるコラボレーションの涅槃に至るソーシャルスキルの三本柱、HRT(ハート)の3原則の「謙虚(Humility)」「尊敬(Respect)」「信頼(Trust)」が好きです。なんちって。
Team Geek ―Googleのギークたちはいかにしてチームを作るのか
- 作者:Brian W. Fitzpatrick,Ben Collins-Sussman
- 発売日: 2013/07/20
- メディア: 単行本（ソフトカバー）
アレクさんのはてなブログ『等身大から1割増し』での感想記事。 alek3.hatenablog.com
このアレクさんはzuckeyさんgamiさんと学校時代からの長い知り合いとのことで、しがないラジオsp.60abにゲスト出演、またep.35の公開収録にも登場されています。
shiganai.org shiganai.org shiganai.org
エンジニアの登壇を応援する会などでもおなじみさっぴー川原さんの、MacでPDFからPNGを出力するときの解説記事。何気に本書が題材に使われています。 kawahara-ci.hatenablog.com
という訳で『チーム開発1年目の教科書』の感想でした。本当はこの記事エントリは2019年5月頃、『非エンジニアのためのJavaScript入門』の次にあげる予定だったのですが、僕の仕事のチーム開発がその後めちゃんこ忙しくなって今になってしまいました。スミマセン。。
