Hatena::ブログ(Diary)

yujiorama の日記

2017-09-25

XP祭り2017で参加した「振り返りを振り返る」ワークショップのメモ

XP祭り2017:さまざまな振り返りを知り,振り返りを振り返る (栗田 太郎さん)

チームまたは個人の仕事において,振り返り (ふりかえり),リフレクション,レトロスペクティブなどと言われる活動には,

さまざまなフレームワーク (“KPT”,”YWT”,”ORID” など,また,KPT だけでも多くのバリエーション) と課題があります.

本ワークショップでは,参加者の皆さんの日頃の目的と工夫と課題の共有,いろいろなフレームワークの試行と比較,

振り返りにまつわる対話,を通して,日常の振り返りを多様な視点から振り返り,振り返りの意義と意味について考えていきます.

いろいろと話題の講演がある中、裏番組的なワークショップに参加していました。

懇親会でもいろいろお話を聞くことができてとてもためになりました。

関係ないけど、レトロスペクティブやイントロスペクティブの スペクトは「よく見る」という意味らしい

やったこ

  • ふりかえりのフレームワークの講義
  • マシュマロチャレンジ を実践
  • マシュマロチャレンジについて ORID で「ふりかえり」
  • 「各自がふりかえりで課題だと思っていること」について「KPT でふりかえり」
  • ワークショップ全体について「YWT でふりかえり」

最初に説明があったわけではないので、すごくメタい構造だった。

ふりかえりの由来

  • 「ふりかえりとは基本的に内省のことである」
    • プラトンまで遡るので人によっては気味が悪くなる可能性がある
  • 「内省とはリフレクション(反射)である」
  • 「過ぎ去ったことに光を当てるようにふりかえり、こころに描かれたことを呼び戻したり表出したりすること、すなわち注意深く考えることや黙想すること」
    • この考え方は雰囲気があって素敵だ
    • 過去は闇であり、闇に光を当てその有り様を観測するから反射なのだ、と

ふりかえりのフレームワーク

  • メジャーなやつ KPT
    • たくさん亜種がある KPT + Stop、KTP + Action、YWT + KPT、KPT + Thanks、KPTそれぞれに5W1H
    • KPT 採集
    • 改善サイクルを回しやすい
  • YWT
    • 試行錯誤的な学習に向いている
  • 知らなかったやつ ORID
    • その場にいる人間の文脈が多岐に渡る場合などに有効かもしれない
    • Objective: 事実やデータ
    • Reflective: その時の気持ち(ここが発見だった)
    • Interpretative: 解釈や意味
    • Decision: これから、あるいは次にどうするか

チームでふりかえりをするとき、書く時間と共有する時間を分ける理由

  • ちゃんと他の人の話を聞くため
    • 他の人が話しているときは、自分のことを考えたり書いたりしないで、ちゃんと聞くため
  • 共感とは、「自分ならこうするとか」そういうことを考えずにただただ相手の身になって聞くこと
  • 「話している人が認識している事実や感じた想い」から学習する?
    • この辺よくわからない。ワークショップ中でも説明はされてなかった

看護師の人たちは日常的にふりかえりを活用している

  • 看護記録とか
  • リフレクションの研究自体が看護教育に端を発するものだとか
  • (後で聞いた話)
    • ワークショップの講師の人は、病院の看護師さんを相手にリフレクションのワークショップを開催しているとのこと

2017-02-17

[] 考察

所属する組織に不満があるわけではないので特に声を上げるようなことはしていないけど、ときどき考えさせられることがあるので気が向いたら書くようにしよう。

  • コピペはよくない(ただし場合による)
    • 脊髄反射的にコピペしたものをそのまま動かすとか常識を疑わざるを得ません
  • 何の思想も目的も意思も意図も希望も展望も設計もなくガラクタを寄せ集めても粗大ゴミにしかならない
    • とりあえず集まったところで何も生まれません

思ったよりも忘れている。

他にもなんかあったような気がするんだけど、大して気に留めなかったんだろうな。

[] n回目のDevsumiで見聞きしたことのメモ

Developers Summit 2017

何回目か忘れてるけど一般参加してきた。

ちょっとした発見があったりしたので、自分用に記録しておく。

16-D-2 Elastic Stack による異常検知

Elastic Stack の紹介。

基本的に収集したログをいかに扱うか、という問題になるのだけど、部分的には AWS CloudWatch よりも柔軟性がありそうなところが気になった。

時系列データのトレンドを自動的に学習して異常を検出するPrelertというプラグインはよさそうだった。

普通のしきい値判定と組み合わせることができればほとんどのケースがカバーできそう。

16-A-3 ヤフーの開発を10倍速くした社内 PaaS 構築の今とこれから

開発ツールに起因する問題を解消するため,Cloud Foundry を導入した話。

Spring Blogでは Cloud Foundry の話がしょっちゅう登場するのできっと世界的には主流なんだと思う。

日本の大手SIerのプラットフォームで使われているのは知らなかった…そうなんだ。

17-E-1 自動化はどこに向かうのか 〜まだ開発・運用の自動化で消耗しているの?〜

一度前佛さんにお会いしたかったので参加。

slideshareプレゼン資料が本当にすごい。エンターテイメント。

ツール推しな人だと思ってたら全然そんなことはなく、とてもバランス感覚のある話だった。

17-D-6 『もしもスクラムマスターがテストエンジニアだったら』(もしテス)

社内ツールをインクリメンタルなプロセスで開発してみたという話。

もともとトップダウン開発プロセスに馴染みがあり、かつ、テスト設計が専門ということで、ユースケースの書き方を工夫してみたとのこと。

2015-11-01

[] 成果物の評価を公開するということ

わからないということをわかるや、全く駄目な成果物と人格否定についてを読んだ。

人格否定されている感じになるのは、成果物じゃなくてそれを生み出すプロセスを否定されている(と受け取った or 受け取られるようなやりとりがあった)ときだと思う。

自分でもよく、部分的にダメなところがあっただけで、全体に対する評価もダメだと判断してしまうことがある。

つまり、部分を生み出す手順がダメなのだから、それに従って生み出されている他の部分もどうせダメだろうという思い込み

これでは受け手から人格否定されてると思われても仕方ない。悪い例。

成果物の評価を公開ときは、純粋に成果物だけの評価になるようにしないと、いろんな人の心がざわざわしてしまうので気をつけよう。

注目を浴びたいだけならともかく、成果物をより良くしたいという思いがあるはずなのに、自分の考えを押し付けるだけではただの暴力だ。

2015-10-03

[] ビヨンド ソフトウェアアーキテクチャを翻訳しました

はじめに

共著者の id:ditigalsoul。言葉使いや翻訳の技術や作法について学ばせていただきました。また一緒に何かやりましょう。

f:id:yujiorama:20151003131418j:image

陳列状況

池袋ジュンク堂で先行販売(!)とかやってて見てきました。ちゃんと陳列されてて素敵。

f:id:yujiorama:20151003131146j:image:w360

f:id:yujiorama:20151003131145j:image:w360

原著について

内容

ターキテクト(テクノロジーを担当するアーキテクト)とマーケテクト(マーケティングを担当するアーキテクト)が協力して課題を取りこぼすことがないように進めていきましょう、どちらが欠けても成功することはできませんよ、というものでした。

ブランディングや販売管理(のためのSKU)、インストールプロセスなどが、どれだけアーキテクチャに影響するものなのか、改めて考えさせられました。

著者

当時はコンサルティングや講師業をしていたようですが、今はチーム内のコラボレーションを高めるためのサービスやツールを提供する会社(Contentneo)を運営している模様。

Slideshareにもいろいろとプレゼン資料が公開されています。

本書の付録Bで紹介しているプロダクトマネジメントパターンを発展させているようです。

ツール

翻訳をするのに欠かせなかったツールです。

今回もありがとうございました。

統計データ

2014/05/30くらいに開始して、2015/09/30で完了しました。

仕事の都合でしばらく中断させてもらっていた時期がありますが、1年半か…

コミット数は1832で、私のコミット数は1025でした。

規模はこんな感じです。Re:VIEW のツールで数えることができます。

約1MB、12347行、結構な量になりました。

$ review-vol  | tail -n 2
=============================
    1064KB 395381C 12347L 1064P
感想

翻訳をやるだけの英語力があるのかどうか不安に思っていた時期もありました。

ですが、訳す、読む、直すのサイクルを何度も回して行く中で、そんなことを気にしているのはもったいないと思うようになりました。

他にも、英文を読む量を増やしたり、実際に訳してみたり、とにかく反復し続けていたらなんとかなった感じです。

特に身についたと思えるのが、知らない言い回しが出てきた時の対応です。

そのまま訳するとすごくおかしな日本語になってしまいます。

訳す前にまずその言葉自体を調べて、そこから日本語としてどういう形式になるといいのか考えられるようになりました。

翻訳したからといって、本の内容の全てを自分のものにできるはずはありません。

自分には不足している領域の内容を扱っているのだからなおさらです。

今後とも精進していきたいと思います。

謝罪

id:digitalsoul とは同じ職場、同じチームとして過ごしてきました。

彼と一緒に過ごした時間がこの1年半の大部分を占めているのではないか…

仕事の考え方の違いにより、言い争いになりかけたこともありました。

挑発めいた言葉を言ってしまったこともありました。

口頭では自然解決した風を装っていますが、実はちゃんと謝ってません。今度会ったときに誤ります。

2014-09-28

[] レガシーコード改善勉強会でした。 #wewlc_jp

レガシーコード改善勉強会

運営について

アークヒルズサウスタワーにある、Yahoo さんの会議室でした。

  • 広い!
    • だいたい100人くらいが座って余裕がある
    • 無線LANを使わせていただけた
    • スクリーンは6つのディスプレイで1面、それを左右に配置。観やすかった
  • タリーズのホットコーヒーが無料だった
  • 大手出版社からの参加者プレゼント!
    • 全部で20冊くらいあったような
  • 質問の時間や発表中の割り込みは無かった
    • 自分語りや糞コード自慢に興味は無いのですが、実践するにあたってのユースケースとかは興味があったのですけど、その辺の情報は得られず(ヽ´ω`)

オープニング

発起人?の方から、オープニングとして次のような話をうかがいました。

  • この集まりの目的は何?
    • 改善について議論できる下地を作ること
  • 今後どうしたいか
    • ITの力の最大化
    • レガシーコードを改善しなくてよくなる
    • レガシーコードの改善が当たり前に
    • 今回はウルシステムズさんと一緒にやらせていただいた、もっといろいろ広げたい
    • それ以上は分からない

アンケート用紙が配られていて、その集計結果次第で第二回、第三回があるかもしれない、とのこと。

セッション1

演者の稲葉さんが都合が悪くなってしまったとのことで、代役で訳者である平澤さんが書籍の内容をざっくりと説明するセッションになりました。

平澤さんはドメイン特化言語リファクタリングも訳されてる…大物感。

一番記憶に残ったのは、レガシーコード改善ガイドがすでに七刷にもなっていて、一定したペースで売れ続けているということでした。

息が長いっていいことですねぇ…

書籍の内容ですが、書かれているのはビルドできるコードのことが多い。

なので、よくわからない設定ファイルや、ビルドできないコードについても、同じような(場合によってはもっとヒドい)戦いの記録がありそうだなぁと思いました。

セッション2

kyon_mm による方法論の話。

何のために、どういうことをやればいいのか、積み上げていく感じで分かりやすいものでした。

  • 変更するなら、そのものを知らなければならない
  • 知るためには、役割、目的に応じて適切なツール(ものであったり技法であったり)を使うべき
  • ツールの使い方なんてもはや教養なので学べ

1 bleis 月とか 1 kyon_mm 月とかの人に特化した規模感がなんとなく危ういなぁとか思ったので、懇親会で会話してみたのですけど、

いまいち伝えられなかったのが残念でした。

kyon_mm 曰く「PO と QA を兼任してるけど、やっぱりコードが書けてテストもできる人がやるべきだよ!」(意訳)って言ってて、

それ巷で話題のフルスタックエンジニアですよねー、とツッコんでおきました…

セッション3

goyoki による心構えや振る舞いについての話。

以前見かけたときより健康そうな雰囲気でした。

大枠として次のような分類で課題と目標、実際のアプローチを説明していました。

  • 環境
  • アプローチ

保守性の話で、リスク分析して優先度を付けて要件にして、そのトレーサビリティを保つようにしていく、という話を聞いていて、

「で、誰が何をどうするから、誰がどう嬉しいんだろう」というのが分からず隙間時間(という名の休憩時間)に聞いてみましたけど、やっぱりよく分かりませんでした。

今度機会があったら聞いてみよう。

セッション4

ソニックガーデンの西見さんでした。

今回も Point of Sales と Point of Use のグラフが紹介されていたんですが、個人的に何か腑に落ちていなかったんですけどその理由が分かりました。

それぞれで、縦軸の縮尺が違うはずなんですよ。

納品時点での利益?が最大、という場合、利用者が要求したものが10入っているとする。

一方、使い始めたときから利益?が最大、という場合は、最初の時点では要求したものが1か2しか無いはず。

なのに、それらを同じ縮尺であるかのように見せている…これがグラフの魔術!!

今回も、組織的に技術基盤を揃えて、その効率を高める戦略は素敵だなぁと思いました。

セッション5

Jenkins Boot Camp中の人でもある、NTT Data の佐藤さんでした。

継続的インテグレーションの話でした。

セッション6

Yahoo トップページ部隊としての佐藤さんでした。

組織内でコード改善をする機運を高めて、実際にやってきたという話。

namespace で関数名を隠蔽してスタブ関数を実行する、というトリッキーなテクニックとかを紹介されてました。

懇親会で、テストコードのサンプルを作りこんで「さあお前ら手を動かせ」的なアプローチを取らざるを得なかった、などの裏話をお聞きして、

見かけによらずパワーのある人だなぁと思いました。

セッション7

誤タイプを招く ID 体系を導入されている t_wada さん。

こちらも一番最近の記憶に比べて健康さが増しているように感じたのですが、実際はそうでもなかったっぽい。お大事に…

お話をまとめるとこんな感じでした。

  • 状況を具体的にして
  • 一番やばいところから
  • できることを一つずつ
  • 確実にやっていけ
  • 高望みするな

早速やろうと思って、話を聞きながらどうにかこうにか自動ビルドを復活させたりしてました。