『Fearless Change』を読んで
はじめに
いま、自分は所属している組織にアイデアを広める活動を行っています。
活動をしていて、方向性をたまに見失ったり、本当に正しいのか不安になったり、どうやって周りを巻き込むかなど、色々と悩むことがあります。それぞれに対して自分なりに考えて行動してみるものの、行動の支えがほしいなあと思っていました。そんなある日、同僚や Regional Scrum Gathering Tokyo でお会いした人から紹介されたのが 『Fearless Change』 でした。
読み終えての、ささった本文の言葉や感想を書いていきます。
ささった本文の言葉
- 「チェンジエージェント」かっこいい
- 「学習する組織」っていい言葉
- 変化にはそのアイデアに共感してくれる仲間づくりは不可欠
- 心や感情が先で、ロジックはそのあと。そういう研究でも出てる。何かを決めるときもそうだし、人に伝える時もそう
- 強制的にトップダウンから新しいアイデアを導入しろといわれたら、一時期は従うかもしれないが、長期的には反発や抵抗が待っていることが多い
- 著者の経験上、変化がもっとも効果的にあらわれるのは、ボトムアップからはじまり、現場および上位レベルのマネジメントから適切な支援が得られたケース
- 変化したいドメインを先に考え、守り、背中を押し続けること
- エバンジェリストになることが変化の最初である。自分のやることの大切さを信じ続けることが大事
- 変化に抵抗のあるドメインにアイデアを広める試みの一つに、少数の人数で短い期間でやってもらい、なじまなければ取りやめることがある
- もともとの対象としていたドメインの変化が終わったとしても、対象としていなかったドメインをさらに巻き込むことで相乗されさらなる効果が生まれやすい
感想
活動をしていて思ったようにうまくいかない時は落ち込むのですが、この本を読んで励まされたり、新しい選択肢に気づけたりしました。
アイデアを広めるのがメインテーマの本ですが、ここに書かれていることは、アイデアを広めること以外にも物事を円滑に進めるうえで大事なことばかりだなあと感じました。
勇気と知恵をくれる、素敵な本です :)
『ザ・ゴール コミック版』を読んで
問題解決の考え方の一つに TOC というものがあるのですが、どういったものか知りませんでした。知り合いのコンサルの方に TOC を学びはじめる取っ付きやすい本がないか聞いたら、『ザ・ゴール コミック版』を教えてもらいました。
オリジナルの『ザ・ゴール』は小説で長いらしいですがコミック版は 1時間ほどでさくっと読めました。
TOC の考えの段取りは、
- step1. 制約を見つける
- step2. 制約をどう活用するか決める
- step3. step2 の決定をその制約以外すべてに従わせる
- step4. 制約の能力を高める
- step5. 制約が解消したら step1 に戻る
なのですが、漫画でその段取りをどう活用するかが描かれていました。
本編は製造の現場にどう TOC を適用するかという話ですが、スマホアプリの開発におけるプロジェクトの進め方など、様々な問題領域に応用できる考え方だなと思いました。プロセスやコミュニケーションを最適化するための視点を増やしたい方にオススメです。
スマホAPI の Controller 実装でよくつかう HTTPステータスコードの意図別まとめ
はじめに
Rails でスマートフォン向けの API をつくっている時にどの HTTPステータスコードを返すか、自分なりの判断基準をまとめてみました。
Controller を実装している時によく返すステータスコードをイメージしています。
200 :ok
- 以下が正常に行われた場合
- GET系。action: index, show
- UPDATE系。action: update
- DELETE系。action: destroy
201 :created
- 以下が正常に行われた場合
- POST系。action: create
400 :bad_request (2015/04/15 更新)
- 必要なパラメータが存在しない場合
- 例: 緯度と経度はセットでほしい
- パラメータが範囲を超えている場合
- 例: 検索条件のパラメータの範囲がオーバーしている
- クライアントを普通に使っていれば起こりえないリクエストを受け取ったとき
401 :unauthorized
403 :forbidden (2015/08/06 更新)
- ユーザが退会や BANされている状態で認証を試みた場合
404 :not_found
409 :conflict (2015/08/06 更新)
- リソースに矛盾がおきそうな場合
422 :unprocessable_entity
- バリデーションエラーの場合
- http://stackoverflow.com/questions/15225325/is-http-status-422-appropriate-for-records-that-fail-uniqueness-validation
- http://tools.ietf.org/html/rfc4918#section-11.2
- "the syntax of the request entity is correct (snip) but was unable to process the contained instructions"
さいごに
だいたいのケースは上記で間に合っている気がしてます。
他にもこういうステータスコード使うよ、このステータスコードはこういうシーンでも使ってるよ、それを表現するにはもっといいステータスコードがあるよ、などありましたら教えてください :)
参考
参考: Restful Webサービス
おまけ: ステータスコードの数字と意味/シンボルの見方
rails console> pp Rack::Utils::HTTP_STATUS_CODES => {100=>"Continue", 101=>"Switching Protocols", 102=>"Processing", 200=>"OK", 201=>"Created", 202=>"Accepted", ... 511=>"Network Authentication Required"}
rails console> pp Rack::Utils::SYMBOL_TO_STATUS_CODE => {:continue=>100, :switching_protocols=>101, :processing=>102, :ok=>200, :created=>201, :accepted=>202, ... :network_authentication_required=>511}
コードに数字が書いてあると意味の変換に脳内で時間がかかるので Symbol を使うのが好みです。