-
- いいね！0
yoh nakamura
@yohhatu
「10. 手のかからない社員であれ」最後で笑ってしまった。確かにそうなんだろうけど。第10章 上から降ってくるものをうまくさばく « Inspired日本語版 http://t.co/Z1bYVUX9
2012-08-13 08:22:08
yoh nakamura
@yohhatu
「飛ぶ前にはよく観察したほうがいい。難しいのは、この観察を、すばやく、簡略化した形で、それでいながら効果的にやることである。」これに近いことをやっていた(る)人を2人知ってる
2012-08-13 08:36:39
yoh nakamura
@yohhatu
「解決すべき問題とソリューションを切り離さずにいっしょにして考えてしまうことだ。そして、そのソリューションで行き詰まると、製品化そのものまであきらめてしまう。これは、「汚れた風呂水と一緒に赤ちゃんを捨ててしまう」、と言われる古典的な失敗例である」あぁよく陥るわ
2012-08-13 08:37:41
yoh nakamura
@yohhatu
「もし、好むと好まざるとにかかわらず、製品化することにしたからさっさと製品開発にとりかかれ、とCEO から言われたら、何をすべきだろう？」この最後の段落もニヤリとする 第11章 製品の市場性評価 « Inspired日本語版 http://t.co/8RkXZ0hc
2012-08-13 08:42:55
yoh nakamura
@yohhatu
「ソフトウェア製品を開発するプロジェクトは、まったく別の 2つの段階に分けることができる。作るべきものを決める (正しい製品を定義する) 段階と、それを作る (正しくその製品を作り上げる) 段階である」定義しながら作っていることも多いよね。
2012-08-13 08:44:53
yoh nakamura
@yohhatu
「作る時には脇目もふらず集中する」ことが生産量やその出来映えに影響を与えるかってことだと思う。とは言うても、色々変更は入るものだから(これは0にはなかなかできない)、短い期間で区切ってフィードバックを得て、調整するんだと思う。
2012-08-13 08:47:05
yoh nakamura
@yohhatu
「あるバージョンがエンジニアリングの段階に入ったら、発案力は次のバージョンに振り向けよう。」1回リリースして終わり！な場合、なかなかこれはできないよなぁ。だからあれもこれも入れ込もうとして、開発チームは疲弊していくわけで。
2012-08-13 08:51:47
yoh nakamura
@yohhatu
Product Principles(製品理念)てのも良い言葉。自分達のこれを出せるには1時間の会議とかでは無理だと思う。それこそ長い年月で積み重なったり、時には合宿して缶詰になったりして、出てくるものだと思う。
2012-08-13 08:54:12
yoh nakamura
@yohhatu
インセプションデッキにも通じるものがあると思う 第13章 製品理念 « Inspired日本語版 http://t.co/NYgdPDmG
2012-08-13 08:56:02
yoh nakamura
@yohhatu
「今まさに問題となっていることに取り組みながら話し合えるユーザーや顧客が何人かいてくれる。」ファンでも良いけど、ファンでなくても「純粋に自分の問題を解決したいと思う」ユーザかな。
2012-08-13 09:07:17
yoh nakamura
@yohhatu
「モニターの募集は、やる価値のある仕事に時間を費やしているのかどうかを実際に確かめる最初の試金石にもなる。」確かに。誰も「試しても良いかも(そのために時間を使って)」と思わないものを出しても難しいと思う。
2012-08-13 09:08:15
yoh nakamura
@yohhatu
「それぞれの種類のユーザーのための機能を何か入れようと思ってしまいがちだ。が、また繰り返すが、それだと混乱して収拾がつかなくなるだけだ。」○○部長特別機能なんてのも最たるものだと思う
2012-08-13 09:40:36
yoh nakamura
@yohhatu
「ペルソナを創れば、現実のターゲットユーザーと顔を合わせて話さなくてもいいとか、現実のユーザーでデザインをテストしなくて大丈夫、ということにはならないのだ。」あぁこれはやってしまいそう。安心してしまって。
2012-08-13 09:42:13
yoh nakamura
@yohhatu
ペルソナはもっと色々勉強していきたいなぁ。第17章 プロダクトマネジメントのためのペルソナ « Inspired日本語版 http://t.co/PamvsOqg
2012-08-13 09:42:40
yoh nakamura
@yohhatu
「ほとんどの仕様書は、書くのに時間がかかり過ぎていて、めったに読んでもらえないし、必要なことが詳しく書かれていないし、難しい問題点を取り上げることもないし、問題点に取り組むのに必要な重要情報も書かれていない。」滅多切りやな。「なぜこの仕様なのか？」が無い時点で価値は半減すると思う
2012-08-13 09:47:13
yoh nakamura
@yohhatu
「さらにまずいのは、仕様書が存在するというだけで、すべてはうまく進んでいるという間違ったサインを経営陣や製品開発チームに与えることになりやすい、という点だ。」仕様書だけできてもユーザにはなに1つ価値を届けていないわけで。
2012-08-13 09:47:42
yoh nakamura
@yohhatu
「製品仕様の大半は、ハイフィデリティプロトタイプとするべきだ。これは、機能要求、情報アーキテクチャ、インタラクションデザイン、ユーザーエクスペリエンスのビジュアルデザインなどを表現するものなのだ。」確かに良いツールは多くなっているし、少なくとも文章だけで表現するよりは早く確実。
2012-08-13 09:51:04
yoh nakamura
@yohhatu
業務向けのシステムの場合、UIも大事だけど、業務ロジックの方がより大きな比率になるだろうから、そこは仕様書という形で埋めないと仕方ないのかなぁ。むしろ見た目にこだわらない発注者はまだまだ多いんかな
2012-08-13 09:58:01
yoh nakamura
@yohhatu
ただ全てをそれでは表現できないから、そこを素早く補完するツールなどがあったらもっと良いかもなぁ。最終的にはプロトタイプに書き込めるような感じで。
2012-08-13 09:51:43
yoh nakamura
@yohhatu
「心理的な理由もある。いったん実装の態勢になってしまうと、それがしっかり根を下ろしてしまい、前に戻る気にならなくなるのだ」これも分かる。この文脈とは違うけど、機能を削るってのは難しいと思う。
2012-08-13 10:48:04
yoh nakamura
@yohhatu
「エンジニアが実装を始める前に、製品要求とユーザーエクスペリエンスの設計をいっしょにやってしまうように強く勧めているが、この最初の段階からエンジニアリングチームのだれかに参加してもらう必要はある」最近の開発でこれは強く思った。これが弱かったから色々と大変だったし。
2012-08-13 10:51:43
yoh nakamura
@yohhatu
こういうMTGにエンジニアを引っ張り出そうとする際にどうしても目先の作業の進捗が気になる(本人もそうだろうし)。ただそこでそっちを優先すると後々手戻りになったり、良いモノを作るチャンスが減ってしまうような気がする。そこをうまくバランスを取るのがリーダーの役目でもあると思う。
2012-08-13 10:53:28
yoh nakamura
@yohhatu
「仕様書からは、P1、P2、P3 というような注釈は全部外して、今あるものがこの製品のすべてだということを、製品開発チームのみんなに言い切ってほしい。」この辺はPBLの"優先度"でなくて、ただの"順番"という話に近いのかな？
2012-08-13 10:59:23
yoh nakamura
@yohhatu
「与えられた時間の中では克服できない、とエンジニアリングチームが判断するような障害があるなら、開発が進んでしまってから、つまり、時間とお金をつぎ込んでしまった後ではなくて、今、それを知ることが重要なのだ。」やってみないと分からないこともあるけど、当たりは付けれるように。
2012-08-13 11:02:42
yoh nakamura
@yohhatu
「今時の経営陣の多くは、家の縮尺模型を作るのが実際に家を建てるのとは違うように、シミュレーション用の試作品を作ることは実際の製品を作り上げることとはまったく違う作業である、と理解している。」請負などの場合のお客様もそうならもっと良いと思う
2012-08-13 11:05:15