KPTでトライ狙いすぎ問題 - @ledsun blog
KPTは「チームの力で問題を見つけるふるまい」の養成ギブスです。 ふるまいに慣ていない間は違和感があります。 たとえば次のような問題が起きます。 トライ狙いすぎ問題 KPTの「改善活動」の面に強く期待しすぎて生じる問題です。 無意識に、KPTの成功指標を「TRYの数」にします。 TRYを出すことに意識をとらわれると、慣れている「個人で問題を見つけて解決する」方法を取ることがあります。一つのKPTの場に集まって、参加者がそれぞれ別々に問題を発見して解決します*1。 すると、途中のプロセスが無駄に見えると思います。特にKeepに意味を感じないのではないでしょうか？アイスブレイクの一緒だと思ってはいませんか？たとえばKPTの参加者にKeepを出していない人が居ても問題ないと思っていませんか？あるいは、時間短縮のため事前にKeepやProblemを用意していませんか？ KPTをK→P→Tの順に進め
タスクの完了からはじめるプロジェクト進捗管理 - @ledsun blog
何の話？ タスクの進捗状況をパーセンテージで管理することがあります。 例えば、進捗報告会議で現在着手中のタスクAの進捗を報告するとき「50%完了しています。」という報告の仕方です。 進捗を「タスクの進捗率」で測る方法には、ちょっとした問題があります。 「予定しているタスクのうち2つ完了しています。残りのタスクは3つです。」というように、完了したタスクの数と未完了のタスクの数で報告すると、プロジェクトの進捗管理が、すこし良くなります。 どんなメリット？ プロジェクトの進捗を「タスクの進捗率で測る」方法に比べて、「完了したタスクの個数を数える」方法は、早く正確な進捗情報が手に入ります。 早く正確な情報が手に入れば、プロジェクトが遅れたときにとれる対応策の選択肢が増えます。 お客さん（ステークホルダー）とスケジュールの調整をする プロジェクト全体で確保してあるバッファを使う 予想より早く作業が進
1on1ミーティングのやり方 - @ledsun blog
1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。 前提条件 弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。 インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。 面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。 やり方 人数 インタビュワーは6人います。ベテランエンジニア5人と営業1人です。 インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。 組み合わせ もっとも長い期間面談をしていない組み合わせで実施します。 組み合わせは、モンテカルロ法で抽出します。 そ
人はFat Modelを恐れサービスを求め ドメインモデルは貧血に至る - @ledsun blog
この文章は祈りです。 主にRuby on Railsアプリケーションを想定した話です。 Ruby on Railsアプリケーションでは、Fat Model問題という問題が起きることがあります。 ドメインオブジェクトが肥大化しメンテナンスしにくくなる問題です。 Fat Model問題に対応するためにサービスレイヤーを導入することがあります。 「ドメインモデル貧血症」と呼ばれているアンチパターンです。 ドメインモデル貧血症 ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。 Fat Modelを恐れよ Fat Modelは「単一責任原則」を満たしていないモデルです。 単一責任原則 | プログラマが知るべき97のこと 1つのサブシステムやモジュール、クラス、関数などに
忍者式テストとは？ - @ledsun blog
「忍者式テストの定義が知りたい」という意見を観測しました。 実践者の一人として、現時点の理解を記録します。 簡単に言うと？ どういうときに向いている？ どうやって実施する？ 準備 最新のプロダクトをユーザー（の立場）で操作できる環境 手動テスト項目 毎日の作業時間（数分 〜 1時間） 嬉しさ 小さなテスト手順書から始められる 発見がある テスト手順に対して プロダクトに対して 新しいバグ バグを埋め込んでから発見するまでの時間が短い 何ではないの？ 歴史 その他の参考情報 名前 おまけ 簡単に言うと？ 忍者式テストは、手動テスト手法の１つです。 開発者が、日々のテスト実施を通して テスト項目 ユーザーとしての視点 テスターとしての視点 を育てていく手法です。 どういうときに向いている？ ユーザーインターフェースのテスト プロジェクトに参加したての時 プロダクトの目的、機能をよく知らない プ
npm auditは有益なのか？ - @ledsun blog
体感として、npm auditが出してくる警告は、利益より手間の方が多いように感じてはいます。 とはいえセキュリティに関わることなので、手間でも対応しなきゃなあと、頑張って対応しています。 僕自身は、主にアプリケーションのメンテナンスだけなので、それほど大変ではないのですが、chokidarのような色々な開発ツールで使っているパッケージの脆弱性が報告されると、対応が面倒です。 chokidarを使っている複数のパッケージを更新しないといけない パッケージによってすぐに更新されたり、しばらく時間が掛かったりする ので、in progressなタスクが居座るのが面倒です。 パッケージメンテナーの人は、加えて、ユーザーから早く直せという要望が来て大変なのだろうなあ・・・と思います。 これに関わる話が、DHHのコメント/bin/importmap outdated · Issue #19 · ra
#TestingFrameworkMeeting に参加しました（１） - テスティングフレームワークの歴史 - @ledsun blog
参加した時のメモです。 t-wadaさん Testing Framwork Meeting テスティングフレームワークの歴史 http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。 有史以前 make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。 JUnit Kent BeckがJUnitを書いた。 1994 SUnit 1997 JUnit プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。 テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。 自動テス
技術的負債の数え方 - @ledsun blog
技術的負債の数え方に関する与太話。 落ちを先に書くと「シュレディンガーの猫」って言いたかっただけです。 技術的負債とは Ward Cunningham 曰く 最初のコードを出荷することは、借金をしに行くことと同じである。 小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。 危険なのは、借金が返済されなかった場合である。 品質の良くないコードを使い続けることは借金の利息としてとらえることができる。 技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、 立ち尽くす羽目になる 技術的負債 - Wikipediaから引用 要約すると「汚いソースコードは後で直すのが大変。けど、拙速も大事」という話です。 数え方 「技術的負債が借金だとすれば、いくら借りているのか数えられるのでしょうか？」が今日のお題です。 技術的負債を観測する方法 Michael F
オブジェクト指向設計とは - @ledsun blog
オブジェクト指向という言葉には オブジェクト指向分析(OOA) オブジェクト指向設計(OOD) オブジェクト指向プログラミング(OOP) の三つの意味があります。 オブジェクト指向初心者泣かせです。 ここではオブジェクト指向設計を説明します。 ソフトウェアの設計 ソフトウェアの設計には二つの側面があります。 作成するソフトウェアの共通部分を探し出しモジュール化する 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする 一つ目のモジュール化は構造化設計からある手法です。 オブジェクト指向設計で特に取り上げる点はありません。 ここでは二つ目の将来の変更のために抽象化することに重点を当てます。 オブジェクト指向設計 オブジェクト指向設計とは多態を実装する部分を決めることです。 多態とはオブジェクト指向言語を活用した次のものです。 変更可能な点に抽象クラス*1 （オブジェクト指向言語
えぇー！MVCのContollerはプレゼンテーションロジックのinput担当だったのかい！？ - @ledsun blog
この話はMVC（Model-View-Controller）の話です。 特にクライアントMVCの話です。WebMVCの話ではありません。 事前 ViewとModelを分けるためにControllerを挟むのだと思っていました。 事後 Contollerはプレゼンテーションロジックのinput担当でした。 参考文献 The Model-View-Controller (MVC) Its Past and Present を読んでください。すべてが書いてあります。 本題 WebMVCから考えた俺のコントローラー そんなことより聞いてくださいよ。 WebMVCからMVCに入った口としてはViewとControllerの分け方なんて考えたこともないんですよ。 分かれてて当たり前ジャンと思ってたんですよ。 ところがJavaScriptで3000行くらいあるDOMをゴリゴリするアプリケーションをいじっ
新人エンジニアにレポートを書かせて技術書の読み方を伝える。 - @ledsun blog
技術者が1~3年目で成長するかは自習するかに依存してる。業務とは別に勉強する方法を叩き込めば誰でもそれなりに出来るようになる。 そんなわけで僕の所属している会社では年に5冊指定した本を読ませてレポートを書かせている*1。 なぜレポートを書かせるか 僕の所属している会社が採るような大学生は自習しない。分からないことや知りたいことがあっても本を買わない。業務をやるうちに実地で学べることはあるのだけど、実際に自分がやっていることが世間でどれくらいの位置づけなのか知っておくとなお良い。理想的な手法が使えているのか、それとも現場に合わせて翻訳して使っているのか。本に書いてあることと一致していれば普遍的なことなので覚えておけばいいし、書いていないことをやっているなら、下手をうっているか、現場に合わせた調整をしたかどっちか。そういうことを知っておくと違うプロジェクトに移ったときに同じ名前でちょっと違うこ
社内勉強会はヤメだ。自主的はいらん、全員技術発表だ！ - @ledsun blog
社内勉強会について僕にも思うところがある*1。 社内勉強会をやらない理由 - 勘と経験と読経 社内内弁慶を社外勉強会に参加させる方法: ソフトウェアさかば 最初に言っておくと弊社は20人くらいしか居ないし、受託開発と派遣が半々くらいのSIerだ。 id:kent4989 の会社とはだいぶ状況が違う。 社内勉強会はやらない 結論から言うと社内勉強会はやっていない。やらない理由は発表者のコストが高くてメリットが少ない。 勉強会のつらさ IT系の勉強会のノリだと テーマに対して興味のある人が少なく参加者が少ない 最新ネタは業務と離れすぎていて、継続する努力がハイコスト過ぎる 研修のつらさ 教育を重視して基礎的な内容をやると 基礎的な内容だと教える側が刺激が足りなくて飽きる 教える側が教えるほどは理解していないので、事前準備がハイコスト過ぎる そんなわけで社内勉強会をやるのはやめました*2。 技術
JavaScript殺法 11のリファクタリング - @ledsun blog
JavaScriptを書いていてぶち殺したくなった時によく使うリファクタリングです。 1.定義順を整理 JavaScriptパターンの5.4.1 モジュールパターンの開示を参考に、var、処理、API公開の順に並べなおす。 function () { //宣言 var hoge = 'hoge', fuga = ''; //処理 fuga = foge; //APIの公開 return { hoge: hoge, fuga: fuga }; } 2.戻り値をオブジェクトにする 戻り値を増やしたいときにまずオブジェクトに変えてから、値を増やす。 型付けが弱い言語は二つ以上の値を返すのが当たり前なのが凄い。 function () { return { hoge: hoge, fuga: fuga }; } 3.戻り値をオブジェクトでなくす 「戻り値をオブジェクトにする」の逆。 戻り値を一つし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
