私の2013年 2月のツイートを適当にまとめてみる
2013年 2月のツイートをまとめた備忘録。グルーピングは非常に適当。
- 過去のツイートまとめはこちら
主な参加イベント
実践メモ
先週の教訓：ベロシティは有用な指標だけど、一番大切な「スケジュールへのコミット（直感的に出来そうと感じて、それを（ある程度）約束出来る）」を軽んじてはいけない。
2013-02-25 20:32:05 via web
もう一度。「今それどころじゃない」とかいってタイムボックスを無視して、よかったと思った経験は今のところ一度もない。 > 自分
初期の見積もりの当てずっぽう感と、初期の設計の想定漏れの量がやばい。初期に正しく想定出来るべきだと考えて、「失敗」して自分を責める技術者はどのくらいいるのだろう。少なくとも私はその一人でした。
2013-02-19 22:25:54 via web
ストーリーのテンプレの冒頭「（ペルソナ）として、」を、「（ペルソナ）は、」にした方が個人的にしっくりくることを発見した。「（ペルソナ）は」の方が、仮説が嘘っぽい時に違和感を強く感じる。
2013-02-12 12:35:24 via web
「仕様とシナリオは相補関係にある」とどこかで習ったが、同じように、「要点を絞った完結な説明」と「ストーリー」もきっと相補関係にある、はず。
2013-02-09 17:44:28 via web
ポモドーロテクニックのタイムボックスの使い方を誤るとケアレスミスを招く（というか招いて後輩に迷惑をかけた）。スプリントのスプリントデモのような「抑止力」を取り入れられるとよいのだが。思いつかない。
2013-02-01 21:21:15 via web
energize
「リーダーの大切な資質を一つだけ挙げるとすれば、明るいこと。リーダーに相談にいったら、元気になって帰ってくるようでなければ」by 野中郁次郎
「もう1人いたらやってみる」 / 社内勉強会の初めの一歩 URL
ブログのススメ URL
この視点は面白いですね。 / デブサミ2013で悪ふざけに関する真面目な話をした - 勘と経験と読経 URL
「○○やりたい」と「これがあれば○○できる」との間はだいぶ合って。後者は色々お手伝いできると思うんだけど(しなくてもできるだろうけど)、前者は正直難しいなぁと最近特に思う。
◯◯できたらいいんですけどねぇ…ってのは、やってみたら良いと思う。ただ全部思い通りにならないから、その時には一旦それを前提として受け入れて、デザインすれば良いわけで。で、やってるうちに最初のことができるようになるかもしれないし、そもそも不要になってるかもしれないし。
あの人と一緒に働きたいと思える人と、一緒に働けていますか？ 自分もそう思われていますか？ / MY JOB WEND TO VIETNUM? DevSumi ver. on @slideshare URL
とても心にしみますねー。 / 愛せないコードを書くには人生はあまりにも短い on @slideshare URL
agile
これはとてもいい資料だなー。 / もうアジャイルなんて言わないよ絶対 - Developers Summit 2012 FB - by @TAKAKING22 on @slideshare URL
どんな方法論も、最初は知って試してみる時期があり、自分の現場でうまくいかないことにヘコみ、それを一旦は忘れて、自分の頭で問題の本質から考えるようになって、そうして少しずつ理想に近づいていくうちに、そのうちに外からは、その方法論を実践しているように見えるようになる。それが守破離か。
I know I don't know. DRY も YAGNI も。/ 適切に抽象化されたコードとはなにかって話 - life.should be_happy # => 1 examples, ? failures URL
とてもやってみたくなった。 / タスク管理や業務改善を体験できる『かんばんゲーム』がすばらしすぎる | 世界 URL URL @daipresentsさんから
Q. 『...同時に「要求という言葉が嫌いだ」とも書かれています。』 A.『 ...ひどい言葉だね。』 / Jonathan Rasmusson さん突撃インタビュー( 後編 ) URL
2013-02-09 17:23:00 via web
trust buildingののち、価値を伝えて理解を得られたら、という道のりになるわけだ。顧客に価値が伝わらないなら、きっとあまりやるべきではないのだろう。
2013-02-08 23:36:58 via web
「タイムボックスが守れないということは、スクラムチームがまだ未熟なことのあらわれなんだ」 この視点はあまり無かったな。言われてみれば･･･ってことなんだけど。 #scrumbcbook
devsumi 2013
#devsumi 2回目参加でした。「よし、やってやるぞ！」感が毎回半端じゃなくでるデブサミマジック。今回一番記憶に残っているのは、 @ursm さんの「汚いコードで開発スピードだけを追い求める事は出来る。でもそうやって作ったプロダクトで幸せになった人は一人も居ない」というお言葉
2013-02-16 15:17:27 via web
興味深くて一気に読んでしまった。 / 2013 デブサミ 「SIの未来ってどうなのよ？」 by @serverworks on @slideshare URL
とても勉強になります。再演が聞きたい… / Kanban and Scrum URL
Developers Summit 2013【14-E-4】デザインをするときにデザイナーが考えること〜デザイナーの頭の中〜 on @slideshare URL
devlove たのしい自分戦略
#devlove たのしい自分戦略に参加しました。今自分がいる枠組みの意味を理解し、そして一度ゼロベースで理想型を考えて、もう一度戻って来よう！で、組織という枠に「なんとなく」隷属することなく、その良さも問題も知って、積極的に活用して企業人ライフを楽しもう。とメッセージを解釈した
2013-02-05 00:11:41 via web
会社は自分がやりたい、一人ではできないことを実現するためのツール #devlove
ユーザーの本質的要求からビジョンを描き提案する - OpenCU
一日目に参加してきました。リフレーミングの必要性, ラポールの形成, UXマップ（特に軸をどうするか）等々を学び、とても勉強になりました / OpenCU WorkShop：ユーザーの本質的要求からビジョンを描き提案する（全3回） URL
junitbook
唯一変わらないのが「人間」のスペック -> よって、最近の言語は「表現力」を重視する方向になっている。 #junitbook
2013-02-02 18:09:22 via web
テストが全部通ってるのにバグった、なぜ？ → モック使ってたんだけど、本物の方の動きが変わってた。おそろしや。だから他のテストも併用しないといけないのか。 #junitbook
chef
「初めてのChefの教室」を開催しました。(動画&資料) - Engine Yard Blog JP | Engine Yard Blog JP URL
DDD・GOOS
テスト駆動開発の進化 on @slideshare URL
validation borad
The #ValidationBoard just launched! FREE tool to test startup ideas without wasting time or money. URL @Leanさんから
ITS
commitログにITSのチケットIDを打ち込むのが面倒になってきた。うまいソリューションないかな？Mylynとかを使えばいけそうな気もするが、Mylynはあまりしっくり来なくてやめてしまったんだよなあ。再チャレンジしてみようかなあ。
2013-02-19 22:42:31 via web
ビジネス・SI
業務系SEの今後について on @slideshare URL
業務系SEの末路的なお話でして URL
2013-02-19 09:48:33 via web
「顧客が出す金」＝「顧客価値」でしょ。それ以外に定義のしようがないし、一致しないケースがあるとすれば取引当事者間の情報格差が大きい場合で、平たく言うと詐欺。>RT
フォード生産方式について - ハイパーレガシーコードクリエイターのblog URL
諸々
学びは「Action」の視点でまとめた方がよいことに気付いた。自然に内容が凝縮されるし、行動につながりやすいし。デブサミ様々。
2013-02-16 20:23:56 via web
最終的に ゴール -> Action -> 裏付け, メモなど という流れでまとめてみるのはどうだろう。
2013-02-16 20:29:57 via web
「頑張っているので許してください」という言い訳の向き先は、上司でも顧客でもなく、自分自身になりやすい。頑張っているので人に迷惑をかけても仕方がない。頑張っているので解決策を検討する余力がなくても仕方がない。頑張っているので長期的視点でのデメリットを考えるのはつらいけど仕方ない。
2013-02-23 17:07:48 via web
そんな一大決心みたいに意気込まなくても、「あ、この人とは一生付き合っていきたいな」みたいななんとなくな覚悟でも、相手にはけっこう伝わる。「今自分が過ごしているこの空間を大事にしたいなー」とか。場を大切にしようって思いはけっこう皆、無意識下に汲みとってくれるように思う。
アクティブリスニングのコツの1つ：「結論に飛びつかない。自分の理解が正しいか相手に確認する」。おっとこれは…気をつけよう
2013-02-09 22:37:43 via web
「やらない明確な理由がないからやる」のか、「やる明確な理由がないからやらない」のか。この文化の違いが、違いが、、、。
2013-02-12 12:48:44 via web
確かに。「選べないことに気付いていない」場合があるのが厄介。当たり前になってしまったことこそ見直すべき、とはよく言われますね。/ 会社員は「選べない」ことばかり - 脱社畜ブログ URL
暗黙知と形式知は違うものだ、と認識するだけでも大きく違うのではなかろうか。「暗黙知が存在している = 形式化をサボっている = 職務怠慢」 と言う認識が意外とありがち、な気がする。で、知識は壁越しにぶん投げて共有できるものと思ってドカーン。
2013-02-07 23:48:53 via web
私の2013年 1月のツイートを適当にまとめてみる
2013年 1月のツイートをまとめた備忘録。グルーピングは非常に適当。
主な参加イベント
- 「Lean Diagram」に学ぶProblem/Solution Fit - POStudy
- 『JUnit実践入門』写経・実践会 in 横浜 #2 - connpass
- Scrum Alliance Regional Gathering Tokyo 2013
- 1月17日〜18日 ユルゲン・アペロ 「マネジメント3.0」アジャイルリーダーシップ実践研修
- Enterprise User eXperience Design -ユーザー中心設計の実践 - - DevLOVE
- アジャイルサムライ読書会 横浜道場 特別編「ワールドカフェ再び」 - アジャイルサムライ読書会 横浜道場
- LeanStartupNight - Startup Begins - - DevLOVE
ツイート
「考えないための標準化」はダークサイド。標準はかならず失効日を決める。
2013-01-02 14:53:59 via web
プロジェクトを止めるのに説明が必要、ってよく聞くんだけど、ものすごく危ない状況だよそれ。プロジェクトを進めるのに説明が必要という状態を保っておかないと。
Noから始める。毎回根拠を確認し、なくなったら自動でやめられる仕組みづくりが大切。
色んなワークショップのお手伝いを何度かやって気付いたことが一つ。チームの生産性を上げるのは、「多様性」と「それを活かせる優秀なファシリテーター」。傍から見ていると15分程度のワークでさえ劇的に差がつくのだから、それが数ヶ月におよぶ普段の仕事を考えると怖い。
多様性重要
ボーイスカウトルール
私の完璧主義思考から生まれるよくないパターン。「ここが気に入らない、ちょっと直そう -> でも、xxの方が優先順位高いし、どうせならこっちもやりたい -> そんなに時間はない -> 結局何もやらない -> できればやりたいことがたまる -> 最初に戻る」
2013-01-19 15:02:57 via web
「完璧主義はxxの問題があるのでよくない」というより、「ボーイスカウトルールやろうぜ」といったほうが楽しい。ひとまず我が家の（最低限の）清潔さは、ボーイスカウトルールによって保たれている。
2013-01-19 14:45:39 via web
ボーイスカウトルールは楽しいですし、initialコストゼロです。強くお勧め。
リーンスタートアップまわり
インセプションデッキだと、ソリューションの価値, 目的は表現されるが、その目的が本当に正しいか（本当に顧客が求めている？お金や導入コストを支払ってくれる？そもそも顧客って誰？）があまり表現されない（少なくとも、私は表現できていなかった）。リーンダイアグラムを先に使うのがよいかも
2013-01-29 00:13:52 via web
リーンダイアグラムをいじっていると、いかに自分がSolutionばかり見つめて、ProblemやSwitching Cost、ましてearly adopterが誰かを深く考えていなかったかが分かる。マーケターなら当然のことかもしれないが、私は出来ていなかった。
2013-01-30 21:09:14 via web
よいKPIの3原則の1つ「KPIは作業者にとって、興味深い作業の一部である」。とりあえず私は自分がどのプロジェクトにどのくらい作業を割り振ったかの実績等全く興味がないので、誰か適当に書いておいてほしい。
2013-01-19 12:50:36 via web
KPIを決めるのは、とてもとてもスキルが要る。
雑感
不機嫌の8割は、自分が受け入れている常識を破る人に対する怒り「許せない事なんてない。許したくないだけ」か、自らの非を認めたくないために、無意識のうちに相手の非とする怒り「悪いのはあちら」でなりたっている。気がする。つまり本来不機嫌になるほどでもない。
2013-01-29 08:04:54 via web
「これはタイプの問題じゃない、土俵の問題だ。要するにおまえはまだ実践という土俵に上がっていないんだ。だからソフトウェアを脳みそからひねり出した理屈なんかで計ろうとする。見当違いもはなはだしい。背の立つところまでしか海に入ってないのに、俺は海を知ったと公言してるようなもの。」
2013-01-27 13:35:39 via web
｢生きてるだけで丸儲け｣の意味 - teruyastarはかく語りき (id:teruyastar / @teruyastar) URL
アジャイルになる、系のおはなし
導入でなく、少しずつ目指すものに対して変容して行くものだ、という考え方があり、私はこの考え方が好きです。メンタルモデルの変化が必要なものの「導入」って大抵自己満足。ましてや「アジャイルを」「導入」とかだと日本語としておかしいと感じる。 #agilesamurai #横浜道場
2013-01-23 00:36:12 via web
アジャイル導入！とか、その時点で少しもアジャイルじゃないし。
気付くと「アジャイルになる/する」ことが目的になっていることがあって、そのたびにはっとする（というか、こうなっているときは周囲への愚痴しか出てこなくて少しも建設的でない）。よって備忘録。「何のために」を元にしないと上手くいかないし成長もしない、と思う。
2013-01-24 19:09:46 via web
最初あった志は、ともすると簡単に忘れられて手段だけが残る。
「皆さんは赤いピルを飲みたいんでしょう？青いピルのスクラムをやるんですか。」 / Jim Coplien のスクラムマスター研修を受けた - word-iteration (id:takeshinoda) URL
赤いピル = いわゆる破壊的イノベーション（だと理解している）
なぜアジャイルなのですか？改めて考察するウォーターフォールとの違い on @slideshare URL
Scrum Regional Gathering 2013
非常に広い世界が一つに収束していく感じを受ける、凄い講演でした / Phronetic Leadership And Agile Scrum Gathering Tokyo 2013 by @hiranabe on @slideshare URL
野中先生の講演は、新しい視点や思考の枠組みを得られたことだけでも十分すぎるほど素晴らしいが、感動やInspireを得られた点がすごいんだな、と、講演メモを見返していてしみじみ思った。
2013-01-20 17:09:48 via web
目から鱗が落ちる講演（これだけでも十分すぎるほど凄い）は何度かあるが、感動する講演はなかなかお目にかかれない。
#sgt2013 無知は間違った自信を増幅する。 / Dunning?Kruger effect URL
2013-01-24 18:59:09 via web
直観的に、そしてこれまでの経験則からして、これは絶対正しいと思う。
#sgt2013 でcopeに「改善マインドよりcommon senseを重視するのは何故ですか？改善マインドがあればcommon senseは徐々にすりあわせられると思うのですが」と質問したところ「レトロスペクィブスでcommon senseが変えられると思うかい？」と返された
2013-01-23 00:57:12 via web
改善って、そもそも目指すところはある程度理解できている前提。
#sgt2013 スクラムの基本用語を知っている方なら気軽に遊べる、各プラクティスにおける要素毎の優先順位をつけて、それが偉大なる先人（Cope含む）とどの程度マッチしたかが見られるゲーム。遊んでいるといろいろ気づきがある。 URL
2013-01-16 00:09:11 via web
パターン
改めて見直す。考える契機になることと、とりあえずのヒントを与えてくれる事と、共通言語になるところがパターンの素晴らしいところか、と浅学ながら思ってみる。 / Scrum Patterns Summary URL
2013-01-29 22:19:36 via web
パターンがたくさん！ / URL
2013-01-29 22:28:03 via web
Pattern mining-scrum gatheringtokyo20130115 on @slideshare URL
今、パターンが（私の中で）とても熱い。
SIerなど
エンジニアのSI業界ディスって、「誰にとっての問題か、どのような意味で問題か」の問題定義がすごく弱い印象。「問題だ問題だっていうけど、それお客さんが言ってたんですか？」と聞くと「まずお客さんを変えていかなければ」とか平気で返ってくる。せめて「未発掘のニーズがある」ならわかるが。
悪意がある元請け/上位者をどう扱うか、みたいな議論がよく起こるけど、これはもう相手に悪意がある以上、騙すか騙されるか逃げるかしかないような気がして、騙すのも騙されるのも私は嫌なので、逃げの一手です。 #agilesamurai #横浜道場
2013-01-23 00:52:51 via web
SIerにいるエンジニアが残念な気持ちになる現場の現状リストかと思った。 / SIer系エンジニアがベンチャーで働き始めるとぶつかる壁のリスト - IDEA and Players URL
2013-01-14 11:35:44 via web
手近な不満点に反応的になるだけでは籠の中の鳥。
システム思考、ビジネス全体の理解、それと大前提の自己マスタリー。
このあたりがカギか？
仕事のフローを見える化し、一番のボトルネックを改善する。
2013-01-02 14:55:32 via web
プラクティス
そうか、卓上カレンダーとドットシールでもいける！ / ニコニコカレンダーURL
2013-01-31 22:39:22 via web
「幸福度」は間違いなく重要な指標。
必要なのはやることリストではなく、やらないことリストな気がする。というか、私の今年の抱負はいつになったらできるのか。一応毎週振り返りしているので、それでよいといえばよいのだが。
2013-01-14 11:58:40 via web
「やりたいこと」って放っておくと無尽蔵に増えて、次に何をやるかについて「分析麻痺」状態になりがちですので。
（こうなると、経験上誰かに言われた「緊急に見える」タスクに隷属することになりがちで、これは悲惨・・・）
これも実践の積み重ねかなー。
その他
amazonで「スクラム」を検索しようとして「すく」まで打ったところ、検索キーワード候補のトップ5が全てスク水で残念な気持ちになった件。retargetingの結果ではないことを信じたい。
2013-01-19 15:15:42 via web
これは酷い。
「可愛い」って言われたときの女の子の反応一覧だって。個人的にでお願いします URL
やっぱ4だな。
便宜上アカウントがあるだけでほぼ利用していなかったFacebookを、本格的に利用してみようと思っている。
2013-01-19 16:56:54 via web
ご存知の皆様はよろしくお願いします！
私の2012年 上半期のツイートを適当にまとめてみている
下半期につづいて上半期もやってみよう。
気が向いたらコメントやら何やら挿入したい。
下半期はこちら
1月
社外有料セミナー, 社外勉強会ともに初参加だったりしました。
主なイベント
ツイート
本によるが、私がよく買う程度の大きさで、学ぶ事の多い本をひとまず読み終えるのに、大体3〜6時間かかる。1日1時間読めば、1週間に1冊読める計算だ。なのに1ヶ月に2冊程度しか現状読めていない。
2012-01-08 19:30:41 via web
この時より格段に読む速度が上がったのに、今も一か月に2冊程度しか読めていなかったり。時間を作りたい。
仕事が若干ダルく感じる理由を考えてみた。全力で解消する1. 自分でコントロール不能な点が多い。1の補題. コントロールできる権限のある人が期待通りにコントロールしてくれない。2. スケジュールが何となく非現実的な感じがする。どこが、と言われると答えられないのが、より嫌な感じ
2012-01-10 20:26:38 via web
こういうのはよくあります。受け身になると非常につまらないので、主体的かつ積極的に、責任を受け持つか、全力で逃げるとよいと思います。
これはじわじわ来る。説明が上手い人は本当に凄い人。 / 僕は自分が思っていたほどは頭がよくなかった - しのごの録 (id:tictac / @naoski) URL
2012-01-11 21:25:47 via web
無駄に思えるインシデント対応に結構時間がかかっていることを発見したので、こういった対応を撲滅する方法を考えてみる。
2012-01-12 20:53:23 via web
おかげさまで大分減りました。昔の自分がいかに無駄なことをしていたか分かります。
騒々しく、無味乾燥で、割り込みが次々と入る場所に、プログラマーを押し込めているかぎり、どんな改善策も意味が無い──オフィス環境の改善以外には。PW_P50
妄想、証拠なし。親の最も重要な役割は「無償の愛」の存在を子に信じてもらうこと。これが満たされなかった子は、自らの力でアイデンティティを獲得するまで、自信を持てない、人を信じられないなどの不都合を被る。アイデンティティを獲得出来れば、人を信じるための長期のリハビリに臨むことになる
2012-01-15 01:33:25 via web
実際には、「無償の愛」を与えられない子供がけっこう多いのではないか。私には、子供を「きちんと」育てないと世間体が悪いから、「きちんと」「それらしく」育てているだけに見える。
2012-01-15 01:39:45 via web
世間の子供と自分の子供の差異に過度に反応し、「しつけ」という名の矯正を行う。暴力が最悪だが、暴力でなければいいわけではない。重要なのは、子供の意思を尊重するつもりなどない点だ。これは子供が成人しても続く。子は成人と同時に親と疎遠になる。
2012-01-15 01:40:51 via web
現在の環境で最善をつくさない人は、きっといつまでも最善をつくさないのだろうし、大した成長もしない気がする。「次の環境ではきっと理想的な状況があって、云々」みたいなことをずっと考えて現実逃避するのだろう。それは学生の頃の私の事だが。
2012-01-20 20:44:52 via web
幸せの青い鳥症候群。私は罹患しやすいので注意したい。
考えさせられる。そういう場合、大抵誰かのせいにするよね。あながち間違いでもないが。。/誰にも文句を言われないから、誰も困らないから、最低限の基準は満たしているからといった態度で仕事を進めるのは、仕事への姿勢として大きな問題があると思う/ URL
2012-01-23 20:14:41 via web
こちらも注意して見返したいところ。「箱に入る」とも言える。
リーダーがいないと言い放つよりも、個々人がちょっとづづリーダーになった方がいいと思う。それじゃー混乱するでしょ？っていう意見もあると思うけど、今の現状はむしろ混乱した方がまだいい。そのうち、そんな混乱をうまく調整する調整役の人が出てくるでしょう。そいつが「結果としての」リーダー。
今も昔も、日本のリーダーシップの特徴の一つは調整能力の高さだと思うし。だからもっと個人は「いい加減・適当・やりたい放題」でいいとおもう。それでも遠慮は入るし、自分で勝手に調整するし。それくらいまでいかないとどうにもならないでしょう。そんなのをまとめるのが、リーダーでしょうよ。
目から鱗。
日本の個々人の能力の高さは世界的に見ても良い線いってるってのは、特に教育水準＋平均値的にはそうでしょうよ。低いのは組織の進化のスピードなんだから、その辺をうまく動かすには、個々人の「適当な個人プレー」しかないし、組織の長はその辺意識しないと駄目だとおもう。
あと一個減らせば1ページに収まるのに、減らせなかった。。。 常に見返したいと思っている名ツイート： URL
2012-01-22 20:32:06 via web
ツールありきでプロセスを考える場合と、プロセスに合わせたツールを選ぶでは大きく違う気がします 前者はツールを使いたい指向導入 後者は仕事を楽にしたい指向導入
これが当たり前のようで、できていない。特に組織では。
必読。というか、大抵のケンカは1つ目の違いが原因な気がする。 / あなたが異性を理解できない理由はここにある！こんなにも違う、男女の脳の作り。 - ゆっくりしていってね!!-ゆっくりライフハック、しませんか？- URL
久々に全力でツボに入った / 【バグ】 QWOPを完走しようとしたらとんでもないことになった 【実況】 (13:05) #nicovideo #sm16789445 URL
最近外のイベントに結構出てる。仕事を前より効率よくやらないと時間が出来ないという効果もある、という事に気づいた。自分で本読んだ方が学習効率よいかも？とか思ってたが、「気付き」という面ではイベントにしかないものも多いかなあ。あと、やっぱり「刺激」がでかい。やる気も出る。
2012-01-28 21:04:49 via web
チームメンバーのベクトルが個人（「リーダーシップ」を取ってる人とか）に向いていると失敗する。 ベクトルをそろえるにはエレベーターピッチを皆で考える、などが有効 #agilesamurai #新宿道場
2012-01-29 22:32:25 via web
ポモドーロ実行の徹底の方が、5:00起床18:00退社より難しそうだから、ポモドーロの徹底を目標にしようかな。でももう一方も大切なので、もし私が18:00以降会社に居るのを見かけたら全力で罵って下さい > 会社が同じ人とか
2012-01-28 22:27:24 via web
恥ずかしながら、実は未だにできていなかったりする。これは問題。
20時まで残業してしまったので、反省会なう。俺、今月のピークを過ぎたらレトロスペクティブするんだ。
2012-01-30 22:29:02 via web
でも昔は24時まで残業〜とかやっていたので、大分成長はしたかな。少しは効率よく出来るようになったかも。でもまだまだだな〜。このままだと明日も残業になってしまいそうだし。
2012-01-30 22:31:08 via web
現プロジェクトの処方箋について。現状考えついているのは、やはり「リスク発生時にどうするか」についてのコンセンサスが皆無だった事が悪いのかなーと。お客様どころか、社内どころか、同じ部署内でも全くコンセンサスなし。誰に頼っていいかもよく分からない。
2012-01-30 23:03:21 via web
自分でこんなこと考えてたの忘れてたが、これはあるなー。
で、さらに「声を上げた人が割を食う」状態になってしまう。
私はプロジェクト管理とかプロセスに興味を持って勉強している以上、そうでない人よりは時間をかけてやっている。つまり、例えばプログラミングに情熱を注いでいる人が、少しプロジェクト管理の知識が足りなかったからといって、それは仕方のないことなのだ、と漠然と考えたりしてた。
2012-01-31 19:36:38 via web
2月
主なイベント
改めてイベント振り返り
見える化は、説得の材料にもなりやすい。
2013-01-02 14:07:16 via web
巻き込むべきは、上司ではなく、顧客。
2013-01-02 14:07:51 via web
もうけを出すためにはスケーラビリティが大切なのか。スケーラビリティを実現するためには属人性を排除すべきなのか。属人性を排除した仕事は楽しめるのか。
2013-01-02 14:10:00 via web
重要なのはフロー, ストリームの見える化, 最適化。
2013-01-02 14:11:01 via web
ツイート
チケット駆動でプログラミングする場合、「宵越しのチケットはもたないようにする」がSonicGardenのルール。最大でも１日で消化できる範囲の大きさの粒度にすること。超える場合は、チケットの分割をする。
2012-02-02 19:04:31 via web
CleanCoderの根底にある考え方は「約束を破る一番簡単な方法は、出来ない約束をする事だ」「守れない約束はしない」だよね。プロなら約束を守ろう。
2012-02-05 13:19:18 via web
守れない約束はしない！
業務時間中に人に話しかけるのってしんどいよなー。このコストを削減する方法を、いろんなアプローチで考えてみる価値は充分にあると思う。たとえば、朝会 ・仲良くなっておく ・事前アポ ・心の持ちよう ・話しかけなくてよい方法を考える ・話しかける時間を決める etc...
2012-02-06 18:26:11 via web
後で考えると、これってチームビルディングに失敗していますよね。
チームメンバーがこんなこと心配しているようでは、そのチームは相当まずい気がする。
コアは内製、コモディティは外出しに、という話をどこか有名な本で読んだけど、どこまでがコアかという点が経営的に(もしくは執行組織的に)意思決定できてないのが日本企業だったりしないだろうか、と。
いろんな本を読んだり勉強会に出ていると、IT業界は本当に楽しいところだなと思います。未開拓な部分がたくさんあって、しかも元手があまりなくても熱意さえあれば開拓出来るのです。同士もたくさんいます。しかもこれを仕事にすることも出来る。有難いことだ。フロンティアスピリッツ大切にしよう。
2012-02-14 21:28:55 via web
こういった心は忘れたくないですね。
ソウルジェムが濁らないようにしないと。
問題を根性で解決するな！が凄く良かったです / デブサミで僕が話したことの簡単なまとめ - YoshioriのBlog (id:Yoshiori / @yoshiori) URL
過激上等。人の顔色伺って言いたいこと飲み込んでもいいことないよ。スクラムでのチームも同じ。思うことがあったら遠慮なく言えばOK
2012-02-26 20:17:56 via web
優秀なプログラマがリーダーになると陥りやすい罠。1.マイクロマネジメントする。2.技術的判断に口を出す。3.価値に対する重み付けが技術に偏る。4.「いざとなったら俺が何とかする」。
2012-02-18 20:20:55 via web
自分が料理人だったとして、マクドナルド本部で新しいジャンクフードを考案する仕事と、小さな料理屋でお客と触れ合いながら仕事するのと、どちらにやりがいを感じるだろうか？ 難しい問題だけど、少なくとも「料理人を目指しているのにマクドナルドでアルバイトする」は間違っている。
2012-02-19 13:02:24 via web
分かりやすい比喩ですね。
いろいろ疑問も湧きやすいです。体制を整備すればバイトさんがソフトウェアを作れるようになるのかしら？
ひらめきメモ：書きたいことが浮かんだらひとまず体裁とかあんま気にせずアウトプットしてしまったほうが良い。一度しか言ってはいけないという決まりも別に無いし、同じ事を表現するにしても、その時の気分とかで表現のされ方って変わってくるので。
「どうしてコレをしないのか、どうしてアレをしないのか」という質問に対して私達のお気に入りの答えはこうだ「だってどうでもいいんだから。」何が重要なことのかを見極め、それ以外は忘れればいいのです。
長すぎるTODOリストにはゴミが集まる。長いTODOリストに私たちは嫌悪感を覚え、感情はネガティブになる。TODOリストはなるべく短く、小さな期間のものにすべきだ。TODOなどと言い始めれば私たちにTODOがなくなる日はない。
どうでもいいことは忘れてしまえばよいのです。
努力って一種の娯楽なのだ。今の満足出来ない現状を、打破してくれるかもしれないという幻想に浸れる。価値のあることをしていると思わせてくれる。間違っちゃいけないのは、そういう娯楽や安心のための努力に終わらせてしまわないようにすべきということ。努力の仕方を間違わないようにせねば。
頑張ってるつもり感は大敵。サボってると自覚している人の方がよほど見込みがあったりするのです。
思いどおりにならないのは、思ったとおりに行動していないから。
これは耳が痛い指摘。
3月
主なイベント
記事
改めてイベント振り返り
「おやつタイム導入」とか結局やってみてないなー。
2013-01-02 14:40:39 via web
まずは2週間後に価値を提供する、と明言する。そしてその方法を考える。
2013-01-02 14:57:29 via web
仕事のフローを見える化し、一番のボトルネックを改善する。
2013-01-02 14:55:32 via web
「考えないための標準化」はダークサイド。標準はかならず失効日を決める。
2013-01-02 14:53:59 via web
どうなりたいか。どう評価されたいか。
2013-01-02 15:02:00 via web
局所最適化に陥らないこと。本当にそれは制約か？取り除くべき障害ではないのか？
2013-01-02 15:06:04 via web
ベンチャーカフェ
問題の無い業界、問題の無い組織、そんなものはないから。問題を問題と思わないのが一番の問題なのさ。 #vcafe
ひが氏：悪い受託開発をしている会社は、どうしようもない。良い受託をするには客を選ばないといけない...会社が悪い受託開発をしているなら、...抜けるなど別の方法を考えた方がいい/受託開発は本当にオワコンか？ SI業界の未来を前向きに考える URL
ツイート
あった方が便利とか、あれば嬉しいとか、マストでなくベターなことを言い出したら危険信号。リリース出来なくなる。まずは不満が出ようともユーザに出すべきだ。そして本当に出てきた不満から、それを素早い速度で改修していけば良いのだ。素早い改修を出来ることがアジャイルの本当の価値なのだから。
これはよくあります。
アジャイルの何をどう説明しても、「で、どのツールを普及させるつもり？」「いっそのことツール自製してみようか」という答えしか返らず、非常にげんなりするなど。デブサミで和智さんがおっしゃってたように、相手のコンテキストを意識して上手く伝えられるように修行しないとだめだー。
2012-03-03 21:31:58 via web
ツールを馬鹿にする気はないが、ツールを云々言う前に積み上げるべきピラミッドが3〜4段はあって、そこが完全にアジャイルの本質なんだよ〜。現場がその土台を積み上げ、自らニーズを出してくる前に、いきなりツール与えても無意味だと個人的には思っている。違うのかなあ。
2012-03-03 21:34:53 via web
アイデアは、暖めるほどにつまらなくなる。...「空気の読めない人」は、たいてい物事をよく考えて、アイデアをまじめに磨く。磨いた結果として、アイデアの価値は減じて、発せられるべきタイミングを失ったアイデアは、放り出されて場を凍らせる。 / URL
2012-03-04 14:20:45 via web
書きだしは大事だし、タイミングはもっと大切。
ご冗談を。
メールというコミュニケーション手段は、きちんと再考すべきですね。
とりあえず一言。せいぜい会社をクビになるくらいだ。大した事ない。過労の悪循環にはまって学習できないほうがよっぽど問題だ。とはいえ、クビになった後で胸を張れる程度には責任を果たす事は必要だが。過労している人は責任感が強いので、そんなことをわざわざ言わなくても大抵大丈夫。
2012-03-12 20:58:07 via web
価値ではなく人月に対して対価をもらっているSIerは詰んでると思う。単価は低下傾向で生産性を上げたら売り上げは下がる、そしてパイは縮小中。価値に対して対価をもらえるように変えたくても差別化できる価値は提供できないし。
あとは、規模を小さくして属人性を高める（アジャイル）か、規模を大きくして属人性を低下させる（組織化）か。前者の方が職人肌の人には楽しいだろう。ビジネスとしてスケールするのは後者だろう。
2012-03-14 09:56:37 via web
しっかり考えたいポイント。
世の中の8割の人に嫌われても1割の熱狂的な味方がいるほうがよい、などと言いますが、世の中の全ての人に嫌われても、自分で自分を誇りに思えればよいと思うのです。
2012-03-21 07:22:32 via web
もし今日が人生最後の日だとしたら、私が今日やろうとしていたことは、本当にやりたいことなのだろうか？Noと答える日が何日も続くと、何かを変えなければいけないと気付くのです・・・ありとあらゆることを。 / スティーブ・ジョブズ
2012-03-21 11:03:47 via web
いつの間にか「上の人がxxやってくれない」という発想になっている不思議。昔からずっと上下関係が空気のように存在しているせいだと思う。こんな空気がなければ、一人一人が自律的に動けると思うのだが。いや、それは個人の担当範囲が広くなりすぎてしまうか？難しいなあ。
2012-03-23 21:58:17 via web
これは本当に格好悪いが、残念ながらよくある。
本当にその若者は当事者なのか？明示的に必要な権限委譲をしたのか？コマンドアンドコントロールですらない「空気読んでよい報告だけもってこい。権限は与えないが責任はとれ。」という放任主義（笑）マネジメントが横行しているからなあ。 / 最近の若者には、当事者意識が欠如している
2012-03-23 22:35:40 via web
正論並べて責めるより、「なぜ？」と聞いて相手に考えさせた方が効果的だし、自分も相手も幸せだし（お互いに新しい学びがあるかも！）、いいことずくめだぜ、という話。/ 「なぜ?」 の効用 URL
2012-03-28 15:30:14 via web
一方で、使い方を間違えると詰問みたいになる。
ャーにはなりたくないものです。
会社間のビジネスであっても、結局はお互いにリスペクトしあえる関係でなければ成立しないんですよ。お客様もパートナーもリスペクト出来る人たちと仕事ができて嬉しい。そうでない人たちにはなるべく近付かないようにしてる。
2012-03-30 00:10:46 via web
こういう注意喚起の仕方が効く。「今は気持ちいいかもしれないけど、あなた何かを失ってますよ。悪い方向に転がってますよ」という言い方が効く。 URL
これはすぐ使える。
成果出せない部門や下請けに文句言う前に、何故成果が出なかったのかを分析するのが先。大概が上位層からのInput不足やOutput定義の不足だよ、経験的に言えば。それを下に「期待」しちゃうならそれは組織の不備。期待でなく信頼できる組織にしてから期待しましょう。ksg
おっしゃる通りです。
4月
主なイベント
記事
- みんなに「改善したほうが楽になる」と気づいてもらうには？ 〜継続的デリバリー座談会 in 新宿#01 に参加しました〜 - カイゼンにっき。
- プロジェクトをアジャイルに進めるポイント 〜アジャイルサムライ新宿道場#05に参加しました！〜 - カイゼンにっき。
- みんなをバスに乗せるには？ 〜アジャイルサムライ横浜道場 「みんなをバスに乗せる」に参加しました！〜 - カイゼンにっき。
- 週4時間とは言わないが、一日4時間だけ働く！徹底的な選択と集中, 無駄のフィルタによる生産性の向上術 〜「週4時間」だけ働く。を読んで〜 - カイゼンにっき。
- アジャイルな計画の有効性を伝えるための障壁とは 〜アジャイルサムライ新宿道場#04に参加しました！〜 - カイゼンにっき。
本日のポモドーロテクニック紹介のLT資料を（白い悪魔にマスクを掛けて）アップロードしました。ハッシュタグ付け忘れたので再掲。/ Pomodoro Technique Introduction(LT) URL#agilesamurai #横浜道場
2012-04-27 01:51:21 via web
ツイート
今、この瞬間にスーツ着た可愛いめの女子から「よろしくお願いします、先輩」とか言われてる奴がいるかと思うと、爆発しろ以外の何も感じなくなる。
それ何てエロゲ？
スケールアップするかじゃなくて、どうやったらスケールダウンできるかを考えるんだ！ / URL
2012-04-03 11:39:19 via web
We are purpose maximizer！ / URL
2012-04-03 11:40:48 via web
アジャイル開発は、やりすぎるアーキテクチャに懐疑的なだけ / URL
2012-04-03 11:42:05 via web
アジャイルなソフトウェア開発プロジェクトとは、変化は常に起こり、予測不可能であり、間違いは常に起こる事を受け入れている。そのため、あらゆるレベルでのフィードバックループを回し、継続的学習を行っている。 #アジャイルを140字弱で表現してみる
2012-04-03 21:41:29 via web
そんなに外してないのではなかろうか。
その代り、早期のコミットメントはできない。
「はい、できます！」という前に10秒数えろ！だそうだ。
2012-04-07 19:52:02 via web
「おそらくできると思います」と言っても脳内変換されるから注意！
先生！解決する必要がない問題を解決する成果物なんて、評価対象にしないで下さい！え？それが半期の成果だって？ / 「その問題は本当に解決する必要があるか？何て考えるのに時間を使いすぎちゃいけない。そんなことしてたら「成果物」を作る時間がなくなって、君の評価が下がっちゃうぞ！」
2012-04-07 22:19:40 via web
有効な解決策を検討する時間は非稼働、無駄な解決策の実装にいそしむ時間は稼働だそうだ。
このシステム上では、ただ闇雲に長時間手を動かす人が最も「優等生」となる。
というか、稼働率の幻想をそろそろ捨ててほしい。
「それはやる価値があるか？」「人に任せられないのか？」いずれかがNoならやらない。全てがYesのものの中で、優先順位を付けて、高い方から順にやっていく。優先順位を付ける際は、「今すぐやらなければいけない」ものが、本当に「今すぐ」「やらなければ」いけないかに注意。
2012-04-04 11:32:29 via web
選択と集中。
選択と集中。
選択と集中。
自分にしかできないことを減らしていくことが、効率化のカギであり、プロフェッショナルとしての態度でもある。様な気がする。
2012-04-04 17:21:45 via web
自分で抱え込んでおいて、周りを無能扱いする反面教師はよく見かけます。
メアリーさんトレーニング中曰く、開発組織でよくある大きな二つの問題がある。一つは開発の問題。エンジニアはよく知っていると思う。もう一つはビジネスの問題。ビジネスピープルでまとめるんじゃなくて、『誰が』がわからないとダメ #rakutendojo
「本から得た知識ばかりだと、説得力がない。」とのご意見を頂いた。まさに最大の問題。実践していくことが大切。しかし説得力がないと実践を始められないという、ニワトリと卵問題。現状は学ぶフェーズではなく、実践するか、実践するために必要な取り組みをするフェーズであることは間違いない。
2012-04-12 17:50:58 via web
ゆとり社員が仕事しないのは当たり前です - デマこいてんじゃねえ！ (id:Rootport / @rootport) URL
ものすごくためになる。そして、少し長いが読みやすい。 / 戦略(Strategy)、作戦(Operation)、戦術(Tactics)、そして兵站(Logistics) - UEI/ARC shi3zの日記 URL
2012-04-17 12:31:00 via web
戦略とは何か。
顧客の財布を自分の財布だと思うというのは、価値になることに注力し、価値にならないことはやらず、責任を持って行動する、ということだと身にしみてきた。責任をとって行動するというのは、xxが悪かったとか言い訳して諦めたりせずに、全力を尽くすこと（場合によっては出来ない事を伝えること）
2012-04-17 13:34:23 via web
当事者意識は非常に大切です。
ビジネスモデルを考える。
振り返りや改善のような、先を見据えた作業を行う為には、「体力があるときに」「それを行う為の（それ以外行ってはいけない）」「固定の」時間がないと上手くいかないんだろうなー。私がそうなので。帰宅時間が遅くなると、起床時間が遅くなり、最終的に全ての先を見据えた行いが犠牲になる。
2012-04-17 21:08:23 via web
私は不真面目なので、こういったことは半強制がよいのです。
「痛みを伴うものはこまめに実施し、痛い思いは早めにしておけ」「できるようになりたければ、練習しろ」。私はここが肝だと思う。継続的デリバリも、アジャイルも。 #cdelivery
2012-04-21 21:37:30 via web
アジャイルなマインドを持ったメンバーで、プロジェクトを上手く回す方法よりも、アジャイルなマインドを持っていないメンバーのマインドをどうやったらアジャイルに出来るか、の方が需要が高い気がする。供給できるのかは分からないが。
2012-04-26 09:32:47 via web
5月
主なイベント
- 5月10日 アジャイルサムライ読書会 横浜道場 「全体像を捉える」
- 「アジャイル開発基本のキ リターンズ 完全版」#agilesamurai #横浜道場 - ヲトナ.backtrace
- スクラム道 Full Boost 「青物横丁制圧作戦」 | スクラム道
- 5月21日 全員スクラムマスター。(東京都)
- アジャイルサムライ読書会 新宿道場#6 - connpass
- （受付終了）【有料セミナー】要件定義をかえる！ユーザーストーリーで実現するコラボレーティブなビジネス開発ワークショップ ｜ 永和システムマネジメント
- 継続的デリバリー座談会 in 新宿 #2 - connpass
- ジャネット・グレゴリー 「実践アジャイルテスト」研修 5月29日〜30日 (同時通訳付き) - アギレルゴコンサルティング株式会社
ツイート
まさに! / 複雑なものを構造を与えて単純にするんです。それが設計じゃないですか。 / 人月を超えるエンジニアリングの未来 - GoTheDistance (id:gothedistance) URL
Less is more. Simple is best.
「次に予定されている会合を単にキャンセルしましょう。それでも問題ない事が分かります。」これは本当かどうか怖い。私が設置している話し合いも、本当は不要なコストな可能性もある。考え直してみたい。
2012-05-20 00:01:58 via web
個人で作るチェックリストは役に立つのに、押し付けられるチェックリストが邪魔にしかならない理由は何かというと、後者は「コンテキストにマッチしていない」「そもそも改善したくても出来ない」からだと思う。
2012-05-24 12:27:32 via web
理屈っぽい人にそれらしい指摘をされると、そのまま受け入れがちだが、必ず次の質問を投げかける必要がある。「それが出来ると何が嬉しいのですか？」。理屈には説得力があるが、それだけで納得してはいけない。ちなみに、私に理屈っぽい指摘を投げかける人の筆頭は、私自身。
2012-05-27 10:54:21 via web
「それは網羅的に考えたのか？」「網羅的に考えると何が嬉しいのですか？」「抜け漏れをなくすことが出来る」「抜け漏れをなくすと何が嬉しいのですか？」「嬉しいに決まってる！」「確かに。でも○○よりも優先ですか？」位は闘う必要有り。ほとんどの事は「やらないよりやったほうがいい」ので。
2012-05-27 10:57:12 via web
思考停止を避ける簡単な方法。何かに脊髄で反論しそうになったら、同じ事を自分が尊敬する人がいってもそれを批判するかどうか考える。何かに手放しで賛成しそうになったら、同じ事を自分が距離を置きたい人が言っても賛成するかを考える。
2012-05-27 23:24:01 via web
脊髄反射って意外と誤ってるよね。
要件定義工程とテスト工程に手を付けず、途中だけにScrumを適用しようとすることは、Scrumが解決しようとした「誤った前提」( URL を参照)が、実は誤っていなかったのだと主張するに等しい。
アメリカ式がいいよね「日本での仕事のすすめ方は製品の発売というような大きなゴールがあって、その中で明らかになったタスクに対しリソースが投入されていく感じ」「アメリカでの仕事のすすめ方は限られたリソース内でできることを積みあげていく感じ」 URL
顔見知りになっているかどうかだけでも、コミュニケーションコストは相当違う。
2013-01-02 16:14:13 via web
TED
常に選択の余地を与え続けるのがよいとは限らない。
Fearless Change
その価値は、ステークホルダの価値観やコンテキストに本当に合致するの？を分かりやすく伝える。/ Tailor Made: 新しいアイデアから得られる価値を組織の人に納得してもらうには、組織の必要性に合わせてあなたのメッセージを作る。 / URL
2012-05-19 10:35:17 via web
組織のコンテキストに合わせる。
目から鱗。これは大切/ Sustained Momentum: 忙しいからと言って、改革の推進が疎かになってしまうと、あなた自身や周囲の人が新しいアイデアに興味を失う。重要度は問わないので、目標に近づくように毎日少しでも活動する。/ URL
2012-05-19 10:39:20 via web
慣性の法則。
企業での催しに使えそうな考え。でも、勉強会とかでも普通に活かせるかも。 / Token: 新しいアイデアを覚えてもらうには、紹介した話題につながるトークンを渡す。/ 最初に聞いたときには熱狂していたことも、明日には冷めてしまう。/ URL
2012-05-19 10:43:01 via web
名前重要。あーあれね、と言ってもらえる存在にする。そしてそれを認識してもらう。そうしないと話題にすらあがらないので。/ Group Identity: 変革の取り組みにアイデンティティを与えて、その存在を認識してもらう。/ URL
2012-05-19 10:49:04 via web
AIDMAのAとIをとりあえず達成する。精神的な距離を縮める。/ In Your Space: 組織にリマインダを設置して、新しいアイデアを可視化する。新しいアイデアに関する情報を、皆の目に見えて議論出来る場所に投稿する/ URL
2012-05-19 10:55:25 via web
一次情報を死守せよ、という奴ですね。説得力が全然違いますし。単純に考えが誤っていることも多いでしょうし。細部の詰めも。/ Just Do It: 新しいアイデアを広める前に実際に仕事で使ってみて、その利点や限界を知る。生の情報を集める。/ URL
2012-05-19 19:17:07 via web
翻訳がよく分からなかったので改訂。彼らのコンテキストで分かりやすく話す。非常に重要ですね。/ Personal Touch: 新しいアイデアの価値を説得するには、彼ら個人にとって、便利なことや重要なことを説明する/ URL
2012-05-19 19:27:19 via web
個人という視点を意外と忘れがち。
なるほど。Tokenとセットでやりたい。/ Next Steps: 新しいアイデアに関するイベントの終わりに、参加者が次に出来る事を見つける。どうすれば参加者が新しい情報を適用出来るかを、プレゼンテーションの終わりに議論する。/ URL
2012-05-19 19:30:08 via web
こちらも相手の視点。
目から鱗。いろいろアイデアはありそう。/ Piggyback: 新しいことを導入する戦略に障害物があれば、組織のプラクティスに便乗する方法を探す。組織で既に受け入れられているプラクティスに便乗して、障害や手続きをショートカットする。/ URL
2012-05-19 19:32:52 via web
重要なワザ。
まさに今日風呂場で考えてたことかも。/ Champion Skeptic: 懐疑的なオピニオンリーダーに「反対派代表」や「現実主義者代表」の役割を担ってもらう。気持ちを変えられなくても、彼らのコメントを使って取り組みを改善出来る。/ URL
2012-05-19 19:36:41 via web
Dedicated Champion: 変革の取り組みを仕事の一部として認めてもらう。新しいアイデアを効果的に組織に導入するには、ボランティアでは荷が重すぎる。/ URL
2012-05-19 19:40:56 via web
6月
主なイベント
- 6月7日 アジャイルサムライ読書会 横浜道場 「具現化させる」
- 6月21日 アジャイルサムライ読書会 横浜道場 「荒ぶる四天王」
- 6月27日 アジャイル守破離 事例編(東京都)
- 社内でアジャイルについて説明する場があった
- 若手育成期間なるものが終了
改めてイベント振り返り
教科書通りにやることが目標化し、問題の原因を、その通りにやらない人に求めるようになる。
2013-01-02 16:55:50 via web
ツイート
それを実施出来るメンバーがいない「解決策案」は幻想。 #agilesamurai #横浜道場
2012-06-08 01:26:51 via web
Fearless Changeに「Just Enough」というパターンがある。初めは詳細を省いて難しい事を分かりやすく伝え、時が来たら徐々に詳細を伝えて行くと言うものだ。この能力が、今とても欲しい。
2012-06-05 22:33:28 via web
Just Enough。ついついすべて伝えようとして何も残らない、なんてことはありがち。
チームメンバー全員での共通理解（e.g. Doneの定義, ビジネスの用語で書かれた"ストーリー"）、進捗や予定・問題などの見える化、誠実さ（隠さない）等をひっくるめて、「透明性」と読んでいるのかな。検査を行い、適応する為の前提条件で、これらは三つで一セットである、と理解。
2012-06-06 20:39:36 via web
スクラムチームの説明に、自己組織化、職能横断型という見慣れたフレーズを発見。いつも思うのだが、これらが満たされた方が「よりよい」ことには賛成するが、スクラムの目指す価値を満たすのに必須かと言うと、今ひとつ腑に落ちない。アジャイルマニフェストに記載があるからと言えばそれまでだが。。
2012-06-06 20:53:05 via web
自己組織化していないと、自らプロセスをカイゼンして行けないからだろうか？しかし、穿った見方をしてしまえば、チームの「リーダー」さえプロセスをカイゼンするスキルと気概が有れば、プロセスはカイゼン出来そうな気もする。むー
2012-06-06 20:59:05 via web
睡眠時間を削るのは、まさに明日の資源を食いつぶす行為だ。と考えてて、北斗の種もみ爺さんを思い出した。
2012-06-13 08:45:04 via web
すべての人は天才だ。しかし、もしも魚が木登りの能力で評価されるとしたら、その魚は自分をばかだと思って一生を過ごすだろう / 「豊かさ≠幸福」だということ - デマこいてんじゃねえ！ (id:Rootport / @rootport) URL
ビジョンをはっきりさせず、顧客の言う事をはいはい聞いていると、企業はコモディティ化すると言う。ということは、ビジョンをはっきりさせず、会社の言う事をはいはい聞いていると、自分もコモディティ化するのではないか。コモディティ化すると、いかに安く早く多く提供するかの勝負に。。。
2012-06-18 20:07:14 via web
コモディティ化怖い。
SIerがなぜ銀の弾丸を追い求めるのか分かったぞ！銀の弾丸の存在なしでは、ソフトウェア開発の属人性を排除出来ないからだ！プラグマティックな解決法を取るしかないからだ！ってみんな知ってるかも。私の中でやっと「No Silver Bullet！」が何故常識化しないのか腑に落ちたので
2012-06-18 20:24:16 via web
属人性が排除された職場で働きたくない。というのもあるが、そもそも属人性って排除できるの？
マインドマップを書いてから実装に移すまでに、もうワンステップだけ見直しを含めると、手戻りを減らせて効率的な予感。
2012-06-20 08:57:42 via web
このあたりのバランス感は重要。
某スクラムマスターが、「『普通の人』は準備万端整っていてリスクもなくて実績があって、あとはチームにジョインするだけ！」まで整えておかないと乗ってこない。そんな学校で一番かわいい子が告白してくるようなエロゲみたいな展開ねーよバーカ！みたいなこと言っていた。
きっとすごいスクラムマスターが幼馴染で、その幼馴染は自分の隠れた良さに気付いてくれてたんじゃないかな。
私の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
