2014年8月29日金曜日

出力しよう!

今年もSWEST16に参加しています。

今年で3年目になりますが、
3度目でもこのような場は貴重だなぁ とつくづく実感します。

オープニングセッション、夜の分科会
と参加し、
「分ける」と「分かる」と「分かち合う」を再考する事が出来ました。

最初の難関である「分ける」為には、
言うまでもありませんが、考える必要があります。

以前も多角的な視点で考える事で
「似て非なるものを分ける」といった内容で投稿しましたが、
この多角的な視点を持つ事が難しいですよね。

その為に具体的に何をするか!?

それは「出力」ではないかと思っています。

文章でも絵でも 出力する事で、

1)自身の考えが整理出来る
 これは恐らく、みなさんも実感した経験があると思います。

2)もう一人の自分になれる
 出力したものを改めて見ると、もう一人の自分が必ず現れませんか?!
 「けっこーいけてるじゃん!」とか「ぜんぜんダメじゃん!」
 というような、もう一人の自分が突然出現しませんか?!

3)分かっていない事が分かる
 いざ、出力しようとすると、出力出来ない!
 という事ありますよね。
 つまり、”分かっていない” という事ですよね。

4)更に掘り下げられる
 出力すると、具体的に何をもっと掘り下げる必要があるのか
 と逆に何が不要なのか
 といった事が明確になりますよね。


などなど、つまるところ、整理されるのだと思いますが、
出力するだけでも、こんなにも分かる事がある
と改めて感じた次第です。

なので、この出力を「早め」に実施する事が重要なのだと思います。
自分の状態を知る為にも、まず現段階の考えを出力してみる。

そこから改善していく。

つまり、リボンモデルですね!
小さな改善の繰り返し!!

考えるだけでなく、出力して、小さな改善を繰り返す事で、
「分ける」事が可能となり、「分かる」と「分かち合う」となります。

と、いう事で、出力しましょう!


2014年8月21日木曜日

実装時は、複数案を意識せずに考えている?!

前回は、設計において複数案を考える
でした。

今回は、実装時にも有効
という事ではなく、
実装時には意外と、複数案考えていませんか?!

設計時よりも、実装時は、比較的複数案を検討し、
ベスト?なコードを選択している事は多いのでは無いでしょうか?


例えば、デバッグ時です。

原因は分かっても、さてどう対策(修正)するか
といった場面は誰しも体験しているかと思います。

この場合、複数案を検討している事が多いのではないでしょうか?
また、このような場面ではペアプロ(ペアで作業)しているケースも多いかと思います。


例えば、複雑な処理を実装する時です。

タイミングや分岐条件が複雑な場合など
どう実装すれば分かり易いか など
こっちが良いか、あっちが良いか などなど
詳細設計まで落ちていても、
細かいところでは、実装案を複数考えている事がある気がしています。


などなど、意外と
実装時には、あれこれ考えている気がします。

実は、設計でも複数案考えているのかも!?
と思ったりもします。

設計時にもいろいろ考えてはいますが、
コードのように実装イメージが明確ではなく
曖昧な状態な気がしています。

なので、設計時は、
複数案をある程度まで形にする必要がある気がしています。

設計の場合は、形に(アウトプット)して見直す事で、
メリット・デメリットを明確にする
という事が必要なのだと思います。

実装の場合は、実装イメージそのものがアウトプット(最終形)になるので、
出力する前に解決可能となり、
複数案を考えている事が分かり難いだけで、
複数案考えているケースが多い!

と思います。




2014年8月1日金曜日

続・複数案で考える

前回の続きとなりますが、

設計では複数案を検討するのは
とても有効だと思っています。

上流設計であればあるほど効果は高いかと

特に重要なアーキテクチャー設計では必須!?

複数案を検討し、メリット、デメリットを比較し
何を、どんな理由で選抜するか

といった事が明確になる

と、いうより、
複数案を検討し、メリット、デメリットを比較し
何を、どんな理由で選抜したか

を明確にする必要がある

という事だと思うのですが、

初期の段階で、これを明確にしないと、
その後の工程で
”どうすべきか”が時間と共に徐々にブレてきます。

このブレが大きくなると、
アーキテクチャーのメリットが最大限に生かされず、
デメリットを克服出来ない

という結果となり、
当初に検討していたアーキテクチャーは
影も形もなくなってしまいます。


明確にしてもブレてしまう問題はありますが、
こちらの対策は、また今度。

まずは、明確にする事が大事かと思います。

少人数のプロジェクトであれば、
明確にするだけで、各自がメリット、デメリットを生かす為に
更に工夫していきます。
そうなると、アーキテクチャーは、より強固なものとなります。

もしかすると、こういう状態にならないと、
アーキテクチャーは維持出来ないのかもしれませんね.....