プログラミングをうまくやるための方法が提案されていました。
プログラミングに限らず、他の作業にも当てはまる汎用的な考え方だと思ったのでメモしておきます。
プログラミングで問題解決を目指す際に、コードを書いてシステムを構築するほかに必要となるプロセスについて、「世界をプログラム可能にする」という理念を掲げるソフトウェアプラットフォームLoBのエンジニアが解説しています。
元ネタはこちらのブログでした。
LoBのエンジニアであるラファエル・リー氏は、LoBが導入している「優れた形の問題解決ができるようになる3つのステップ」を紹介しています。
この枠組みに従うことで、プロジェクトは後戻りや中断が少なく、また労力や運用の負担も少なくなるため、成功する可能性が高くなるとのこと。
第1ステップ 理解
第1のステップを「理解する」ことだと述べ、ビジネスの成果として望むものは何か、今その結果を妨げているものは何か、ということを十分に理解することの重要性を説いています。事前の理解が十全に行われていないと、情報確認のために作業に割り込んで中断させてしまうことが頻繁に行われるほか、いざ完成させてみたものが問題を解決するものではないという結果に終わるおそれもあります。
一番最初にゴールを設定しておかないと、その後の作業が迷走しますね。
ゴールを設定するには、
- 何が必要なのか?
- 何が不要(障害)なのか?
を明確にしておく必要があります。
それが「理解」ってことですね?
第2ステップ 設計
第2のステップは「設計する」こと。
実際にプログラミングを始める前に、どのようなアプローチが可能で、それぞれの手段の利点、リスクおよびその軽減策は何か、という完成までの青写真を描くことが、プログラミング技術を純粋な実装から充実したクリエイティブな仕事へ変化させるカギだとリー氏は述べています。
通常、解決のためにとる手段はいくつか考えられ、最初に思いつくものが最善であるとは限りません。
そのため、あらかじめ設計図をデザインして手段を検討することが重要だそうです。
「理解」によってゴールを設定した後、次は「設計」によって完成形の見本(プロトタイプ、試作品)を描きます。
事前に細部まで検討しておくことで、曖昧さがなくなり、具体性が増してきます。
設計の段階で曖昧さが残っていると、次の構築(作成)の段階で、「ここはどうしたらいいのかな?」と悩む機会が増えてしまいます。
「あーでもない、こーでもない」と考え込むようになると、作業が面倒くさくなってきて、やる気が失われていきます。
逆に、悩むことなくスパスパと作っていけたら、
「うまく作れたな~!」「自分は何てスゴイんだろう!」
と自己効力感を実感しながら、自己満足に浸れます。
充実したクリエイティブな仕事って、極端に言えば「自画自賛」みたいに、自分で自分の作品に満足できることが必要条件だと思います。
他人がいくら作品を褒めてくれても、自分で納得できていなければ、深い充実感は得られないですよね?
第3ステップ 構築
抱えている問題を理解し、どのような手段をとるべきか設計できたら、実際に「構築する」段階に入ります。
このステップが最も労力を要すると考えがちですが、リー氏は「すでに難しい設計上の決定を下していれば、コードを書くことは最も簡単な部分となります。またそれはスピーディーであり教育的であり、また楽しいものでもあります」と述べています。
設計がしっかりできていて、迷う余地が少なければ、制作の段階はスムーズに進むと思います。
UDB
3つのステップは、それぞれの頭文字(Understand、Design、Build)を取って、「UDB」と呼ばれていました。
それぞれのステップに問題があると、どんな結果になるかが示されています。
この図を日本語に翻訳してみると、以下のような図になります。(少し表記を変えてあります。)
今の自分を見直すと、「設計」の段階が不十分なパターンが多かったです。(反省)
UDBの3ステップは、「デザイン思考」や「デザインスプリント」と発想は同じで、もっとシンプルに表現したものだと感じました。
デザインスプリント
「デザインスプリント」とは、5日間という短期間で、商品やサービスを開発する手法です。
- 理解
- 発散
- 決定
- 試作
- 検証
という5つのステップで作業を進めます。
実際にデザインスプリントをやってみると、短期間にたくさんの作業を詰め込んでいて、結構大変です。
特に、動く試作品を作るのは1日では無理な場合が多いですw
デザインスプリントをもうちょっと緩い感じでやるのが、UDBの3ステップってかんじでしょうか?
デザインスプリントとUDB3ステップの両方から良い所取りをして、作品の制作作業を改善していきたいと思います。