BT

正しいもの作りのためのシンプルさ

| 作者: Ben Linders フォローする 20 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー 投稿日 2013年7月1日. 推定読書時間: 4 分 |

原文(投稿日:2013/06/20)へのリンク

GOTO Amsterdam 2013のhard things made easy(難しいことを簡単に)というトラックにおいて、Russ Miles氏が5つの問いによる正しいもの作りについてライトニングトークした。彼はGojko Adzic氏によるインパクトマッピングから4つの問い「Why? Who? How? and What?」を引用しつつ、「すべての根拠になっている仮説は何ですか?」という問いを加えた。これらは製品や技術ロードマップを作るのに、また正しいものを正しく作るための、役立つシンプルなツールになる。

複雑さとシンプルさについて、彼はこう説明した。

「複雑さというのは、ソフトウェアや変更を正しいタイミングで届けることにとって、サイレントキラーになります。これだけで、すぐれたアイデアや企業を殺す原因になり得るのです。シンプルさにフォーカスすることが解決策になるのですが、シンプルさというのは簡単なことではありません。私たちのテクニックとプラクティスを活用することで、ソフトウェアを顧客に届けている組織やチームが、できるだけシンプルな、それでいてシンプルにしすぎて重要なところが欠けないような解決策をとることを手助けします。」 – Russ Miles, Formation of Simplicity Itself, 2013

私たちは、シンプルさによる正しいもの作りについて、Russ Miles氏にインタビューした。

InfoQ: GOTO Amsterdam 2013のライトニングトークで、あなたは正しいもの作りについて語りました。なぜそれが重要なのでしょうか?

Russ氏: 私たちは10年かけて、組織が将来性のあるソフトウェアをデリバリーするための実にすばらしいエンジンを作ってきました。そして、そのエンジンは実に快調に動きはじめています。最近、問題になっているのは、届ける方法ではなく、いかにして正しいものを作るか、あるいは、そもそも何を作るべきかを決めることなのです。

ソフトウェアの開発とデリバリーは簡単なことではありません。このレベルで私が注意しているのは、複雑すぎるソフトウェア、あるいは目的を達成するのにシンプルな解がないようなソフトウェアを構築しようとして、時間を無駄にしないことです。

InfoQ: 正しいものを作るのに、シンプルさはどのように役立つのですか? 具体例をあげてもらえませんか?

Russ氏: 正しいものを作る(あるいは先ほどあげたようなものを作らない)ためには、目的と仮説を明確にして、テスト可能なロードマップを作る必要があります。たとえば「これ以上削ると重要な価値を損なうというレベルまで削ること」というシンプルさを表わすステートメントは、立てた目標に向かってロードマップを進みながら様々な選択肢の中から選ぶときに、すぐれた基本的価値観になります。

このように、シンプルさはロードマップを進むときの指針となります。途中で複雑になりすぎたり簡単になりすぎず、前進するのに必要なものを作るのに役立ちます。

InfoQ: あなたは「開発者のスキルやプラクティスにある、不要でコストのかかる複雑さを取り除こう」と言っています。これはリーンに似ているように聞こえるのですが?

Russ氏: 確かに、リーンやアジャイルの価値と原則とシンプルさとの間には調和があると思います。実のところ、シンプルさはいろいろな方法でこれらの取り組みを支えています。

私がやりたいのは、シンプルさを曖昧で不明瞭な価値から、具体的な原則やガイドラインに変えて、ソフトウェアの開発やデリバリーのあらゆる面に影響を及ぼすことです。プロセスに関して、その一部はリーンやアジャイルにルーツがありますが、これは私たちの作るソフトウェアの構造にまで広げることができます。

シンプルさによる適応性と敵対するような複雑なソフトウェアを作ると同時に、シンプルさによる適応性のプロセスを最適化しようとしても、むだ足に終わります。私の狙いは、最初から最後までシンプルさを反映することで、私たちが作るものとプロセスだけでなく、ソフトウェアの観点からも適応可能にすることです。

InfoQ: 多くの人は複雑さを嫌っているのに、どうして複雑さを減らすためにできることをやっていないのでしょうか?

Russ氏: 残念ながら、複雑さを特定するのは簡単ではありません。しかも「シンプルさ」という言葉には、個人的な偏りや曖昧さがつきものです。

シンプルさは、アーキテクチャ、設計、コードにおける絡み合いの客観的指標になりますが、どこに複雑さがあるのか、どこに複雑さを取り込んでいるかは、いつも明確であるわけではありません。必然的あるいは本質的に複雑な問題領域は、あまりに容易に複雑になるのです。

これが取り込まれた複雑さ、私たちが外因性あるいは想定外の複雑さと呼ぶものです。私は開発者がこれらを見分けられるよう手助けします。なぜなら、ここから得られるもの、本質的に適応力のあるアジャイルなソフトウェアには、大きな影響力があるためです。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT