ari’s view このページをアンテナに追加 RSSフィード

2013-09-29

はてなブログを開始

はてな記法とMarkdown記法を比較すると、はてな記法の方が好きです。はてな記法は、脚注の書き方や番号付きリストフォームが簡単ですし、用語の定義表現できます。ただ、使っているエディタMarkdown記法の相性が良く、しばらくMarkdown記法を使ってみようと思っています*1

現在のところ、はてなダイアリーMarkdown記法に対応しておらず、はてなブログはMarkdown記法に対応しているようなので、Markdown形式で書いたものに対して、はてなブログもあわせて始めることにしました。この本ダイアリーを、はてなブログにインポートして移行するかどうかは、しばらくしてから考えます

読者の方にはご不便をお掛けします

http://motohasi.hatenablog.com

最初タイトルは「富士山は岩でごつごつしているのに、遠くから見るときれいなのか」です。

*1:三日か三年か三十年かは不明

2013-05-10

[][] 方法論やプラクティスにまつわるパタン転回とゆる思考

タン転回を用いた ゆる思考の適用を、主にソフトウェア開発やプロダクト管理手法プラクティスについて、もう少し具体的な例で概要を示したい。

 ◇ ◇ ◇

状況

ソフトウェア開発やその周辺では、様々な方法論がある。たとえば、能力成熟モデル統合や、PMBOKなどの体系、DDDからUMLウォーターフォール型開発からアジャイル型開発まで、先人たちの知見は素晴らしい。

どのぐらい昔だったのか覚えていないのだけれど、どこに行ってもCMMIのレベルをあげる、なんて耳にしている時代があったような気がする*1ITサービスマネジメントにおけるベストプラクティス成功事例)はITILもある。監査の人たちとは、CoBITをベースによく会話した。最近、よく耳にするのはアジャイル型開発もScrumやXPクリスタルクリア、リーン…様々あり、読むとなるほど参考になるなぁ、と思うことが多い。私自身は、ワインバーグエゴレスプログラミング拡張した、エゴレス開発が成功体験としてある。

その中で、異なったフレームワーク方法論によって論争が起こることが多い。アジャイル型開発対ウォーターフォール型開発などの対立のエントリブログSNSで盛り上がった。しかし、私の経験からすると、ウォーターフォール型開発においても、実質的にはアジャイル的なプラクティス実施することは多い。スクラムというアジャイル型開発を実施していても実質的ウォーターフォール型開発に近い状態で回す場合もある。ほとんどの案件が0.5人日から2人日程度であれば、ウォーターフォール型開発でもうまくいく。さらに、ソフトウェア開発の周りを見てみれば、それこそ個人、チーム、ビジネスなどの切り口はあるものの、置かれている状況は千差万別である

ビジネスに関しても、様々な方法論やベストプラクティスがあふれている。生活もだ。「これをすればうまくいく!」みたいな本はあふれている。パタンコミュニティも大量のパタンを生み出し、成功体験があふれかえっている。さらには、インターネットの発展で、それこそ無数にも思える情報があふれている。まさしく百花繚乱であり、何を選択するべきか、どのようにすべきかよくわからない。

論争は、それぞれのパラダイムの発展に寄与する部分もある。何を選択すべきかの参考になる場合もあろう。しかしながら、たまに終着点を感じないような状態になることが多い。そして、不毛にも思える議論は、健全な成長や営みを阻害するような状況も発生しているようさえにも感じる。


問題

どのような標準や方法論に準拠すればよいのだろうか。「あるべき姿」はどんな姿なんだろうか。

ビジネス目的にするのであれば、ベストプラクティスを選べば、フォロワー戦略を取ることになる。はずれはないものの、他のビジネスとの差異を作り出すことが困難になる。

プラクティスは、その文脈の中でのみ評価される。文脈を読まずに著名なベストプラクティス方法論に実施することは、ネガティブな結果を生み出してしまうことさえ、ある。たとえば、アジャイル型開発のスクラムでの例を挙げよう。朝会をやるべき、というモデルに従って朝会をしたところ、リッチな会話がなくなってしまった。ソフトウェア開発者と、製品企画担当者分化していなかったので、プロダクトオーナー役を決めたところ、状況の分離が進み、コミュニケーションがギスギスしてしまった。コールセンター的な役割をする業務で、電話があるごとに対応する必要があった場合、計画作りをしたところで、意味をなさない。など、文脈の中でのみ、プラクティスは評価されるのである

それゆえ:(解決策(案))

まずは現場を見て、現場の状況に合わせた解決策を探し出そう。パタン(の種)を作り出すときは、過去の知見やノウハウを参照することによって、より豊かで納得性の高い方法実施しよう。

先のメタ方法論として、パタンもしくはパタンランゲージを用いると、方法論が持つ目的や関心と、その現場などの状況が持つ問題の目的や関心をすりあわせることができる。例えば、パタンプロセス自身にもこの考え方を適用できる。未来を織りなすパタンの文脈の中で、問題解決を探る方法として制約条件の理論クラウドを用いることができる。たとえば、 情報のオープン戦略:攻殻機動隊 Stand Alone Complexに対する解決策案 - ari’s viewは、パタンクラウドを埋め込み、クラウドで見つかった解決策(インジェクション)をパタンの解決策案として採用することもできる。パタンランゲージと制約条件の理論マッピングができているので、そのほかの応用も利くし、不足しているところも補完できる。たとえば、クラウドを見ただけでは、状況やストーリが見えづらい。そこで、パタンとして表記することによって、第三者に伝えるというメリットを見いだした*2

この方法論でこうすべきだ!このプラクティスではこのようになるべきだ!的で原理主義的になりやすい硬直した状況をゆるめることができる。実際、別の記事で紹介したが、アジャイルウォーターフォールの組み合わせや、CCPMの組み合わせなど、複数の事例がある。それもいいけれど、これもいい、では、文脈やリソースにあわせて、次の一歩はこのようにしよう、という、方法にとらわれずにデザインを行おう。

その結果、ビジネスソフトウェア開発で発生している問題やジレンマ当事者として解決する。「おしきせ」でも「命令・指示された方法」をそのまま実行するのではない。それも制約とした道筋を感じながら、自分たちの物語を紡ぎたい。そのときの結論についても、指示や命令した人と話し合うことができれば、なお良い。このようにパタン転回によって、関心や目的が相対化され、非常に幅広い視点を持ち、その中で現実的な方法が選択できる*3

 ◇ ◇ ◇

この概要が示した通り、ソフトウェア開発やその周辺においても、健全な営みができることを祈っている。

*1:「成熟レベル5は、段階的および革新的な技術進歩を通じた継続的なプロセス有効性の改善を重視する。(Wikipedia)」となっているので、アジャイルの文脈とも接点はある。ただし、そこに至る経緯や背景が異なる。

*2:逆に、第三者に伝える必要がなければ、クラウドで十分である

*3原理主義的な強いこだわり」に対する否定的な意見も持ちやすくもなるのだが

2013-05-07

[][] 見ている夢のお話:コミュニケーション的転回(Communication Turn)β

「夢かもしれない、ひとりかもしれない」が、これから何をしていくのか何をしていきたいのかの夢を文字にしておく。現在、どのような問題があるのだろうか。どの社会であったとしても、必ずや矛盾があり、その矛盾を乗り越えていくとはいえ、切実な問題はなんであろうか。

子どもの頃から、私の問いは「なぜ人は争うのか」であった。それは、戦争であり紛争であり、テレビや新聞で見聞きするニュースであり、友人から家族日常生活の中にも争いはある。そして、2005年12月18日から、その問いに「生きること」が加わった。生きることに敏感になった。生きるってなんだろう。私のペンネームである「あり(有り)」のように。

まだ「β」をつけたように、答えではないのですが、少しだけ見えている道筋を紹介したい。

 ◇ ◇ ◇

状況

(暗く重たい話が含まれます

続きを読む

2013-04-17

[][][] トップダウンボトムアップの対立と和解(その1)

ボトムアップ的なアプローチトップダウン的なアプローチの話を状況やステージ視点でざっくりと書いてみました。

◇ ◇ ◇

状況

トップダウン的なアプローチと、ボトムアップ的なアプローチの二種類がある。

一方のボトムアップ的なプロセス発見的なプロセスでもある。たとえば、パタンは、ボトムアップ的なプロセスと相性がよい。ひとりひとり、もしくは、ひとつのチームなどでの成功体験や気持ち、状況などを丁寧に見てコトバ(パタン)やカタチにしていく。たとえば、「あの大きな木が好きだ!残そう」という気持ちであったり、「コーディネータ役(調整役)を入れたら成功した」であったり、様々なスケールにおいて、コトバやカタチを足していく。その結果、ランゲージ(コトバによる構造)として、ある領域における世界観を生み出していく。診断した結果、不足しているところがあれば、どんどん言葉を継ぎ足して修正し、使わない言葉は消滅していく。

他方のトップダウン的なプロセスは、上から覗くような視点である。ある領域ドメイン)における、完全な「全体」をロジカルに理解し、コンセプトや方針を決め、それに基づいたタスクルールに分解する。たとえば、ある領域を細かく分け、「重複なく・漏れなく」という意味であるMECE(Mutually Exclusive and Collectively Exhaustive)という観点でチェックする。そのMECEでの分割する観点は、その領域ドメイン)でのリソースや制約状況によって、違いがある。

問題

トップダウンアプローチボトムアップアプローチは対立している(のではなかろうか)。

解決策

このふたつの考え方のどちらが優れているか?という議論は、むろん大切ではある。ただ、私は「どのようなときにそれぞれを活かすことができるのか」という議論が好きだ。目的や関心に応じて、どっちの手法を選択するのか、ということだ。

いろいろな状況や現場があり、一般解を提示するつもりはないが、二つのモデルケースを考えてみた。

現在のところ、ボトムアップ視点構造システムを作り、トップダウン的な視点でチェックし選択や実施する、のがひとつの方針案として有用そうだ。たとえば、『ゲームストーミング』を参考にし、ある会議を考えてみよう。最初は、ブレインストーミングなど、いろいろな意見を出し発散させていく。その後、整理し、実行可能性などの視点から順番をつけるなど収束させる。そのときの発散はボトムアップアプローチに近く、整理や収束などに強いのがトップダウン的なアプローチであろう。むろん発散のステージにいるのに批判をするなどの収束的なアプローチを取ると混乱することが多いので、ある程度のバランス感覚の中で明確にステージにわけることは現実的なノウハウだ。また、トップダウン的なアプローチを主に置いてしまう、もしくはボトムアップ的なアプローチでもスケールが大きくなると、個別の要素についての変数が無視される傾向があるので留意したい。その後も、発散と収束ボトムアップトップダウンをくり返していくことになるだろう。

トップダウンボトムアップの利点を見いだし、目的や関心に応じた使い分けを今後も検討していきたい。

◇ ◇ ◇

トップダウンボトムアップの対立と和解(その2)は、スケールに応じたダイナミックスの切り口です。

2013-04-10

[] パタンの種類、パタンライティング手法の選択と、パタンライフサイクル

タンライティングには、様々な手法がある。その目的に応じた方法を選択すると良い。むろん、ひとつそのワーク自身の目的を探すためなパタンライティングも良く行う。いずれにせよ、その組織にあった目的や関心を探すことが何よりも重要である

タンライティングを行うときの観点は複数にも及ぶ。この観点一つ一つが記事になるので、そのリストを参考までに紹介すると:

それにかかるリソース時間、人、金など)*2成熟度などの制約に応じて選ぶ。

その中でも、最も大きなファクターは、過去を紡ぐのか、それとも、未来を紡ぐのか、の違いである。パタンライティングには、大きく分けてパタンの作り方には二種類ある*3ひとつ過去を紡ぐためのパタンであり、もう一つは未来を紡ぐためのパタンである。その本質的な違いは、パタンを作っているときにすでに解決策があるかどうか、ということだ。ただ、気をつけてほしいのは、過去を紡いだパタンであっても、デザインなど未来を紡ぐために参考にできる。あくまで、その違いは、そのパタンライティングを行うときに解決されている問題かどうか、ということである

 ◇  ◇ ◇

過去を紡ぐパタン(のパタン

  • 自分たちがうまくいった工夫などの成功体験を知られていない。
  • 似たような状況を乗り越えた他の人たちがどのようにやったのを知ることができない。
  • マニュアルだと、どのようなときに、その解決策を適用すればいいのかわからない。
問題

成功体験が共有されず、同じ失敗が繰り返されている、もしくは、問題が発見されてもいない。

解決策

既に解決したことがある「うまく行くコツや工夫」を集める過去を紡ぐパタンを書こう。アレグザンダーの『パタンランゲージ』も情報処理推進機構(IPA)のアジャイル調査も、それまでの成功体験や工夫などの過去を集め、発表している。そして、読者は、その他人の成功体験を参考に自分実施する。

『パタンの書き方 http://www.cultureworks.jp/blog/?p=44 』を参考にする。成功したもの、うまく行っていること、その領域について土地勘があることが前提になる。成功したこと(解決策)から、その前提や制約事項、名前を探していく。いくつかの方法があるが、初めてのパタン作りを試みる人は、ぜひとも参考にしてほしい。

過去を紡ぐパタンの特徴は、文章の記述量が多い(厚いとも表現する)ことだ。なぜならば、筆者と読者は、コンテキスト(状況や文脈)を共有していないため、その状況を事細かに説明する必要がある。たとえば、『シェファーディングのランゲージ - 羊飼いと羊のためのパターンランゲージ http://patterns-wg.fuka.info.waseda.ac.jp/japanplop/Translations/LoS-YH-01/LOS-YH-V0120.pdf 』のパタンランゲージに「体験談War Stories:直訳すると戦争物語)」というパタンがある。体験談の解決策はこのようになっている:「そのパターンを明確にするため、実際に体験したこと(体験談)を作者に話してもらおう。体験談は、そのパターンが一体何なのか、そして、いかに利用できるかを示す、きわめて強力な道具になりうる。」つまり、戦争を語る人のように体験を丁寧に語ることで、臨場感があり、第三者が説得されるのだ。

その結果

文脈に応じた解決策を臨場感を持って知ることができ、自らの問題に適用できる。

ただし、書くための手間がかかるし、パタンフォームの使用するかどうかだけでは、「質」が向上するかの関係は不明である

最終的には、その個人もしくは組織常識や習慣となり、比較意識しないで行われるため参照されない状況になる。


未来を紡ぐパタン(もしくは、パタンの種(のパタン))*4

現在の状況に近いコンテキスト(文脈)のパタンが見つけられれば、そのまま過去成功事例を当てはめることはよいだろう。また、十分に生き延びている知見(パタン)を、状況を読まずに適用することも良く行われる(たとえば、ふりかえりをしようよ、とか)。その結果に基づいた知見を修正していくだろう。

しかしながら、課題がありそうだ。

  1. 似たようなコンテキスト(文脈)を持つパタンが探せない。パタンの前提や文脈が直面していることに合わない。たとえば、「今ここにある日差しのよさを守りたい」としたとき、その状況は個別のものである。別の例では、大学研究室で作られた知見は、前提としている状況が異なっていて共感することができなかったとよく聞くことがある。問題は無数にあり、よく似たコンテキストを探すことはとても困難だ。
  2. よく似たコンテキストを持つそのままパタンが見つかったとしても、自分環境にそのままあてはめることが適切かわからない。良い例であるかは不明であるが「二度あることは三度ある」というパタンと「三度目の正直」というパタンは相反している知見であり、どちらも適切だ。三度目があったかを知るため、試してフィードバックを得られる種類の知見は実施すればよいと思うが、単なる迷走状態を生み出しかねない。意思決定の材料として、どちらが正解かを事前に知ることは難しいだろう。
問題

意思決定やデザインの場面において、(他人の)過去を紡いだパタンは参考にできるかもしれないが、自分の解決策にすることは困難だ。もしくは、自分の解決策にしたときに違和感が発生する。

解決策

そのような状況では、自らの状況を把握し、解決策を考えだし、利用・実行する必要がある。過去成功事例を参考にしつつ自分の関わっていることがらをデザインする。

このときにパタンのコアは「アレグザンダーからメッセージ http://www.cultureworks.jp/blog/?p=40 」にある。一番大切なことは、心から美しいと思うこと、正しいと思うものだ。コトバになっていなければ、いくつかの民族学的な手法を参考にしたテクニックを用いてコトバにすることが多い。パタンフォームでは「問題(もしくは、実現したいこと)」として記載する。

そして、この心から美しい、正しいと思うものを実現するために、それを制限するものを洗い出す(フォース)。その際、その制限するものは、立場の違いだけであってそちらも正しい、もしくは現実的な解だと思っている可能性があるので、くれぐれも尊重する心がけがその後の解決策を探すことになる。

次は、問題との解決策を探る。その際、U理論、超越法、TOCクラウド(対立解消図)、システム思考など様々なツールを使うことによって、解決策をさぐろう。選び方のポイントは、実施する目的による。たとえば、参加者がその手法を学びにきているのであれば、目立つ手法を選択するだろうし、あくまで参加者自身の関心ごとを取り扱うのであれば違和感のない透明な方法がよい。たとえば、透明な方法とは、U理論を用いる場合を例にとると、Uの谷を潜る、という表現をあえて使わず、その実質的な方法をとる。

この未来記述するためのパタンは、参加者の多くがその状況や前提を把握しており、記述量が少なくなる傾向になる。成功体験に繋がった後は、過去経験として様々なストーリを追加し広めていく。

その後、期待されるスコープを見定めながら、この解決策の実現や「修復(悪いことを直し、良いところを守る)」をしていく。過去のパタンから学び、未来を紡ぐパタンをさぐり、それが過去を紡ぐパタンになり修復しながら広がっていくライフサイクルになるのだ。

 ◇ ◇ ◇

本記事には、パタンランゲージおよびプロジェクトランゲージセンタリングセンタリングプロセス、なぜ、それが大切なのかについての記述は言及しなかったので注意されたい。

*1IPAの調査では、こちらを使った

*2リソース時間、人、金など)って一言で書いていますが、それだけでもたくさんの要素が絡み合う。現時点では別の書籍や文書に譲りたい。

*3:二種類のパタンについては自分で気づいたつもりだったのだが、H氏が似たようなことを話されていたし、K氏の図を見ると似たような結論に至ることができる。すでに私が聞いていたことを再発見したのかもしれない。

*4:参加のまちづくり(C.Alexander's Community Planning)ワークショップを通じて中埜氏から学んだことを、自分なりに整理し肉付けしたものである