こまぶろ

技術のこととか仕事のこととか。

「ちいとぽ」こと『Team Topologies』の翻訳(12月1日発売)を読んだ

邦訳が待望されていた『Team Topologies』(邦題は『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』。以下、「ちいとぽ」)ですが、発売日(12月1日)を前にして翻訳レビュワーを務められた角谷さんからご恵投いただいた(ありがとうございますありがとうございます)ので、とりあえず一気に読みました。

Kindle版も出る予定とのことです。

内容については、すでにiki-ikiTwitterで色々話を角谷さんから聞いていて、ある程度前提があったのですが、実際に読んでみて印象に残ったことや感じたことを2点ほど記します。

一読した感想を先に記しておくと、この本は、自分一人で読んで、自分の組織について「あのチームは『ちいとぽ』でいうとこういう風に再定義できて、そうなると・・・」と考えてみるのも面白いですし、同僚と一緒に読んで「現状だとうまくいっていないところがあるだろうか?」と話してみるのも有意義だろうなと思いました。フルカラーで、視覚的にも楽しいです。そして、翻訳もとても読みやすかったです!

詳しい紹介が欲しい人は原書を読んで書かれた以下の記事がおすすめです。

deeeet.com

訳者の一人である吉羽さんの記事もご覧ください。

www.ryuzee.com

翻訳書籍とは別ルートで「ちいとぽ」に興味を持った方によるよいまとめ記事も公開されていました。

zenn.dev

「内容を三行で・・・」という人は以下もご活用ください。

scrapbox.io

組織・チームの「継続的な設計」

「ちいとぽ」といえば「4つのチームタイプと3つのインタラクションモード」です。こういうのをみると、「はいはい、またSpotifyモデルみたいな話でしょ?」となってしまいがちで、実際にこの書籍の中でもSpotifyモデルの話は何度か登場するのですが、「ちいとぽ」の優れているところは、これらを動的なものとして、書籍中の表現を使えば「継続的な設計」をするものとして位置付けているところだと思います。

できる限り効果的なチームにするには、ただ偶発的もしくは行きあたりばったりでチームを編成するのではなく、継続的にチームを設計する必要がある。このように継続的な設計によるチーム構造のことをチームトポロジーと呼ぶ。これは、それぞれのチームの責任範囲を明確にしながら、組織内にチームを意図的に「配置」することを意味する。(p.72-73)

「ちいとぽ」による組織改編の結果のスナップショットは(まさにSpotifyモデルがそうであったように)常に動的な過程の中の一断面に過ぎないと考える必要があります。

書籍では、スナップショットを説明するための静的な概念の紹介は一部のみで、重点は組織構造をどのように変化に対して適応させていくか、という方面にあります。第1章のタイトルは「組織図の問題」ですし、冒頭で既に以下のようにインタラクションモードは状況に応じて変化させていくものであるという言明があります。

技術やプロダクトの探索段階では、成功のために、チームの境界がオーバーラップしたコラボレーションの多い環境が必要だ。だが、探索が終わって技術やプロダクトができあがったあとも同じ構造を維持すると、無駄な労力と誤解を生んでしまう。(p.10)

あらゆる状態に適した組織構造というものはあり得ず、状況の変化に応じて形を変えていく必要があるというのは当たり前といえば当たり前なのですが、この書籍がその適応のさせ方に明快なガイドラインを与えてくれていることの価値は大きいように感じました。

豊富な参考文献と納得度の高い経験に基づいた議論

「ちいとぽ」を一読して印象に残るのは、豊富な参考文献を用いた議論の整理や裏付けと、時折挿入される経験にもどついた議論の納得度の高さです。

巻末に参考文献表が掲載されているのですが、細かい字で丸々12ページに渡って文献が列挙されています。これらの文献が文中のいいところで引用・紹介されていて、理解の助けになったり、「そういえば積んでるなその本・・・」となったりします。書籍の本筋とは別のところでも得るものが多いというのは、個人的には読む甲斐のある書籍の1つの特徴だなと思っています。

一方で、著者のこれまでの経験に基づいた記述も納得度の高いものです。たとえば、51ページではチームに割り当てるドメインの複雑度と数についての経験則が紹介されています。ここでいう複雑度は「シンプル」「煩雑」「複雑」の3つに分類されていて、「第2の経験則」として「1つのチームに、シンプルなドメイン2~3つ」がちょうどいい、という話がされています。これ自体もなるほどと思わされる記述ですし、最後に付け加えられている「しかし、仕事がルーティン化することで、チームメンバーのモチベーションが下がるリスクもある」という但し書きも、「お、そうだな……」と思わされます。

全体を通して、理論的根拠と経験の裏付けの両方に支えられた優れたガイドラインになっていると感じました。

おわりに & おまけ

というわけで、「ちいとぽ」を読んだよ、面白かったよ!というお話でした。

「ちいとぽ」を読んで、チームをトポっていきましょう!

おまけ:関連資料

IDDDの著者のバーノンのポッドキャストに著者2人がゲストで出てました。

open.spotify.com

「DDDとTeam Topologiesでプロダクト・レッド・オーガニゼーションですよ」だそうです。


www.youtube.com

プロダクト・レッド・オーガニゼーションについては、横道さんが訳された以下の書籍をご覧ください(僕は積んでます)。

公式のGitHub Orgもあります。

github.com

国内の事例も。

engineering.mercari.com

第4章でも言及されている「DevOpsトポロジー」について。

kakakakakku.hatenablog.com

おまけ:印象に残った参考書籍

前述のように「ちいとぽ」の中では様々な文献が紹介されているのですが、印象に残ったいくつかについて少しコメントをしておきます。

『LeanとDevOpsの科学』はしばしば引用されていました。ちょうど3年前にざっと読んだままなので、改めて読み直してみようかなと思いました。

ky-yk-d.hatenablog.com

『モチベーション3.0』も引用されていました(13ページや104ページ)。「ちいとぽ」13ページで言及されている「8人の精鋭からなるチーム」の話は読んでいるだけで辛いものがありますね。こちらもだいぶ前から積んでいるのでこれを機に読んでみようかと思います。

最後に、ナオミ・スタンフォード『Guide to Organisation Design: Creating high-performing and adaptable enterprises』です。9ページなど何度か言及されているこの書籍ですが、おもしろそうでした。Amazonだと2つページがあるのですが、Kindle版のある方のページのリンクを貼っておきます。

Janet Gregory さんの Agile Testing for the Whole Team 研修 に参加した

※以下の記事は研修の内容を伝えることを意図したものではなく個人的な感想と学んだことを記載したものです。

Agile Testing for the Whole Team 研修

3/1~3/3の3日間で、アギレルゴコンサルティング主催のオンライン研修「Agile Testing for the Whole Team」に参加してきた。

www.jp.agilergo.com

講師は Janet Gregory(@janetgregoryca) さん。『実践アジャイルテスト』の著者の一人で、最近では『Agile Testing Condensed』という書籍も執筆している(こちらについても既にブロッコリーさん(id:nihonbuson) による邦訳がある)。

leanpub.com

また、Janet Gregory さんは先日開催された RSGT2021 でも基調講演の1つを務められていた。動画を以下に貼っておく。


RSGT2021 - Janet Gregory - What’s Testing Got to do with Quality?

研修の概要については、冒頭のアギレルゴコンサルティングのWebサイトの他、Agile Testing Fellow のWebサイトで研修概要のPDFファイルがダウンロードできる。

前置き

なぜ開発者である自分がこの研修に参加したか

会社がお金を出してくれ(ry

自分は、開発者の立場でアジャイルに関心を持って勉強してきて、前職時代から自分の仕事に学んだことを活かそうとしてきた。前職では自分の力不足もあってアジャイルのプラクティスを実践に投入できる機会は多くなかったが、現職のチームではイテレーション開発を採用し、ペアプロやCI、その他のアジャイルプラクティスを適用しながら仕事をしている。

しかし、テストという部分を見てみると、開発チームとQAチームとの関係は(決して険悪ではないが)密接とはいえず、「開発チームが作ったものをQAチームに回す」という流れになっている。バグによる手戻りが多くて困るということはそんなにないものの、仕様の把握とシステムが仕様通りに動いていることの確認という2点において、開発チームとQAチームが重複して仕事をしてしまっているなど、改善の余地があると感じていた。そういった背景もあり、冒頭で言及した書籍『Agile Testing Condensed』も、邦訳が出たときにすぐに買って読んでいた*1

また、別の観点からは、TDDやDDDの方面からATDD・BDDにも関心があり、つい最近は きょんさん(id:kyon_mm)と東口さん(@hgsgtk)による雑談を聴いたりしていた。


ATDD再考 2021

そういうわけで、この研修の存在をTwitter経由で知って「面白そうだな、参加してみたいな」と思っていた(会社Slackのtimesチャンネルにも投げていた)ところ、ありがたいことに会社で声をかけてもらい、同僚の開発者・QAメンバー数名と一緒に参加することになった。

研修のフォーマットなど

このご時世なので、当然オンライン開催で、3日間8:00~12:00の合計12時間の研修だった。これとは別に、事前に資料と動画(研修後にみることを想定したおさらい編も含めて全部で5時間ほど)が配布されていて、座学になる部分は極力事前予習で済ませ、当日の研修の時間ではさまざまなグループワークを行うことに時間が割かれた。

講師は英語話者だが、日本語の通訳者がついており、Zoomの同時通訳機能を使って、参加者の方で聴きたい言語(英語 or 日本語)を選んで聴くことができるようになっていた。この通訳の方がすばらしく、通訳を待って話のスピードが遅くなるという体験はほぼしないで済んだ。また、アギレルゴコンサルティングの川口さん(id:wayaguchi)が共同トレーナーとして臨席されており、参加者からの質問に対して補足説明を加えるなどしてくださって理解の助けになった。

研修の内容について

「チーム全体」で品質を考える

タイトルに「Agile Testing for the Whole Team」にあるように、研修のコアメッセージは「品質のことをチーム全体で考えよう」というものだったと思う。ここでいうチームとは「デリバリーチーム」であり、役割としてはテスター、開発者に加え、プロダクトオーナーのようなビジネスサイドのメンバーも含まれている。このメッセージは研修を通じて一貫したもので、当日に行ったワークショップでもPO、開発者、テスターというそれぞれの観点に立って意見を出してみるとしばしば促された。

研修の主な受講者として想定されていたのはテスターであったと思われるが、テスターに対してもマインドセットの転換を要請していた。開発プロセスの最後にバグを見つけることにテスターの役割を限定せずに、「そもそもバグを作らないで済むようにする」ことなどを通じて、「ソフトウェアを成功裡にデリバリーする」ための行動をテスターに取るように求めていた。

当然、その裏返しとして、開発者に対しては、品質を作り込むことを強く求めていた。研修中に出た印象深い発言として、「テストをする気がなく、品質について考えようとしないプログラマーがいたら、『コーディングを止めろ!("Stop coding!")』と言ってやりなさい」というものがあった。これを含め、テスターをエンパワーするような発言が随所にあり、(自分はテスターではないが)参加していたテスターの人たちには非常に心強かったのではないだろうか。

ワークショップから

先述の通り、研修当日(3日間)の時間は多くがワークショップに割かれた。かなりたくさんのワークショップを行ったので、いちいち内容に言及することは避けるが、ワークショップを通じて印象に残っているのは、「仕様について勝手に自分で判断せずに質問する、質問することで共通理解を形成する」ことの重要性である。自分はかなり「理解力」的なものを尊んでいて、「一を聞いて十を知る」的なあり方に憧れてしまうのだが、チームでものづくりをしているときには自分の頭で勝手に補うことが非常に危険であると実感することができた。

また、今回の研修のワークショップの多くは、ストーリーにイテレーションで取り組む前の段階にフォーカスしたものだった。講師の言い方では「ストーリー準備ワークショップ(story readiness workshop)」、スクラム的な言い方をすればバックログリファインメントで有効活用できそうなプラクティスを多く学ぶことができた。研修の趣旨からすると、この段階でチーム全体での共通認識の形成が、(バグの混入など)ソフトウェアのデリバリーを妨げる事象の発生の防止に重要ということなのだが、個人的にはストーリーを小さくスライスする具体的な方法が今まで良くわかっていなかったので大きな学びだった*2

ATDD, BDD, SBE

個人的には一番関心があった部分。『実践テスト駆動開発』(通称GOOS)は読んだが、実務ではATDDは取り入れておらず、BDD(Behavior Driven Development)やSBE(Specification by Example)は概要を知っている程度で本は未読だった。

講師はATDD(Acceptance Test Driven Development)が最も包括的な用語だとして説明していた。ATDDといえばGOOSで、GOOSは技術的な側面にフォーカスした本なので、自分の理解も(『テスト駆動開発』付録Cの表現を借りると)「外側のループ」をTDDに足したものという捉え方をしていたのだが、この研修では自動化の前段階で、チーム全体で共通認識を作り、ストーリーのスコープを把握するためのものとしての側面を重視していた。

イテレーションで実際にストーリーの実装(テスト&コード)に取り組む前に、ATをチーム全体で考える。ATを記述するフォーマットとしては、BDDスタイル(Given/When/Then)や、表形式(Tabular)など複数の書き方があるが、Given/When/Thenは自然言語で記述するのでわかりやすく、表形式では具体的な値を使って考えるのでより踏み込んだ議論を促してくれるということだった。これは実際にワークショップで体験したが、確かに表形式で記述しようとすると具体的な入出力をイメージしやすく疑問が出やすかった。

その他、研修で言及のあったもの

上記のトピックの他に、一部を挙げると以下のようなトピックが取り上げられた。

  • テスト自動化ピラミッド
    • なるべく下にテストを押し込んでいく
    • それぞれのテストがどのレイヤでできそうかを考え、マッピングしてみる(もちろんチーム全体で!)
    • 真ん中のレイヤ(API・サービス層)のテストはビジネスサイドの人も読めるようにする(Living Documentation!)
  • アジャイルテストの四象限
    • 第四象限おそろかにしがち問題
    • 上半分のテストはビジネスサイドの人も読める
  • バグトラッキングシステムの必要性
    • 新規フィーチャーの実装では、ゼロトレランス方式*3を採用するため不要
    • レガシーシステムの場合、本番環境で発生する不具合などの傾向を分析することが更なるバグの防止のために重要なのでしっかりとバグは管理するべき
  • テスト計画

まとめ的な感想

今回の研修を通じた最も大きな学びは「ストーリーをいかにReadyな状態にするか」に関わる具体的なプラクティスだった。ストーリーを十分に小さくしてReadyな状態にすることは、短いタイムボックスでインクリメンタルにソフトウェアを開発してフィードバックを早く得ることを旨とするアジャイルにとって極めて重要な営みであるはずだが、自分はあまりその部分を勉強してこられていなかったので、今回の研修を通じてようやく「ああ、こうやるのか!」と得心がいった部分が多かった。ただ、うまくやらないとストーリーをReadyにする営みにかなり多くの時間をかけてしまいそうで、そこは難しいところだと感じた。

他の感想としては、研修の語り口からすると、テスターを主な参加者層として想定しているようだったが、プロダクトオーナーや開発者にも役立つことの多い研修だったと感じる。「エラーをみつけるつもりでプログラムを実行する過程」としてのテストの技法についてはあまり言及がなかった分、自分のような開発者ロールで働いていて、テストに関する知識がそこまでない人間にもとっつきやすかった(裏を返せばその部分に関する学びは少なかった)。ただ、アジャイルという考え方についての説明や、TDDやCI/CDといった技術的プラクティスについての説明は少なかった(ある程度わかっている前提だった)ので、一定以上のアジャイルについての前提知識は持っていた方が理解しやすい研修だったのではないだろうか。

今回、同僚の開発者やQAメンバーと一緒に参加していたので、研修が終わった後、今後の実務にどうやって生かしていこうかという対話を始めている。研修で教わった内容をそのまま適用するのは難しいが、目指す一つの方向としてモデルを持てたこと、組織の課題を語るための共通言語を得られたことは価値があると思っている。この記事を読んで、「次回開催されたら参加したいな」と思っている人がいれば、ぜひチームのメンバーみんな(できればプロダクトオーナーも!)で参加すると良いと思う。

おまけ

Agile Testing Fellowshipについて

なお、この研修の副賞的なものとして、Agile Testing Fellowship のメンバーになることができるというものがある。研修受講後にオンラインでのアセスメントを受験して、合格すれば会員として迎え入れられるというシステムだ。自分も研修が終了したその日に受験し、無事に合格した。合格すると、PDFの会員証がもらえるほか、会員で構成されている Slack workspace に参加することができる(名称からして「認定なんちゃらer」ではないし、むしろこちらのコミュニティでの交流・相互支援に重きがあるようだ)。

なお、この Agile Testing Fellowship への入会は、研修を受けなくても可能で、120ドルを支払うことでアセスメントを受験し、入会することができる。『Agile Testing Condensed』の邦訳を手掛けられたブロッコリーさんはこちらの方式で昨年の時点で入会されている。

nihonbuson.hatenadiary.jp

参考:研修に関連する書籍

Janet Gregory & Lisa Crispin

その他

leanpub.com

*1:なお、研修を終えてみて改めて読んでみたところ、研修前に読んで全く頭に入っていなかった内容がワークショップでの経験によって理解できるようになったことを感じた。書籍には掲載されていないが研修で扱われているトピックも多くあったことも確認できた。

*2:「スチールスレッドコンセプト」というもので、フローチャートを使ってコアを特定していくワークショップを行った。

*3:既知の不具合が混入した状態でイテレーションをストーリーが通過することを許さないということ。

Keynote で作成したスライドを Speaker Deck にアップロードすると Transcript が文字化けする問題への対処法

※以下の問題が発生しない場合もある。おそらく使用するフォントによると思われる。

Speakerdeckの既知の問題

登壇するエンジニア御用達のスライド共有サービス Speaker Deck だが、いくつか既知の問題がある。

たとえば、以下のようなものだ。

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

今回、別の問題に直面したので、対処方法をメモしておく(結論から先に言えば、 Speaker Deck の問題ではなかった)。

Transcriptが文字化けする問題

Speaker Deck には、「Transcript」という項目があり、スライドの各ページの記載内容をテキストで自動的に補ってくれる。

Keynote で作成したスライドを Speaker Deck にアップロードすると、以下のようになってしまう。

文字化けしている様子
文字化けしている様子

この問題は、企業が運営しているアカウントのスライド資料で発生している例もあり、様々な人がぶつかっている問題だと思われる。

対処方法

当初、 Keynote の問題だとわからなかったため、「Speakerdeck 文字化け」などで検索してもなかなか見つからなかったのだが、知人からCMAPの問題ではないかとの指摘をもらい、以下の記事にたどり着いた。

fu7mu4.hatenablog.com

結果としては、上の記事で記載されている通りの作業を実施することで、 Transcript の文字化けも回避することができた。

手順1: Keynote から「PostScriptとして保存」

PDFが必要な場合、Keynote から「PDFとして保存」するのが定番だが、問題を回避するために一度 PostScript を経由する。「プリント」から「PostScriptとして保存」を選択する。

「PostScriptとして保存」を選択
「PostScriptとして保存」を選択

手順2: PostScript をプレビューで開き、PDFとして書き出し

PostScfript を「プレビュー」で開いて、PDFとして書き出す。

PostScriptから「PDFとして書き出す」
PostScriptから「PDFとして書き出す」

※2024.3.9 追記

Macの新しいバージョンではPostScriptのビルトインサポートがなくなっているため、上記の工程を代わりにGhostscriptなどのツールで行う必要がある。

ky-yk-d.hatenablog.com

対応後

綺麗に Transcript が文字化けせずに表示されるようになった 🎉

綺麗に表示されている様子
綺麗に表示されている様子

補足

16:9 のスライドを上記の方法でPostScriptに書き出すとサイズの関係で余白ができてしまうので、以下のようにサイズを調整してアップロードするとよい。

  • keynoteで「プリント」
    • ページ設定でカスタムサイズ設定
    • サイズを横254mm*142.9mm
    • PostScriptとして保存
  • プレビューで開いて、PDFに書き出し

ソフトウェア開発者としての4年目を新しい会社で始めた

今年の4月から新しい会社で開発者として働いています。

2017年4月に新卒で前職に入社したのがソフトウェア開発者としてのキャリアのスタートでもあったので、この4月で4年目に突入していたこととなります。早いものです。

大学院(修士)卒で就職したので、25歳になる年に就職したわけですが、あっという間に28歳になる年です。あと2年で30歳になる年です。以前(当時は26歳)、id:nitt_san さんに投げかけられた「30歳のときにどうしていたい?」という問いに改めて向き合おうと思う今日この頃です。転職できたことに満足して一息ついていたら30歳になってしまっていたということがないように。。


色々書こうかなと思うことはあったのですが、まとまらないのでやめました。Amazonの欲しいものリストだけぶら下げておいてもよかったのですが、なんか気が乗らなかったのでそれもやめました。それなら転職エントリ自体書かないという手もあったのですが、まぁ一つの区切りとして書いておくとすっきりしそうだなと思ったので書きました。ふー。

このブログもだいぶご無沙汰になってしまっているのですが、また思い出したように何かを書き始めることもあるかと思います。乞うご期待。またTwitterの方は(アイコンもIDも何もかも変わってしまっていますが)相変わらず元気にやっていますので引き続きご愛顧ください(?)。

ソフトウェア業界におけるパターン・ランゲージの受容についての覚書:「付録C」を待ちながら

※本稿はあくまで覚書です。大事なことなので本文にも書きました。筆者はアレグザンダーの著作を限られた範囲でしか読んでいないことを予め表明しておきます。また、XP やスクラムについても書籍で得られる知識しか持ち合わせていません。専門家によるアレグザンダーについての分析は長坂一郎『クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う』を、ソフトウェア業界における受容についての分析は江渡浩一郎『パターン、Wiki、XP ―― 時を超えた創造の原則 WEB+DB PRESS plus』をそれぞれご参照することをお勧めします。

追記(最終更新:2020/05/10)

同様のテーマについての(個人的には重要な)記事を忘れていたのでリンクを記載しておきます。

上記記事で取り上げられているエヴァンスのDDDを本記事で取り上げられなかったことの反省文です。

また、(上記ツイートのリプライツリーにも言及がありますが)アレグザンダーの日本のソフトウェア業界における受容の最先端(だと思う)きょん(id:kyon_mm)さんの上記記事を承けてのツイートと発表資料も転記しておきます(こちらもリプライツリーまでぜひご覧ください)

以上の観点を踏まえると、本記事で書いた自分の認識はやはり見落としているものが多いと早くも感じるのですが、それはそれで一つの認識なのでそのままにしておきます。

きょんさんは上記の発表資料の中で言及されていますが、Alan Kay のオブジェクト指向とアレグザンダーの思想、エヴァンスのDDDなどとの関連(これについても Coplien 氏が重要な手掛かりになると思いますが)機会があれば自分なりに整理できればと思います。 (以上、 2020/05/09 追記)

本稿で取り上げている事柄について、日本のソフトウェア業界にあってパターンに関わる実践を重ねてこられた懸田剛さんのまとまった資料(本記事執筆段階ではこの資料を直接参照していませんでしたが、懸田さんからはTwitterやその他の資料で学ばせていただきました)をご紹介いただいたのでこちらにも掲載しておきます。

(以上、 2020/05/10 追記)

パターン・ランゲージの付録C

建築家のクリストファー・アレグザンダー(1936-)のパターン・ランゲージの思想が、ソフトウェア業界に受容されてきたことは、周知の事実である。パターン・ランゲージという語に馴染みがなくても、GoFのデザインパターンや、最近ではAWSのクラウドデザインパターンを知っている人は多いだろう。

日本語で書かれたソフトウェア業界におけるパタン・ランゲージの需要についての文献としては、2009年の江渡浩一郎氏の『パターン、Wiki、XP』*1のほか、2011年の情報処理学会の会誌「情報処理」52巻9号の特集「ソフトウェアパターン−時を超えるソフトウェアの道」がある*2

しかし、パターン・ランゲージがソフトウェア業界に持ち込まれてから約30年が経ち、当初の脈絡や原典たるアレグザンダーの思想(それ自体、2000年代にかけても進展がある)との関連が見えづらくなっている。このような事態を、Kent Beckの『テスト駆動開発』の新訳版の訳者を担い、そこにこの20 年間のTDDをめぐる議論の流れを補足する「付録C」を執筆し挿入した和田卓人(id:t-wada)氏は、以下のように語っている。

パターンにも付録Cが必要なんですよ。歴史が切れてしまっている所があって、パターンってGoFのデザインパターンでしょ?みたいなところがあったりするから、やはり背景や意義を補わなければならない。

(出典:希薄化したTDD、プロダクトの成長のために必要なものは?〜『健全なビジネスの継続的成長のためには健全なコードが必要だ』対談 (6) | by Takeshi Kakeda | 時を超えたプログラミングの道

数年前にこの業界に入ったばかりの自分としては、パターン・ランゲージについての「付録C」が書かれることを強く期待している。相応しい人物は、上記の対談の関係者など多くいるだろう。

本記事は、「付録C」が書かれることを待ちながら、なんとか自分なりの理解を形作ろうとしている筆者が、外出自粛の暇に任せて書き殴る覚書である。アレグザンダーの思想やデザインパターンについての紹介記事ではないことをご承知おき願いたい。また、筆者はパターン・コミュニティの一員ではなく、PLoPに参加したことも、パターン・ライティングの経験もないことを書き添えておく*3。パターンに詳しい方々におかれては、「ある若者にはこう見えている」という一例として読んでいただきたい(認識に誤りがあればぜひご指摘をいただきたい)。

ソフトウェア設計についてのパターン

ソフトウェア開発者にとって身近な「パターン」はやはりGoFのデザインパターン(オブジェクト指向における再利用のためのデザインパターン)である。ソフトウェアそのものについてのパターンとしては他に、POSA(ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系)、PoEAA(エンタープライズアプリケーションアーキテクチャパターン)などが挙げられる。

上記のようなソフトウェアそのものについてのパターン(=プロダクトについてのパターン)は、パターンの語はソフトウェアの設計において「繰り返し現れる、問題に対する解決方法」という程度のものとして使われている場合が多く、アレグザンダーのパターン・ランゲージの理論のうち、「無名の質(QWAN)」(これは難しい観念だが、価値的な要素を含んでいる)や、「ランゲージ」たる部分はあまり重視されていないように思われる。

このような用法における「パターン」は、良くも悪くも、深遠なものではない。おそらくアレグザンダーの原典を読まなくてもこれらのパターンは理解・利用できるし、もし読んだとしても混乱するだけだろう*4

Kent Beck による受容

そもそもパターン・ランゲージというアイデアが建築業界からソフトウェア業界に持ち込まれたのはどのようにしてであったか。一人の重要人物は、エクストリーム・プログラミングの祖であり、『Smalltalkベストプラクティス&パターン』(ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集)などのパターン形式をとった書籍も複数執筆している Kent Beck である。

江渡氏によれば、「ベックは大学生のとき、生協で『時を超えた建設の道』を読み、大きな衝撃を受け、そのまま立ち読みで全部読み終えてしま」ったという*5。『時を超えた建設の道』が出版されたのは1979年で、 Kent Beck は(Wikipediaによれば)1961年生まれであるから、出版されて高々数年という時期に読んだと思われる。

Kent Beck は Ward Cunningham*6と共にソフトウェアの設計にパターン・ランゲージの考え方を持ち込む実践を行った。そこでは、ソフトウェアの利用者に参加してもらってユーザーインタフェースの設計*7を共同で行うこと、そしてパターン・ランゲージを用いることが試みられた。その成果は、1987年の OOPSLA で紹介され、ソフトウェア業界でパターンというものが流行する端緒となる*8

オブジェクト指向プログラムのためのパターンランゲージの使用 - kdmsnr.com

その後、Kent Beck は開発の手法としてのエクストリーム・プログラミング(XP)を生み出す。 XP とアレグザンダーの(主に『オレゴン大学の実験 (SD選書)』における)思想との類似性は江渡氏が指摘しているところであるが、当初の実践の要素のうち、(利用者参加は残っているものの)存在していたユーザーと共同でパターン・ランゲージを使用するという要素はXPには残されていない。これは、2002年に Ralph Johnson*9 が語っているように、マーケティング上の配慮もあったかもしれないが、現在手に入るいわゆる「白本」の第2版(『エクストリームプログラミング』、2004年)では(1999年の初版には参考文献でのみ言及されていた)アレグザンダーへの言及に1章を割いていることを考えると、ただ単に、設計行為の中でパタンランゲージを用いるというプラクティスは XP には持ち込まれなかったと考えた方がよいだろう。

Kent は,XPをマーケティングする際,パターンの時とは違ったアプローチを 取りました.両者に違いは多くありますが,重要なのは,XPについて彼が書い たものには,Chistopher Alexander が出て来ないということです.私が推測するに,典型的なソフトウェア開発者に Alexander を指し示すのは間違いであると彼は考えたのではないでしょうか.なぜなら,Alexander の考えは彼らに理解しにくく,Alexander をこの議論に持ち込むと,人々はすぐにソフトウェア開発の話題から逸れて行ってしまうからです.Kent は,みんなに「ソフトウェア」を考えて欲しかったのでしょう.

(出典:- XPとパターン Ralph Johnson'sの見解

パターン・ランゲージを用いる当初の実践から、 XP を経て、現在の「アジャイル」に至るまで、開発対象のソフトウェアの利用者(顧客)を開発に参加させるという考えは引き継がれている。しかし、そこではパターン・ランゲージの(利用者を含めた当事者による)使用というアイデアは見られない。

Jim Coplien の生成的プロセスパターン

XP を生んだ Kent Beck の他に、アレグザンダーの影響を受けて独自の議論を構築したソフトウェア業界の人物として、 Jim Coplien がいる。 Jim Coplien は、1994年頃からパターンに関する様々な著作を発表しており、その一つの種類として組織およびプロセスについてのパターンについての著作がある*10。前述の Ralph Johnson や江渡氏は、これらの著作が Kent Beck 、したがって XP に影響を与えていると推察している。組織についてのパターンが書籍化された『組織パターン: チームの成長によりアジャイルソフトウェア開発の変革を促す』の冒頭で紹介されているエピソード*11も、それを伺わせる。

着目したいのは、 Jim Coplien がアレグザンダーの「生成的(generative)」という概念を自身のプロセスについてのパターンの理論に持ち込んでいることである。

パターンの側面を組織の分析に取り込むことは、何も目新しいことはない。この研究での斬新なことといえば、パターンを生成的な方法で使おうとしていることである。(中略)パターンはすでに存在している組織を理解するのに役立つだけでなく、新しい組織を作り上げるのにも役に立つ。組織に関するパターンのよい集合は、“間接的”に正しいプロセスを作るのに役立つ。この間接的であるというのは、Alexander流の生成的方式である。実際のところ、組織に関するパターンは、ソフトウエア・アーキテクチャ・パターンへの最も生成的なアプローチであろう。Alexanderは、「アーキテクチャを作ることはできない、通常の人々の行動によって間接的によってのみ作ることができる。それは、花を作ることはできなくて、種からによってのみ作ることができることと同じである。」と述べている。

(出典:「生成的開発プロセス・パターンランゲージ」

アレグザンダーは、1967年*12の論稿 ”System Generating System" で、全体としてのシステム(system as a whole)と生成システム(generating system)という概念対を導入し、設計者の設計の対象を(通常の考え方がそうであるように)個々の事物(objects)ではなく後者の生成システムと規定する。特定の質をもった全体としてのシステムを生み出す生成システムの設計が、設計者の使命となる。

(出典:”System Generating System" ※引用者による私訳)

アレグザンダーは1968年に既にパターン・ランゲージを冠する著作を発表していたが、その後の成果は1977年に『パタン・ランゲージ―環境設計の手引』に結実する。ここで提示されているパターン・ランゲージは、まさに上記のような生成システムとしてのものである*13

Jim Coplien は、「生成的」という点を強調した上記の論文において、優れたアーキテクチャを生み出す開発のプロセスを生成するパターン・ランゲージを提示している。 Jim Coplien 自身が「間接的」と言っているように、ここではソフトウェア自体に現れるパターンが考察の対象になっているのではない。これは、アレグザンダーの建築についてのパターン・ランゲージとも少し次元を異にしている。

アレグザンダーのパターン・ランゲージで扱われるパターンは、最終的な生産物である町や建物に現れるものだった。これは先に言及したソフトウェアにおける「デザイン・パターン」と同様、プロダクトのパターンである。ソフトウェアにおけるデザイン・パターンとアレグザンダーのパターン・ランゲージが異なるのは、アレグザンダーのパターン・ランゲージが利用者をも巻き込むものであった点である*14

Jim Coplien は、このようなパターン・ランゲージの枠組みを、開発プロセスに適用する。このとき、ソフトウェアの利用者にランゲージとして共有され、ソフトウェア自体に現れるパターンというものは、存在しなくなっている。パターンは開発プロセスに現れるものであり、それはソフトウェアの利用者と共有されるものではない*15。その代わりに、開発プロセスの中で生きる開発メンバーこそがプロセスの利用者であり、パターン・ランゲージを使用しながら自らのプロセスを形作っていくというわけである。XP もまた同様である。再び Ralph Johnson の発言を引く。

しかし,XP 自体,一種のパターン言語です.私は,Kent は Jim Coplien のプロセスパターンから影響を受けていると思います.『デザインパターン』と『Smalltalk Best Practice Patterns』の中のパターンは「プロダクトパターン」であり,XP は一組の「プロセスパターン」だとも言えます.でも,もしXP を一組のプロセスパターンと見るならば,それは非常にうまく定義された,パターン言語になっています.そして,それは,多くの点でAlexander アプローチ(Alexanderian)だと言えるでしょう.特に,生成的(generative)であるという点です.XP には「信頼性」や「理解容易性」に直接関連するパターンが無いにも関わらず,「プラクティス」全体が結びついて,信頼性が高く理解が容易なシステムを生成(generate)しています.

(出典:- XPとパターン Ralph Johnson'sの見解

別の着眼点としては、上記の論文で Jim Coplien が、アレグザンダーの「無名の質(Quality Without A Name, QWAN)」の概念を借り、組織の「無名の質」について語っている点を挙げておく。

ある組織は“無名の品質(Quality Without a Name)” [Alexander]を持っている。彼らは、株主に利益を与え、顧客にうまく対応し、継続し条件を満たし支援的な職場を従業員に提供しているので、目的にかなっている。このような成熟レベルに達している組織は、他のすべての面でも優れていると思われる。ここで示されているパターンは、そのような組織を構築することを可能にするのであろうか?

(出典:「生成的開発プロセス・パターンランゲージ」

彼の議論においてアレグザンダーの「無名の質」が目指されるべきものとして措定されていることは確かだろう。しかし、上記の引用部分の最後の問いに、 Jim Coplien は暫定的には懐疑的な回答をしている。プロセスパターンと並んで語られていた組織パターンにおいても、「無名の質」は語られない。彼の影響を受けたとされる XP においても事情は同じであり、その後のアジャイル開発においても「無名の質」という側面は強調されてこなかったと思われる*16

Scrum Patterns におけるアレグザンダーへの回帰?

ソフトウェア業界におけるアレグザンダーの受容の2つの流れ、すなわちソフトウェア自体に現れるパターンを問題にするもの(「プロダクト・パターン」)と、ソフトウェアを開発するプロセスに現れるパターンを問題にするもの(「プロセス・パターン」)の両方において、アレグザンダーの思想はそのままの形では取り入れられなかったと思われる*17

ところが、大々的にアレグザンダーの「無名の質」に言及するものがある。Scrum Patterns である。最近になって書籍媒体で出版された『A Scrum Book』は、Scrum PLoP コミュニティが書いてきたスクラムについてのパターン・ランゲージである。書籍版の Introduction には、以下のような記述がある。

We believe that the patterns in this book have something special. The pattern community calls it “the Quality without a name,” or sometimes just “the Quality,” a kind of Wholeness that aspires to day-to-day excellence.

(出典: "A Scrum Book"

PLoP の主要人物の一人が Jim Coplien であることからすると、アレグザンダーへの言及があるのは不思議ではない。そもそも、スクラムはその初期において Jim Coplien の取り組んでいた組織パターンの研究に影響を受けている*18。パターンとしてスクラムを表現することも、1998年の時点で既に、 Jeff Sutherland らによって行われている*19

注目したいのは、先に取り上げた「生成的開発プロセス・パターンランゲージ」の「はじめに」において、著者自身がその獲得に懐疑的な態度を示していた「無名の質」が、上記の A Scrum Book では獲得できたとされていることである。「無名の質」以外にも、アレグザンダーの『時を超えた建設の道』で既に色濃く表現されていた東洋思想の影響が、 A Scrum Book にも現れている*20RSGT 2020 の Jim Coplien の基調講演で題材とされた十牛図も、 Preface において紹介されている。

本文のパターン・カタログには、アレグザンダーへの直接的言及は多くない*21。既にソフトウェア開発フレームワークとしての有効性を示し、地位を確立したスクラムであるから、「無名の質」などというものに言及せずとも成立しただろうし、多くの読者は気にも留めないだろう。それどころか、書物としての読者へのハードルを高めてしまう危険性すらある*22

それにもかかわらず、あえて A Scrum Book がアレグザンダーの影響を強く表現していることは、興味深い事実である。それは、単に Jim Coplien 氏の「色」が強く出ただけなのかもしれないし*23、良くも悪くも単なるフレームワークと化したスクラムに対するコミュニティ全体の切実な問題意識ゆえなのかもしれない。いずれにせよ、「無名の質」を語るスクラムがどのように受け入れられていくのかは注目していきたい。

所感

以上、アレグザンダーあるいはソフトウェア業界におけるその受容についての現時点での知識と理解を書き留めた。書きながら感じたのは、自分のアレグザンダーについての理解不足である。Kent Beck や Ward Cunningham 、 Jim Coplien をはじめとして様々なソフトウェア開発者を惹き付けたアレグザンダーの思想を、自分自身がまず存分に浴びたいと思った。また、 Jim Coplien 氏の考えにはオブジェクト指向との関連においても関心があるので、彼の著作についても読んでいきたいと思う。

TODO

  • アレグザンダーの著作を読む
    • 翻訳済みの主要著作を中心に
    • できれば未邦訳の後期著作The Nature of Order vol.2-4も
  • Coplien の著作を読む
  • 初期のスクラムの歴史を知る
  • パターン・ライティングの実際を知る
    • どこかの PLoP に潜りにいく
    • パターンを書いている人たちに話を聞く
  • 慶應・井庭研究室の研究成果を知る

関連資料

Christophor Alexander


Christopher Alexander - Patterns in Architecture

Kent Beck と Ward Cunningham

James O. Coplien


RSGT2020 Keynote by Jim Coplien


Jim Coplien — Symmetry in Design

スクラム、Scrum Patterns

www.slideshare.net

Togetter

その他

*1:紙媒体は中古のみだが、Kindle版は購入可能。

*2:特集のうち本稿の関心に近い寄稿のリンクのみを本文で掲載した。

*3:また、井庭研究室にも関わりがない。

*4:別の議論として、GitHubなどの「設計書共有サイト」がある現在では、この種のパターンがかつて果たしていた役割は縮小している、というものもある。

*5:江渡浩一郎『パターン、Wiki、XP』62ページ。

*6:Wikiの開発者。

*7:これはオブジェクト思考の関心事である。

*8:この辺りについても江渡氏の著作が詳しい。なお、1980年代半ばに既にパターン・ランゲージのアイデアのソフトウェア業界における受容が始まっていたことを指摘している文献として、「情報処理」41巻1号「連載解説:パターン - ソフトウェア開発のノウハウの再利用 第1回 パターンの発展と現状」がある。

*9:GoFの一人。

*10:Jim Coplien 氏の著作については、本人のWebページの著作一覧を参照。

*11:『組織パターン』2ページ。XP の創始者の一人であり、 Smalltalk に関連するもののみを「実際の仕事」と見なす著名なソフトウェアコンサルタントは、 Kent Beck その人だろう。

*12:ここで引用したWeb上の資料には1968年とあるが、長坂一郎『クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う』の記述に従い、1967年とする。当該論文については同書115ページ以下を参照。

*13:参照、長坂一郎『クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う』117ページ。

*14:アレグザンダーは、パターン・ランゲージが住民にも共有できるものであることを重視している。参照、『時を超えた建設の道』270ページ。

*15:利用者参加の過程で共有されることはあっても、そのパターンは生み出されたプロダクトには現れない。

*16:もっとも、後述するように、認識が及んでいなかった可能性もある。

*17:初期の Kent Beck と Ward Cunningham の実践は例外という位置付けになる。

*18:参照、Scrum as Organizational Patterns

*19:参照、SCRUM: An extension pattern language for hyperproductive software development(※PDFへの直リンク注意。邦訳は、SCRUM: 超生産的ソフトウェア開発のための拡張パターン言語)。

*20:いわゆる「パタン・ランゲージ」三部作だけでなく、後期の The Nature of Order にも言及があるのは注目に値する。

*21:アレグザンダーの『パタン・ランゲージ』のパターンを明示的に参照しているものもある。たとえば、「おやつ神社」パターンの説明では、アレグザンダーの「150 待ち合わせ場所」および「127 親密度の変化」を参照している。

*22:江渡氏は、アレグザンダーの『時を超えた建設の道』について、「この本はしばしば「分かりにくい」と評される.その理由の 1 つに,彼が明白に東洋思想の影響を受け,そこから都市や建築への考 えを巡らせているという点が挙げられる.「道」や「門」といった老子の言葉の借用にそれがよくあらわれている.」と指摘している。参照、江渡浩一郎「ソフトウェアパターン−時を超えるソフトウェアの道−:2.パターンランゲージからソフトウェアパターンへ」。

*23:Jim Coplien 氏は、スクラム関連以外の場面でもたびたびアレグザンダーの著作に言及している。例えば、Jim Coplien — Symmetry in Design