2 posts tagged “開発”

【動作を分解して考える。】

頭にあることを「紙」に出し、誰にでも（後々の自分にも＾＾；）わかるように「母国語で書く」必要性について書いてきました。

今回は「動作を分解して考える。」です。

前回晒した「画面遷移書」のように、作ろうとするものの動作や機能については一通り「紙」に「母国語」で書き出すことができたわけです。

しかしこの資料は「制作者以外の方でも読める」ということを念頭に置いていますので、「当たり前のことを当たり前」に書いています。
例えば、「ドラッグ&ドロップ」や「拡大／縮小」「ポップアップメニュー」などなど。。。

「専門用語は使わない」と前回に書きましたが「わかるだろう。＾＾；」と思われる専門用語はそれなりに使っています。そうしないと読み手に苦痛を与える冗長な文章になってしまい

「読みにくい」→「読まない」→「認識を共有できない」

という大変なことになるので、そこはバランスをとりながら書いています。

しかし、少しでもプログラムに挑戦したことがある方なら察しが付くと思いますが、

「実際の動作は細かい動作の積み上げの上に成り立っている」

ということに。。。

つまり、文章では一言で表現した「ドラッグ」や「ポップアップメニュー」「拡大／縮小」などというものは、細かな動作の集合の上に成り立っている動作であるということです。

そのため、本当に必要なベースとなる動作（＝処理）を見極める必要がでてきます。

たとえば、一言で済むように

「珈琲を淹れてください。」

といったお願いだって。。。言われた人は「珈琲を淹れる」という認識でも。。。

「湯をわかす」
「カップ&ソーサーを用意する」
「インスタント珈琲の粉をカップへ入れる。」
「やかんの水は沸騰したかどうか？」
「沸騰したらカップにお湯を注ぐ」
「角砂糖の器とフレッシュとカップ&ソーサーをトレイに」
「依頼者へサーブ」

といった細かくわかれた処理を一つずつ積み上げながら「珈琲を淹れる」という動作を実現していますよね。＾＾

これが「動作を分解する」ということ。

もちろん書面や口頭で「珈琲淹れて＾＾」って一言で済むことを、ここまで「動作を分解」して伝える必要はないと思います。お互い人間同士なら。

それは前述したように「珈琲を淹れる」という大きな動作が「湯を沸かす」「入れ物を用意する」「珈琲豆を用意する」といった大きな動作を実現するための小さな動作を持っていて、その小さな動作を再構築することで大きな動作である「珈琲を淹れる」が実現できることを知っているから。

但し。。。「珈琲を淹れる」ために何の準備が必要で、どういう作業が必要で、そもそも珈琲が何かわからない人にお願いする場合はどうしますか？

そうですよね。
「珈琲を淹れる」という動作を事細かく説明しますよね。
説明するために「珈琲を淹れる」という動作を細かい動作に分割する筈です。

そうした行為がプログラミングには必要になります。

そうしたことが、#01で引用させてもらった

「プログラムとは、コンピュータへの命令ではなく、
コンピュータに何をしてほしいか、人に説明することだ」

Donald E. Knuth, “Literate Programming”
（ドナルド E. クヌース 『文芸的プログラミング』）

ということだと自身では理解しています。

だって、コンピュータはあなたが依頼したい事柄の何一つも知らないんですから。
あなたが親切丁寧に細かい動作に分割して一つ一つ教えてあげる必要があるんです。
「コンピュータに何をしてほしいか、人に説明すること」のように。

そのために「動作を分解して考える」んです。

【まずは母国語で考える】

さて。。。大分「間」が空いてしまいましたが３回目です。

タイトルにある「プログラム／コーディングのその前に。。。」どんなことを考え、どんなことをしているか？ということを、まぁ何かの参考、何か「足がかり」にくらいはなるだろうと思い晒しているものです。＾＾；

• 前々回は「書こうと思った理由など諸々←継続予定^^;」
• 　前回は「まずは紙にでも書くということ。」

ということで、一旦、自分の頭の中にあることを勘違いを防ぐために、忘れ物をしない（減らす＾＾；）ために、「外部装置」である「紙」に出してしまえ！という話をしました。

今回は「まずは母国語で考える」というタイトルです。

なんだか当たり前っちゃぁ当たり前の話なんですが。。。
要は「専門用語」を多用しないということです。

自分で仕様切って、設計して、プログラミング／コーディングまでやっていると。。。
「仕様書」や「画面遷移書」を書いている時点で

    「○○_mcをon(press)で.startDrag(枠_mcの範囲内)」
    「○○_mc.onLoad = function(){初期化};」

とか、普通に書いています。^^;
もちろん間違いではありません。
一応日本語で書くと、

    「○○_mcを押下しながら枠_mcの範囲内をドラッグする」
    「○○_mcがステージに読み込まれた時に値の初期化をする。」

というような感じでしょうか？

実際にとある案件で使った「画面遷移書」を晒すと。。。
こんな感じです。

実際の動き、つまり、

    どのボタンを押したら、何がどう表示されて、どう動くか？

といったことをまさに「母国語」で順を追って書いていきます。

どうですか？「めんどくさー！！」と思われますか？
僕は正直思います。＾＾；

じゃぁなんでこんな面倒臭いことをするのかというと。。。
そうです！

　「思い込みや勘違いを無くすため」

です。

そして、わざわざ面倒臭いことでも「意味／メリット」があるのであれば行う値打ちはありますよね。＾＾；

僕は何故こんなことを行うかというと。。。

　・お客様への資料となる。（やってますよ！感アピール）
　・内部の資料となる。（異なる職能の方々との意識合わせのため）
　・自分の資料となる。（いろいろ作業やったり、飛び込みが来て戻っても忘れない。）

というメリットを知っているから。
そして何より

「望まれているモノの整理と限られた予算の中でできうることを最大限投入するため」

だったりします。

何が言いたいかと言うと。。。

制作サイドの勝手な判断と思い込みで作りこみ過ぎない。そのパワーをお客さんが必要としているモノに注ぐということ。

よく制作の現場であると思うのですが。。。
実装まで行って。。。クライアントから「そんな機能いる？」とか、
実装も終盤に近づき「動くもの」が見えてからの「その機能あるんだったらこんな機能も入れてよ。」という追加仕様。。。

まぁ良くあることですが、結局これでは誰も幸せにはならないですよね。。。

なので。。。一番最初に「書き出す」ことを行い、
誰でも読めるように「母国語で書く」んです。重複しますが、

「望まれているモノの整理と限られた予算の中でできうることを最大限投入するため」

各々、職能やスキルには個人差があります。
ましてお客様は（特に最終決裁者に限って）IT系の知識が無い方だっています。
逆にお客様は自身の業務体系や、「何故作るのか？」という目的や目標を知っています。
お客様が遠い場合、制作者はこの当たり前の制作依頼者のニーズがぼやけていたりします。

だからこそ、きちんと見慣れた「紙」に出し、「母国語」で機能や動きをまとめた資料を渡すようにしています。

そこで、お互いの想いをすり合わせ、認識を共有することを行い、本当に必要な費用・機能・方法・期間などを出すようにしています。＾＾

僕自身は、このような資料を作成するときは、大抵「母親に画面を見ながら電話で説明している」シチュエーションを思い浮かべながら書いていたりします。＾＾；

そして、制作サイドとしては、急な仕様変更等を極力防ぎ、どうしようも無い仕様変更ならこうした「紙」と「共有した認識」を元に「追加費用」の請求、せめて「製作期間の追加」だけでも行えるように心がけて「面倒臭い」ことかもしれませんが、僕は「紙」に「母国語」で出すようにしています。＾＾