先日、ロボコンの設計をレビューする為に
以下の7つの質問をしてみました。
1)この設計(モデル)の一番良いところ(拘った点や、アピール点)
2)この設計(モデル)のメリット
3)この設計(モデル)デメリット
4)なぜ、そのデメリットを受け入れたか、回避方法はあるか
5)一番実現したかった事
6)これだけは避けたい事
7)いま、いちばん気持ち悪い点、事
この質問は、セットベース思考、セットベースアプローチとして、
「どのように考えていくのが良いのか」
を考えていた中で、
今回のレビュー依頼を受けて、直観的に生まれたものです。
回答するまでには、けっこう悩んだようですが、
その回答を見た感じでは、
そこそこ考えを整理出来るかも!?
って感じました。
昨年から、
インセプションデッキを使い始めていますが、
その設計版みたいな感じでしょうか。
インセプションデッキも各チーム毎にカスタムされてきて
定着しつつあるように感じています。
設計版もここから進化出来たら面白そう!
もちろん、セットベースに繋がるアプローチとして。
セットベース開発アプローチも少し更新しました。
2015年6月15日月曜日
2014年7月18日金曜日
複数案で考える
昨今、設計やコードが吟味されていないと感じる事が多いです。
吟味されていない原因を考えてみると、
1)どのように吟味して良いのかを知らない技術者が多い
2)論理量の肥大化と反比例して、短納期要求が多い
という事かと思います。
特に受託開発では、2のような状況を理由に
良いものを追及するモチベーションが低下しているような気がしています。
その長年の蓄積により、1となる?
もしくは、いろいろ諦めている間に、吟味しなくなる
のかもしれません。
要するに、
現場の声は、「そんな時間は無い!」
という事なのだろうと思います。
しかし、時間が無いからこそ、良いものを追及する事で
短期間で高品質が実現出来るのだろうと思います。
と、いうのはタテマエで、
良い物を追及する方が結果的に、ラク出来るので
最大限ラクする為に
どーするかを必死に考えているだけです...
そして、ラクする為に
最近お勧めしているのが、複数案を検討する事です。
複数案を検討し、それを選択する事で、
1)多角的な視点が生まれる
2)レビュー時にも、様々な意見が出る
3)漏れ抜け防止にもつながる
4)どうして、この設計にしたのか、このコードにしたのか が明確になる
5)デメリットが明確になる
インセプションデッキ同様に
やらない事や、デメリットを明確にする事って
重要だと思っています。
デメリットを明確にするには、
この複数案による選択はとても効果的かと思います。
デメリットが分かっていると、
そこで無理をしなくなる
分かっていないと
デメリットを無理矢理に、強引に力技で突破してしまい
そこから、どんどんコンセプトやアーキテクチャなどが崩れてしまう。
一度壊れると修正は難しく、どんどん汚くなり、
超巨大な関数が作成されてしまう など
ウィルスのように、あっという間に全てに感染していきます。
このような失敗をしない為に
複数案を検討し、選抜するアプローチ
如何でしょうか?
吟味されていない原因を考えてみると、
1)どのように吟味して良いのかを知らない技術者が多い
2)論理量の肥大化と反比例して、短納期要求が多い
という事かと思います。
特に受託開発では、2のような状況を理由に
良いものを追及するモチベーションが低下しているような気がしています。
その長年の蓄積により、1となる?
もしくは、いろいろ諦めている間に、吟味しなくなる
のかもしれません。
要するに、
現場の声は、「そんな時間は無い!」
という事なのだろうと思います。
しかし、時間が無いからこそ、良いものを追及する事で
短期間で高品質が実現出来るのだろうと思います。
と、いうのはタテマエで、
良い物を追及する方が結果的に、ラク出来るので
最大限ラクする為に
どーするかを必死に考えているだけです...
そして、ラクする為に
最近お勧めしているのが、複数案を検討する事です。
複数案を検討し、それを選択する事で、
1)多角的な視点が生まれる
2)レビュー時にも、様々な意見が出る
3)漏れ抜け防止にもつながる
4)どうして、この設計にしたのか、このコードにしたのか が明確になる
5)デメリットが明確になる
インセプションデッキ同様に
やらない事や、デメリットを明確にする事って
重要だと思っています。
デメリットを明確にするには、
この複数案による選択はとても効果的かと思います。
デメリットが分かっていると、
そこで無理をしなくなる
分かっていないと
デメリットを無理矢理に、強引に力技で突破してしまい
そこから、どんどんコンセプトやアーキテクチャなどが崩れてしまう。
一度壊れると修正は難しく、どんどん汚くなり、
超巨大な関数が作成されてしまう など
ウィルスのように、あっという間に全てに感染していきます。
このような失敗をしない為に
複数案を検討し、選抜するアプローチ
如何でしょうか?
ラベル:
AVASYS,
RibbonModel,
インセプションデッキ,
ソフトウェア開発,
リーン,
実装,
受託開発,
小さな改善,
設計
2014年6月6日金曜日
10の手強い質問
先日、インセプションデッキ使ってみました。
といっても、私は「使ってみて!」と お願いしただけですが....
受託開発でも営業的な立場の人を参加させれば
十分使える(効果が高い)と感じたので、
各プロジェクトリーダーにお願いしました。
ほとんど説明はせずに、自分達で調べて使ってみて!
と、お願いしただけです。
そして、その試行第一回目に参加
議論となったのは、
「やらないことリスト」 と
「トレードオフスライダー」
この2つと「夜も眠れなくなるような問題」
の3つは私のお気に入りです。
そのお気に入りの2つで議論となったのは
なんともワクワクしましたね。
やってみて、改めて
インセプションデッキではなく、
「10の手強い質問」
として、次回は、10の質問は以下のタイトルで試行してみようと思いました。
それは、可能な限り、開発で使わない言葉や
極端な言葉を使った質問にする方が
より多角的な視点でプロジェクトを捉えるキッカケになるような気がしたからです。
1 我々はなぜここにいるか?!
2 エレベータピッチ
3 目指すイメージ画像(絵)
4 やらないことリスト
5 ご近所さんを探せ
6 攻撃的な解決策を描く
7 夜も眠れなくなるような問題は?
8 セットとポイントを見極める
9 何を諦めるか
10 何がどれだけ必要か
受託開発に特化する面も多少ありますが、
今後も、このタイトルを模索していこうと思います。
といっても、私は「使ってみて!」と お願いしただけですが....
受託開発でも営業的な立場の人を参加させれば
十分使える(効果が高い)と感じたので、
各プロジェクトリーダーにお願いしました。
ほとんど説明はせずに、自分達で調べて使ってみて!
と、お願いしただけです。
そして、その試行第一回目に参加
議論となったのは、
「やらないことリスト」 と
「トレードオフスライダー」
この2つと「夜も眠れなくなるような問題」
の3つは私のお気に入りです。
そのお気に入りの2つで議論となったのは
なんともワクワクしましたね。
やってみて、改めて
インセプションデッキではなく、
「10の手強い質問」
として、次回は、10の質問は以下のタイトルで試行してみようと思いました。
それは、可能な限り、開発で使わない言葉や
極端な言葉を使った質問にする方が
より多角的な視点でプロジェクトを捉えるキッカケになるような気がしたからです。
1 我々はなぜここにいるか?!
2 エレベータピッチ
3 目指すイメージ画像(絵)
4 やらないことリスト
5 ご近所さんを探せ
6 攻撃的な解決策を描く
7 夜も眠れなくなるような問題は?
8 セットとポイントを見極める
9 何を諦めるか
10 何がどれだけ必要か
受託開発に特化する面も多少ありますが、
今後も、このタイトルを模索していこうと思います。
登録:
投稿 (Atom)