私の2012年 下半期のツイートを適当にまとめてみている
ほぼ私自身のためだったりする。
気が向いたらコメントやら何やら挿入したい。
なお、上半期はこちら
7月
主なイベント
改めてイベント振り返り
机上の空論で気持ち良くなっていても意味がない。行動が大切。
2013-01-02 17:45:57 via web
「楽しさ」「チーム感」を大切にする。みんなが同じ方向を向いている、と思えることが第一。
2013-01-02 17:47:03 via web
ツイート
「文書はあくまで口頭で話し合ったものをまとめたり明文化しておくためのものであり、文書で「話し合い」を行う等はとんでもない間違い」とどこかで聞いた。フェイストゥフェイスでの対話大切。文書の使いどころを間違えると、コストも無駄だし伝わらない。 #agilesamurai #横浜道場
2012-07-06 00:11:13 via web
話し合いをするには、話す必要がある^^
最優先かつ肝なのが、「改善の型」にはまることだと思っている。で、そのために必要なってくるのが、適当なフィードバックかと。エンジニアリングならまずCI, 回帰テスト。マネジメントならバーンダウンチャート, 朝会の障害事項, チームの雰囲気, KPTあたりになるのかな。
2012-07-06 00:21:36 via web
KATA of Kaizen.
ちなみに、人が怒りを感じやすいのは、自分が「嫌だけど我慢していること」を我慢していない人を見かけたとき、だそうだ。
CIもそうだけど、なんでチャレンジしようとする人に自己犠牲が強要されるのか。会社は投資すべきなんじゃねーの。 #agilesamurai #新宿道場
2012-07-08 15:48:05 via web
【再掲】今日のスライドも@haradakiro さんのURL と @digitalsoul0124 さんのURL に強くインスパイアされています #agilesamurai #新宿道場
私の少ない経験上、完成する前から明らかにダメなソフトウェアってたくさんある気がする。
「なるべく作らないこと」が至言ですね。これが伝わらない事は実に多い。ビジネスモデル的な問題もある。
2012-07-10 23:14:58 via web
つい作ることが目的化しやすいので注意。
これは耳が痛い話。/ 手離れのよい仕事をするということ URL
非常に大切。
ステークホルダーには、それぞれの「部署」ごとの「局所的な」ニーズがあり、それらが最も重要と考えていることが多い、という現実を受け入れることが必要かもしれない。それらを無視してもきっと何も進まない。
2012-07-11 19:54:08 via web
「xxxという問題が起こっています」なぜですか？「xxxが原因です」ではそれをどうにかしましょう。「しかし、それはうちには関係のない部分です」いやいや、さっきそれが原因で問題が起こっていると言っていたような気がするんですが、本当に関係ないんですか？
2012-07-11 20:38:58 via web
あとで調べるけど、確かプロジェクト失敗原因で最も多いのは「リソース不足」。十分なリソースが用意できないのは、過当競争だから。身も蓋もないが、デスマーチを根絶したいならプロジェクト運営の改善だけではダメ。
努力する前から、兵站の不備を戦術でカバーしろ、みたいな指揮官が多すぎ。
上司と部下、一番大事なのは信頼感。心理的な壁が無ければ、思いや考えのすれ違いが減る。コミュニケーションロスが無ければ効率が飛躍的に上がる。 "@yohhatu: 上司だから命令に従うけど、信頼するかは別っていう関係では、いくら自発的な行動を求めても表面的にしか動かないわな"
まさにその通りだわー。
一人一人切り出すと素晴らしい方ばかりなのに、どうしてこうなったのか。サイロ化か？目標管理制度か？うーん。
2012-07-13 22:32:46 via web
全体としての系の問題かな
読んでいると、むしろ「開発者の熟練度が低いのが真の敵」と言っている気がする。/ 日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経 URL
誰と戦っているのか。
そこを見えるようにしないとね。見えない物に関心を持つのは難しい。 RT @ryuzee: バリューストリームへの関心が必要 RT @haradakiro: 全体最適というのは効果の高い局所を全体合意の上で最適化するので、現場からみると区別はつきにくいかもねぇ。
見えないと議論が始まらない。
. @hyokota 「日本流のスピード感ない同意形成手法がボトルネック」とはよく聞く批判ですが、よくよくステークスホルダ分析すると、実際のデシジョンメーカーは1人2人だったりしますよね。稟議だ会議だという建前を真に受けると、ほんとに不幸なシステムができちゃう。
A successful Git branching model を翻訳しました URL 見えないチカラ #cdelivery
2012-07-22 21:14:18 via web
横浜道場 特別編
現場はそれぞれ違う。標準化や横展開なんて無理。 #agilesamurai #横浜道場
2012-07-20 01:15:48 via web
振り返りに魂を込める。アジャイル知りたいなら振り返りを見ろ！ #agilesamurai #横浜道場
2012-07-20 01:23:44 via web
8月
主なイベント
ツイート
「とりあえず」でプログラムを書き始めると、無駄な機能を作ってしまうことが多い。が、あまり書き始める前に悩んでいるのもよくない。なんとなくこんな感じ、というスイートスポットはあるのだが、まだまだ会得出来ていないし、何より言葉で上手く説明出来ない。
2012-08-01 00:00:42 via web
何も考えず書き始めないことが第一！かな、私的には。
難しい状態であるほど、自分の「役割」のみに集中したくなるが、大体それでは解決にならない。役割を全うしていれば怒られることはないのだが、むー。
2012-08-01 23:02:28 via web
自らプロフェッショナルとしての誇りを放棄するな、ということです。
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経 URL
9月
ツイート
スキルセットが違うチームメンバーを助ける方法だってたくさんあるし、万が一助ける方法がないなら、それを制約として受け入れて上手くまわるように考える必要がある。直接手伝えない場合でも出来る事はたくさんあるということ。 #agilesamurai #新宿道場
2012-09-01 23:07:11 via web
KPT is harmful on @slideshare URL by @nawoto #agilesamurai #新宿道場
チームであることが第一。
期待を明らかにすること、期待マネジメント。大事ですね。なぜか忘れがちなのですが、何故ですかねぇ。アルティメットアジャイルストーリーズ2に目を通して。
2012-09-19 21:34:47 via web
期待マネジメント重要。
期待マネジメント重要。
期待マネジメント重要。
10月
主なイベント
改めてイベント振り返り
インセプションデッキには、「who」の観点が弱いので、ペルソナなどで補間するのがよい。
2013-01-02 18:14:35 via web
「やらないコト」を確認すると、ステークホルダーの実際の期待が明らかになりやすい。
2013-01-02 18:15:55 via web
責任を取る覚悟があれば、大抵のコトはできる。
2013-01-02 18:16:40 via web
ツイート
新人SEがSIerに絶望した時に読みたいスライド4選 URL ギークに憧れて
2012-10-31 11:50:56 via web
新人というか、常に読みたい。
つまらない会社のディスカッションと、つまる医療のカンファレンス URL @daipresentsさんから
11月
主なイベント
- POStudy Conference 2012
- 横浜道場 特別編 Cucumber HandsOn !!
- Redmineのプラグインとか作ってみる
ツイート
このルールはおすすめ。言える空気づくり重要。 RT @hyokota: 朝会で「今日は19時に帰ります！」と宣言します。 / “朝会”やっていますか？ URL @fenrir_officialさんから
これはもう是非真似したいですね。
ストーリーはDoneにして顧客に届ける。信頼関係の構築を試みる。悪いニュースは早めに伝える。常に誠実に話し合って最前策を模索する。信頼関係の構築をあきらめたうえで、「でも、アジャイルにやるにはどうすれば？」みたいな議論が多い気がするが、信頼関係をあきらめた時点で負けな気がする。
2012-11-09 13:17:24 via web
というか、どんなときでも信頼関係は大切だと思う。
PO Study Conference 2012
「プロトタイピング？もちろんやっているよ！」と知ったかぶっていても、肝となる（and/ or リスクの高い）部分を含んでなかったら不十分。 マシュマロチャレンジより。ちゃんとマシュマロのせてみなきゃ。 #postudy
2012-11-04 21:08:03 via web
マシュマロのせずにやった気になっちゃダメ。
PO = 関わるステークホルダーが最も多い「結節点」の役割 => 相談出来る可能性のある人間が最も多い = 味方になりうる人間が最も多い。さらに派生させると、敵にも味方にもなりうる人間が最も多い、と。#postudy
2012-11-04 21:13:29 via web
上手く出来たか分からないが、ほとんどコンテキストを考える事がメインになった。 ： Pragmatic Persona 。 コンテキストの仮定大切。#postudy
2012-11-04 21:17:04 via web
ペルソナ怖くない。
PBI作成とマッピング。複数人で実施の場合は、最初の発散と収束が難しそう。というか、ワークショップではいつも何かしら衝突が起こる。本日の学びは「文字を大きくきれいに」「エピックレベルの認識とコンテキストをしっかり合わせる」「根本的な認識のずれがあったら戻る」 #postudy
2012-11-04 21:20:58 via web
12月
ツイート
大組織の中でのリーン on @slideshare URL
経営者はツンデレ。
迷ったらワイルドな方を選べ。
どうしても楽しくない仕事が避けられなかったら、楽しくない仕事を楽しいものに変えようと考えると、急に楽しくなるお。と考えてみる。
2012-12-20 13:02:28 via web
主体性重要。
成果物ベースでブレイクダウンすると、カイゼンしやすい。
「システム開発の失敗が多くなったのはアーキテクチャ設計やユーザー理解が複雑になったことが主要因なのに、その根本には触れずにプロセスだけを改善しようとしたのです。」
なのに、やってしまいがち。
なんとなくペーパープロトタイピングで確認するのは画面レイアウトな印象があったが、全く間違っていた。
2012-12-31 13:39:58 via web
エンタープライズ開発におけるコラボレーション - arclamp URL
「仕様がわからない」と「仕様が決められない」は意味が違う - 勘と経験と読経 URL
