Romanticismこの広告は、90日以上更新していないブログに表示しています。『スモール・リーダーシップ』では、リーダーシップのあり方として、「協調型」という言葉を使っています。これについては平鍋さんの推薦の言葉を引用したいと思います。自分で考え、自分で決め、自分が指示する、というやり方では、現代のプロジェクトは簡単に破綻します。それよりも、一緒に考え、一緒に決め、一緒にコミットするチームを作ること。成功の喜びを分かち合う仲間を作ることのほうが、大きなビジネス成果を生み出すことができるのです。リーダーに求められることを一言で言えば、「チームで考えながらゴールを目指す」ことになるのですが、それにあたって考えなければいけないことは大きく二つあります。一つは「チームで成果を出すこと」、そしてもう一つが「チームを成長させること」です。書くと簡単なようですが、そのために学ぶべき事柄は多岐にわたります。一方ではプロジェクトマネジメントの手法を知る必要があり、それと同時に、「チームで考え、問題を解決していく」ための広義のコミュニケーション能力が必要になるのです。そこで、『スモール・リーダーシップ』では、チームとしてのゴールに向かうためのマネジメント手法と、コミュニケーションについて考えなければいけないことの二つを軸として整理しています。本記事では、特に「コミュニケーション」にフォーカスを当てて、「協調型」リーダーにとって役に立つ本を紹介していきます。見るリーダー/マネージャーの仕事を理解する一冊目は、『最高のリーダー、マネジャーがいつも考えているたったひとつのこと』です。この本は、「リーダーとして、マネージャーとして何をしなければいけないのか」を実にわかりやすく教えてくれます。邦題が若干誤解を招きますが、「マネージャーとして知っておくべきこと」「リーダーとして知っておくべきこと」がそれぞれ個別に提示されています*1。要約すれば、マネージャーに求められるのは「『人』と向き合うこと、つまり、メンバーの個性を理解してそれを活かすこと」であり、リーダーに求められるのは「進むべき方向を明確に示すこと」です。普通の組織論に見えますが、どちらかというと「個人として読者がどうするか」という視点で書かれている印象です。事例も豊富で題材も多岐にわたるため、読み物としても楽しめます。見る考える力を育てる「コミュニケーション」というと「伝える」ことに目が行きがちですが、その前提として、いわゆる「論理的思考力」が備わっていなければなりません。「チームで考える」ことを目指すのであれば、自分が理解しているのは当然としたうえで、そうした「論理的思考力」をどう身につけてもらうかもあわせて考えなければいけないのです。考える力の育て方――ものごとを論理的にとらえ、目標達成できる子になる』です。タイトルにもあるように「子どもの考える力の育て方」の体裁をとってはいますが、ここで紹介されていることには子どもも大人も関係ありません。「答えを教えるのではなく、傾聴しながら相手が答えを出すのを支える」という姿勢は、協調型リーダーにとって欠かせないものです。論理的思考のためのフレームワークとしては、TOCfEが採用されています。この本はTOCfEの教科書として見ても、きわめてわかりやすく解説されています。見る共感力を高める「『仕事』なのだから感情は持ち込むべきではない」という考え方はもちろん正しいのですが、人間そこまで割り切れるようにできてはいません。押し殺された感情は必ず別の形で噴出することになります。したがって、リーダーは「論理」だけでなく、「感情」に寄り添うことが求められるのです。人と人との関係にいのちを吹き込む法』です。Communication(非暴力コミュニケーション)の略で、「人を思いやる気持ちを引き出し、人と理解しあう」ためのコミュニケーションの方法論です。方向性としては、『スモールリーダーシップ』でも紹介した『話す技術・聞く技術―交渉で最高の成果を引き出す「3つの会話」』に近い部分もありますが、こちらの方がより深く感情に寄り添っています。NVCの大きな特徴は、まずは自分の感情を見極めるところから始まる点にあります。感情に触れれば、当然自分の感情も揺れます。「そうした感情に対してどう向き合うのか」から丁寧に解説されています。見るまとめ知識領域がどんどん幅広く、また深くなっている今、「知識労働においては、仕事の成果は「知的能力」×「コミュニケーション能力」で決まる」とも言われます*2。「知的能力」あるいは専門分野における能力を高めなければいけないのはもちろんですが、チームとして成果を出すためのコミュニケーション能力を高めるうえでフレームワークとなる本のご紹介でした。*1:付け加えると、「個人として継続的に成功を収めるために知っておくべきこと」を含む三本の柱で構成されています。チームを育てながらゴールに導く「協調型」リーダー』について、簡単なまとめとふりかえり。見る出版に至る道のりソフトハウスでプログラマを始めて以来、システム開発のベンダー側に10年ほど勤めていましたが、2015年10月からユーザー企業の情報システム部に勤務しています。早いもので、もうすぐ二年が経つことになります。「発注者の側に回っても、システム開発に変わりはなかろう」と思っていた部分はあったのですが、いざ移ってみるとその見込みの甘さに気づくことになります。SIer側にいた頃と比べると、文化や基礎知識、さらには責任範囲もまったく違う環境に移った結果、今までの「最前線で手を動かしながら、全体としてのバランスを取る(もしくは、周りのメンバーに取ってもらう)」というやり方が通用しなくなったことを強く感じました。これは、今にして思えば、できあがるモノやそれを作るプロセスの前に、以前にも増して「組織」と向き合わなければならなくなったことを意味しているのですが、転職してすぐの頃はそこまではっきりとは理解できませんでした。「システム開発のような汎用性の高い知識は自分の中にある一方、業務知識はまったくない」という状況を受けて、最初のうちはチーム内の議論をファシリテートすることに徹していました。以前はそれほど多くなかった「ホワイトボードを使った認識合わせ」を数多くこなすうちに、そういう時のちょっとしたテクニックを言語化することは、「やろうとしてもなかなかうまくいかない」と困っている人の役に立つかもしれないと思い、最初はブログのネタとして書きためていました。そんな折に翔泳社の岩切さんから本を書かないかと勧めていただき、「実はホワイトボードの本を書きたいと思っているんです」とお願いしたのが、この本を書いたそもそものきっかけです*1。その後、書き進めるうちに、「そうやって認識合わせをしていることの目的は、実は会議をうまく進めることに留まらないのではないか?」と、自分の立ち位置に気づくことになります。「書くべきなのはホワイトボードの話ではなく、リーダーとしての仕事のやり方の話だ」ということになりました。日々の仕事に追い回されていると「組織に対して自分は何をするべきなのか/したいのか」という根本的な問いかけをする機会は意外とありません。著者である自分自身にとっても、考えていることを言葉にできたことは大きな価値があったと思っており、お声がけくださった岩切さんに深く感謝しています。何より、読者の方にとって、日々のチーム運営の奥にある「人と向き合うこと」を改めて考えることが意味あることになれば幸いです。本書で伝えたかったこと「特定の問題を解決して成果を出すこと」と「組織と向き合うこと」は本来切り離せないはずですが、両者の必要な知識セットはだいぶ異なります。メンバー(プレーヤー)として仕事をしているときには自分で考えて答えを出せばよかったことも、リーダーになって「考えるプロセス」自体を共有しようと思えば、そのプロセスを改めて言葉にする必要が出てきます。変わった環境に適応するため、私自身ここ二年ほどは、「組織」や「チーム」といったテーマについて、意識して本を多く読むように努めていました。いった活動を通じて感じたことが大きくは二つあります。定跡の奥には常に「人」がいるどちらも基本的なことではあるのですが、一通り理解することはなかなか容易ではありません。どこまで行っても定跡は大切あるジャンルを扱った本を何冊か読んでいると、「根底に流れている考え方」もっと言えば「定跡」のようなものがぼんやりと見えてきます。システム開発で言うなら、例えば、「V字をきちんと設計しましょう」(つまり、「仕様は検証しましょう(横のつながり)」/「成果物間の連携は正確にとりましょう(縦のつながり)」)というような話です。チームの文脈に置き換えるなら、「目標を設定し、そこに向けてメンバーの意識を揃え、そこに至る道筋を作り、日々発生する問題を解決し、定期的にふりかえって改善する」ということになるでしょう。これ自体は普通のことなのですが、目の前のタスクでいっぱいになってしまうと、こうした定跡が崩壊しつつあることに気づけないこともあります。そんな時に、拠り所になる場所があるだけで随分と違うものです。PDCAといったチーム運営の話について、ある程度わかりやすく整理することには価値があるだろう」という思いがまずはありました。ここまでであれば通常の「プロジェクトマネジメント」の教科書のカバー範囲です。書きたいと思ったことにはもう一つの理由があります。定跡の奥には常に「人」がいるこうした定跡は、確かに形を真似するだけでも一定の効果はある(というより表面的にでもなぞっておかないとひどい目にあう)のですが、本来的には、チームとして納得感を持って進めなければ、真価は発揮できません。チームで定跡を適用しようとした場合に、そうした定跡の奥で「人」と向き合うことが結局欠かせないのです。そのために学ばなければいけないことは少なくありません。セルフコントロールなど、少し考えただけで多岐にわたります。一つ一つを取り上げれば名著は少なくありません*2。その一方で、チーム運営に必要なこれらの知識について、「チーム」あるいは「リーダー」という観点から、プロジェクトマネジメント自体の知識と合わせて包括的に説明してくれている本は存在しないように思いました*3。結局自分としては、これまでの経験に加え、新しい環境での日々の体験と様々な本を読むことで得られた学びを実践に取り込み、試行錯誤しながらリーダーとしての仕事を進めることになりました。本書はこうして得た学びを気づきをまとめたものとなります。本書の内容について、私自身がすべてを100点満点で実践できているとも思いませんが、少なくとも心がけていることであり、また自分にとって一定の基準となっていることでもあります。ある以上は、「リーダー」という役職で私と同じように悩み、手探りで進んでいる人にとって、手がかりになれるはずだと考えています。自画自賛ですが、仕事を抱え込んでメンバーを振り回していた5年ほど前の自分がこの本を読んでいたら、随分と仕事のやり方を変えられたのではないかと思っています。チームがうまく機能していれば、リーダーの仕事はむしろそうしたチームの機能を促進し、周りの横槍から守ることになります。チームがうまく回っていない時には、成果だけでなく、チームとして向かう方向について指針を示さなければいけません。端的にいえば、「チームの仕事についてどう考えるか」という価値観を共有しなければいけないのです。「どう仕事をするか」「それについてどう考えるべきか」といった価値観について、なるべく地に足をつけながら記述したつもりです。出版後のあれこれ本書は予約時点から、Amazonのカテゴリ「経営理論」部門で第1位を獲得(9/2時点)、また、東洋経済の「売れているビジネス・経済書200冊ランキング」(9/12)で36位を獲得と望外のご好評をいただきました。予約してくださった方々のお手元には届いているかと思いますが、ご満足いただけていることを願ってやみません。9/8のデブサミ関西では、「チームで議論すること」をテーマに読書会ワークショップを開催いたしましたが、こちらも参加者の方々の間で熱い議論が展開されました。積極的に参加してくださったことに感謝するばかりですが、書籍の内容が、多くの方々の抱える悩みに何かしら刺さる部分があったのであれば幸いです。おまけ今回本を書くうえで、いくつか軸となった価値観があります。裏話的ではありますが、この機会にそれらをご紹介したいと思います。ポップであることすごく当たり前のことなのですが、文章としてのタッチが柔らかいことは、内容のレベルが低いことを意味しません。重要なのは、根本にあるメッセージとそれを伝えるための論理構成であって、文体ではないのです。すれば耳慣れない概念を引っ張り出して、難しく説明したがる私の拙い文章を、適切に噛み砕いて平易な表現に直しつつ、全体の論理構成に目を配ってくださった編集の秦さんには何とお礼を言っていいのかわかりません*4。秦さんとの会話を通じて、文章を書くときの「間合い」が少しずつわかっていったことを覚えています。最初にドヤ顔で提出した草稿の出来は凄まじく、今となっては自分でも正視に耐えないところもあるのですが、そんな草稿からスマートな目次案を示してくださった時には、匠の業を見た思いでした*5。そんなこともあって、草稿まで含めると、実際に書籍になった分量の1.5倍強は文字を書いたような気がしています。学びを書くこと前述した通り、「学ぶこと」と「実践すること」と「書くこと」がほぼ同時に起きている本ではありました*6。その時に勇気を与えてくれたのが、結城浩さんのこちらのツイートです。「自分が今回の執筆中に発見した喜びと驚きと感動を書く。そこにこそ本物の道がある」と(ぜひ全文を呼んでください)。原稿の段階では受け売りっぽい内容が混入していたケースもありましたが、そういったものは推敲の時に細心の注意を払って排除し、自分が自分の言葉で語れることだけを書くように心がけました。これは、自分の言葉を刻む作業であると同時に、自分に言葉を刻みこむ作業でもあったように思います。「斬新なこと」が書いてある本ではありませんが、地に足をつけることについては成功していると自分では思っています。全体を貫く信念を持つこともう一つ大切にしていたのが、これもやはり結城さんのこちらの言葉。「本を書くときには全体を綴じる「糸」が必要で、それは著者の「意図」である」と。性質上、ノウハウ集的に散らかりそうになっていたところを、この言葉を見て軸を取り戻すことができました*7。本書で一貫して大切にしているのは「言葉」です。「言葉にする」ということは自分なりのものごとのとらえ方を宣言する、ということでもあります。リーダーとして自分の思想を言葉にすること、そしてメンバーの言葉を引き出すことは何よりも大切なのです。いった信念を「糸」として全体の記述を見直して初めて、本としてのまとまりが得られたように思っています。本書が読者の方とチームにとって、価値ある一冊となれば幸いです。見る*1:この「ホワイトボード」の発想はAmazonの予約特典でひっそりと復活しました。*2:特に、交渉術の『話す技術・聞く技術―交渉で最高の成果を引き出す「3つの会話」』、セルフコントロールの『サーチ・インサイド・ユアセルフ――仕事と人生を飛躍させるグーグルのマインドフルネス実践法』は読んで損のない2冊です。*3:もちろん、これは私の狭い観測範囲に限ったことですので、私の知らない名著はあるのかもしれません。あればぜひ教えていただきたいと思います。*4:もちろん、今の書籍の内容や構成に何か問題があれば、それは著者である私の責任です。*5:岩切さんからも、「あなた、とりあえず本をたくさん読みなさい」と何冊もお借りしたことを覚えています。*6:その意味で会社で一緒に仕事をしてくださっている方々全員に深く感謝しています。*7:連ツイの日付を見ると5/24とありますが、期日的にはギリギリまで手を入れていました。恐ろしい量の赤に対応してくださった組版のBUCH+さんと何度も絵を描き直してくださったデザイナーの荒川さん(ことのはデザイン)には深く感謝いたします。~『スモール・リーダーシップ』出版のお知らせ~Tweet広告を非表示にするもっと読むコメントを書く2016-12-30今年読んだ本と仕事に役立つおすすめ5冊(2016年版)Books意識的に行っている多読の結果報告と、その中でのおすすめを5冊紹介。(紹介している本は今年出版されたものに限っていません。)ふりかえり今年の1月末から、意識的に多読をするように心がけています。目標は年間50冊としていて、概ね一週間に一冊です。一応、「エンタテインメントやコミックは除く」という制約を課していますが、哲学系、社会系は含めていて、必ずしもビジネス書だけというわけではありません。結果、今年は55冊ということで、月によって凸凹はありますが、目標としては達成できたことになります。9月以降は失速しているので、来年は、あらためて計画的に進めないといけなさそうですね。結果的に読んだ本の一覧はこちらです。読書の管理にはブクログを使っています。web本棚サービスを使って読みたい本を管理するのは初めてでしたが、数値目標を立てたときには、結果を記録するのは必須ですね。非公開の読書メモも書けるので、「あの本にこんなことが書いてあったな」と後から見直すにも便利です。一覧をざっと見返すと、私自身がSIerから「エンタティンメント系総合商社」という位置づけのユーザー企業に転職したこともあり、分野としてはドメイン知識や組織論が中心で、IT関連も上流寄りになっています。分野の選択をある程度戦略的に行うことで、自分の頭の中にある「目次」が広げられたような気がしています。一方で、ドラッカーの『マネジメント』や、コッターの『リーダーシップ論』、グリーンリーフの『サーバントリーダーシップ』など、「その道の古典」と言える本は積んでるだけでまだ手が出ておらず、来年はこの辺りもきっちりと仕留めたいと思います。古典は一通り読んだうえで、新しく出版された本を読み重ねるような形を早く作りたいものです。これらの中から、「仕事」という観点で読んで頂きたいおすすめを5冊ピックアップしました。見るこの本をきちんと読みたくて読書記録をはじめたと言っても過言ではないくらい昔から気になっていた一冊です。太平洋戦争について、敗戦の原因を日本軍の組織論に求めたうえで緻密に分析しているのですが、本書を貫く感情は「怒り」であり、それが本書をいわゆる組織論や軍事評論とはまったく別のものにしています。失敗から学び、それを繰り返さないことこそが祖先に対する敬意であるという強い意志が根底にあり、正直、仕事に「役立つ」と表現することがはばかられます。読める本ではありませんが、組織運営にすこしでも関わる人ならば読んでほしい一冊です。私も定期的に読み返したいと思います。見る2016年5月出版。アンガーコントロールの本を探していて出会いました。瞑想術の本と言えなくはないのですが、「瞑想」という言葉から通常想起されるような脱現世的な価値観ではなく、ビジネスパーソンあるいは人と関わりながら生きる一人の人間として、心を平静に保ちながら人間関係を構築していくためのプラクティスです。大好きな一文を引用するなら、「相手の気持ちに同意することなく、それを理解し受け入れられるのは、発達した心のあかしだ」(p.243)です。それをできるようにするためのマインドフルネスなんですね。見る全体としては、小説仕立ての前半と、フレームワークを説明している後半の二部仕立てです。ポップなタイトルと表紙とは裏腹に、「なぜ組織がうまくいかなくなるのか」が実にロジカルにわかりやすく構造化されています。組織を立て直そう、と思う人にとって、「何を前提としてまずどこに取りかかるのか」は重要課題であり、そういう悩みに対して間違いなく一定の答えを与えてくれる本です。見る"知的生産の「シンプルな本質」"という副題がまさに本書の内容を的確に表現しています。適切に「課題」を設定し、それに「解」を与えていくという活動をどのように行うべきかが緻密に書かれています。あるイシュー(課題)に対して、一心不乱に解の質を上げようとするのは労が多くして益の少ない活動であり、まずはイシューの質を高めるべきである、という考え方が基本になります。一般化すれば、いわゆる「仮説」思考であり、とにかく目の前の作業に没頭するのではなく、まずは適切な仮説を持って物事に当たるべき、ということを前提とし、それを発展した形であるとも言えるでしょう。いずれにしても、筆者の結果へのコミットメントの強さが、本書を単なるハウツー本ではないものに押し上げています。見る「27歳からのMBA」というタイトルが果たして的確だったのかと疑いたくなるほど、ビジネスパーソンであれば絶対に抑えておかなければいけない内容です。「論理的思考力とコミュニケーション力」という基礎力をベースに、企画提案力と実行力という二本柱について語られています。単なるノウハウに留まらず、マインドセットにまで言及しているのが素晴らしいですね。幅広い内容をコンパクトにまとめているため、一つ一つに関する記述は少なめですが、重要事項の網羅性は高く、その後勉強をするうえでの有益なインデックスとなってくれます。終わりに他にもご紹介したい本はあるのですが、「50冊読んで5冊拾い上げる」ということに価値があるように思いますので、これに留めます。上記の中にまだお読みでない本があれば、ぜひ一度お手にとってください。今年読んで強く印象に残った本を最後にもう二冊挙げておきます。こちらは「仕事」とはまったく別の軸で読んで頂きたい本となります。見る小説ではありません。記憶に新しい「足利事件」の背後で、執念を持って犯人に迫るジャーナリストの方の記録です。見る2016年6月出版。出版当時は話題になりましたね。タイトルで敬遠されている方もいるかもしれませんが、人と接することにある種の難しさを感じているひとであれば、誰でも心に刺さる内容だと思います(上記、55冊のカウントからは外れています)。21:14今年読んだ本と仕事に役立つおすすめ5冊(2016年版)Tweet広告を非表示にするもっと読むコメントを書く2015-11-16GxPで学んだ、ただ一つのことEssayパラダイムを学ぶことと、実際にデリバリーすることとのバランスについて。導入9月末を以て、グロースエクスパートナーズ株式会社を退職しました。4年と2ヶ月の間この会社にお世話になっていたことになりますが、その中できわめて多くの貴重な経験をさせていただいたと思っています。退職を決めてから、4年前に自分が書いたエントリ(SIを仕事にするということ)は何度か読み返しました。その中でGxPを表現した次の言葉は、今読んでも正しかったと思います。ソフトウェアをデリバリーすることには、多くの「泥臭い作業」が伴います。その「泥臭い作業」は本に書かれたり、語られたりすることがあまりない。それはたぶん、語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったりするせいでしょう。いって、「そういうこと」をしなくていいわけではない。このあたり、パラダイムと泥臭い作業をひっくるめた「デリバリー」の全体像が見えずに苦しんでいたわけですが、他にもそういう方はいるのではないかと思います。「バリューストリームの中で自分の手を動かしつつ」「企業をお客様として業務に使うアプリケーションを作る」ことができる場所があるんだということは、多くの方に伝えたいメッセージです。この4年間のふりかえりとして、この文章にある「泥臭い作業」を言葉にしてみようとしてみたのですが、相変わらず「語るまでもなく当たり前のことであったり、語れるほどには言語化されていなかったり、語るほど面白くなかったり」したので、そのかわり、GxPで学んだマインドセットのようなものについて言葉にしていくことにします。それは、自分が求めていた「パラダイムを学ぶことと実際にデリバリーすることとのバランス」にとって、欠かせない要素だったのだと思います。納得して向き合うその要素とは何か...と溜めるまでもなく見出しに書いてしまいましたが、「納得感」の一言に尽きます。「そうすることになっているから」「誰がそう言ったから」そういう理由で仕事を進めることは許されませんでしたし、納得できなければ誰に対してでも何かを言える文化だったと思います。分解するなら、一つは「理解」もう一つは「説明」でしょう。どちらも同じコインの表と裏です。プロジェクトに対してなんらかコミットしようと思えば、この納得感を一定のレベルで確保しなければなりませんし、ましてや、プロジェクトのハンドルを握ろうと思えば、それを隅々にまで行き渡らせる必要があります。具体的に書いてみます。「何を」「どのように」「いつまでに」「いくらで」「誰が」作るのか、それら複合した要素をプロジェクトとして組み立てるときにはツールが必要なのですが、この点に関する「これさえやれば大丈夫」という包括的なツールは、僕が知る限りありません。いうより、「これさえやれば大丈夫」という感覚がそれ自体すでに危険です。....「何を」に関して言うならば、ユースケースなりシナリオなりで対象システムが備えるべき「機能」を何らかのかたちで表現することは誰でもやっていることでしょう。作るものの性質に応じて、適した記述方法は変わります。画面とER図があればおおよそ大丈夫なこともあれば、なんらかのルールを表形式にまとめなければいけないこともあるでしょう。「設計書とは、あるいは要件定義書とはこのフォーマットで記載するものである」という固定化した発想からは確かに安心感は得られますが、確実に何かを取りこぼします。その「何か」を具体的に「どのように」実現すべきかは、ハードウェア構成/ソフトウェアのモジュール構成等いくつかのビュー、いわゆるアーキテクチャで表現されることになりますが、分解された構成要素は「いつまでに」「いくらで」「誰が」というスケジュール/コスト/チームの根拠になります。アーキテクチャの方針によって複雑さは凝集することも点在することもあり、そういった実態を無視して引かれたスケジュールには現実性がありません。他にもどういうドキュメントを書くのか、そのドキュメント同士はどうつながっているのか、テストとはどう関連するのか、テストの考え方は十分か、など考えなければいけないことを挙げていけばキリがありません。大切なのは、そういった個別の構成要素およびその関連性について、まずは自分が理解する必要がある、ということです。その理解は、計画時であればプロジェクト計画という作業結果ではなく、その作業を通じて、自分あるいはチームの中で醸成されるものです。いった「理解」があって初めて、顧客に会社にあるいはチームに「説明」できるようになります。一会社員がプロジェクトに対して果たせる責任といえば、せいぜいがそういった説明責任だけなのです。逆に言えば、誰かのせいにせずに「こういった理由により自分はこれが正しいと考えている」と説明できる立場に立つことこそが、プロジェクトのハンドルを握るということなのだと思います。余談ですが「自分がこう考えた」ということを基点に置くことは、プロジェクトに限らず、様々な面において後悔しないための一つの方法であるように思います。ある種の後悔はするのですが、少なくとも自分のこととして引き受けて、誰かを恨まずに先に進むことはできますからね。いうことをひっくるめての「納得感」ですね。***社員がそういう姿勢で仕事に臨むことについては、どんな企業であっても少なくとも経営陣は望んでいるような気がします。それが様々な事情や経緯で現場レベルで実践できなくなっているケースも多々あるのだと思います。いうことを求めつつ大きな裁量と共に仕事を任せていただいたこと、また、チームのメンバーが皆、主体的に考え動いてくれたこと、そして、色々なものを放りだして去って行く僕を温かく送り出してくださったこと、そういったことすべてについて、深く感謝します。ありがとうございました。その後10月からは、中間流通を軸としたエンタテイメント系総合商社の情報システム本部に勤務しています。立場が変わり、見えるものもだいぶ変わってきました。ユーザー側に移ったことにより、これまでできなかったことでできるようになったこともあると思います。根底にある「ものづくり」という本質はそう変わるものでもなく、これまでの経験を活かして引き続きがんばります。言葉を紡ぐ作業はこれからも続けていきたいと思いますので、どうかよろしくお願い致します。ソフトウェアアーキテクチャの先に最後に、少し宣伝めいたことを。10/1付で新しい翻訳書が出版されました。転職のタイミングとなってしまいましたが、僕がGxP名義で出版する最後の翻訳書ということになります。編集の上野様、パートナーの岡澤さんにはいつものように多大なるご迷惑をおかけしました。10年前に書かれた本を訳させてほしいという私の勝手なお願いを引き受けてくださった翔泳社様に深くお礼申し上げます。内容については、ゆうすけさん、今野さんのインタビューがこちらに掲載されていますので、興味のある方はどうかご覧ください。「結局のところ、アーキテクトは考えるという行為から逃れられない」という、ある種このエントリで書いてきた内容とつながるところがあるのですが、そういう、考えながら前に進もうとする人に対して、多くの気づきを与えてくれる名著だと思います。Essay本に書かれた内容を実際に使うことの難しさについて導入ここ一年ぐらい将棋にハマっているのですが、最近は棋力が上がらなくて悩んでいます。序盤で失敗して一方的に敗けるのが嫌なので、序盤から中盤の入り口について解説してある戦型の本をよく読んでいるのですが、いまいち「強くなった」という気がしません。原因は明らかで、「知らない形に出会った時に安定して力が発揮できない」のです。見る局面でも自信を持って指せるようになりたい。私が触れたいのは、定跡とか手筋を超えたところにある「棋理」みたいなものなんでしょう。そんな話をあるプロ棋士の先生にしたときに言われたのが「お勉強しても強くなれませんよ」という言葉で、それが妙に耳に残っています。似たようなことはシステム開発にも言えるのではないか、ということを最近よく思います。そのことについて、「ドメイン駆動設計(DDD)」や「スクラム」を例に言葉にしていきます。DDDにせよ、スクラムにせよ、パラダイムとして優秀であることに疑う余地はありません。一方で、「DDD/スクラムで開発をしようとしているが、いまいちうまく行っていない」という話も時折耳にします。いう「うまく行かなさ」は何に起因するのでしょうか。書き留められたパラダイムと現実のコンテキスト特定のパラダイムを教える立場にある人なら、そのパラダイムを正確に理解することは欠かせません。プロジェクトやビジネスを推進している側からすれば、「優れた手法を取り入れることがプロジェクト(ひいてはビジネス)の成功につながるとは限らない」といえます。理由の一つとして、プロジェクトやビジネスが、置かれている環境や構成要因、対象とするドメインの性質、文化といったさまざまなコンテキストに束縛されていることを挙げられます。あるパラダイムが一つの体系として書き留められる場合、そうしたコンテキストは語られないため、そもそも適用段階で具体的にどのようにしたらよいかわからないことになります。適用の方法についての議論は、こうした「どのように」が多いような印象を受けています。したことについてはそれほど深刻とは思えません。適用事例が増え、ノウハウが蓄積されるにしたがって自然と解消していくものでしょう。深刻なのが、「何をするべきか」という問題です。「DDD/スクラムを実践する」と、パラダイムが目的化してしまった場合、「何をすればDDD/スクラムをしていることになるのか」というメタな議論が生じます。した関心の横滑りはきわめて危険で、DDD/スクラムを正しく実践することに意識が向くと、プロジェクトの本来の目的から逸れてしまいます。DDDで言えば、モデルの正しさを追求するあまり、複雑化しすぎて誰にも理解できなくなったとしたらどうでしょう。スクラムの実践に取り組み、「タイムボックスによる定期リリース」ができていたとして、バックログに積んであるものがバグフィックスだけだったとしたら、それはうれしいことなのでしょうか。それがうれしいとしたら、誰にとってなのでしょうか。実践から得られるものわかりやすくするために極端な例を挙げましたが、現実に特定のパラダイムを理解し、そのパラダイムの価値を自分なりに解釈し、実際の文脈の中で必要なことを行って成果に結びつけるのは、決して簡単なことではありません。私自身は大筋、DDDであれば、適切なドメインの分析とドメインの特性に応じたモデリング/アーキテクチャ設計が、スクラムであれば、ゲームのルールに従うよりも組織全体のバリューストリーム/フィードバックループの構築が骨子だと考えていますが、具体的なコンテキストに置かれれば、また違った解釈が必要になることもあるでしょう。後から振り返れば教科書通りで最適だと言える判断も、その場に置かれたときに行えるというのは、まさに「お勉強」ではたどり着けない場所で、実際どうすればそういうことができるようになるのか、正直私もよくわかっていません。視野を広げ、「全体」という言葉で自分に見えるものを広げつつ、一歩ずつ考えながら進んで、「何かがおかしい」という違和感や、あるべき姿に対する感覚を磨いていくしかないのではないかと思っています。GxPでは人材を募集しています今の会社に入って一番よかったと思うのは、会社の規模的に正しく手を伸ばせばどこまでも届く反面、プライムという立場でお客様と直接やりとりができることです。すべてがうまくいくわけではなく、苦労がないわけではありませんが、「全体」を見渡しつつシステムを通じて世の中と関わるという実感は、間違いなく得られる場所だと思っています。入社してからの取り組みについては、以前ご報告させていただきましたので、よろしければ、こちらもご覧ください(動画はこちらで公開されています)。弊社はいつでも人材を募集しています。弊社に興味を持ってくださった方で、いきなりサイト登録するのがためらわれるという場合には、お気軽にお問い合わせください。gmail.com)やfacebookなどでのご連絡もお待ちしております。導入もうだいぶ前の話になってしまいましたが、アジャイルに関するブログエントリ「アジャイルがダメだと思う7つの理由」は予想以上に波紋を呼び、それに呼応していくつものエントリが公開されました。発端となったエントリに関していうと、通常であれば必要となる数々の留保事項や前提事項を書かずに切り込んでいるという点において、間違いなく「煽り」であると言えます。「アジャイル」という言葉をとりまく数々の事象をかなり的確に指摘することによって、「アジャイル」という言葉をパブリックな場所で語っている少なからぬ人たちに対して、(意識的か無意識的かは問わず)ある種のポジショニングを強いたという意味で、実にいい釣り針なのではないでしょうか。個別の論点に関する「アジャイルでは全体スケジュールにコミットできない」「いや、アジャイルだって全体スケジュールにコミットできる」という議論は一通り終わった感がありますので、だいぶ出遅れた立場としては、少し違う視点から整理したいと思います。ところで、「アジャイル」と「ウォーターフォール」は何が違うんでしょうね反射的に出されるであろう主張とそれに対する反論をいくつか挙げてみます。「ウォーターフォールは出来上がるまでの時間が長い」―本当ですか?ウォーターフォールは一年かけなければならないなどという定義はどこにもありません。「ウォーターフォールではフィードバックを受けられない」―どうでしょう?重要な機能なら必要に応じてプロトタイピングをするなどということは常識です。「ウォーターフォールでは変化に適応できない」―そうでしょうか?顧客がソフトウェアを触るようになって上がってきた諸々の仕様変更を、テストの進捗を考慮しつつ、別の線を引きながら取り込んでリリースに間に合わせる、みたいなことは普通だと思います。アーキテクチャ策定段階で、比較的安定している機能と後々変化が予想される機能とで設計/実装方針を区別し、変化に対応しやすい(その代償としてコストのかかる)設計にしておくといったことも当然やるべきことです。テスト」という工程は、フィードバックサイクルの長短に関わらず必要なことであり、これを以てアジャイルとウォーターフォールの違いを語ることは難しいでしょう。「基本設計書がすべて出そろってレビューが完了するまでは実装に着手してはならない」といった教条も時折は耳にしますが、それがウォーターフォールのあるべき姿かどうかという疑問と共に、現実としてそこまで厳格な運用が行われているケースはごく稀ではないかと思います。実際には、サブシステム(あるいは大機能など、呼び方は色々あると思いますが)といった、一定の粒度でシステムを分割し、各工程を並行させると共に、実装も着手できるところから着手しているでしょう(そのリスクを発注側と受注側のどちらが持つかは別として)。現実の開発においては、「変化の方向性を先読みしつつ、フィードバックを適切に受け取ること」が重要なのは間違いなく、そのための施策は色々とあるわけです。いった諸々の施策を「アジャイル」と呼び、そうではないものを「ウォーターフォール」と呼んで思考停止するのは、色々と不幸なことを引き起こすと思うのです。一方で、アジャイルの主張する「変化への適応」に気を取られすぎて、「事前に考えること」を否定することも逆方向の思考停止です。「それは後で考えれば良い」という台詞は、後で発生するであろう揺らぎを吸収できるスケジュールとアーキテクチャに支えられてはじめて説得力を持ちます。事前に計画を立てること、全体像を描くこと、全体の中で個別に戦略を考えること...総じて先のことを予め考え、読んでおくことは常に必要です。いった「考えること」の放棄に「アジャイル」という名前を冠することに対しては、同様に強い危機感を覚えます。結局のところ、「考えてわかることは、考える。考えてもわからないことは、どうすればわかるかを考えたうえで、そこまで手を進めてみる」という基本がすべてで、それ以上でもそれ以下でもないということです。いうものの、世の中に目を向けてみると、ここまで「アジャイル」という言葉が盛り上がる背景には、"これまでの"開発がうまくいっていないという感覚あるいはある種の閉塞感が存在するのだろうとは思います。批判されるべき「何か」は現実に存在し、それへの批判として別の「何か」が存在するのは事実で、それぞれがウォーターフォールとアジャイルという名前をまとっているだけではないか、と感じるのです。それが一体何であるのか、普段受託開発を行っている自分の経験をふりかえりながら言葉にしていきたいと思います。批判されるべき「何か」は、プロセスや成果物ではなかろう、ということが出発点です。プロセスにしても成果物にしても、コンテキストに応じて適切なものを選んでいけばよいものだからです。「コンテキストに応じて適切なものを選ぶ」ことができない環境にこそ問題視すべきだと考えます。単能工とコマンドコントロール基本設計書を書くだけの"SE"。設計書の内容を実装するだけの"PG"。「それではダメだ」という批判と、「実際にそういう人たちが集まってシステム開発をしているんだ」という現実路線の両方が存在すると思います。僕自身の経験に照らせば、一定以上の規模であれば、実装がある程度わかる人が設計書を書き、設計の矛盾に気づける人が実装し、双方のコミュニケーションが円滑に進んでいる状態が現実的で健全な開発であるという気がします。それでも工程ごとに担当者が分かれれば、そのコミュニケーションを繋ぐための中間成果物が必要になるのであり、そういう中間成果物が「お客さんと要件を詰め、過不足のないドキュメントを描き、柔軟かつ統一のとれたアーキテクチャでそれを実装して、鉄壁のテストをやってくれるエンジニア」から見て無駄なオーバーヘッドに見えてしまうのは仕方が無いことだと思います。いうエンジニア2,3人で開発できる規模なら、また違ったやり方もできるでしょう。工程ごとに担当者が分かれていても、工程間がスキル的にもコミュニケーションパス的にもゆるやかにつながってフィードバックが回っていれば、それほど問題にはならないと僕は考えています。問題なのは「あらゆる指示が上から降ってきて、ただ決められた期日までにその指示をこなす」ことが求められる環境です。これを生み出すのは、同一工程内の階層化、具体的に言えば、少数の「タスクを分解し指示する人」と多数の「指示に従ってタスクを遂行する人」との分断です。工程ごとに作業者が分かれていて、かつその作業が上から降ってくるという構造であれば、メンタリティとして成果物の提出先が「仕事を割り当てる人」になってしまい、それを受け取る次工程の人が忘れ去られてしまうのもわからなくはないですが、当然いい結果は生まないでしょう。個人的には、この「分解されたタスクの指示書」がWBSの姿をしていることこそが、この構造が「ウォーターフォール」と呼ばれてしまう原因ではないかと思っています。開発モデルとしてのウォーターフォールは関係ないですよね。ここにあるのは、「多重階層によるコマンドコントロール」と「成果物を壁の向こうに投げつけるサイロ構造」です。フィードバックが届かない多重階層構造によって人が病み、サイロ構造によって成果物の品質も下がるのはよくわかります。「お客さんと要件を詰め、過不足のないドキュメントを描き、柔軟かつ統一のとれたアーキテクチャでそれを実装して、鉄壁のテストをやってくれるエンジニア」に話を戻します。アーキテクチャ策定、実装、テストといった各工程を個別に経験する中で知識と技術を蓄積した結果にすぎません。多能工になるためには、工程を横断して様々な経験をする必要があるわけですが、前述の文化ではその経験を積むことができません。「多重階層によるコマンドコントロール」では多能工が育たず、多能工が育たないから「多重階層によるコマンドコントロール」が必要になるのです。この負の連鎖を断ち切るために、単能工とコマンドコントロール、多重階層の関係をもう少し整理しておきます。作業をする人が見ることのできる範囲が狭い場合、その狭い範囲に応じたチャンクにまで仕事を細分する必要があります。その負荷は、指示をする人に集中することになります。一人で見ることのできるノードの数には限りがありますので、作業者が食べられるサイズになるまでに階層ができあがるのはよくわかります。「指示を出す人/従う人」という構造に無理があるのです。違う道はどこにあるのでしょうか。「正解」ということではないのですが、受託開発のリーダーという立場で自分のやっていることは、「指示出し」ではありませんので、少しふりかえってみたいと思います。...さて、僕は何をやってるんでしょうね。感覚を言葉にすると、対チームとしては「大きな方向づけと情報の流れのコントロール」、対顧客としては「窓口」ですかね。考えてみると、作業の細分化はほとんどメンバーに任せてます。得意分野を中心に緩やかに周辺をカバーできるメンバーに囲まれているので、渡せる仕事のチャンクが大きく、作業分割と統合にコストがかからないんですね。コストがかからない、というよりそこに自分が入ると、自分がボトルネックになって効率が落ちてしまう、という表現が正しいです。大きな方向づけと書きましたが、進め方も自分だけで決めているわけではなく、あまり時間を気にせずに、よく議論している気がします。いえ、和智「どうしたらいいと思います?」○○「こうですかね?」和智「じゃあそれで」○○「」というパターンが頻出している気もして、エントリを書いていて、改めてメンバーに恵まれていると思いました。要は自分がボトルネックにならなければ順調に開発が進むわけで、ボトルネックにならないコツは、情報の流れをプッシュ型からプル型に変換することだと思っています。「大きく渡して、必要に応じて聞いてもらう」というやり方ですね。終わりにソフトウェア開発を生業としていれば、さまざまな業務に関わることになります。やることが大きく、作るべきものが最初から分かっている業務であれば、コストを抑える代償に変化を想定しないアーキテクチャで進めることができるでしょうし、そもそも何をするかもわからないうちから実験的にモノづくりを始める状況であれば、変化に柔軟に対応できるアーキテクチャをインクリメンタルに膨らませていくべきでしょう。重要なのは常に、「何のために何を作るのか」という目的であって「どう作るか」は手段でしかあり得ません。それに対してエンジニアとしてできるのは、専門性を高めることと守備範囲を広げることを通じて、どういう要求にも対応できるようになっていくことかありません。顧客が満足するものを提供しつつ、プロジェクトを通じてメンバーが成長できるのであれば、開発手法は別に何でもいいと思うのです。TDDデブサミ関西2012での講演内容まとめはじめに今月、GOOS日本語版が発売されました。見る継続的デリバリーに続き、高木さんと一緒にお仕事をするのはこれで二冊目です。今回も多くの人に助けられて、目標としていたデブサミ関西での出版にこぎつけることができました。関係者の皆さま、どうもありがとうございました。講演では触れませんでしたが、ここで「実践テスト駆動開発」というタイトルの由来について少し書いておきます。Tests"で、前半の頭文字をとってGOOSと呼ばれています。"grow"も"guide"も本書にとって外すことのできないキーワードでしたので*1、タイトルから外すことは考えられませんでした。これをうまく収めるタイトルがどうしても浮かばなかったため、直訳を副題としました。(Beck)))以来、TDDにとっては二冊目のバイブルという位置づけを大切にしようと考えたのです。講演のタイトルを「テスト駆動開発の進化」としたのは、2002年のケント・ベックの著作と比べてGOOS本はどういう所が変わっているのか、という点にフォーカスしているためです。今回の講演のアジェンダです。テスト駆動開発の進化とは?ケント・ベックの著作と比べて何が変わったのかということを整理します。GOOSのポイント進化という観点だけではとらえきれないGOOSのポイントについてご紹介します。開発の現場で活かすには?GOOSで紹介されるテスト駆動開発を実際のソフトウェア開発のライフサイクルに組み込むにはどうすればいいかを考えます。それでは内容に入っていきましょう*2。当日使ったスライドはこちらです。テスト駆動開発の進化そもそもテスト駆動開発とは、プロダクションコードに先立ってテストコードを書く(テストファースト)ことで、コードを動かしながら完成に近づけていくという手法です。失敗するテストを書き(レッド)、そのテストを通るようにし(グリーン)、先に進む前にリファクタリングする、というリズムは、黄金の回転と呼ばれたりもします(詳しくは(こちら)。具体的にFizzBuzz*3を使って例を示します。TDDでは、プロダクションコードを書く前に、まずはテストコードを書きます*4。}シンプルなテストですが、これだけでも多くの判断をしています。クラス名はFizzBuzzにしようメソッド名はresultにしよう(これでいいの?)戻り値は文字列にしよう("fizz"と"buzz"があるので)この状態では実コードがありませんのでコンパイルも通りません。コンパイルを通しながら、最もシンプルな仮実装をするとこうなります。Integer.toString(i);でも構いません。どこまで先に進んでいいかということについてTDDでは特に何も定めていないのです。重要なのは、「何をテストすべきか」という自分の理解を深めながら先に進むことです。個人的には、まずはできる限りシンプルなテストと実装(この場合であれば「1を渡したら"1"が戻る」)でインターフェイスを定め、その後で仕様に関するテストを計画的に書いていくのが良いのではないかと思っています。テストがグリーンになったところでリファクタリングです。resultというメソッド名がなんとなく気になりますが、今は先に進みましょうか。テストを書いてレッドにします。インターフェイスが定まったので、次は仕様のテストですね。今回は、数字のテストを置いておいて先に"fizz"をやりました。}これを通すためにコードはこうなります。}これでふたつめもグリーンです。中身もとりあえず良さそうですね。して、5の倍数だったら、公倍数だったら、数字だったら、とテストを書いていくと、動かしながら完成品が出来上がります。テストがあるのでリファクタリングを安心してできるところも、TDDのいいところですね。ここまで読んで頂いておわかりの通り、TDDは何かひとつのクラスを実装するには非常に優れた手法です。普段我々が携わっているようなアプリケーション(私の場合はWebアプリケーションになります)では、どこから手を付けて良いのかわからなくなってしまいます。した疑問に対して、スティーブとナットはやはりテスト駆動開発の黄金律を使って立ち向かいます。その黄金律とはすなわち、まずは失敗するテストを書くというものです。そこで彼らが最初に書くテストは、「受け入れテスト」です。受け入れテストでテストするのは、システムが実装すべきフィーチャ、顧客に対して提供すべき価値ということになります。この受け入れテストはエンドツーエンドに実施しなければいけません。エンドツーエンドとは、システムの「端から端まで」、たとえば、ユーザーインターフェイスからデータベースまでということです。この受け入れテストから書き始めるTDDは次に示すような二重のループを描くことになります。外側のテストは実装すべき機能がどこまでできているかを示す進捗の指標となり、内側のテストによってコードの質が高く保たれます。この外側のループと内側のループを繰り返し辿ることで、ソフトウェアが作られていきます。本講演のタイトルにしたテスト駆動開発の進化とはすなわち、コードを書くことから、ソフトウェアを作ることへということなのです。GOOSのポイントさて、前述した二重のループに加え、GOOSにはいくつか特筆すべきポイントがあります。ここではそれを二つとりあげます。それが、モックとウォーキングスケルトンです。モックについてケント・ベックがJUnitの作者であるように、スティーブとナットはjMockの作者です。jMockは二人のオブジェクト指向観をベースに作られています。彼らはオブジェクト指向システムを、「協力しあうオブジェクトの網の目」ととらえます。クラスの継承関係よりも、オブジェクトがどのようにコミュニケーションし合うかが大切だと考える彼らにとっては、クラスよりもインターフェイスが重要です。そのような発想に従い、網の目としてオブジェクトが構成されていると、テストをするのが難しくなってしまいます。あるオブジェクトをテストしようと思うと、隣り合う他のオブジェクトも動いてしまうことになるからです。そこで登場するのがモックです。モックを使うと、隣り合う他のオブジェクトをニセモノと差し替え、テストの際に思い通りの動きをさせることができます。Romanticism」をご紹介しました。興味のある方はご一読くださいませ。前のブログの方には書いていませんので、テストコードの表現がシーケンス図と同じになるという点をここで強調しておきたいと思います*5。is("VALUE"));}例に示した仕様ではオブジェクトローダーが事前に存在することが想定されていましたが、実際にテストを設計しながらインターフェイスが発見されるということも十分に起こります。受け入れテストからはじめて、外側から内側へ、インターフェイスを発見しながら開発を進めていく点がモックを使ったTDDの特徴になります。モックを使ったテストコードを書くことは設計の活動ですので、テストファーストとはいえコードを書くことにこだわりすぎず、色々な図を使いながら考えて進めていくのが良いのではないかと思います。そのようにインターフェイス(あるいはオブジェクト)を発見するためのパターンがGOOSには三つ出てきます。out)あるオブジェクトが責務を持ちすぎている場合、ふるまいの凝集した単位を分割するというものです。off)新しい概念が登場したときにプレースホルダー型をラップする(値)もしくは、サービスを定義する(オブジェクト)というものです。分解は既にあるものを分けるのに対して、発芽は新しい概念が導入される点が特徴です。up)関連するオブジェクトの集団をひとつのオブジェクトにまとめるというものです*6。上記二つは分けるパターンだったのに対して、これはまとめるパターンです。これらのうち、分解と包含は基本的な考え方だと思いますが、発芽はきれいなコードが書けるようになるためのいいテクニックだと思います。一つ重要な点として、ビジネスロジックの中核は、ビジネスドメインの言語を使うべきだ、というものがあります。これについて詳しく知りたい方は、ぜひ以下の本をご覧ください。見るウォーキングスケルトンについてGOOS流のTDDでは、フィーチャの開発とエンドツーエンドテスト基盤の開発を並行して進めなければなりません。これには、テストが失敗したときの原因がどちらにあるかわからないという点を始めとした難しさがあります。Skeleton)とは、これを解決するための方法です*7。できる限り薄いフィーチャのスライスを取り出し、それをビルド/デプロイ/テストするための基盤を作ります。した基盤が一度できれば、あとは少しずつテストを増やし、プロダクションコードを育てていくことができるようになります。詳しくは以下の本をご覧ください。見る中間のまとめこれまでの内容をいったん整理します。第一に、GOOS流TDDの核心は受け入れテストとユニットテストにより構成される二重のループにあります。それを円滑にまわすために、まずは薄いスライス(ウォーキングスケルトン)を使ってテスト基盤を作り、フィーチャを増やしていくという形をとることになります。第二に、テスト駆動開発という名前がついてはいますが、ここで言われているテストはシステムのふるまいです。テストを考えるということは、システムを外側から見たときのふるまいを考えるということに他なりません。Romanticism」をご参照ください。開発の現場に活かすためにさて、ここまでGOOSに書かれたTDDの特徴を見てきました。自社システムの開発を数人で行っているチームであれば、ここまでのノウハウで十分にうまくいくと思います(もちろん、スクラムのようなある程度の開発プロセスに関する方法論は必要でしょうが)。プログラマ30名〜40名で行う受託開発を考えると、なかなかこの形に持ち込むのが難しそうです。最後に、こういった中規模〜大規模の開発現場でGOOSを活かすにはどうすればいいかを考えていきたいと思います。二重のループをどう開始すればよいか、という問いは、二重のループの外側を見ることでしか解決できません。二重のループに入る前の段階として、GOOSには以下のステップが説明されています。問題を理解するアーキテクチャを定めるビルド/デプロイ/テストを自動化するここで重要なのは1.と2.、特に2.のアーキテクチャです。GOOSが想定しているアーキテクチャは、タイトルにある通り、「オブジェクト指向ソフトウェア」です。ここで想定しているような中規模〜大規模の開発では、すべてを「オブジェクト指向」で作ることはあまり現実的ではありません。重要なのは、業務分析を行った上でドメイン(ここでは「機能の大分類」と読み替えて頂いても構いません)を抽出し、それぞれのドメインごとに特性を分析することです。ここで分析すべき特性とはすなわち、業務の複雑さをどこで受け止めるべきか、ということです。ここでは二つ分類を出してみます。エンティティ主体のドメインロール主体のドメインエンティティ主体のドメインは、普段多くの方が目にしているものだと思います。業務の複雑さがデータモデルに吸収され、E-R図とSQLがビジネスロジックの中核になるようなドメインです。このようなドメインであれば、ムリにオブジェクト指向的に作る必要はなく、SQLを気持ちよく書くためのSQLテンプレートエンジンを準備した上で、入力チェック、DBアクセス、編集処理といった手続きをトランザクションスクリプトとして実装することが正解となります。このようなドメインに対してO-Rマッパーを当てはめた結果、コード内に大量のJPQLが埋め込まれ結果として可読性が落ちてしまうケースを見たことがある方も多いのではないでしょうか。したドメインの場合、テストとして設計するべきは、シナリオではなく、データのパターンになります。ユーザの操作だけで見ると「詳細画面を表示する」という一シナリオで済んでしまうところ、「このフラグがこうなっている場合はこの項目は表示しない」、あるいは「ここがこういう状態の場合にはリレーションのこっちから値を持ってくる」といったパターンが出てくることになります。一方で、処理が複雑で、ロール間のインタラクションとしてモデル化した方が適切だと思われるドメインも中には存在します。例としては、決済処理や権限といったよくある共通処理、あるいは外貨金利の日またぎ計算といった特殊な業務ロジックが挙げられます。このようなドメインに対してトランザクションスクリプトで立ち向かってしまうと、処理が重複したり、メソッドが長くなりすぎたり、という問題が発生します。テストの設計も、「こういう条件でこういう入力があったらこのインターフェイスを呼び出す」という形のシナリオになるでしょう。ここでは二つの分類を出しましたがこれが二つである必然性はありません。各ドメインを記述するのに適切なパラダイムは他にもあり得ると思います。重要なのは、作るものの特性を見極め、それに合わせたアーキテクチャを策定しようということです。GOOSではソースコードは「育てる」ものだとされていますが、そのソースコードが育つ方向性を事前に規定するのがアーキテクチャなのです。ご協力ありがとうございました。*5:これは行きの新幹線の中で、上司の@yusuke_arclampから指摘されて気付きました。静的な構造を表現するクラス図より、動的な動きを表現するシーケンス図の方が、モックとの相性が良いのです*6:日本語版p.64で包*括*となっていますが、ミスによる表記揺れです。*7:直訳すれば歩くスケルトンで、骨格だけで筋肉のないガイコツが動いている、というイメージです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。