ヒビノログ

プロダクトオーナー目線からのスクラムについての解説本。
内容が簡潔であっという間に読めてしまいます。

「アジャイルとかスクラムについて一通りわかったつもりだけど、じゃあ実際にどうすれば？」というようなプロダクトオーナーが読むとドンピシャの内容では、と思う。POとしての「考え方」に焦点を当てた内容になっているので、いろいろなプロジェクトに幅広く応用できるヒントが詰まっている。
反面、これをやればどんなプロジェクトでもOKというような手法は紹介されていない。「え、載ってないの？」と言うかもしれないけど、そもそもすべてのプロジェクトが必ずうまく行く手法なんてものは無く、それはWFでもアジャイルでも同じこと。ただ、書籍の中で著者のローマン・ピヒラーさんは「チームと共働せよ」と繰り返し言っている。少なくともPOはプロジェクトの最初に要件を出したら後は進捗の管理と成果の確認だけすればいい、というような存在ではないということ。常に、開発チームと向き合い、プロジェクトが進む中で発生する問題点と向き合い、顧客のフィードバックと向き合う。そして、それをそのまま聞き入れたり盛り込んだりするのではなく、自らも含め、ともに考えながら、プロジェクトを進めていくことが大事。

この書籍の特徴としてもう一つ、各章に出てくる「よくある間違い」という項がよくできている。
「ビジョンが無い」「POが働き過ぎ」「POが遠隔地にいる」「大きいことは美しい(という勘違い)」「チームに要件を押し付ける」「受け身である」「ビックバンリリース（をしたがる）」「持続不可能なペース（を要求する）」など、（アジャイルに関係なく）よく見かける話が著者本人の実体験やアドバイスも交えて書かれていて、わかりやすく、参考になる。

とあるスマホサイト開発のプロジェクトで嵌った問題。

要求としては、そのサイト内でユーザーが閲覧したページの履歴や、検索の履歴、サイトが提供する「チェック」機能を使ってユーザーがチェックしたページの情報、そのチェックに対して訪問者が入れたコメント、といった内容を、すべてブラウザのCookieに保存させたい、というものでした（そこまで使うならローカルストレージとか、会員登録制にして会員情報としてDBに突っ込めばいいのに、という議論はあるんですが）。

で、この要求についてAndroidの標準ブラウザでは特に問題なくクリアできたんですが、iPhoneのSafariだと、あるCookieサイズを超えると保存ができなかったり、そのサイズまでCookieが保存されてる状態で、あるCookieを削除しようとしてもできなかったり、指定したCookieとは別のものが削除されたり、という現象が起きました。

RFC 2965で定義されているCookieのサイズや数に関する制限内容として、

（前略）一般使用のユーザエージェントは個別に以下の最小限の容量を提供すべきであるが、同時にすべてが必要と言うわけではない。
* 最低 300 のクッキー
* 一つのクッキー毎に最低 4096 バイト
* ユニークなホストあるいはドメイン名毎に最低 20 のクッキー
特定の目的あるいは容量が制限されたデバイスのために作られたユーザエージェントは、ユーザがセッションに基づいたオリジンサーバと相互作用する事を保証するために、最低 4096 バイトの 20 のクッキーを提供すべきである。（後略）

とあり、今回の要件は上記の範囲内なんですが、Safariに関してはクッキーの数こそ20以上登録できるものの１つのドメインのクッキー容量の合計が4096バイトを超えて登録できない！　つまり上記のRFCの2つめと3つめを同時に満たしてないんです。

で、Appleの開発者フォーラムで調べたところ同じ問題を指摘してる人が。
https://discussions.apple.com/message/18820657#18820657

PC版のSafariも同じらしい。。。

開発の方はCookieに保存する内容を見直して、さらに要件を変更してもらって切り抜けましたが、iPhoneやiPadはPCサイトも普通に見られるので、いろいろCookieに突っ込んで保存しておく系のサイトを作ってる場合はこのあたりも確認しておく必要がありそう。

はじめての電子書籍！
ふつうの「組織」に共通するであろう課題と、その解決について道筋を示してくれる本。短めの話なのでサクッと読めてしまった。

人間は共感したい、されたい生き物なのだと思う。

こんな風に言ったらわかってもらえた、協力してもらえた
こう言ったけど反応が薄かった
言ったけど忘れられてしまった
こうしたらどうだったんだろう

誰にでもこういう経験はあると思う。
そしてそんな経験を通じて、なんとなくぼんやりと思ったことをズバリと文章にしてもらった感じがしてとてもありがたかった。

同じ方法、話し方でも通じる人とそうでない人がいる。それで、変えようと思ったけど途中で頓挫してしまったり。もちろん変える側に強い意志が求められるのだと思うけど、こういう時にはげましてくれる人がいると大きい。以前、楽天のカンファレンスだったかなぁ、よしおかさん（@hyoshiok）が「楽天の芸風を変えたい」と言っていて、来場者の「芸風を変えるというのは、具体的にはどのようにするのか」という問いに対して「励ます」と答えていて、あの頃はあまりピンときていないところがあったのだけど、いやー、それってホント心強いことだよなぁと本書を読みながら思った。

みんながそれぞれ自由に喜びを見つけ、表現し、好きに生きることができる世の中だからこそ、どうやって気持ちを同じ方向に向けるか、そしてマネジメントしていくか。そのハンドブック的な存在として、最適な本だと思います、

CSS Nite back2basic #8「Fireworks」に行ってきました。
講師は山口有由希さん。

出席者は制作とかデザイナの方が多かったんだろうな。スーツ姿はゼロだったし、女子率50%くらいだったし、技術系の勉強会とはちょっと雰囲気違いました。始まった直後にワークショップがあったのですが、「某航空会社の集客率（搭乗率）を上げ、売り上げをアップさせるためのバナー広告デザインを考えよう」というもので、なかなかパッとイメージができなかったのですよ。「うわぁ、制作の方々はこういうオーダーと日々格闘しているのだよなぁ」となんとも当たり前なことに改めて気付かされたりもして。

山口さんは個人で「Fireworksマニア」というサイトを持っていて、よく参考にさせてもらっているのですが、非デザイナなぼくでさえ「これなら自分でもできそう」というアイデアを紹介してくれるんですよ。今回のデモでもそんなTipsが満載で、非常に参考になりました。開発者同士だと「ペアプログラミング」がありますが、デザインにおいても、実際にアプリを操作してデザインを作り上げていくところを見るのはいろいろと勉強になりますねー。これからもFireworks使っていろいろデザインしたいと思います。

執筆された本にサインいただきました。ありがとうございましたっ

「エンジニアのためのアイコン作成勉強会」をやりました。
参加いただいた皆さん、ありがとうございました。

海外から来日して活躍されているCookpadの方や、通販サイトを作られている方、個人でiPhoneやAndroidアプリを作られている方など、いろんな方々が集まった会になり、とても嬉しく思いました。

Keep
•準備を進める中で、自分の頭の中を少しは整理できた
•参加された方がどんな部分で詰まっているか知ることができた

Problem
•ゴールの定義が曖昧だったかもしれない
•実例が少なかった
•自社の会議室でやったのだが、前の会議が長引いて参加者をお待たせしてしまった

Try
•需要がありそうなら懲りずにまた開催してみる
•そのときには操作デモをもう少し増やしてみる

使用したスライドをアップしておきます。（背景などを少し変えました）

【補足：スライドに引用させていだいたもの】
•ペーパースーパーマリオ – nintendo.co.jp
•icloudのアイコンに隠れた美しさの法則。 – DESIGN ARCHIVE
•色のいろいろー色彩調和 – キレイのためのカラー情報京都より