共通認識を深めるデザインの要素分解
デザインを決める5つの要素誰もが『自分の正しさ』『良さ』といった価値観を抱きながら、目指すゴールに向かって働いています。私にしても「こうありたい」というミッションがあり、それを達成するための活動をしています。 それぞれが良かれと思って活動していたとしても、チームメンバー全員が同じ価値感をもっているとは限りませんし、優先順位も異なります。私たちデザイナーが抱える価値の重さを、他人が同じように感じているわけではありません。私はそれを「デザインの理解が足りない」ではなく、「価値観の重きの置き方が異なっている」と捉えるようにしています。 デザインフィードバックが難しい理由のひとつは、どう考えても正しいと言い切れる成果物が作れない（説明できない）ところ。ひとりが「良い」と評価したデザインが、他の人に尋ねると「そうでもない」と言う場合があります。人によって意見が変わる場合もあれば、タイミングやコンテキ
うまくフィードバックをもらうためのTips - Konifar's ZATSU
春だ。初めてソフトウェアエンジニアとして働き始めた頃、いつも機能のレビューで突っ込まれまくって涙目になっていたのを思い出した。今ならそんなことにはならないので、意識していることを雑にまとめておこうと思う。 今の状況を最初に伝える ざっと考えた仕様や、とりあえず作ってみたプロトタイプを見てもらおうとしただけなのに、めちゃくちゃ細かい部分まで突っ込まれて「あー今そういう感じじゃないのになぁぐぬぬぬ」となったことはないだろうか。これを防ぐには、最初に今の状況を伝えて認識を合わせておくとよい。 「先に今の状況を伝えておくと、まだ完成度は20%くらいです」 「まだ叩き台なのでアラも多いと思うんですがとりあえずざっと作って持ってきました」 みたいな一言があるだけでもだいぶ違う。大事なのは、これを最初の説明で自分から言うことだ。意見をもらい出すと相手も白熱してきてなかなか言うタイミングが難しくなることが
内なる秩序の探求〜テスト駆動開発をやめて、なお残すべき習慣とは(7)
はじめに前回は、外側のテストループについて何を作ればよいかの探求について解説しました。今回は、実際に「どう作ればよいか」について、コードや設計の内側の秩序の探求について解説します。 TDDの肝は、動作するきれいなコードを目標に、テスト書いて、 実装して、学んで、リファクタリングして… を小さく繰り返し、内なるコードや設計の秩序化するステップを踏み続けることにあります。では、「動作するきれいなコード」と呼ばれる目指すべき場所は何を頼りに向かえば良いのでしょうか？ プログラミングにはコードや設計の秩序化を図るための定石が幾つか知られています。例えば、UNIXの設計判断（例：一つのプログラムには一つのことをうまくやらせる）、メタファ、名前重要、DRY原則、SOLID原則、KISSの法則、コマンドクエリの分離原則、契約による設計、オブジェクト指向のイディオム、関数型のイディオム、各種の言語やフレー
フィードバックをイチから学び直す〜テスト駆動開発をやめて、なお残すべき習慣とは(4)
前回、テストの４象限を紹介しました。今回からフィードバックについては、複数に分けて解説します。1回目は、フィードバックの基本のキから解説します。次回に実戦テスト駆動を参考に多重のフィードバックを解説する予定です。 フィードバックのおさらい”フィードバック”という言葉は、意味が多義的に使われており、誤解を生じやすいです。Wikipediaのフィードバックを下記に引用します。 フィードバック（feedback）とは、もともと「帰還」と訳され、ある系の出力（結果）を入力（原因）側に戻す操作のこと。古くは調速機（ガバナ）の仕組み[1]が、意識的な利用は1927年のw:Harold Stephen Blackによる負帰還増幅回路の発明に始まり、サイバネティックスによって広められた。https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A3%E3%83%BC%E3
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
