1
/
5

アジャイル・DevOps#8 「アジャイルなマインドセットとは③」

「アジャイルなマインドセットとは」3回目です。


ingに価値を見出す

本当の価値は作成されたモデルではなく、モデリングという作業そのものにあることを認識すること、これを重要な思想として採用すべきだ。

これは、私も翻訳者のひとりである、「ディシプリンド・アジャイル・デリバリー」という書籍内の一節です。これを読んだ時に、自分の中でいたく納得感があり、それ以来、同じようなことをあちこちで言いまくっています。(この連載の第4回でも)

この考え方は、本書が初出ではありません。アジャイル関連書籍で有名なところとしては、「アジャイルな見積りと計画づくり」でしょう。初めてアジャイル開発に取り組む方の必読書ですが、この中で最初に強調されているのが、「作成された計画そのものよりも、計画づくりが重要」という点です。だからこそ、この本の原書のタイトルは、"Agile Estimating and Planning" と両方ともingが付いています。

アジャイルの実践者は、明示的に言語化されていなかったとしても、みんなこのingの重要性を知っているのではないかと思います。
プラクティスとしての「モブ/ペアプログラミング」「合宿」、さらには全員参加のスクラムの各イベント、ユーザーストーリーのVacation Photoという考え方。これらはすべて、物事の決まった結果ではなく、その過程を重要視しているように見えます。

過程を共有することに時間を使っていますか

ところが、従来の、特に文書駆動の開発になじんでいる方には、この「過程の共有」という考え方が、おそろしく無駄に感じられます。

「計画って少人数で決めて、後で全員に伝えればいいじゃない」
  「最初の目標設定段階から開発者に入ってもらうと、その分コストがかかる」
  「モブプロって全員でひとつのプログラムしか書かないのは、時間がもったいない」

こんな言葉を聞いたことはないでしょうか。

従来の考え方には、「完璧な文書があれば計画や設計は伝えられる」という暗黙的な信念があったような気がします。しかし、文書には大抵「決まったこと」だけが記述され、他にどんな選択肢があったのか、どんな議論がされたのか、決まるまでの過程は出てこない。これをすべて文書化しようとすると、おそろしく煩雑な文書になるでしょう。

決まったことだけを伝えられ、その過程を知らないと、その結果に対する判断を誤ります。なぜこういう計画になったか/こういう設計になったかを理解しているからこそ、納得感をもってその計画/設計に沿うように行動したり、逆に変更の提案ができます。
(変更の提案など不要、言われた通りにやってもらえればそれでいい、と考えていらっしゃる方は、アジャイル開発をやめてください。)

この考え方の転換をしない限りは、アジャイルの「何でもみんなでやる」ことに、抵抗感があると思います。さらに言えば、この、決めることを先に決めて後から共有、というやり方が、善意でなされることがあるから、難しい。「開発チームの○○さんはいつも忙しいから、こんな曖昧な計画段階から巻き込むのは、申し訳ない。ビジネス側だけでやっておいて、後で共有しよう」とか、考えることはないでしょうか。しかし、開発側からすると、大抵は「早めに相談してくれればいいのに」という結果になります。

組織内でこれからアジャイルを推進していこうという方は、まずご自身の中に、こういう考え方がないかどうかを振り返ってみてください。その上で、組織内の相手がこの考え方を持っている場合、「過程を共有する重要性」を、どう相手に分かってもらうか、に心をくだく必要があります。

アジャイルなマインドセットとは、3つめは、「○○より○○ingが重要」です。

※転載元の情報は上記執筆時点の情報です。
 上記執筆後に転載元の情報が修正されることがあります。

アジャイルなマインドセットとは③
豆蔵の中の人ナカサトのヒトづくり・モノづくり・コトづくりへ一言 第13回 「アジャイルなマインドセットとは」3回目です。 本当の価値は作成されたモデルではなく、モデリングという作業そのものにあることを認識すること、これを重要な思想として採用すべきだ。 これは、私も翻訳者のひとりである、「 ...
https://www.mamezou.com/techinfo/agile_devops/nakanohito_013
株式会社豆蔵's job postings

Weekly ranking

Show other rankings