狩野モデル

というのがあるらしい。
かのうモデル。

狩野は、企業の製品やサービスのあらゆる要素を改善することが顧客満足度の向上につながるという従来の通説に異を唱えた。顧客の目には製品やサービスの要素すべてが等しく映っておらず、ある要素は他と比べてより高い顧客ロイヤリティを創出できると狩野は主張した。

つまり弊社みたいに部分最適を奨励するアホはなんでもかんでも改善改善、コスト削減コスト削減とやって全体の品質が落ちるけど、実際は顧客は全部を見て評価してるわけじゃないから、選択と集中が重要であるという考え方であり



弊社でそんなことを言ったらブチのめされる事案であることは言うまでもないｗｗｗ

ん

品質を魅力的品質要素（充足されれば満足、不充足でも仕方がない）、一元的品質要素（充足されれば満足、不充足で不満）及び当たり前品質要素（充足されれば当たり前、不充足で不満）に考え、ネガティブな顧客情報を集めた改良型製品ばかりにならないように定義している（これは狩野モデルと呼ばれている。以下に詳細を示す[1]参照）。

これってハーズバーグの二要因論っぽい。
当たり前品質要素が衛生要因で魅力的品質要素が動機づけ要因。

一元的品質要素：それが充足されれば満足、不充足であれば不満を引き起こす品質要素。

世間ではこれを要件と呼ぶｗ
これは冗長じゃないかしらね・・・
でなけれりゃいったいなんの製品を作っているのかなにがなにやらだろうし。

ふむ

オリーブネット株式会社
こんな感じでターゲット層が明確でない場合のマトリクス化には役にたつかもね。
まぁサービスが動き出してからいまさらそんなんやってんのは遅いよっていうことにはあるけど、基礎の基礎すらできてない弊社みたいな企業はそこそこあるだろうからコンサル(混沌とすると去る人々)が導入しやすいツールではあるかもしれん。

まぁ

アジャイル開発による進捗管理でもっとも高速なのが付箋を手書きしてホワイトボードに張り出すことであって、
低速で鈍くさくて社会的にもたいしたことない仕事だったらレッドまいんちゃん（かっこわらい）でやってもいいと思うよというスタンス。

ふむ

市場環境変化が早い現在、ソフトウェア開発においてもスピードや柔軟性が求められている。だが、価値あるイノベーションを起こすためには、アジャイルやDevOpsといった方法論以前に大切なことがある。

価値あるイノベーションなるものを志向することがどれほど価値があることなのか・・・

うーむ。

　野中氏が提唱した「スクラム」は、1990年代、ジェフ・サザーランド氏らによりソフトウェア開発に応用され、アジャイル開発の実践手法として広く普及することになっ

俺が8歳の頃にはもうすでにスクラムは存在していた。
しかもスクラム自体はもっと前からあったんだろう。
しかも日本人が提唱していた。
にも関わらず採用したのは海外の人であり、そこから逆輸入されている。
と。

およ

スクラムは軍事研究からはじまっていて、私は以前、防衛大学校にいて日本軍がどうして負けたか、という研究をしていた。

なんか聞いたことがるような文言が・・・
軍事研究ってあたりがしびれるね。

ふぉおーー

また大艦巨砲から航空戦になると、太平洋の島々の攻防が大事になってくる。米軍において島々の攻防で最初に戦うのが海兵隊で、海から陸を攻めて島をとるという大事な部隊。このとき、空と陸と海という時間軸の違う人たちがチームを組み、あらゆる関係部門がそれをサポートする。空軍なんかはメシを食うスピードまで違う。こうした異なるチームが一体となって戦う。

営業なんかはメシを食うスピードまで違う。

もう何度も言ってきたけどね

http://www.publickey1.jp/blog/11/is05.jpg

不安定な状態を保つ
　メンバーには高い自由裁量と同時に、極端に困難なゴールを与える

→困難なゴールすぎて討ち死にし、その分評価が下がるから誰も手を出さなくなる



などなどすべてにアンチパターンの実例をあげることができっます。

wwww

ぺ○スみたいですね！（怒！） #修正　#再掲

つーかなにを表しているのかわからん。
ギターかと思ったけど違うし、パソコンか新聞？
あるいは本当にペニスなのではないだろうか。
情報収集を(風俗的な意味で)サポート”

GTDで特にわからないのは

資料としてファイルにしまうものは、「資料」リストへ。
いつかやる仕事としてあたためておくものは、「いつかする」リストへ。

これ。なんだよ資料って。
資料、すなわちDocumentっていうのはただ読むだけのもんだろ？
どうあつかえというのだよ。
というかタスクを見直すときに「これは資料行きだな・・・」っていうのがわけがわからない。
おまえ「資料行きだな・・・」っていいたいだけちゃうんかと。
今すぐやるべきじゃないけど、いつかもやらない、っていうんならゴミだし、そんなあやふやで明確っでないものはただの保留である。
一生し続ける保留であって、そんなものはGTDを実行する本来の目的からかけ離れている。

おお

従って、INBOXに入ったものを「処理」する時は、「これは次に取るべき行動か、それともプロジェクトか？」と考えること自体が間違いなのです。

同じっこといっとる。
つまりこれはGTDの欠陥というわけやな？