Buttonとてもやってみたくなった。『...同時に「要求という言葉が嫌いだ」とも書かれています。...ひどい言葉だね。buildingののち、価値を伝えて理解を得られたら、という道のりになるわけだ。顧客に価値が伝わらないなら、きっとあまりやるべきではないのだろう。この視点はあまり無かったな。言われてみれば・・・ってことなんだけど。TweetDeck逆に言えば、そう思えないドキュメントは削減しつつ、本質的なものは洗練させていくと。2013とても夢を感じた。「よし、やってやるぞ!」感が毎回半端じゃなくでるデブサミマジック。さんの「汚いコードで開発スピードだけを追い求める事は出来る。web興味深くて一気に読んでしまった。Button製品は最初から英語で作るべき結果、超単純な英語か言語に依存しないユニバーサルなUXに逆になりやすい!日本のウチワの文脈を持ち込ませない。iPhoneとても勉強になります。たのしい自分戦略に参加しました。今自分がいる枠組みの意味を理解し、そして一度ゼロベースで理想型を考えて、もう一度戻って来よう!で、組織という枠に「なんとなく」隷属することなく、その良さも問題も知って、積極的に活用して企業人ライフを楽しもう。OpenCU一日目に参加してきました。よって、最近の言語は「表現力」を重視する方向になっている。モック使ってたんだけど、本物の方の動きが変わってた。他のテストも併用しないといけないのか。HootSuitechef「初めてのChefの教室」を開催しました。ButtonITScommitログにITSのチケットIDを打ち込むのが面倒になってきた。うまいソリューションないかな?Mylynとかを使えばいけそうな気もするが、Mylynはあまりしっくり来なくてやめてしまったんだよなあ。再チャレンジしてみようかなあ。web細かいようで大切なこと、だと思う。Buttonビジネス・SIEmpathyとかAssuranceも考える。web「顧客が出す金」=「顧客価値」でしょ。それ以外に定義のしようがないし、一致しないケースがあるとすれば取引当事者間の情報格差が大きい場合で、平たく言うと詐欺。学びは「Action」の視点でまとめた方がよいことに気付いた。自然に内容が凝縮されるし、行動につながりやすいし。いう流れでまとめてみるのはどうだろう。web「頑張っているので許してください」という言い訳の向き先は、上司でも顧客でもなく、自分自身になりやすい。頑張っているので人に迷惑をかけても仕方がない。頑張っているので解決策を検討する余力がなくても仕方がない。頑張っているので長期的視点でのデメリットを考えるのはつらいけど仕方ない。webそんな一大決心みたいに意気込まなくても、「あ、この人とは一生付き合っていきたいな」みたいななんとなくな覚悟でも、相手にはけっこう伝わる。「今自分が過ごしているこの空間を大事にしたいなー」とか。場を大切にしようって思いはけっこう皆、無意識下に汲みとってくれるように思う。twittbot.netアクティブリスニングのコツの1つ:「結論に飛びつかない。自分の理解が正しいか相手に確認する」。web「やらない明確な理由がないからやる」のか、「やる明確な理由がないからやらない」のか。この文化の違いが、違いが、、、。「選べないことに気付いていない」場合があるのが厄介。当たり前になってしまったことこそ見直すべき、とはよく言われますね。Button暗黙知と形式知は違うものだ、と認識するだけでも大きく違うのではなかろうか。言う認識が意外とありがち、な気がする。知識は壁越しにぶん投げて共有できるものと思ってドカーン。今日のプログラミングは、...より上級の、馬鹿でも使えるプログラムを構築する努力をしているソフトウェアエンジニアと、...より上級の馬鹿を生み出そうとする宇宙との間の競争である。1月のツイートをまとめた備忘録。グルーピングは非常に適当。DevLOVEツイート「考えないための標準化」はダークサイド。標準はかならず失効日を決める。webプロジェクトを止めるのに説明が必要、ってよく聞くんだけど、ものすごく危ない状況だよそれ。プロジェクトを進めるのに説明が必要という状態を保っておかないと。YoruFukurouNoから始める。毎回根拠を確認し、なくなったら自動でやめられる仕組みづくりが大切。色んなワークショップのお手伝いを何度かやって気付いたことが一つ。チームの生産性を上げるのは、「多様性」と「それを活かせる優秀なファシリテーター」。傍から見ていると15分程度のワークでさえ劇的に差がつくのだから、それが数ヶ月におよぶ普段の仕事を考えると怖い。Mac多様性重要ボーイスカウトルール私の完璧主義思考から生まれるよくないパターン。web「完璧主義はxxの問題があるのでよくない」というより、「ボーイスカウトルールやろうぜ」といったほうが楽しい。我が家の(最低限の)清潔さは、ボーイスカウトルールによって保たれている。webボーイスカウトルールは楽しいですし、initialコストゼロです。目的は表現されるが、その目的が本当に正しいか(本当に顧客が求めている?お金や導入コストを支払ってくれる?そもそも顧客って誰?)があまり表現されない(少なくとも、私は表現できていなかった)。adopterが誰かを深く考えていなかったかが分かる。マーケターなら当然のことかもしれないが、私は出来ていなかった。webよいKPIの3原則の1つ「KPIは作業者にとって、興味深い作業の一部である」。私は自分がどのプロジェクトにどのくらい作業を割り振ったかの実績等全く興味がないので、誰か適当に書いておいてほしい。webKPIを決めるのは、とてもとてもスキルが要る。不機嫌の8割は、自分が受け入れている常識を破る人に対する怒り「許せない事なんてない。許したくないだけ」か、自らの非を認めたくないために、無意識のうちに相手の非とする怒り「悪いのはあちら」でなりたっている。本来不機嫌になるほどでもない。web「これはタイプの問題じゃない、土俵の問題だ。要するにおまえはまだ実践という土俵に上がっていないんだ。ソフトウェアを脳みそからひねり出した理屈なんかで計ろうとする。見当違いもはなはだしい。背の立つところまでしか海に入ってないのに、俺は海を知ったと公言してるようなもの。Buttonアジャイルになる、系のおはなし導入でなく、少しずつ目指すものに対して変容して行くものだ、という考え方があり、私はこの考え方が好きです。メンタルモデルの変化が必要なものの「導入」って大抵自己満足。「アジャイルを」「導入」とかだと日本語としておかしいと感じる。webアジャイル導入!とか、その時点で少しもアジャイルじゃないし。気付くと「アジャイルになる/する」ことが目的になっていることがあって、そのたびにはっとする(というか、こうなっているときは周囲への愚痴しか出てこなくて少しも建設的でない)。「何のために」を元にしないと上手くいかないし成長もしない、と思う。web最初あった志は、ともすると簡単に忘れられて手段だけが残る。「皆さんは赤いピルを飲みたいんでしょう?青いピルのスクラムをやるんですか。Button野中先生の講演は、新しい視点や思考の枠組みを得られたことだけでも十分すぎるほど素晴らしいが、感動やInspireを得られた点がすごいんだな、と、講演メモを見返していてしみじみ思った。web目から鱗が落ちる講演(これだけでも十分すぎるほど凄い)は何度かあるが、感動する講演はなかなかお目にかかれない。無知は間違った自信を増幅する。web直観的に、そしてこれまでの経験則からして、これは絶対正しいと思う。web改善って、そもそも目指すところはある程度理解できている前提。スクラムの基本用語を知っている方なら気軽に遊べる、各プラクティスにおける要素毎の優先順位をつけて、それが偉大なる先人(Cope含む)とどの程度マッチしたかが見られるゲーム。遊んでいるといろいろ気づきがある。webパターン改めて見直す。考える契機になることと、とりあえずのヒントを与えてくれる事と、共通言語になるところがパターンの素晴らしいところか、と浅学ながら思ってみる。Button今、パターンが(私の中で)とても熱い。SIerなどエンジニアのSI業界ディスって、「誰にとっての問題か、どのような意味で問題か」の問題定義がすごく弱い印象。「問題だ問題だっていうけど、それお客さんが言ってたんですか?」と聞くと「まずお客さんを変えていかなければ」とか平気で返ってくる。「未発掘のニーズがある」ならわかるが。iPhone悪意がある元請け/上位者をどう扱うか、みたいな議論がよく起こるけど、これはもう相手に悪意がある以上、騙すか騙されるか逃げるかしかないような気がして、騙すのも騙されるのも私は嫌なので、逃げの一手です。webSIerにいるエンジニアが残念な気持ちになる現場の現状リストかと思った。web手近な不満点に反応的になるだけでは籠の中の鳥。システム思考、ビジネス全体の理解、それと大前提の自己マスタリー。このあたりがカギか?仕事のフローを見える化し、一番のボトルネックを改善する。web「幸福度」は間違いなく重要な指標。必要なのはやることリストではなく、やらないことリストな気がする。いうか、私の今年の抱負はいつになったらできるのか。一応毎週振り返りしているので、それでよいといえばよいのだが。web「やりたいこと」って放っておくと無尽蔵に増えて、次に何をやるかについて「分析麻痺」状態になりがちですので。Buttonこれも実践の積み重ねかなー。その他amazonで「スクラム」を検索しようとして「すく」まで打ったところ、検索キーワード候補のトップ5が全てスク水で残念な気持ちになった件。retargetingの結果ではないことを信じたい。「可愛い」って言われたときの女の子の反応一覧だって。iPhoneやっぱ4だな。便宜上アカウントがあるだけでほぼ利用していなかったFacebookを、本格的に利用してみようと思っている。横浜道場に参加させて頂きました。下記、勉強会にインスパイアされて、私が学んだ/感じたことのまとめです。※例によって、勉強会のまとめではなく、内容のごく一部にしか触れていないことにご注意を。顧客に価値ある成果を届けること「イテレーションのゴールは、お客さんに取って価値ある成果を届けることだ。本日は、これまで何気なく読み飛ばしてしまいがちな一文に引きつけられました。「設計書」のような、その時点では何者でもないもの納品出来ない品質のコードではよくない、というのはもちろんなのですが、それだけでは何も生み出さない「機能」もう1イテレーション実施すれば、価値を生み出すであろう「中間物」とりあえず動くソフトウェアでも充分でない。重要な点として、下記を感じ取りました。「ストーリー」を実現するフィーチャーを作っても、「お客さん」に「価値」を届けなかったら意味がない。お客さんは誰なのか、この1イテレーションの間に、「価値」を届けるにはどうすればよいか。その中でも最も優先度の高い価値は?一文から改めていろいろと考えさせられました。※私は、何となくふわっとした「とても抽象的な」レベルの「顧客」が、「もしかしたら必要かもしれない」何かをする、そんなレベルのストーリーを記述しがちだったで、よい学びとなりました。具体的な顧客像、具体的な顧客の課題感(の仮説)が大切。必要なとき、必要な分だけいち早く価値を届ける為には、早すぎる最適化を防止し、「選択と集中」を行う必要がある。分析やバックエンドの準備は、必要なとき、必要な分だけ。必要なとき必要性を感じた時がそのとき「DB」も、必要が生じたタイミングでアーキテクチャジャンプをする、のがよい?必要な分だけ分析なら、プランニングポーカーで、見積もりのコンセンサスが得られる程度の分析。チームのレベル、ドメインやアーキテクチャへの習熟度にも(もちろん)依存。さん、皆さん、素晴らしい場を設けて頂きありがとうございます。connpassに参加させて頂きました。下記、勉強会にインスパイアされて、私が学んだ/感じたことのまとめです。※例によって、勉強会のまとめではなく、内容のごく一部にしか触れていないことにご注意を。※そして、開催者によるこれ以上ないクオリティのまとめ記事はこちら。次回の募集も始まっているので、ご興味をもたれた方は是非!モックとスタブの違い「モック」と「スタブ」ではassertionのタイミングも対象も違う。最後にassertion。sutのモックの扱いかたをテスト。最初にassertion(を指示)、かな。mock)ので混同しやすいが、役割も注目点も違う。webモックによって、オブジェクト同士の「今注目している」会話だけに着目してテスト出来る。モック使ってたんだけど、本物の方の動きが変わってた。他のテストも併用しないといけないのか。HootSuiteモックの本当の価値モックを用いる事で、SUTと依存オブジェクト(これをモックにする)の、今注目すべきやりとりに集中し、テストとして定義することが出来る。これはどのような価値を生み出すのか。正直なところ、私にはまだ熱く語れるほどの実感がない*1。SELECTION)にはこうある。私たちは、実行時のシステムをコミュニケーションしあうオブジェクトの網の目と捉える。したがって設計時には、必要な機能を実現するために複数のオブジェクトがどう協力し合うかという点に注力する。確かに、クラス構造はうまく設計したい。オブジェクト間のコミュニケーションパターンの方が重要だと考えるのである。Javaのような言語では、インターフェースを使ってオブジェクト間のやり取りに使えるメッセージを定義できる。同時に、コミュニケーションのパターンも定義する必要がある。これは言わば、コミュニケーションプロトコルだ。命名と規約を使って出来ることはやるが、インターフェース同士の関係やインターフェース内のメソッドの関係を記述する手だてが、プログラミング言語には用意されていない。そのため、設計において非常に重要な箇所が暗黙的なままになってしまうのだ。私たちがモックオブジェクトと共にTDDを用いるのは、こうしたコミュニケーションプロトコルを明示するためだ。私たちが主張して来たのは、互いに命令を送り合うオブジェクトに集中すること、そして、その状態を問い合わせる方法を一切露呈させないということだ。これでは、ユニットテストでアサートする手段がなくなってしまったのではないだろうか。...テスト対象のオブジェクトの隣接オブジェクトを、テスト中に代用品と置き換えるやり方の一つとして、...モックオブジェクトを使うことで、起点となるイベントに対して、テスト対象のオブジェクトがどのように隣接モックとコミュニケーションするかについて、自らが期待する内容を定義できるのだ。した定義のことをエクスペクテーションと呼ぶ。テストをしている間は、期待された通り呼び出されたことをモックオブジェクトがアサートする。...こうしたテスト基盤を適切に用いれば、TDDでの作戦を変える事が出来る。...私たちはただテスト対象のオブジェクトだけをテストしたいのだということ、それから、隣接オブジェクトがどのようなものであるかが、既に分かっているということだ。実際には、ユニットテストを書いている時点では、こうした協調して動作するオブジェクトは存在していなくても構わない。テストを使う事で、自分たちのオブジェクトが必要とする補助的なロールを明らかにすることができるのだ。したロールはJavaのインターフェースとして定義され、実際に実装されるのはシステムの残りの部分を開発するときだ。私たちはこれを、インターフェースの発見と呼んでいる。コードを書く上で非常に重要な観点に触れた気がする。web実践と、合わせてGOOSの熟読をしたい。#junitbookに参加しました。本日はありがとうございました。web*1:恥ずかしながら、私は普段スタブは使っても「モック」を使った事がない。twitterに呟いていますが、twitterに書ききれない事をここに綴って行こうかと。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。