デマルコの本。プログラミングエッセイ
【書籍】情熱プログラマーがあまりにもハズレだったので、 もうちょっと無難なデマルコの本でも読もうかなぁ、と探していたら、 まだ読んだ事が無いこの本を見つけたので読んで見る。
なんかこのエピソードは良く分かるなぁ。自分も腐臭がする、と同じような事を表現した事がある。 遅れると最初から分かっていて何も言わないだけじゃなくて、 マネージャーが死んだ魚の目をして支離滅裂な事を言ってくるというのも特徴としてある気がする。 死んだ魚の目、という自分の比喩と死んだ魚というこの本の比喩の共通点もちょっとおもしろい。
全部で80ちょいのエピソードがあるようで、現在9まで読んだ。その範囲でこの本はどういう本かを書いてみる。
この本は、チームやプロジェクトの良く見かけるパターンを名前をつけて並べたもの、といえる。 うまく行っているプロジェクトのパターンもあれば失敗しているプロジェクトのパターンもある。 うまく行っているプロジェクトが本当に良いパターンか、というのは微妙な事もあるけれど、 【書籍】情熱プログラマーのようにどうすべきか、という事を言うのではなく、 うまく行ってない感じを説明して終わりにするので説教臭さは少ない。
この本はチームとかプロジェクトが対象で、個人のプログラマは対象では無い。プログラミングもあまり対象では無い。 ソフトウェア開発、という感じに思う。 また、最近読んでいた本と同様に、やはりそれなりの大きさの会社組織が前提になっていて、フリーランスや零細ベンチャーとはだいぶ状況は違う。
ただ今のところは読み物としてそれなりの面白さがある。そうそう、こういうのでいいんだよ。
20の「一人一役」というのは、各メンバの仕事の責任が明確に分かれていて、それぞれが自分の専門の作業をこなす、 という形態のチームを指していて、これは上手くいくチームであるとなっている。 それと対比されているのが「全員がすべてのことに責任を負う」というスタイルで、 これはめったにうまく行かない、といってどうして上手く行かないかをレストランの役割分担にたとえている。
自分の経験では責任が明確に分かれている方がうまくいくという気はあまりしない。 分かれていると分かれているがゆえの非効率さはあるし、またそれ故に人数がより多く必要になる傾向があると思う。 皆が全部の事をやる方が小さなチームでは良く見られる形式だし、小さなチームではそれゆえに上手くいく事も多い。
以前に比べて昨今は独立したテストチームとか運用チームを持たない事が多く、 それはなるべく横断的に作業出来るように、という事だと思うんだよな。 それがいつも上手くいく訳では無いけれど、上手くいく事はそれなりにあるように思う。
要求があってQA担当が居て製品を作ってテストする、みたいな形式の話が多く、 そこで書かれている事がどうも自分が新卒だった頃の会社を思い出す。 あれは自分の中では2000年代の初頭から2005年くらいまでの時代を反映しているが、2000年代の後半もある程度はそういう組織はあった気もする。
だがそれでも本書が書かれているのは原著が2008年と言っている。この頃ならもうちょっとそういう形態では無くなっていたような？
昨今は独立したQA担当というのはあまり居ない気がする。大規模組織ではバカでかいCIを作り込む専用のチームはあるけれど、 テスト自体は各自が追加する。 そして製品自体のテストは以前よりも劣化した。 その代わり問題が出た時に迅速に直すようになったし、リリースも段階的に行われるようになった。
みんながみんなそう上手くこのスタイルを用いている訳では無いけれど、うまく行ってない組織も以前のようにやっている所は少ない。
その結果、QAと開発の軋轢みたいな話や形式チェックばかりしてしまう、みたいな話は、 行く所に行けばあるとは思うがそんなに多くある話では無くなったような気がする。 実際いろいろな職場を渡り歩いたが、ここ10年くらいそういうのを目にした事は無い。
2008年だったらもうちょっと現代的な話が多くてもいいんじゃないかな？という気がするんだが。 現代的なスタイルには現代的スタイルなおもしろエピソード、いろいろあると思うんだけどねぇ。
マネージャーが全部他のチームとの折衝やマネージメント的な作業をやってしまう為、他のリーダーが育たず25人くらいまでしかスケールできない、けれどその範囲では非常に優秀、というようなものをアトラスと呼んでいて、良くない事としているが、そんな悪いかね、これ。
100人が必要な仕事にはスケールさせられないので大きな仕事は任せられない、と書いてあるが、規模を増やさずにより重要でインパクトの大きい仕事を任すという方向への進歩はありえると思うんだよな。 大きいものを大人数で作るよりも、iPhoneを作って世界を変える方が重要なんじゃないか。
このリーダーが居なくなったあとが困るという話も、25人というのが多すぎるという話でもう少し小さいチームであれば同じスタイルのリーダーを持ってくれば済む話で、そこまで問題も無さそうに思う。
マネージャーになりたい人もいるはずだ、と言っているが、みんながこのリーダーの下で働きたがるという冒頭の話からすると、マネージャーの仕事を嫌がっている人たちが集まっていると考える方が自然では無いかなぁ。
むしろこういうチームがたくさんになるように組織を変えていくのは、結構現代的なマイクロサービス的チームになって良さそうではなかろうか。
採用でマネージャー以外のチームのメンバも面接するのをピアプレビューと呼んでいて一般的では無いが有効だ、 という書き方をしているが、今となっては普通だよな。 この頃の時点でもまぁまぁ一般的だった気がするが…
ワインバーグの本でもそうだが、コンサルが書くとコンサルが対象とするような企業というバイアスが結構ある気がする。 例えば零細はコンサルなんて雇わないよな。 モダンである事を自慢にしている中堅優良ベンチャーなどもあまりコンサルは雇わない気がする。 コンシューマー向けの一般的なwebサービスの企業もあまり雇わない気がする。 コンサルを雇うような企業というのは、自分が働かないような企業が多い気がするな。 どちらかといえば自分が仕事をもらうような企業を対象とした話が読みたい所だが…
前にも言った通り、どうもこの本の前提となっている開発形態は古い気がする。 例えばイノベーションのところで「その一方で、どんなプロジェクトでも、完成する時期をかなりの精度で予測する必要がある。」とあるが、 これはかなり違和感のある主張に思う。 こうした違和感がちょくちょくあるので、逆にじゃあ現在と感じるのはどういうものなのかな？というのを考えてみたい。
自分が最近取り組むプロジェクトは、すでにリリースされているサービスやソフトウェアの変更が多い。 期限は別に無いし、リリースして反応を見てまた次の方向性を考えるので、リリースの前に合意を形成したり顧客の期待値をコントロールしたり、という事は必要無い。 作るものがどれだけ客に望まれているのかも良く分からない中でものを作るし、多くはそれほどのjustificationも無い。
これは現在のモバイルのアプリやwebのサービスでは割と一般的に思う。リリースは継続的に続いていくし、 顧客の反応も予想するよりは確認していくものだ。 本当に顧客がそれを望んでいるかは良く分からないし望んでいないものも実際たくさん作っていると思うしそれを避ける事は難しいという前提に立っていると思う。 それは、これまでよりもより本質的な正しいものの見方に思う。
予想に重きを置かずに、反応を見て修正していくというのは大きな違いに思う。 見積もりもあまり行わずにどちらにせよそんなに長く無い期間に終わるものを出して反応を見ていく。 「なるべく予想を避けて結果を見る」というのは現代的な手法の基本と言えそう。
これらのやり方は新規に大きなものを突然出すのには向かないけれど、なるべくそういう物を減らしているのが現在のやり方なんじゃないか。 現代のやり方で作るのに向いているものをみんな作っている、というか。 作るものに合わせてやり方ができたのか、やり方に合わせて作るものが定まっているのかはどちらか良く分からないし、 たぶん両方あるんだろうけれど。
マネージャーとか経営陣の立場もだいぶ違うように思う。マネージャーとか経営者は説得する対象という訳では無い。 彼らもやはりサービスやアプリを成功させたくて、むしろかつてそれを成功させるのに大きな貢献をした人がCTOなどになって組織の経営判断をしている。 彼らは自分たちが開発しているサービスを知らない訳じゃないし、むしろ良く知っている。 もっとユーザーが直接問題になっているよな。 ユーザーをたくさん獲得できれば成功、出来なければ失敗。
これはこの本に書いてあるような「客」とは違う。お金を出して自分の欲しいものをいう訳では無いし、 プロジェクトの協力関係にも無い。この本の「客」はお金を出した分、自分の望むものを作って欲しいという動機がある。 一方で昨今の「ユーザー」は良いものだったらやるが、良くないものならやらないだけで、後者が別に損害では無い。 もっと顔が見えない沼のようなものをかき混ぜてどうにかするようなイメージが近いんじゃないか。 手応えも反応も無い中でどうやって望みを知るのか、というのは現代的なソフトウェア開発の重要な部分で、 この本に無い事に思う。
現代のソフトウェア開発の大部分はすでにある程度成功したものを、さらに発展させていこうとするものに思う。 何も無い所で成功させる事は現代でも誰かがやっているはずの事だけれど、多数派はそうした事をやっていない。 現状ある程度成功しているソフトウェアに多くの人をつぎ込んでそれを発展させるというのが多数派のプログラマのやっている事だろう。 それを上手くやっているかどうかは怪しい部分もあるけれど、それは本質的に難しい事なのは真実と思う。 本質的に難しい事を、うまくやれているかどうかは良く分からないけれどやっている、というのが現状に思う。
このすでにある程度成功しているプロジェクトを継続的に発展させていく、という形態がほとんど出てこないのが、本書を読んでいてなんか実態と違う古いやり方に感じられる事じゃないかなぁ。 実際自分のここ10年の仕事を振り返っても、顧客を満足させる仕事はたぶん一回も無かった。 だからそれが主流って事は無いんじゃないか。今でもそういう仕事もあるとは思うけれど。
最後まで読んだので、最後まで読んで思った事などを書いてみる。
最初の方を読むと、この本は「プロジェクトに良くある性質とか傾向に名前をつけてまとめたもの」というふうに見えるし、 そういう本だと自称もしている。 だがそうでも無いものが思ったより多い。
例えば「オフショアの愚行」はオフショア意外と難しいよ、という話が書いてあるのだが、 良くあるなにかを記述していない。しかも内容も「アイコンタクト」と同じような内容で、離れた所にあるチームは上手く行かない、と言っているだけに思う。 なんかこういう、意外とパターンになってない事が多くて、そういう奴は単に著者の思い込みが書いてあるだけという印象で、 面白くも無い。
面白い読み物にはなりそこなっている部分も多いけれど、説教が並んでいる【書籍】情熱プログラマーなどよりは読み物として読める。 あまり説得力のない著者の主張みたいなのがたびたび出てくるけれど、それ以外の部分もそれなりにある。 読み物として読む事はできた。
だが、【書籍】プログラミングの心理学に比べるとエピソードが具体的でないせいで、こう「あるある！そういうの！」という感じがあまり出ていなく、 その辺はソフトウェア開発エッセイとしての出来は微妙かな、と思う。
でもまぁ駄作のなろうを読む時間にこれを読んでも、まぁいいかと思える程度の内容ではあった。
なんか出来損ないのアジャイルの解説みたいなのがいくつかある。例えば「変更の季節」とか。 こういうのは出来が悪くて面白くもなければ勉強にもならない。 なんか十分な経験のもとに語るなにかじゃなくて、 本当にハウツー本みたいな程度の薄っぺらい内容になってしまっている。 2004年とかの本ならそこに新しさもあるかもしれないが、2008年とかでこんな内容… と思ってしまうし、それを2023年に読むと本当に何も価値を感じられない。
こういうのは無くしてほしかったな、と思う。
感覚的に、4割くらいがいまいちな内容。3割くらいは結構良い。残り3割が可もなく不可もなし、という感じに思う。 自分としてはハズレがちょっと多すぎるかな、という気もするが、まぁこんなもんと言われればそうかもしれない、 と思う程度ではある。
あんまり出来の悪いものにイライラせずにさっさと次に行くのが良い気はする。
何かソフトウェア開発に関する教訓のようなものとかは期待出来ない本に思う。 良いと言っているパターンも良いかどうか微妙だし、悪いと言っているパターンも悪いかどうか怪しかったりする。 あまり根拠とかも無いし説得力もあまり感じない。 なにかプロジェクトマネージメントとかを学ぼうという対象としてはあまり良くないように感じた。
なんか昔ピープルウェアとか読んだ時は結構得るものも多かった気がするんだが、 この本はそういう要素は全然無いね。
ただ説教臭いのにうんざりして読み始めた本なので、そういう要素が無い方が望んだものなのかもしれない、とは思う。 だから学びが無いのはマイナス評価という訳では無い。
読んでいると反発にせよなんにせよ、自分の考えを刺激するような部分はあった。 このページの感想がそれなりの量だ、という話。 なにか技術的な事についてブログとか書きたいなぁ、でも別段書きたい事無いなぁ、 という時に読むと良いかもしれない。 なにかを書こうという気分にはなる。
そういう思考を刺激するものとしては一定程度機能していたと思う。