宮水の日記

宮水の日記

主に書評や資格取得について記事を書いています。

【おすすめ技術書】エクストリームプログラミング

みなさんこんにちは!宮水です!

 

 

今回は、会社の読書会で課題図書に上がった、「エクストリームプログラミング」という本を読みました!

エクストリームプログラミング

エクストリームプログラミング

 

 

 

目次

f:id:kattyan53:20181210193955p:plain



 

 

 

なぜこの本を読んだのか?

 会社の読書会でおすすめされたから!と一言でいえばそうです(笑)

 ただ、エクストリームプログラミング(以下XPとします)は基本情報技術者の問題でしか見たことなくて、うーん...ペアプロ?くらいの知識しかなく、この機会にしっかり勉強しようと思いました!

 

f:id:kattyan53:20181209203513p:plain

基本情報のXPの問題

以下、「はじめに」より引用


XPの目的は、圧倒的なソフトウェア開発の実現である。

ソフトウェアは、もっと安いコストで、もっと少ない欠陥数で、もっと高い生産性で、もっと高い投資効率で、開発することができる。

現在苦戦しているチームであっても、仕事のやり方に目を向けて洗練したり、通常の開発プラクティスを極限まで推し進めたりすることによって、このような結果が成し遂げられる。

 

 

おおお、なんかすごい強いエンジニアになれそうな文章から始まったぞおおお 

エクストリームって日本語に直訳すると「極限」ですからね!!カッケー!

 

 

この本の概要

この本は、良いソフトウェア開発チームの共通点を著者がまとめてくれた本です。

 

 

私も先日初めて案件に参画した際には、要件が理解できなかったり、新しい機能を作ろうとしたら既存のコードの問題に対処しないといけなくなったり、お客さん自身もどうして良いかわからないこともあったりして、プロダクトを作っているうちにたくさんの不安を抱えていました。

 

 

でも、どんなプロダクトだって最初から完璧なものは作れません。

では、どうやってその次々に変化していくプロダクトをうまく作るか?という点で、チームのコミュニケーションや考え方について「こんなチームが上手くいってたよー」という紹介が書き綴ってあります。

 

 

「XP is なに」と聞かれると定義が広すぎて困ってしまうのですが、

 

どんなチームが優れた開発をするのか?という点において、

・ソフトウェアは変化するものだと心得よう

・チームのコミュニケーションは大事だ

・優れた開発者の人間性とは...

・失敗も無駄じゃないよ

ペアプロはいいよ

・そのチームにとってベストなら、みんなが同席してもいいしリモートしてもいい。

・週次ミーティングや四半期の振り返りをしよう

...etc...

などという上手くいったチームの参考例が書いてあります!

 

 

XPというのはいろんなソフトウェア開発法でも使用されており、

例えば、アジャイルテスト駆動開発、開発手法がXPの考え方を一部取り入れています。

 

 

この本の特徴

 

最初”はじめに”を読んだ段階だと、「定義も広いしかなり哲学的だな...」と思ったのですが、 1項目1ページほどの文章量でこんな人がいい、こんな方法がいいと書かれていてとてもテンポの良い本だと思いました。

 

特に印象に残った箇所

人事 評価 の 課題 が 発生 する のは、 XP は チーム の パフォーマンス に 集中 し て いる のに、 実際 の 人事 評価 や 昇給 は 個人 の 目標 や 達成 度 に対して 行わ れ て いる から だ。 プログラマー が ペア に なっ て 半分 の 時間 を 誰 かと 一緒 に 過ごし て いる 場合、 個人 の パフォーマンス は どの よう に 評価 できる の だろ う か? 個人 の パフォーマンス で 評価 さ れる と し たら、 他人 を 助ける インセンティブ は どれ だけ 残さ れ て いる の だろ う か?

 

最近「会社に真っ当な評価をしてもらえない」ってことに気づいた人たちがTwitterでもどんどん転職していっていますが、この文章にはハッとさせられました。

 

私も新卒で入った会社では、チームの人ができない”点検時間も長い”、”台数も少ない”専門的な仕事を「女の子だから」という理由で任されていたのに、会社の評価は「1件あたりの点検時間の短さ」「対応件数」だったりして、評価対象ではなかったことがありました。他の人の担当の点検を手伝ったところで、自分の評価にならないんです。

 

 

チームで行動しているのに、誰かを助けたりする時間ってなかなか評価してもらえないし、上司にとっては部下を助けること=足を引っ張られていると捉えがちだな...と。

 

 

でもチームで評価されるのであれば、助け合いが足の引っ張り合いではなくて本当の助け合いになりますよね!!

 

 

この本はソフトウェア開発手法の哲学ですが、このように仕事の進め方にも応用できる考え方がたくさん載っていてとても勉強になりました。

 

 

まとめ

 この本は、ソフトウェア開発を上手く進めていく上でこんな取り組みしているチームがあったよ〜(でもチームによってベストは違うから、色々試行錯誤しようね〜)というような内容の本でした。

コードを書く人だけではなくて、マネージャーや経営者の方にもオススメの本です!

私も明日から、チームがよくなるにはどうしたらいいかな?開発を効率よく進めるためにはなにをしようかな?ということを、この本を参考に考えながらお仕事しようと思いました。

 

 

エクストリームプログラミング

エクストリームプログラミング

 

 

 

読んでいただきありがとうございました!