Archive for the ‘書評’ Category

今まで読んできて印象に残った本を10冊ぐらい。。。?にまとめてみた

8月 6, 2011

ふと思い立ったので、今まで読んできた本で印象に残っているものをまとめてみた。

別に体系だてておもいだしたわけでもなく、まとめたわけでもないので、「なんであの本がないのか?」みたいな意見があるかもしれない。

そんな時はコメントをしてもらえるとうれしい。
すでに読んだ本でも、新たな本でも、手によって読む機会になるので。

ちなみにシステム関連の本が多いのは読んでいる比率の問題であって、システム関連の良書を紹介しようという主旨ではない。

◯UMLモデリングレッスン

UML記法によるデータモデリング学ぶのに最適な1冊。

これ以前に、『UMLモデリング入門』(以下、『入門』と略す)などで、UMLおよびデータモデリングの考え方に親しんでおく必要があるかもしれない。

とはいえ、UMLをつかいながら業務分析をしたり、システムについてコミュニケーションをとったりするための基礎を身につけるのに最適な1冊。

『入門』は、基礎的なUMLの書き方やモデリングの方法や考え方を学ぶ本ではあるけれど、それゆえに内容が概念的で難しい。

本書では、『入門』で学んだ考え方や取り組み方を「実際にモデル図としてどう表現するか」、実際の業務などの「どのような点をモデル化するか」、そして、「どのようにUMLで表現するか」を20ほどの演習問題で学ぶことができる。

ひとりで読むのもいいけれども、読書会を開いて皆で読みながら問題を解いてゆき、「どうしてこんなモデル図になるのか」と議論すると理解はより一層深まると思う。

自分がやってきた読書会のなかでも、楽しく読書会を行えたという記憶があるので、その点でも本書への思いが強いかも。

◯実践UML 第3版

価格も高く、分厚い本なので読んだ時の達成感もひとしお。 

データモデリングという手法を通じた業務分析やシステム設計の手法を学んだら、実際のその手法を活かしてどのようにイテレーティブな開発プロセスを実現するか、についてこの本で学ぶとよい。

イテレーティブ、アジャイルという言葉から、軽量、小規模というイメージを導きやすいが、想像以上な大きな規模でもイテレーティブな開発が可能であると気付かされる。

本のなかでも、

・概念   :考え方
・Tips、技術:関わり方、やり方
・プロセス ;プロジェクトにおける進め方、活かし方

というざっくりとしたわけがあると思って読んでいるが、この本は、考え方、やり方、進め方を網羅しており、アジャイル、データモデリング、デザインパターンなどの様々な本の知識を体系的に1冊にまとめあげている。

これ1冊で十分、というのではなくて、さまざまな本で語られている知識を1本の線でつないでくれている、という点が本書の良いところだと思う。

◯考える技術・書く技術

日常生活で、考えたり話したり文章を書いたりする機会があるのならば読んでおくと役に立つ。

システム開発においても、メール、ドキュメント、プログラムのコメント、IRCなど文章で自分の考えを表現する機会は様々ある。

また、ビジネスにおいては、どのよう思考を整理し、整理した結果をいかに表現するか、必要になる。

プログラマが”CleanCode”を実践するために、『実装パターン』や『レガシーコード改善ガイド』から基礎知識を得るように、一般的な文章やコミュニケーションにおける”Clean”さを追求するための基礎知識を得ることができる。

この本を読むと最初は実践は難しいような気もするけれど、本で得た知識を意識しながらメールや設計書などの文章作成に取り組んでゆくと、徐々に慣れてくる。
読みやすい文書、そして読みやすい文書を書くための思考法がシンプルであると理解できる。

最初は実践するのが難しいと思うが、2ヶ月もすれば慣れてくる。
ブログで悪文を晒している僕がいってもあまり説得力はないけど。

◯「先読み力」で人を動かす

成果をあげる人は、時間をうまく使う。
タイムマネジメント系の本は類書がたくさんあるけれども、自分にぴったりとはまったのはこの本だった。

最近はサボりがちだけれども、週に2時間は来週を中心とした3週間分のスケジュールを、ある予定を実現するためにどのような作業が必要か、という視点で見つめ直すと、ダブルブッキングがなくなり、予定の優先順位も立てやすい。

とりわけ忙しい時には、スケジューリングを行わなくなりがちだけれども、「どの作業は今やる必要はないか」という視点で、計画的な予定の先延ばしができるので、必要な時間の確保できるようになる。

ただ、スケジューリングのために、週に2時間まとめた時間をとるのは簡単なようで難しい。
僕のおすすめは、本書の教えとは違うけれども、日曜日の朝一番に時間を確保して取り組むこと。

◯デザインのためのデザイン

人月の神話』の著者、ブルックスがデザインについて言及した本。

よりデザインを生み出すための試行錯誤の方法ではなく、優れたデザインを生み出すプロジェクトのプロセスについて、自身の豊富な経験から語っている。

デザインのためのデザインというタイトルは、優れたデザインを実現するためのプロセスをデザインする、という意味で付けられたものと思われる。

そして、そのタイトルはまさに本書を正確に言い表しており、どのようなデザインを生み出すかではなくて、より良いデザインを生み出すプロセスをマネジメントするための考え方がつまっている。

「銀の弾丸はない」という表現でも有名な著者は「チームで仕事をすることは銀の弾丸ではない」と警告している。

優れたデザインは、個人かせいぜい2人の強調的な仕事から生み出されるのであり、協調的な多人数よる仕事が常に素晴らしい成果を残すとは限らない。

ブレインストーミングのようなアイデア出しには集団が向いているかもしれないが、その他の作業において集団による思考や決定が必要になるかは、都度、見極める必要がある。

僕自身、仕事はチームによる意思決定が重要だと考えて過ぎていたような気がしていて、目からウロコな指摘だった。

◯構造化分析とシステム仕様

デマルコといえばプロジェクトマネジメントの大家というイメージだったが、本書に出会ってイメージが変わった。

エリック・エバンスのドメイン駆動設計』が出版されて以来、ドメイン駆動設計(以下、DDD)ヘの注目が高まっているように感じるが、DDDにたいする先駆的な考えが本書には詰まっている。

アジャイルにやるためには、「設計と実装を切り離さない、設計と実装を切り離さないことが重要だと言われる。
本書では設計の更に前、要求を浮き彫りにし、整理するための分析とその分析をいかにシステムに反映してゆくかについて、述べられている。

要求は常に変化にさらされる。

そのため、システムそのものはもとより、システム作りのコミュニケーションや知識を集約するためのツールも、変化を取り込みやすくなければいけいない。

DDDでは、分析もまたフェーズゲートのようにすっぱりとある段階で終了するものではなく、設計と実装から分離不可能な要素であると、考えられてる。
が、その考えはすでに本書で述べられている。

構造化分析なんて時代遅れ、構造化設計とまぜこぜにして考えがちだけれども、本書を読めば時代がデマルコの構造化分析に追いつき始めてきた、と感じるとおもう。

上記のエリック・エバンスの本と合わせて読むと理解が進むと思う。

◯パターン指向リファクタリング入門

リファクタリングといえば、マーチン・ファウラーの『リファクタリング』だけれども、僕が印象に残っているのは、この本。


デザインパターンとリファクタリングのおいしいとこどりをしている。

振る舞いを変えず、プログラムの構造を洗練されることがリファクタリングの目的だ。
リファクタリングをちょっとだけでもやった人はわかると思うけど、単純にムダに重複したコードを削除するだけでも、実は根深くこんがらがったプログラムにおいては、解きほぐすための労力が必要になる。
また、プログラムの構造がおかしいことに気付いた後に、今度はどのようなプログラムの構造が理想かを思い浮かべる必要がある。

どのようすればそれが可能になるか、一番の方法は実際にプログラムを書く経験をつむことなのだろうが、その学習速度を上げてくれるのが本書だと思う。

◯デザイン思考が世界を変える

僕がデザインに興味をもつきっかけになった1冊。

デザインとは見た目をデコレーションすることでもなければ、珍奇な形を生み出すものでもない。

デザインを通じて生み出されたデザイン思考が、自身が取り組む仕事の役に立つこと、そして、システム開発においてもデザイン思考を含めてデザインの必要性を感じ取ることができる。
UXとか流行っているし、とおもってデザインに興味を持った人は、読んでおいて損はないと思う。

◯Manage It

プロジェクトマネジメントに関して、経験豊富な筆者の考え方、取り組み方がストレートな言葉で語られている1冊。

かっちりとプロジェクトマネジメントについて書いてある本の中では、僕はこの本が一番好き。

アジャイルとくくられるイテレーティブな開発やフェーズゲート開発まで言及しながら、イテレーティブでタイムボックスが設けられた開発の優位性を語っている。

大抵、プロジェクトマネジメントを語るのは元・プログラマが多く、品質保証をメインに仕事をしていた著者が語るマネジメントという意味でも珍しいような気がする。
こうしたバックボーンをもつ著者が書いたという意味で、イテレーティブな開発は品質劣化が心配、という人は、この本を読むと少しは安心するかもしれない。

◯仕事を100倍楽しくするプロジェクト攻略本

アジャイル開発を学ぶのではなく、アジャイルにやる方法が学びたいならこの本を入門とするのがいいと思う。

アジャイル開発を導入したいなら管理者には『リーン開発の本質』を渡し、プログラマには『XPエクストリームプログラミング入門』を渡せ、という言葉があったような気がするが、僕がだったらこの本を入社間のない新人に渡して、「こんな開発やりたいよね」と洗脳する。

この本がアジャイルを意識して書かれたとは思えなけれども、フィードバックと自らのチームの状態をふりかえる仕組みを取り入れつつ、チームで目的を達成するためのマネジメントについて、アジャイルに近しい文脈で語られる。

また、プロジェクトファシリテーションやレトロプロスペクティブなどの言葉は一切登場しないけれども同じ考え方が随所に登場する。

薄くて読みやすいので、回し読みをすれば、考えた方のよい共有になると思う。

◯パーフェクトソフトウェア

JSTQBなどテストの基礎的な考え方を学んゆくと、品質保証、テストのプロですら文脈によって「単体テスト」の意味が異なることがわかる。
ワインバーグのこの著作は、会社や人など文脈によってことなるテストについて、体系的な考え方を提示する。

近年はTDD、テストファーストという考え方を中心に、開発者、プログラムを書く人たちがテストについて知る重要性が増してきた。
くわえて、プログラムを書く人がいうテストの位置づけや役割と、品質保証と言われるテストのプロの人たちがいうテストの位置づけと役割も当然異なり、双方で理解しづらい部分もある。

双方の理解をすすめ、チーム内でテストの意義や役割、進めたかを合意する基礎として、本書の考え方は役立つと思う。

僕は、開発者として、同値分割などの方法論のみならず、プロジェクトおけるテストの重要性や位置づけを知るとより一層、効果的なテストコードをうみだすことができると思っている。

そのための、テストを知るための入門書として読むと良いと思う。

◯ハッカーと画家

ボール・グレアム、昨今、IT界隈では知らない人はいないY Combinatorの中心的人物のエッセイ。

文句抜きに面白い。

なぜか入社1年目で本書に出会い、Lispの勉強をはじめて人生で3ヶ月ぐらい無駄な勉強期間を過ごした。
今でも拭えないLispへのあこがれを僕に植えつけた一冊。

◯芸術起業論

プログラマはアーティスト(芸術家)だ、という主張をする人はぜひ、一読してほしい。

この本を読めばプログラマは現代の芸術家と重なる部分がある一方で、全く違う側面を持つことに気付かされる。

アート=自己表現、赤貧などという綺麗事、お花畑なお話とは一線を画する、世界で活躍する現代アーティストが自己表現とビジネスのバランスをとり続けるためになにをしているか、を知ることができる。
また、そもそも芸術がどういう活動であるのか、を知ることができる。

本書を1冊読めばアートを理解できわけではないが、現代アートというものがどのようなルールにおいて楽しまれているか、その文脈の一端に触れられる。
パッと見で、「いいね!」という楽しみ方も含め、アートの楽しみ方を知ることができる。

◯わたしを離さないで

今、話題になっているらしいカズオ・イシグロの著作。
前の会社の先輩に教えてもらって読んだ。

世の中には「知りたがり」と「信じたがり」の二種類の人間がいる。
どちらの人種が幸福な人生を歩むのかはわからないけれども、「知りたがり」の女の子が、自分が抱えている運命とどのよう向き合ったか。

淡々した表現と筆致で進んでゆく物語にノックアウトされた。

◯デュシャンは語る

現代アートは意味不明、というイメージを一般の人々に植えつけたアーティストの一人であろう、デュシャンの自伝的告白本。

アーティストは、「なぜ自らの作品が素晴らしいのか」を、視覚的な快を含めて説明できなくてはいけない。
だから、アーティストは格好つけたがり、というか、自分のやっていることをさも高尚にかたり、偉そうにしている印象があるものだけれども、本書に登場するデュシャンは全く違う。

素朴に自身の考えや感情を表現している。
人間くさく、友達思いのデュシャンの言葉は、難しいけれどもおもしろい。

◯まとめ?

ある人が、アジャイルにやる方法を教えるのは自転車にのるのを教えるようなもの、といってた。

教えられる人ができるようになるためには、教えられたことを実践する必要がある、と言いたいのだと思う。

だから、本を読んだだけでは実践はできない。

ただ、本を読まない、しらないでは、そもそもお話にならない。
それは、自転車をのりたいけれど買ってないとか、そもそも自転車自体を知らないってことだとおもう。

本ばかり読んで何のアウトプットもないのも問題だけど、それなりのアウトプットを出すには大量のインプットが必要になる。
このバランスが悩ましい。

このエントリを書いていて思い出した良書。
・モデリングの本質
・オブジェクト指向のこころ
・ライトついてますか
・スーパーエンジニアへの道
・ハイパワーマーケティング
・クラッシュマーケティング
・小さなチーム、大きな仕事
・塹壕よりScrumとXP
・ある広告人の告白
・コンセプチュアル・アート
・裏方ほどおいしい仕事はない

あと、今後読みたいと思った本。
・コードコンプリート(上、下巻)
・ノンデザイナーズブック
・プログラミング言語JAVA
・アジャイルサムライ
・Rails3.0レシピブック
・OnLisp
・プログラマの数学

なんだかんだでシステム関連ばかり。。。

広告

『パーフェクトソフトウェア』を作りたいなら読みなさい

7月 19, 2010

メディアマーカー用に文章を書いていたのですが、悪い癖で長い文章になってしまいました。
ということで、その文章をブログにしようと思います。

取り上げたい本は、ジェラルド・M・ワインバーグ氏の『パーフェクトソフトウェア』です。

私は、とくに以下の文章には感銘をうけました。

良いテストにするためには、リスクを軽減したいという要求と、過剰に情報を集めようとするリスクのバランスをとることだ。(p.6)

一般的にテストと呼ばれるものは、「品質を作り込む」ものではなく「品質を確認する」ものなのです。
テストをするだけでは、ソフトウェアの品質は上がらりません。
当間ですが、テストの結果を受け、ソフトウェアを修正しなければならないのです。
テストは、どこを修正すべきか、どのように修正すべきか、そして、その製品は出荷されるべきか、という判断のための情報を収集するための活動なのです。

ビジネスアプリケーションを作る世界では、ウォータフォール開発であろうが、アジャイル開発であろうがテストの必要性は疑いもないことです。
そして、開発現場における「テスト」としてTDDが出現してきた昨今、「品質を確保する」という使命は品質保証(QA)やテスターだけのものではなくなりました。
もちろん、今までも開発現場の主役である開発者にとっても、「品質の確保」は責務の一つであったのですが、TDDによりそれがより明確になったのです。
なにより、各々が携わる現場において、品質に目を向けて作業をする、という点は、品質の良いソフトウェアを作り込むうえでよいことです。
しかし、各現場において「テスト」という概念が生まれてことにより、開発現場や品質保証の現場、そこに携わる人々が混乱していることも事実です。

ワインバーグ氏が本書で取り上げるテストの概念は、そうした現場の混乱を解きほぐすものになるでしょう。
ワインバーグ氏は、テスターの仕事として以下の作業を取り上げています。

・発見のためのテスト
ソフトウェアを動かし、そのソフトウェアについて新たな情報を得るためのテストです。
たとえば、想定される業務シナリオをどおりに動くか、データ異常が起きた場合はどのようにアプリケーションが振舞うか、などをチェックします。

・絞り込み
想定される挙動とはことなる動きをソフトウェアがした場合、その原因はどこにあるかを調べます。
そのために、そのバグの再現方法と条件を調査し、バグの潜む箇所を絞り込みます。

・特定
バグがコード上のどこにあるか」、デバック作業などで確認します。

・重要度の決定
特定されたコードを修正することと、その修正のために入り込むリスクなどを判断します。
また、修正を行わなかったときのリスクも考慮に入れる必要があります。

・修正
修正を決定したコードを変更し、バグを取り除きます。
修正後は、バグを発見した時と同様のテストを行ない、バグが発生しないことを確認します。

・トラブルシューティング
トラブル発生時に、その障害を取り除いたり、回避したりするのための対策を行います。

・学習のためのテスト
バグを発見することを目的するのではなく、自らの興味に従ってソフトウェアの挙動を確認します。
ハッキングやリバースエンジニアリング、「遊び」ともいいます。

アジャイルな開発プロセスにかかわらず、こうした作業をいったい誰がやるのか、という点を明確化する必要があります。

TDDを例にあげれば、TDDで書かれるテストが本当に「発見のためのテスト」となっているのか、をよく検討する必要があるでしょう。
TDDのテストが、「発見のためのテスト」として機能しえない、と判断されるなら、別でその保障をする必要があります。
また、TDDが「発見のためのテスト」の一部と考えられるのであれば、TDDのテストコードの規約がひつようになったり、システムテストに含めるべきケースも変わったりするはずです。

また、システムテスト時には、「発見のためのテスト」はテスターがやる、「特定」については開発者がやる、など線引きを行う必要があります。
トラブルシューティングなどもどの立場の人間が行うか、またどのような順番で持ち回るか、などを検討しておく必要があります。
プロダクトに関わるすべての人が、責任を持つべきだ、といえば格好がいいのですが、責任の所在があいまいになります。
なによりも、「自分の仕事である」という自覚がない仕事をやらされると、その仕事を矯正されていると感じられ、メンバーの士気は大幅に低下します。

また、テストのコミュニケーションについて、以下のようなプロセスを取り上げています。
上記が、テストの作業を示すものならば、テストにおけるコミュニケーションにおける注意点と原則を示したものです。

・取り込み
能動的に情報を吸収する段階です。
この段階でもすでに情報そのものだけでなく、伝える人物や方法によって情報の取捨選択が行われている可能性があることに注意が必要です。
積極的に情報を収集するとともに、優先度による情報の整理も必要になります。
ただし情報にたいする「意味づけ」は行ないません。
そのためにも、1つの情報が意味することを3つほど考えて1つの意味にとらわれないように心がける必要があります。

・意味づけ
テストによって集められた情報を解釈し、情報が「何を意味しているか」を検討し、決定する段階です。
テストにたいする具体的な期待を明確にしていることが重要になります。
なぜならプログラムが「なにをするべきか」という目的によって、プログラムの動作がバグか否かが決定されるからです。
この作業は1人だけで行わず、複数のメンバーで集まって行なったほうが複数の観点から検討する必要があります。

・意義づけ
意義とはバグにたいして割り当てられる重要度のことです。
バグが製品にとってどれだけ深刻なものか、優先順位をつけ管理し、重要なものから対処してゆきます。

とくに修正の難しさと意義を混同して、難しいものを意義の高いものとして判断してはいけません。

また、意義は個々人の立場によって異なってきます。
それらの多くは、合理性よりも感情に基づいているからです。
そして、人々の感情は立場や受けているプレッシャーによって変化します。
この点を無視してはいけません。特に、意義づけを行うときは、自分自身の感情に目を向けることが必要です。

・反応
バグにたいする反応は、3つのフェーズに分けられます。
-見つけ(find)
-考え(figure)
-直す(fix)
難しいのは、このシンプルなプロセスを維持することです。

そのためには、なによりもプロジェクトの初期段階から正しくプロジェクトが運営されていなければいけません。
正しく運営されないプロジェクトは、終盤での混乱を招き、テストおよび修正のための時間を奪ってしまいます。
そして、とくに品質確認段階のテストで、その点を挽回することはとても難しくなります。

また、テストおよび修正のための見積を正確に行える準備が必要です。
プロジェクトの終盤では特に、「修正するに足るリソースが残されているか」を判断するための見積が重要です。
「修正のためのリソースがない」と判断されたバグが製品にとって深刻な場合は、その機能を外して出荷するか、最悪の場合は出荷そのものを取りやめる判断をする必要があるからです。

以上のようなテスト作業について、プロジェクトのどの段階でどのような立場の人々が責任をもって行うのか、そして、どのようなコミュケーションプロセスがテスト、ソフトウェアの品質に関わってくるのか、を考えてゆくことで、現場の混乱も緩和できるのではないでしょうか。
本書はそれらを整理し、実践することのヒントを与えてくれるはずです。

ソフトウェアの品質向上を目指す人達には、是非、手にとっていただきたい一冊です。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

私は「月」を目指すことにしました。

12月 19, 2009

唐突ですが、月を目指すことにしました。
その月は、

「汎用機開発と美術について語れるスクラムマスターになる」

というものです。
そのために、

「次回の認定スクラムマスター研修を受ける」
「2010年11月の美術検定で3級を取得する」
「1年後にアジャイル開発・保守チームを社内につくる」

という目標を立てました。
やれるかどうかは、わかりません。
とくに、3番目は独力だけは絶対に無理です。相当、難しい試みだと思います。
でも、目指すべき場所は、はっきりしてきました。ですので、やりがいがある、と思っています。

さて、なぜいきなりそのようなことを書き始めたかといいますと、きっかけがあります。
それは、1冊の本との出会ったこと、2009/12/12(土)に「DevLOVE2009 FUSION」というシステム開発などに携わるエンジニアが集うイベントに参加したことです。

まず本の紹介です。その本とは、本田直之さんの『パーソナル・マーケティング』です。

この本を読んで、キャリアを築くに際して、マルチ・キャリア、そしてコントリビューション(貢献)という考え方を意識するようになりました。
マルチキャリアとは、自分の強みを掛け算することです。

ひとつの分野で抜きんでて実績を出すことは難しくても、いくつかの要素を組み合わせることで独自性を創りだすことが可能です。(p.141)

たとえば、汎用機開発に携わる人は、まだたくさんいます。しかし、汎用機開発に携わり、かつエクストリーム・スポーツをやっている人は、あまりいないはず。
さらに、その人がはやりの野菜ソムリエの資格を取得したら、その人の独自性はいっそう際立つでしょう。

では、掛け合わせることができる強み、とはどんなものでしょうか。
著者は、強みを「人に教えられるもの」と表現しています。

ところで、「強み」とは何でしょうか? 私はひとことで言って、「人に教えられることを持っている」ことだと考えます。
(中略)
ちなみに私は、自分がキャリアを積んだり、スキルを磨いたりするときにまず、「それを身につけることが、誰かの役に立つだろうか?」と自問するようにしています。(pp.88-89)

「人に教えられる」「人の役に立つ」という知識や経済の根源的な考え方にもとづいた、「強み」の表現が、わかりやすく、納得できました。
こうした、マルチ・キャリアとコントリビューションに基づいて、キャリアを形成しようと考えたときに、今度は別の疑問が浮かんできました。
それこそが、「今後、自分は何を目指すべきか」「今後、自分は何に取り組むべきか」という疑問です。

「独自性のあるキャリアを構築したい」
「そのキャリアを築くうえで何を強みとすべきか、何が人の役に立つか」
「キャリアを築くうえでプラスになるスキルを何か」

こうした質問がぐるぐると頭の中を回った状態で、私は「DevLOVE2009 FUSION」に参加したのです。
そして、とてもうれしい思いをしたのです。
それは、こんぴろさんのセッションで、

「汎用機開発に携われるのは、うらやましい」
「汎用機開発とオープンとの橋渡し的な技術を学んでみたら」

という言葉をいただけたことです。
汎用機開発でも学ぶべきことはあります。
しかし、これから先を見通したときに、汎用機の開発における知識だけではとても不安でした。
レガシー技術といわれ、これから火が消えてゆくような技術に業務でかかわることに、閉塞感を感じていました。

そんな私にとって、セッションいただいた2つのアドバイスは、目の前の扉を開く鍵のようでした。
汎用機開発に携わることそのものに、可能性を感じ始めることができたのです。

上記で紹介した『パーソナル・マーケティング』におけるマルチ・キャリアにおいても、「20代で汎用機開発に携わった」という事実はきっと独自性をだすためのひとつの要素になると感じることができたのです。

また、なによりも、

「生き残る、という戦略を考えてみたら」

という言葉いただいたときには、本当に心が洗われる思いでした。

「もっとチームを良くしたい」
「もっと役に立てる技術者になりたい」

と考えて、学んでいるうちに、ついつい独りよがりになり、

「もっと華々しい活躍をしたい」
「もっと褒められたい」

という的のはずれた欲求も生み出していたのではないか、と反省させられました。
華々しい活躍もすばらしいですが、今、それが望めないのであれば、「生き残る」という謙虚な姿勢から自分の仕事の価値やキャリアについて考えてみるのも良いかもしれない、と思えました。
何より、自分の能力を鍛えることは、自分自身が華々しい活躍をするためではないのです。
それは、仕事とはお客様とチーム、そして社会に貢献することが目的です。
その第一の原則を、「生き残る」という言葉に思い出させていただきました。

このほかにも、セッションやエンジニアの人との交流をつうじて、

「クラウドはバズワードじゃないっぽいな」
「今、アジャイルに参入することでアーリーマジョリティーにはなりえるかも」
「ドラゴンボール理論、ワンピース精神に準じるワンフレーズの原則をつくってみたいな」
「アジャイルを導入するに役立つビルディングタイプはあるなかな」

などと取り留めのないことを考えました。
まだまだ、まとめられる段階ではないので、記事にはできませんでした。
これから学びや経験を通じて、自分の思ったこれらのことをまとめて記事にしたいと思います。

何よりも楽しかった!
そして、とても大きな成果も得られました。
その成果が、自分の強みと信じる要素をFUSIONさせた、冒頭にある私の「月」です。

※「月」=目標。 これは、papandaさんのセッションからのパクリです。

【コミュニティ情報】
◆DevLOVE
・DevLOVE’Site
・DevLOVEメーリングリスト・サイト ※googlegroupへの参加が必要です。
【イベント情報】
◆「DevLOVE2009 FUSION」 ※すでに終了しています。
http://www.machoup.jp/devlove2009/index.html

『週末はギャラリーめぐり』をしたくなる

12月 13, 2009

かなり前に「読みます!」宣言をした、『週末はギャラリーめぐり』という本を読みました。
久々に自分の興味と本の内容が一致する、という気持ちの良い読書体験ができました。
著者の山本冬彦さんは、アートソムリエを自認し、30年間で1300点もの芸術作品を収集されたという方です。
山本さんの蒐集のきっかけは、マンションを購入した際に壁に飾る絵を探したこと、というのですから、まさに趣味を極めた方です。

そんな著者の手がけた本書は、まさにアート初心者、必読の書です。
現代アートの美術館の紹介から始まり、美術品の種類の説明、都内にある主要な画廊の紹介、画廊やギャラリーでのマナー、美術品蒐集の始め方までと、アート初心者が知りたいことを的確に捉えた内容になっています。

たとえば、初心者にありがちな以下の疑問にも本書では答えてくれています。
・美術品の保存って難しいのでは?
→ きちんと額に入れ、日光や冷暖房の風をダイレクトに当てなければ神経質にならなくても良い。

・サイン帳(芳名帳)ってなに?
→ 個展を開催した作家にとって、どれだけの人が個展に来てくれたか、という記録になる。
また、住所を書くと画廊が開催するショーの知らせを送るのにも使用する。

・最初にどんな作品を買ったらよい?
→ 無名で若手作家の本物の作品を購入する。もちろん、自分の目と頭で価値判断を下して買うこと。

特に私に強い印象を残したのは、著者のコレクションにたいする考えをあらわした以下の文章です。

お金に任せて集めたコレクションの中には、世間で有名な作家の作品ばかりをすすめられるままに集めたもので、そこには集めた人の独自の眼がまったく感じられない、つまらないものが時々見受けられます。
コレクションを雑誌にたとえると、どんなに有名な人気作家を執筆陣に集めて文章を書いてもらっても、その雑誌のテーマやコンセプトが明確で独自性がなければ立派な雑誌はできません。
コレクターとは雑誌の編集者であり、コレクションとはまさに編集という創造活動なのです。 (p.139)

コレクションを創造活動である、とする著者の考え方には共感をおぼえます。
私の場合は、アートではありませんが、読書が趣味なのでよく本を購入し読みます。
社会人になってからは、ビジネス書を中心に読んでいるので、最近まではビジネス書が本棚の大半を占めていました。
しかし、現代アートに興味をもつになってからは、アート関連の本を購入して読む機会が増え、徐々に本棚を侵食してきました。
そのような本棚を眺めていると、自分の思考や嗜好の変化、そして、現在の自分の頭の中を取り出して眺めているような気分になります。
そして、その本棚が自分のひとつの作品に思えてくるのです。
こうした点が、著者のコレクションにたいする思いに共感をおぼえる点です。もちろん、お金のかかり方は天と地ほどの差がありますが。。。

また、こうしたコレクションのたいする思いを見ると、「じぶんも集めてみたい」という思いが強くなってきます。
今年の5月に現代アートと面白みに気づくまで、「アートを買おう」ということなど微塵も考えたことがありませんでした。
それは、触れてきたアートがルネサンスやバロックなどの売り買いどころか、売買すらされないような価値をもった作品を中心に美術館で鑑賞してきたからです。
そして、現代アートに興味をもって「作品が買える」という、当たり前の事実に衝撃を受けてなお、作品を購入するまでにはいたりませんでした。
しかし、著者の言葉を見ると、購入する、集める、という行為そのものが自分自身を表現する1つの手段であると気づかされました。
絵を描くこと、彫刻を削りだすこと、映像を切りとり表現することをあきらめてしまった私にも、芸術にかかわりながら表現する手段がある、このように考えると俄然、「コレクションをはじめたい」と思わされるのです。

とはいえ、はっきりいってお金はありません。
ですので、現代アートを見る際には、買わないまでも「買うか、買わないかの視点で作品をみる」ことを実践したいと思います。

「自分だったらこの作品を買うだろうか」
「この作品だったら買ってもよいとおもうけど、なぜ買いたいと思ったのだろう」

こうしたこと考えながらアートを眺めることで、自分のアートにたいする考え方や趣味・嗜好が見えてくるはずです。
特に何も考えず、偶然にまかせて「いいな!」と思える作品に出会える、というのも素敵な経験だと思います。
しかし、それだけで放っておいてしまうと、出会いだけで終わってしまいます。
素敵な作品に出会ったら、出会いだけで終わらせてしまうのはもったいない。
作品の魅力と自分の趣味・嗜好のどこがあっていたのか、を考えると、その作品とより深い付き合いができそうです。
また、自分の好きな作風の作品たちに出会う機会も増えそうです。

「鑑賞するだけのアート」から「購入を考えるアート」へ、ちょっと進んでみたいと思います。

最後になりますが、著者の山本冬彦さんのコレクションが、なんと!東京で見られるチャンスがあります。
場所は千駄ヶ谷駅ちかくの佐藤美術館で、1月14日(木)より開催、とのことです。
アートソムリエのコレクションに興味がある方は、是非、足を運んでみてください。

【作家情報】
◆山本冬彦(Huyuhiko Yamamoto)
・アートソムリエ・山本冬彦
・山本冬彦, 『週末はギャラリーめぐり』, ちくま新書, 2009年
【展覧会情報】
・佐藤美術館-Exhibition_「山本冬彦コレクション」展
・芸力-検索結果_「山本冬彦コレクション」展

『ひとつ上のチーム。』ってなんだ?!

12月 6, 2009

かなりまえになりますが、『ひとつ上のチーム。』という本を読みました。
コピーライターの眞木準が編集をつとめ、広告業に携わる人たちの理想のチームについての考えを、纏め上げた本です。
編集の眞木準をはじめとして、登場する人々は「見たことある!」、そして、その時代で話題となった広告に携わってきた人たちです。

私が当時この本を手に取ったのは、広告業とソフトウェア開発、はとっても似ているところがあると思っていたからです。。
まずは働く単位がプロジェクトである、というところです。
何か広告を生み出すときには、その期間に人が集められ、広告という成果物を生み出し、チームは解散、となります。
ソフトウェア開発でも、お客様からの依頼があり、いつまでにシステムを納めるかという納期(プロジェクトの期間)を決め、システムという成果物を生み出し、開発チームは解散となります。
次に、肩書きにカタカナが多いことです。
広告業では、クリエイティブディレクター、コピーライター、デザイナー、CMディレクター、フォトグラファー、プロデューサー、マーケティングディレクターなどなど、まだまだたくさんの肩書きがあります。
ちなみにソフトウェア開発では、プログラマー、プログラムマネージャー、プロジェクトリーダー、アーキテクト、コンサルタント、さらにはシニアプログラマーなどなど、です。

2つの共通点をもつ広告業とソフトウェア開発は、日本における立場には天と地ほどの違いがあります。
今、就職活動に励んでいる学生も多いかと思いますが、そのほとんどの人たちは「広告業って面白そう」、と思って採用試験を受けると思います。
一方、ソフトウェア開発については「面白そう」と思って、採用活動を受ける人たちが何人いるでしょうか。
また、広告業のこうしたチーム論の本を出せば広告業以外の人も手に取ることはあるでしょうが、ソフトウェア開発の人たちがこうしたチーム論の本を書いた場合、どれほどの人たちが手にとるでしょうか。
自分が仕事をしている業界を悪く言いたくはありません。
そして、現に今の仕事にはたくさん面白みを感じています。
ただ、一般の人たちはおそらく、現場にあるソフトウェア開発の面白みをまったく知らない。もしかしたら、興味もないかもしれません。
なので、本を読んだ当時は、こうしたチーム論の本を作り売り出せる、という広告業の立場の人たちをうらやましく思いました。

<チームの二論>
今回、私がこの本を取り上げたのは、2009/11/25(木)に「すくすくスクラム」「チームとは何だ?!」という勉強会に参加したからです。

広告業とソフトウェア開発の共通点は、上記に挙げた働く単位、肩書きだけでなく、意識する組織の単位がチームである、という点もあげられます。
もちろん、会社という大きな組織に所属しているのは、他の業界と同じです。
しかし、プロジェクト、という単位で働いて成果をもとられるので、意識する組織の単位は会社ではなく、プロジェクトのチーム、という単位です。

「すくすくスクラム」の勉強会では、スクラムという開発手法をもちいたシステム開発プロジェクトに携わる人たちのチームにとって大切なことはなにか、優れた成果をだす「ひとつ上のチーム」とはなにか、グループワークを交えて学んできました。
講師は、アジャイル開発の導入支援などに携わるodd-e-Japanの代表取締役、エマーソン・ミルズさんです。

・良いチームは統一的な理念、目標をもっている
・人は育てるのではなく、育つ
・失敗は人とチームを育てる
・管理できる失敗を仕掛けることでチームの成長を促すこともできる

など、チームやチームを構成する人についてのさまざな指摘がなされたのですが、私の印象に残っているのは、

・うまくいっているチームを解散させてはいけない

という言葉です。
うまくいっているチームとは、チームのメンバー同士の信頼も高く、成果も出していいるチームです。
こうしたうまくやっているチームの良い部分を、他のチームに波及させるため、うまくいっているチームを解体してしまうことは、プラスがないとミルズさんは言います。
うまくいっているチームとは、仲の良いメンバーで楽しく仕事をし、成果を出している。
にもかかわらず、成果を出したとたんに解体してしまったら、仕事をうまくやるインセンティブはない、というのです。
たしかに、うまくいっているチームほどチームメンバーの仲もよく、楽しくは働いている印象があります。
そして、そのようなチームを解体させることには利点はないのかもしれません。

実際、私が今、所属しているチームもおなじ会社のシステムを10年以上もの間、開発から保守・運用まで携わっているチームです。
そして、長い期間、それほどメンバーが変わることなく、続いているチームです。
私自身も、入社して半年後にそのチームに配属されたから、一貫してそのチームに所属し続けています。
ですから、ミルズさんがおっしゃっている同じチームに所属することの利点を実感しており、共感をもちました。

しかし、仲が良いからといってずっと同じチームで仕事するべきなでしょうか。
ずっと同じメンバーで仕事をすることでチーム内での知識や技術の属人化が進んでしまわないのか。
そして、誰と一緒じゃなきゃダメ、そして、成果が出せない、というのでは、その人にはあまりにも柔軟性がたりないのではないか。
そのような疑問も抱いてしまいました。
仲の良い、やりやすいチームでやることが成果をだすことにつながる、というのは事実でしょう。
一方、現実としては、誰とでも、どのような状況でも成果を出すことを求められます。

『ひとつ上のチーム。』でも以下のような2つの対極の考えが紹介されています。

まずは、チームの人にはこだわりを持つのがプロフェッショナルな仕事をする条件である、という考え方です。

誰と組んでもいい仕事ができるというわけではありませんから、組む相手はおのずと決まってきます。これはやむをえないことだとぼくは思います。
いいかえれば、チームがうまくいくかどうかは、その人が優秀であるかどうかだけで決まるものではないということです。
スターばかりを集めたドリームチームをつくれば、それで何もかもがうまくいくわけではない。仕事の出来を考えれば、嗜好が一致しているかどうかのほうがはるかに大切です。(p.53)

次に、チームの人にこだわりをもつのではなく、誰とでも仕事ができる柔軟性をもとめる、という考え方です。

ときどき、コピーライターは誰で、アートディレクターは誰でなければ、いい仕事ができないといってはばからない人がいますが、その姿勢は本当のプロフェッショナルのものとはいえないとぼくは思う。
そうではなくて、一定以上のレベルのスキルをもったスタッフとならば、誰とでも組める。目的に向かって、誰とでも課題を解決してみせる。
そういう姿勢であらゆる仕事にのぞめるのが、真のプロフェッショナルであり、その哲学のもとで編成されるのが、本当のプロフェッショナルチームではないかとぼくは思います。(p.95)

ひとつは、自分のチームというものをもち、メンバーにこだわりをもちながら仕事をすることで成果を出すことがプロフェッショナルの仕事であり、気心の知れたメンバーで組織されるべきだ、という考え方。
もうひとつは、自分のチームやメンバーにこだわりを持つのではなく、誰とでもプロジェクトの目的を共有しよいチームを築き上げて成果を出すのがプロフェッショナルのしごとであり、特定のメンバーにこだわることは意味がない、という考え方。

ひとつ上のチームにたいする考え方には、こうした対立的な2つの考え方あるようです。

<理想のひとつ上のチームを作るために現実を受け止める>
この対立的な2つの考え方はどちらが正しいのでしょうか。
私は、前者が良いチームとしての理想、後者が良いチームとしての現実、なのではないか、と考えています。

嫌な仕事を嫌なメンバーをやるよりも、好きな仕事を組んでいて楽しいメンバーとやって成果を出すほうが良いほうに決まっています。
よく言われますが、嫌な仕事を嫌なメンバーとするには、人生は短すぎます。
楽しみながら成果を出す、こうしたチームが理想です。
しかし、現実には自分が所属できるチームを選ぶことはほとんどできません。
会社やプロジェクト、お客様といったさまざまな要素によって、自分が所属するチームは決められてしまうことが一般的です。
システム開発においては、システム規模が大きくなればなるほど、自分が所属するチームを選ぶことは難しくなります。
システムのこの部分は自分の会社、この部分はあの会社、ハードウェアの管理はその会社などと、自分の仕事とかかわりをもつチームは大きくなって行きます。
ですので、たとえ自分の会社内でよいチームをつくり、維持することが定着しても、それだけでは理想の良いチームで仕事することはできません。
そのときに必要なのは、

理想のひとつ上のチームを作り上げる行動を起こす

ということなのだと思います。
そして、チームの人にこだわりをもつべきでない、という考え方は、こうしたときに前を向くために必要な考え方なのだと思います。
プロジェクトメンバーのとして集まった自分たちの目標を共有し、自分たちの能力を遺憾なく発揮すること、そうして優れた成果をだすことで、プロジェクト内の人と人との関係も成熟してくるのではないでしょうか。
そのために自分が理想のチームにいないことを嘆かず、理想のひとつ上のチームをつくるために行動すること。
こうしたことの背中を押すために、現実のひとつ上のチーム論が存在するのではないか。
そのように私は考えています。

この質問をお客様にできますか?

11月 24, 2009

最近、読んだ本で本当に身につまされる言葉を発見しました。
現代アート、とはまったく無関係ですが、私の趣味と実益をかねた読書のメモとして紹介したいと思います。

本のタイトルは『選ばれるプロフェッショナル』という本です。
内容は、弁護士やコンサルタントなど、特定の顧客をもったプロフェッショナルとしてもつべき7つの資質をあげ、それぞれの資質について詳細な説明をする、というものです。
ちなみ、7つの資質とは以下のとおりです。

・無私と自立
・共感力
・ディープ・ジェネラリスト
・統合力
・判断力
・信念
・誠実さ

柱となる主張は、選ばれるプロフェッショナルとはアドバイザーであるということです。
普通の弁護士やコンサルタントという専門家は、専門性を売りにします。
弁護士は法律の知識ですし、ITコンサルタントは、システム技術の知識を売りにします。
さらに、弁護士であっても離婚などの婚姻関連の知識に強い、ITコンサルタントであれば、金融業のシステムに強いなどさらに細分化した知識の専門性で競争しようします。
しかし、そのような専門性を売りにした専門家は代替可能な汎用品に過ぎない、と著者たちはいいます。
そして、単なる専門家を超え、顧客に選ばれ続けるプロフェッショナルこそ、アドバイザーという立場にある、というのです。
では、選ばれるプロフェッショナルである、アドバイザーとはいかなる立場にあるべきか?
そのアドバイザーがもつべき7つの資質の詳細はいかなるものか?
こうした点については、本書に譲るといたします。ご興味があれば、是非、本を手にとってください。笑

私が本書を読んでいて心に残ったの以下の文章です。

・私の仕事について、率直な評価をお願いしたいと思います。
・私は、お客様にとって最も主要で重要な問題に取り組めていますか?
・私は、できるかぎりお話に耳を傾けられていますか? どうすれば、お客様やお客様の組織にとって、もっといい聞き手になれるでしょうか?
・お客様のビジネスや組織について、私がもっとよく理解しておくべき点はありますか?
・全体的に見て、お客様が目標を達成するために、望まれていることはありますか?
・どうすれば私とのビジネスがもっとやりやすくなるのでしょうか?
p.107

非常に怖い、勇気のいる質問だと思います。
お客様はこの質問にたいして本音で答えてくれるでしょうか?
また、その本音の答えを真摯に受け入れることができるでしょうか?

本音を濁して返答されてしまえば、お客様の自分にたいする本当の評価を知ることもなく、問題点を改善することはできません。
なにより、返答を真摯に受け入れず、問題を改善する努力を怠れば、お客様は離れていってしまいます。

この文章は、共感力という資質を説明する際に書かれていました。
しかし、この問いは、自分自身が行なうべき仕事にたいする根源的なものなのではないかと思います。
というのは、仕事というのは、お客様の望みをかなえる、役に立つ、ということが第一の原則だからです。
お客様が満足を得て、お金を払うのは、仕事として提供したサービス(もしくは物)が、自分たちの望みをかなえ、役に立つからです。
お客様の望まない、役に立たないことは、いかに時間を割こうが、一生懸命行おうが、自己満足にとどまる行為です。
この自己満足の行為にたいしてお客様はお金を払うことを馬鹿らしく感じるでしょう。
また、不満を感じることでしょう。

忙しくなると目の前の作業に追われがちです
そして、仕事の本当の意味、目的である、お客様の役に立つ、という点を見落としがちです。
上記の質問には、自分の仕事の目的はいったいなんであるのか、という根源的な目的を見直すための力があります。

<自問自答しよう>
腹を割ってお客様と話す、というのは理想的な関係です。
そして、理想的で有意義であるとわかっていてもなかなか確立できない関係でもあります。

こうした言葉によってお客様からフィードバックを得る、という仕組みをすでに組み込んでいる会社があるかもしれません。
しかし、私の勤めている会社では、こうした仕組みは確立されていません。
また、私自身も行ったことがありません。

今すぐにでも取り組めることは、自問自答することではないかと思います。

お客様は今の自分の仕事にどのような評価を下している?
自分の仕事はお客様の抱える問題を解決している?具体的などのような問題解決に取り組めている?
お客様は何を話したがっている?何を理解してほしいと望んでいる?
お客様はどのようなプレッシャーを受けている?
お客様の目標は何?そのために自分はなにができる?
お客様と自分が良い関係を築くために自分にできることは何だろう?

忙しくなり余裕がなくなったときこそ、自分が手をつけようとする仕事の意味を、お客様の視点から問い直す。
このことで自分の仕事が的をはずことを防いで無駄な作業を減らし、お客様の満足を得る仕事をしたい、と思います。
なにより自信をもって、上記の問いかけをお客様にできるような仕事をしたい、と思います。