https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1002_2 Constructive Interaction and the Iterative Process of Understanding (建設的相互作用と 理解の反復プロセス) 三宅なほみ 1986
attempt to specify everything before we start coding. Instead, we’ll work out enough of a specification to let us start and then immediately create some functionality. We’ll try ideas, gather feedback, and continue with another cycle of minidesign and development. インクリメンタル開発 このアプリケーションは、段階的に開発していきま す。コーディングを開始する前にすべてを指定 (Specify)しようとはしません。そのかわり、いく つかの機能をすぐに作り始められるように、十分な 仕様を決めておきます。アイデアを試し、フィード バックを集め、ミニ設計と開発のサイクルを繰り返 します。
style of coding isn’t always applicable. It requires close cooperation with the application’s users, because we want to gather feedback as we go along. We might make mistakes, or the client might ask for one thing at first and later want something different. It doesn’t matter what the reason is. The earlier we discover we’ve made a mistake, the less expensive it’ll be to fix that mistake. All in all, with this style of development, there’s a lot of change as we go along.
す。 Because of this, we need to use a toolset that doesn’t penalize us for changing our minds. If we decide we need to add a new column to a database table or change the navigation among pages, we need to be able to get in there and do it without a bunch of coding or configuration hassle. As you’ll see, Ruby on Rails shines when it comes to dealing with change. It’s an ideal agile programming environment.
of tests. These tests will ensure that the application is always doing what we intend to do. Not only does Rails enable the creation of such tests, but it even provides you with an initial set of tests each time you define a new controller. その過程で、私たちはテストのコーパス(訳注:例文 の集合)を構築し、維持することになります。これ らのテストは、アプリケーションが常に私たちの 意図したとおりに動作することを保証するもので す。Railsはこのようなテストを作成できるだけで なく、新しいコントローラを定義するたびに、初 期テストのセットを提供してくれます。
the main pages in our applications and to understand roughly how users navigate among them. This early in the development, these page flows are likely to be incomplete, but they still help us focus on what needs doing and know how actions are sequenced. ページフロー 私たちは常に、アプリケーションの主要なページ についてのアイデアを持ち、ユーザーがその間を どのように移動するのかをおおまかに理解したい と考えています。開発の初期段階では、これらの ページフローは不完全である可能性が高いですが、 それでも、何をする必要があるかに焦点を当て、 アクションがどのように連続するかを知るのに役 立ちます。
to mock up web application page flows. We like using a pencil and paper. It’s quicker, and the customer gets to play too, grabbing the pencil and scribbling alterations right on the paper. The first sketch of the buyer flow is shown in the following figure. PhotoshopやWord、あるいはHTMLを使って、 Webアプリケーションのページフローをモック アップするのが好きな人もいます。私たちは、鉛 筆と紙を使うのが好きです。そのほうが手っ取り 早いですし、お客さまも鉛筆を手に取って紙に書 き込むことができます。買い手のフローの最初の スケッチを次の図に示します。
which he selects one product at a time. Each product selected gets added to the cart, and the cart is displayed after each selection. The buyer can continue shopping using the catalog pages or check out and buy the contents of the cart. During checkout, we capture contact and payment details and then display a receipt page. We don’t yet know how we’re going to handle payment, so those details are fairly vague in the flow. 極めて伝統的な方法です。買い手はカタログのページを 見て、そこから一度に1つの製品を選びます。選択され た各製品はカートに追加され、選択のたびにカートが表 示される。購入者はカタログページで買い物を続けるか、 チェックアウトしてカートの中身を購入することができ ます。チェックアウトの際には、連絡先や支払いに関す る情報を取得し、レシートページを表示します。決済を どのように行うかはまだ決まっていないので、これらの 詳細はかなり曖昧なフローになっています。
fairly basic. After logging in, the seller sees a menu letting her create or view a product or ship existing orders. When viewing a product, the seller can optionally edit the product information or delete the product entirely. The shipping option is simplistic. It displays each order that hasn’t yet been shipped, one order per page. The seller can choose to skip to the next or can ship the order, using the information from the page as appropriate. 次の図に示すように、売り手のフローもかなり基本的 なものです。ログインすると、商品の作成・閲覧や既 存の注文の発送を行うメニューが表示される。商品を 閲覧する際には、商品情報の編集や商品の削除が可能 です。 出荷オプションはシンプルです。まだ出荷されていな い注文が、1ページにつき1件ずつ表示されます。販売 者は、次のページに進むか、そのページの情報を使っ て注文を発送するかを選択することができます。
in the real world, but shipping is also one of those areas where reality is often stranger than you might think. Overspecify it up front, and we’re likely to get it wrong. For now, let’s leave it as it is, confident that we can change it as the user gains experience using our application. 出荷機能は明らかに現実世界では長くは生きられ ませんが、出荷もまた、現実が想像以上におかし いことが多い分野のひとつです。今のところはこ のままにしておいて、ユーザーがアプリケーショ ンを使う経験を積んだら、変更できることに自信 を持っておきましょう。
going to be working with. Notice that we’re not using words such as schema or classes here. We’re also not talking about databases, tables, keys, and the like. We’re talking about data. At this stage in the development, we don’t know if we’ll even be using a database. データ 最後に、これから扱うデータについて考える必要があり ます。ここでは、スキーマやクラスといった言葉は使っ ていないことに注意してください。また、データベース、 テーブル、キーなどの話もしません。データについて話 しているのです。この開発段階では、データベースを使 うかどうかさえわかりません。
As the user buys items, we’ll need somewhere to keep the list of products they bought, so we added a cart. But apart from its use as a transient place to keep this product list, the cart seems to be something of a ghost—we couldn’t find anything meaningful to store in it. To reflect this uncertainty, we put a question mark inside the cart’s box in the diagram. We’re assuming this uncertainty will get resolved as we implement Depot. データ図の作成作業をしていると、いくつかの疑問が 湧いてきました。ユーザーが商品を購入すると、購入 した商品のリストを保存する場所が必要になるため、 カートを追加しました。しかし、この商品リストを一 時的に保存する以外に、カートは何か幽霊のようなも ので、保存する意味のあるものが見つかりませんでし た。この不確実性を反映させるために、図中のカート のボックスの中にクエスチョンマークを入れました。 これは、Depotを実装していくうちに解決されるもの と考えています。
price in the line item data. Here we’re breaking the “initially, keep it simple” rule slightly, but it’s a transgression based on experience. If the price of a product changes, that price change shouldn’t be reflected in the line item price of currently open orders, so each line item needs to reflect the price of the product at the time the order was made. 最後に、商品の価格を項目データで重複させているこ とにお気づきでしょうか。これは、「最初はシンプル に」というルールを少し破っているのですが、経験則 に基づいた違反行為です。商品の価格が変更された場 合、その価格変更は現在開かれている注文の項目価格 に反映されるべきではないので、各項目は注文された 時点の商品価格を反映する必要があるのです。
we’re still on the right track. (The customer was most likely sitting in the room with us while we drew these three diagrams.) ここでもう一度、お客様に正しい道 を歩んでいるかどうか、再確認しま す。(この3枚の図を描いている間、 お客さまはおそらく同席していたは ずです）。
doing some preliminary analysis, we’re ready to start using a computer for development! We’ll be working from our original three diagrams, but the chances are pretty good that we’ll be throwing them away fairly quickly— they’ll become outdated as we gather feedback. Interestingly, that’s why we didn’t spend too long on them; it’s easier to throw something away if you didn’t spend a long time creating it. さあコードを書こう さて、お客様との打ち合わせと事前分析が終わり、 いよいよコンピュータを使った開発です。最初に 作成した3つの図を元に作業を進めますが、フィー ドバックを得るうちに古くなり、すぐに捨ててし まう可能性が高いです。面白いことに、あまり時 間をかけずに作ったものほど捨てやすいのです。
jointly agree on priorities. In this case, we’d point out to her that it’s hard to develop anything else until we have some basic products defined in the system, so we suggest spending a couple of hours getting the initial version of the product maintenance functionality up and running. And, of course, the client would agree. 私たちは、お客様と一緒になって、優先順位を決 めていきたいと考えています。今回のケースでは、 システムで基本的な部分をある程度定義しないと 他の開発が難しいため、まずはメンテナンス機能 の初期バージョンを稼働させるために数時間かけ ることを提案します。もちろん、クライアントも 納得してくれるはずです。
kawaguti
sakaitakeshi
paraworld
ch1aki
soracom
databricksjapan
ks91
toshi_atsumi
blue_goheimochi
meihei3
fujiwara3
kaonavi
davidbonilla
pedronauck
rocio
keathley
carmenintech
phodgson
eileencodes
trishagee
trallard
hursman
speakerdeck
thekraken
![教育心理学概論 新訂 (放送大学教材) [全集叢書] 三宅 芳雄(著)、三宅 なほみ(著) 経験から固めた「経験則」 (素朴理論) 学校で教える原理原則](https://files.speakerdeck.com/presentations/374d04790e8c4ec6aa227242c370aa4d/slide_34.jpg){kind=link}
![教育心理学概論 新訂 (放送大学教材) [全集叢書] 三宅 芳雄(著)、三宅 なほみ(著) 経験から固めた「経験則」 (素朴理論) 学校で教える原理原則](https://files.speakerdeck.com/presentations/374d04790e8c4ec6aa227242c370aa4d/slide_35.jpg){kind=link}
![教育心理学概論 新訂 (放送大学教材) [全集叢書] 三宅 芳雄(著)、三宅 なほみ(著) 経験から固めた「経験則」 (素朴理論) 学校で教える原理原則](https://files.speakerdeck.com/presentations/374d04790e8c4ec6aa227242c370aa4d/slide_38.jpg){kind=link}
