おはこんばんちは！！！
ゆるふわSEの「ゆるちょここ」です♪
今回は「Joel on Software」という開発者にとって結構評判の高い本（Amazonの星も結構多いです！）を読んでみましたぁ！！！
2005年に出版された本ですが、現代にも通ずる普遍的にためになることが結構書いてあったのでちょーっぴりだけご紹介しちゃうぞ♪
一言紹介文☆彡
※あえて一言でこの本を紹介するならのコーナー♪
「これを読めば、Joelさんっていう結構すごい経歴を持つ凄腕プログラムマネージャさんの考え方を垣間見て、自身が開発業務を実施していく上で参考になることを色々と知れちゃうよ」って本です♪
Joelさんが公開しているブログをまとめたものなので、普通にブログを読んでいるよぉな感じの気軽な読み物として読むと開発やってる人にとっては面白いと思いますよ☆彡
本の説明☆彡
※amazon様より抜粋
ソフトウェア開発者、設計者、マネージャ、それに幸か不幸か何らかの形で彼らと働く羽目になった人々が関心を抱くであろう、ソフトウェア、並びに往々にしてソフトウェアに関連する諸所の問題について
ソフトウエア開発で本当に大切なことは何か―。
米マイクロソフトや米大手ISP(インターネット・サービス・プロバイダ)のJunoでソフトウエアの設計・開発に従事してきた筆者が、分かりやすい言葉で解説する。
タイトルと同名の筆者自身のWebサイト(http://www.joelonsoftware.com)」で公開していたものを書籍化した。
例えば、よいプログラムができないと悩んだときには、難解な理論を導入する前に開発体制を見直すことを勧める。
「ソース管理をしているか」、「新機能を追加する前に、既存のバグを直しているか」、「採用面接のときにコードを書かせているか」といった12の質問に答えれば、開発体制に問題がないかを判断できる。
この質問をWebサイトで発表して以来、世界中の開発者から「役に立った」というメールが数多く寄せられたという。
プログラミングに長年携わってきた経験から、プログラミング言語そのもの、開発環境、仕様書の書き方、それにデバッグ方法などにも多くの誌面を割いている。
一つひとつの記述は“当たり前のこと”だが、現場でありがちな出来事をベースに整理されているため、分かりやすく、参考になる。
内容紹介☆彡
※amazon様より抜粋
あまりに多くのソフトウェアプロジェクトが失敗する。
チームが製品を作るのにあまりに長くかかりすぎたり、誰も欲しがらない製品を作っていたり、あるいはそもそも何も完成できなかったりする。
ソフトウェア開発について書かれた本の著者たちは、あまりに多くの場合、うまく行っていない古いアイデアを蒸し返していたり、うまく行きはしない新しいアイデアを考え出したりしている。
そういうのを私たちは繰り返し見てきた。
新しい流行りものが、失敗した古い流行りものを置き換える。
マントラが現れ、みんなが繰り返す。
「我々は構造化している、いや、我々はオブジェクト化している、いや、ユニファイされている、いや、エクストリームにアジャイルだ」。
残念ながら変わっていないのは、コードを書いている人たちが不幸せで、仕事の時間の一瞬一瞬を忌み嫌っているということだ。
そしてもう1つ変わらずにいるのは、開発チームの多くがソフトウェアの作り方を本当にはわかってないということだ。
これはほとんどシュールな状況だ。
大工の一団が家具を作ろうとしているが、それを釘だけ使ってやろうとしているのを想像してみるといい。
この混乱を取り払ってすっきりと見通せるようにしてくれる誰かを、私たちは必要としている。
かつてある人が、作家の仕事というのは「なじみ深いことを新しいことのように見せ、新しいことをなじみ深いことのように見せる」ことだと言っていた。
Joel Spolskyが何年にも渡ってやってきたのは、まさにそういうことだ。
彼は私たちに教え、楽しませ、そして時には憤激させもするが、いつだって彼は、コンピュータの何もない画面の前に座ってやっていることについて、私たちに考えさせた。
そうやってJoel on Softwareは、世界で最も人気のある開発者向けWebサイトの1つとなった。
あなたは今、彼のサイトの中でも特に重要なエッセイのコレクションを、Joelの新たな洞察とコメント付きで、一冊の本として手にすることができる。
感想と印象に残ったとこ☆彡
ふー・・・
やっと読み終わったぜぇ(´・ω・｀)w
いやー、この本むっちゃいーこと書いてあるんですけど、超分厚くて387ページもあるんですよねぇw
ちょっぴりずつ読んで1週間位で読み終わりましたぁ(*^^*)
ということで、印象に残ったセンテンスを箇条書きで厳選10個備忘を兼ねてご紹介にするよ(/・ω・)/☆彡
①
ソフトウェアチームのクオリティを評価するためのテスト
1.ソース管理してる？
2.ワンステップでビルドできる？
3.デイリービルドしてる？
4.バグデータベースはある？
5.新しいコードを書く前にバグを直している？
6.アップデートされているスケジュールがある？
7.仕様書はある？
8.プログラマは静かな環境で作業している？
9.手に入る最高のツールを使っている？
10.テスタはいる？
11.採用面接のときにコードは書かせてる？
12.ユーザビリティテストはしてる？
②
ちっぽけではないあらゆるプロジェクト（1週間以上のコーディング、あるいは2人以上のプログラマを要するようなもの）において、仕様書がなければ常に、より多くの時間を費やし、より品質の低いコードを作ることになる。
仕様書の最も重要な役割はプログラムをデザインすること。
人間の言葉で製品をデザインしているときは、いろいろな可能性について考え、修正し、デザインを改良するのに数分しかかからない。
③
機能仕様書
ユーザの観点から製品がどのように動くかを記述する。
プログラムがどのように実装されるかは問題にしない。ここで話題とするのは機能であり、画面とか、メニューとか、ダイアログとかいったものの仕様を定める。
技術仕様書
プログラムの内部の実装について記述する。
ここで話題とするのは、データ構造、リレーショナルデータベースモデル、プログラミング言語や開発ツールの選択、アルゴリズムといったものである。
④
良いプログラムマネージャになるためのスキル（明快な文章を書けること、外交手腕、マーケットに対する意識、ユーザに対する理解、良いUIデザインの能力）が良いコーダであるためのスキルでもあることは滅多にない。
両方できる人間がいるのは確かだが、非常に少ない。
よって、コーダを安易にプログラムマネージャには昇進させないほうが良い。
⑤
生産性のカギはただ始めること。
「射撃しつつ前進」の原理が、人生で何かを成し遂げるときのやり方。
毎日少しずつ前に進む必要がある。
⑥
テスタとして優れた資質のある人間はテスタとして働きたがらない
⑦
トップに立っているのがプログラマでない限りソフトウェア会社が成功することはない
⑧
人々がコンピュータを買うのは、それを使って動かすアプリケーションのため
⑨
プログラムマネージャに要求される第一のスキルは何か？
それは、ソフトウェア開発者に自分の思うとおりのことをさせていながら、開発者にはそれが自分のアイデアであるかのように思わせる、という能力だ。
⑩
競合を気にかけるのはやめなさい。
競合にではなく、顧客に耳を傾けよう！
あー、勉強になった！！！
ここまで読んで、興味がわいた方は試しに読んでみたらこれらについても詳しく書いてますので理解が深まりますよ♩
でゎでゎ☆彡
