正しいものを正しくつくる｜市谷聡啓 (papanda)

「アジャイル」の答え合わせ

　「アジャイル」という言葉の広まりようには、隔世の感を感じずにはいられない。ごく当たり前のように開発の選択肢として捉えられるようになった。若い組織であろうと、伝統的で歴史ある組織であろうと、関わらずだ。　そんな状況をぼくらは夢見たはずであるし（ここでいう「ぼくら」はかつて、アジャイルに取り組むも全くうまくいかず、死屍累々の失敗を重ねていたコミュニティの仲間たちのことだ）、実際に至ったことには自分が一つ仕事を成し得たのだという感慨を抱く。　…なのだけども。なのだけども、

インセプションデッキづくりで何をしていることになるのか？

　期初にあたるためか、最近インセプションデッキづくりに携わることが多い。ほぼ毎時間、デッキをつくっている日もある。今更、インセプションデッキ？と思われる人もいるかもしれないが、デッキの有効性はいまだにある。むしろ、めちゃくちゃ高い。　というよりは、デッキレベルの認識あわせもできていない状況で、プロダクトづくりなり、プロジェクトなり始めたところでうまくいくはずもない。ところが、このくらいの内容でさえ合っていない、おざなりになっていることが少なくない。デッキが登場して10年以

仕事の「点」に囚われず、「流れ」を読む

　スプリントプランニングをいつ、誰が、どんな内容で実施するのか。あるいは、受け入れ条件の記述書式をどう決めるか。完成の定義は？　デイリースクラムで何を話す？ etc、etc 　これら一つ一つについて考えを煎じ詰めていくのは大事なことだ。クオリティと効力感は細部に宿る。ただ、開発が、仕事が、より良き状態となるのを目指すのに、これら一つ一つに焦点をあてる前に捉えるべきことがある。それが「流れ」だ。　「流れ」に対して、冒頭にあげたことは「点」だ。「点」の一つ一つがどうあると良

プロダクトをつくろう。そして、そこから「物語」を取り出そう

　最近の関心どころから、井庭さんの創造システム理論を紐解いていた。「創造」そのものをシステムとして、人から外部からして捉えることで、その本質を見ようとするアプローチは、「創造」だけに留まらず広く適用が考えられる。例えば、組織システムもその一つとして。　井庭さんの理論では、「創造システム」と関わるためのすべが「パターン・ランゲージ」であり、それは「発見」に導かれるためのメディア（媒介物）となる。創造的な状況に進むには、何かしらの切欠が必要になる。そこでパターンを用いる。パタ

仕事における「はやさ」とは何か

「はやい、とはなんだろうか。」　この問いをもらった時、さっと応えようと思ったのは「適応のはやさ」についてだった。かわりばえしない、私にとってはいつもの回答パターンだ。　ただ、「適応のはやさ」は刺さりが悪い。たいていの場合、相手の表情には「言っていることは分かるが、それを正解にしたくない。」という色がありありと現れる。少しだけ「はやさ」について考えてみることにした。　結論からいうと、「判断のはやさ」をあげたい。ソフトウェア開発や仕事そのものにとって「はやい」とは何か

目標管理のフレームとしてのOKR、分断を乗り越える手がかりとしてのOKR

「開発もビジネス側に踏み込んでいかないといけない。」　義務感からはなく「そうありたい」という思いとして、この手の決意を耳にすることが以前よりも増えた。現場がより価値を形作っていくためには、どうあると良いのか。考え抜いた末に、出した結論。もとより容易ではないとわかっているが、それでもそうでなければ変わらない。　プロダクトオーナーと開発チームの分断課題について十数年前から言及しているように思うが、いよいよこの課題に向き合う現場が増えているのは感慨深い。と同時に、根深いとも思

原則で語るか、感情で語るか

　最近、ある方との出会いで、新たなインスピレーションが得られた。コロナ以降の流れで、仕事以外での「新たな出会い」なるものはめっきり減ったままだった。やはり、新たな出会いは新たな思考をもたらす。この感覚は久しく忘れていたように思う。　一つ整理がつきそうなのは、こんなことだ。原則で語るのか、感情で語るのか。もしくは原則ドリブンか、感情ドリブンか。　人には何かしら、こうありたい、だからこうしたい、こうしていたい、といった「信念」「価値観」が宿っている。今のところ、「信念」と

ナラティブ・チーム報 (輪番でチームの日報を書く)

　同じものをみていても、あるいは同じ時間をともにしていても、どうみているか、どう感じているかは人によって違う。　だから、ふりかえりであるとか、その他のワークショップや場を設けることで、意識的に分かろうとする。考えをあわせたい場合もあるし、合わせるのではなく違っていることを分かるようにしておきたいという場合もある。いずれにしても「共通理解」を一定得る、時折得ることで、チームや組織の営みを良くする。　こうした「何に、何を感じているか」を表出するのが容易ではないときがある。

「アジャイルとは設計しないことか」へのもう一つの解説

　「アジャイル」という概念を広く適用していこうとすると、思わぬことに気づくことがある。例えば、「"仕事をする" のに必要なこととは何か」といった極めて根本的な事柄にむきあうことになる。　「アジャイル開発」であれば、「仕事をする = 開発する」であるから、「そもそも開発とは何か？」という問いで立ち止まったり、ウンウン悩み始めることは少ない。「開発する」ことについて持ち合わせている知識を元に、アジャイルに向き合っていく。　しかし、文脈が開発から離れた場合、たちまち怪しくな

透明性、検査、適応を3ヶ月やり通した先に得られるもの (ただし骨折において)

　左足第５中足骨骨折から実に10週が経過した。　ようやく、2本だった松葉杖が1本になり、装具（ギプスの代わりになるもの）を外し、よちよち歩きを始められたところだ。2ヶ月以上固定していた足を生脚で地面につけるのは勇気が要る。自分の足でありながら自分のものではないような感触。ちょっと踏み損ねただけで、いろんなところに影響がでそうな繊細な足になっていた。　この骨折からあらためて思ったことがある。人間のからだはブラックボックスで、外部からはフィードバックを頼りにするシステムに

アウトプットと、アウトカムと、インパクト

　引き続き、ソフトウェアと、プロダクトと、システム（系）を巡る話。　プロダクト作りにおいては、「アウトプット（結果）とアウトカム（成果）」が論点としてよくあがる。「アウトプットがあるかどうかだけに意識が向いていないか」「アウトカムに繋がるアウトプットや諸活動になっているか」という問いだ。　文脈としては「単なる出力結果（機能開発）」vs 「アウトカム（ユーザー価値）」や、「収益」vs 「アウトカム（ユーザー価値）」といった二項で議論されることが多いだろう。「ユー

ソフトウェアと、プロダクトと、システム（系）

　前回、「つくる」の解像度を上げようという話を書いた。　「ソフトウェア」という概念を、あえてエンジニアリングの視点に振り切らせると、「プロダクト」とは、ソフトウェアでその中核をなしつつ、ユーザーやビジネスという視点を組み入れる範疇ということになる。　ここで、「いやいや、ソフトウェアにも当然ユーザーの視点があるでしょう」という見方が出てくるが、そこで「ソフトウェア」と「プロダクト」の境界をあいまいにすると、扱いがぼやけるため分ける。ここでは「ソフトウェア」とはエンジニア

「つくる」の解像度をあげる

　「解像度をあげる」とは、より見分けられるようになるということだ。同じようなものと捉えていたことを明確に区別できる。理解の「密度」が高くなる。だから、言葉でより説明ができるようになる。　それはただ単に細かいことをあげつらうということではない。区別できるようになった上で、さらに統合する。共通するところと、異なるところを比較して、区別する前の「全体」として言えることをまた生み出す。個別だけではなく、全体として解釈できるようにする。　このことを前提として何を言いたいかという

その帰り道で、一人何を思うか？

　デブサミに登壇した。　2020年以来のリアル開催ということで、久々の場だった。今回はいつもの雅叙園ではなく、羽田空港。その場の違いがかえって20年前の初回、デブサミ2003を思い起こさせてくれた。　デブサミには他のカンファレンスに比べて、内輪感が少なく感じる。それだけ多種多様なテーマ、人が集まる場になっている、と言える。デブサミは「誰にとってもアウェイ」。20年かけて、参加者、登壇者、コンテンツ委員、スポンサーと一巡してきても、やはりアウェイ。いつまでもアウェイ、そ

正しいものを正しくつくる

記事一覧