Skip to content

Vol.227

Kota Furusawa

Bad Work Is Always Your Fault by Mike Monteiro Jump to heading

自分の仕事に責任をもちなさい Jump to heading

とあるデザイナから送られてきた仕事に関わる悩みに対して、デザイナーとはどのように仕事をするべきかを説く。Mike氏は、デザイナであれば、企業の社員としてどう働くかよりも、一人のデザイナーとしてデザインに対して誠実に向き合って行くことの重要性を説く。自分が作るものにはすべてに責任がつき、それに責任を持っていくことで作り上げられる評判というのは、非常に強固なものになると、アドバイスする。

パイロットの一番の責任が乗客に対してあるように、デザイナーであるあなたの責任は、製品を利用する人々に対してあります。

The Silent Meeting Manifesto v1: Making meeting suck a little less by David Gasca Jump to heading

サイレントミーティングマニフェスト v1: 無駄なミーティングを少なくする Jump to heading

無駄な会議を減らすための手法として サイレントミーティング を提案する。サイレントミーティングでは以下の4つの基本を守る。

  1. 議題を用意し、ファシリテーターを選ぶ
    1. 会議の目標やファシリテーター、議事録役を事前に決めておく
  2. テーブルリードを作成する
    1. 会議で使用する資料を作成する
  3. テーブルリードを読み、コメントする
    1. 会議が始まったら、決められた時間資料を読み込む。質問やコメントがある場合は資料にコメントを残す
  4. ファシリテーターがコメントをまとめ、議論を導く
    1. コメントから重要なトピックをまとめ、議論を進めていく

Design edge cases and where to find them by Tanner Christensen Jump to heading

エッジケースのデザインとどのようにそれらを見つけるか Jump to heading

デザインにおけるエッジケースを事前に予測し、それに対応するためにはどのようなことを行えばよいかについて解説する。すべてのエッジケースを予測するのは難しいが、極端なスケールを想定したり、技術的なエッジケースを想定することで、エッジケースが存在する可能性に気づくことができる。

Creating a Design System: Our Approach and Experiences by Adam Zielonko Jump to heading

この記事では、デザインシステムを作成するにあたっての識見を紹介していく。具体的には、どのようにデザインシステムを始めればよいのか、どのようにデザインライブラリを作るのか、どのようにドキュメントを構造化させていけばよいのかなどについて解説していく。

Programmer Test Principles by Kent Beck Jump to heading

テストを書く前に知っておきたい、テストの原則を紹介。

  • プログラマを待たせる時間を最小化する
  • 確実に実行できる
  • 展開性が予測できる
  • 振る舞いの変更に対応する
  • 構造の変更に対応しない
  • 書くのが簡単
  • 読むのが簡単
  • 変更するのが簡単

Books Jump to heading

Shape Up by Ryan Singer Jump to heading

ウォーターフォールでも、アジャイルでも、スクラムでもない、Basecamp内で行われているShape Upと呼ばれる開発手法がある。そのメソッドを1冊の本にまとめWebで公開している。Basecampが長年に渡り、どのように高品質なプロダクトを作り続けているのかについて、詳しく解説する。

第一部: プロジェクトに対して行う事前作業について
第二部: どのように優先度をつけるか
第三部: チームがどのようにして何をすべきか、どのように時間通りにプロジェクトを完成させるか

In Brief Jump to heading