nDiki : 可視化

今日のさえずり: 「とりあえずグラフにすれば可視化」というのを撲滅する

• 08:13 ナショナル電気ファンヒータ出した。
• 08:46 粗大ごみ申し込み完了。
• 11:10 「とりあえずグラフにすれば可視化」というのを撲滅する。
• 12:00 「ギフトラッピングは利用できませんが、車両はラッピング済みです。」 http://amzn.to/1A9a5uI
• 14:16 「問題が発生したため、プロセス『http://com.google.process.gapps』を終了します。」300回ぐらいタップした。
• 15:51 Xperia GX リセットした……。
• 19:41 Google Authenticator に2段階認証8アカウントを設定しなおすという修行をした。
• 20:57 I'm at 株式会社ミクシィ (mixi, Inc.) in 渋谷区, 東京都 http://4sq.com/12IqhIn
• 22:49 し、しばれるー。冬将軍来てるのか?
• 24:58 ようやくある程度 Xperia GX の設定が戻った。

Developers Summit 2015 2日目

昨日に引き続き今日も Developers Summit 2015 で目黒雅叙園へ。セッション会場では(一般人は)机が無かったので、ノート PC は家に置いてきた。

デブサミはほとんどのセッションが撮影可なんだけれど、スライドを公開すると発表者が言っているのに全スライドをシャッターの電子音を鳴らしてながら撮り続ける人がいて昨日は結構ウザかった。

そういった声は多かったようで、今日は進行の人がシャッター音に配慮するように注意を促していてちょっとは減った感じだった。撮りたかったら無音カメラアプリをインストールしてくるとかした方が良いと思う。

再会

会場でばったり zakwa 氏と再会。まさか来ているとは知らなくてびっくり。今はデータ解析やっているとかいっていたかな。良い再会があったのがデブサミ2日目の一番の収穫。こんど同窓会やりましょう。

「GMOプライベートDMP」の開発にあたって取り組んできた DevOps、更にその反省点と現在進行中のカイゼン事例の紹介 山邉哲生氏(GMOインターネット)

朝一番のセッションは昨日の朝に比べて遅い人出。

Docker や Ansible などの話。いろいろ模索し続けている話。インフラ整備専任者が欲しいとのこと。ローカルホストに開発環境を簡単に構築できるというのは良いのだけれど、やはり管理コストが高い印象。

個人的にはやはりどこかのラックに自分の VM がある方が使う側も楽な気がしている。

「DevOps」やってみた。そして、気づいたこと、陥ること、見直すところ。川瀬敦史氏(日本アイ・ビー・エム)

事前の注意とか言い訳についての前置きが長かった。宣伝セッション。

ドメイン駆動設計再入門 和智右桂氏(グロースエクスパートナーズ)

お昼から帰ってきて会場に行ったら、既にまさかの満席だった。あきらめてソファで本を読んだり、kintone CAFE でコーヒー飲んだり。

高速開発を支えるDMMプラットフォームの作り方 〜DMM.makeの場合〜 濱野正樹氏・清酒渉氏(DMM.comラボ)

プラットフォームの刷新にあたり既存のサービスや機能をきちんと UML を用いてモデリングしなおしてあるべき姿の議論を行ったというのが良いなと。

自分の本部でも今いろいろ可視化を行っているグループがあるのだけれど、散文的に書き出すのではなくてきちんとモデンリングするようにしたい。

世界に展開できるウェブサービスのつくり方 下林明正氏(はてな)・矢野幹樹氏(任天堂)

Miiverse におけるマルチリージョン構成や多言語対応についての話。

各リージョンに対してどういったサーバとDB構成にしているのかについての説明は興味深かった。パフォーマンスもそうだけれど、サービスとしてどこの機能・情報をリージョン別に出し分けるかを念頭におく必要があることがわかった。なおコードベースは1つで環境変数で機能の出し分けをしているのだとか。

L10N については具体的な話で良かった。Miiverse 特有の話というよりは一般的に誰もが通る道的な。

Eraser Button Law など世界展開においてはやはり法的な事情があるというのもやはり大変なところのようだ。監視ポリシーは統一していとのこと。また投稿監視は関係会社がやっているとのこと(どこにアウトソーシングしているのかな)。

Miiverse もそうだけれど、どこも独自にコミュニケーションサービスを提供していくので、汎用コミュニティサイトはどういう路線でいくのが良いのかなと考えたり。

琵琶湖を中心とした世界のようなお話 佐藤由紀氏(マイクロアド)

ガラガラだったし、15分ぐらい経っても本題に入らないし琵琶湖の説明が始まったので途中で出てきた。

Agile TED

• 【司会】高柳謙氏・川添真智子氏(ユニファ)
• 及部敬雄氏(楽天)
• 鹿島恵実氏(GMOペパボ)
• 知花里香氏(ディー・エヌ・エー)
• 西村直人氏(永和システムマネジメント/一般社団法人アジャイルチームを支える会)
• 山口鉄平氏(ヤフー/一般社団法人アジャイルチームを支える会)

及部敬雄氏の

Not プロセス導入 自分たちに必要なものは自分たちで選ぶ

という話が良かった。推進者がゴリゴリ推し進めるのではなくきちんとみんなで考えて試行錯誤していくところに本当の学びがあるんだなと。

セッションの一番最後に、スタンディングオベーションの号令があったのでそそくさと退席した。

2日間の発表についての雑感

• 小綺麗に見せるだけの素材写真を多用しているスライド多かった。Flickr の URL と CC に従ったクレジット表示を読み取れない小さな文字で入れている的な。キャッチーだけの飾り。
• 「いついつのイベントで話します」的なのも結構多かった。この発表はこの発表で完結するのが良いと思う。

Todoist や Trello や【日記】

9連休なシルバーウィークが終わりました。晴れてここ最近にしては暑い朝でした。疲れはきっちり取れた感じです。リフレッシュ。

Todoist はいったん細かくプロジェクトを分けるのをやめてしばらくやってみたのですが、やはり分けた方が便利でした。タスクの多いプロジェクトは専用の Todoist プロジェクトに入れた方が見通しが良いです。

あとは久しぶりに Trello にチームとボードを追加。オフ会やちょっとしたイベント運営では雑多な共有タスクがあるので Trello ぐらいの粒度で可視化・管理できると良いので。

第8回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。

スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。

技術的負債

技術的負債。当初は

意図的に手抜きをしてすばやく仕上げるという意味

技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。

からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。

技術的負債ですが

大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。

ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。

ただ

技術的負債の経済的意味についての適切な認識

については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。

技術者レベルでの技術的負債の可視化

• 方法1: 障害管理システムに記録する
• 方法2: 技術的負債を表すプロダクトバックログアイテムを作る
• 方法3: 技術的負債バックログを作る

サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。

技術的負債の返済

• 作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。
• スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。

あたりがポイント。

「技術的負債返済スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。

ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。

また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

第22回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。

プロセスをスクラムチームが調査するためのものだ。

2月の第15章 さまざまなプランニング以来、4回目の発表担当です。

半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。

事前準備

本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。

スプリントレトロスペクティブに使う時間

• 60分未満で有益なスプリントレトロスペクティブをするのは難しい。
• 2週間スプリントなら 1.5時間。

と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。

インサイトバックログ

付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。

アクションの決定

ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。

アクションはスプリントバックログへ

改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!

なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

部門のソフトウェアエンジニアスキルマップ

部門としてソフトウェアエンジニアでカバーできていない領域があってどうするかとか、学びたい/育成したい領域がいろいろあるとか、個別に課題感を聞くようになってきた。

可視化しないと合理的な話ができないなと感じたのでスキルマップ(スキル - ソフトウェアエンジニアの表)を作ってみた。習熟度は順序尺度なので誤解しないよう数字ではなく記号で。

表で記号を埋めていくという観点ではなく、コミュニケーションの上での共通理解のツールという観点で使っていきたい。

仕事納めとふりかえり 2020

今年は今日が仕事納めの日。ノートやカレンダーを読み返しながら1年をふりかえり。

mixi事業部 部長 満3年

2018年1月付で mixi事業部 部長を拝命して今年で満3年。3年やると事業方針・予算策定などの年次の事業活動についても自分なりのスタイルができあがってきてスムーズにできるようになってきたと感じている。年次だけでなく四半期毎・月次・週次のプランニングだったりデータ可視化やレポーティングなんかも同様だ。

来年・来年度はサービスのためにもっと攻めていきたいぞ。

午前中にミーティングをしない試みの結果

昨年仕事納めのふりかえりで「午前中にミーティングをいれるのを極力やめてみる」としてみたトライは1年続けられた。「動かしたくないと言われた」「別のミーティングに先立ってやっておきたい」という2件だけ午前中に残した他はすべて 12:00 以降に調整できた。原則リモートワーク期間中に出席者の環境の都合でしばらく午前中にしたケースがあったけれど、それも今は午後に戻している。

午前中に生み出した時間は主にタスク管理の更新と細かいタスクのその場での実行を今はしている。毎日朝に時間を確保できるとリズムを崩さず仕事ができてストレスがなくて良い。タスク管理・実行をしているうちにあっという間に早めの昼食時刻となってしまい「午前中の集中力をクリエイティブな活動に活用」まではできていないのでここは来年改善したいところだ。

仕事納めケーキ

3年前から仕事納めの日は何か美味しいものを買って帰っている。今年も何か買って帰るよと数日前から期待してもらっていたのだが、そういえば今日はクリスマス。ケーキ屋は混んでいるだろうなと思いつつ帰りに渋谷スクランブルスクエアや渋谷ヒカリエに行ってみたところ、どちらも混雑していて長蛇の列。これは無理。

途中乗り換え駅の駅ナカや地元駅の駅ビルにも寄ってみたけれど、どちらもケーキ屋に行列ができていた。無理。

最後の望みはコンビニ。セブン-イレブンは品揃えが駄目だったのでさらにファミリーマートへ行ったところケーキに巡り会えた。ふう、手ぶらは免れた。第89回全日本フィギュアスケート選手権大会を観ながら美味しく頂いた。

今年もお疲れさま。

[ Naney と mixi ]

Obsidian のローカルグラフで階層構造を見ようとしない

ノートのネットワーク構造を可視化するのに Obsidian のローカルグラフを便利に使っている。

プロジェクトマネジメントの支援として Obsidian を使う場合

• FY2022 プロジェクト
• FY2022Q2 プロジェクト
• プロジェクト A
• FY2022 プロジェクト A
• FY2022Q2 プロジェクト A
• サブプロジェクト S
• FY2022 サブプロジェクト S
• FY2022Q2 サブプロジェクト S

みたいな感じでプロジェクトの親子階層や期間の階層に合わせてリンクでノートを構造化してみているのだけれど、ローカルグラフだといい感じにならないのよね。

ローカルグラフが見やすくなるように構造をちょっといじってみたりしたけれど、対して見やすくならなかった。リンクにもグラフ描画にも上位・下位概念が無いのでまあ当然だよね。

多次元の上位・下位概念を可視化するものではないと割り切って使うべきだったよ。

今日のさえずり: Google スプレッドシートだと書きたい種類のグラフが無かったので、 Excel にチェンジ

• 12:15 金王八幡宮にて初詣。 https://t.co/UovY59Fhk6
• 16:14 Obsidian mobile v1.1.0 (Build 33) から v1.1.0 (Build 35) にアップデートした。 主にデスクトップ版 v0.13.21 への追従。
• 21:21 Google スプレッドシートだと書きたい種類のグラフが無かったので、 Excel にチェンジして書いた。
• 23:50 2022年1月19日(水) やったこと - DELFONICS クリアカラーペンケース イエローを購入 - 金王八幡宮にて初詣 - 顧客維持率のノートを更新 - 顧客維持率可視化 - 『明日ちゃんのセーラー服』第二話

金王八幡宮にて初詣。 pic.twitter.com/UovY59Fhk6

— Naney (@Naney) January 19, 2022

Chart.js をちょっと使ってみる

最近 HiveQL クエリを実行して集計したりしている。 可視化は Google スプレッドシートで。 Google スプレッドシートは考察を一緒に書いておきにくい。

MkDocs で生成しているノートに一緒にチャートをおけるといいなと思って Chart.js をちょっと使ってみた。

• https://www.chartjs.org/

MkDocs プラグインはなさそうなので、素で canvas 要素と script 要素を Markdown ファイルの中に書いて動かしてみた。

CSV ファイル (あるいは TSV ファイル / JSON ファイル) を読み込むようにできると管理が楽かな。

機会がある時にちょっとずつ使ってみよう。