昨日に引き続き今日も Developers Summit 2015 で目黒雅叙園へ。セッション会場では(一般人は)机が無かったので、ノート PC は家に置いてきた。
デブサミはほとんどのセッションが撮影可なんだけれど、スライドを公開すると発表者が言っているのに全スライドをシャッターの電子音を鳴らしてながら撮り続ける人がいて昨日は結構ウザかった。
そういった声は多かったようで、今日は進行の人がシャッター音に配慮するように注意を促していてちょっとは減った感じだった。撮りたかったら無音カメラアプリをインストールしてくるとかした方が良いと思う。
会場でばったり zakwa 氏と再会。まさか来ているとは知らなくてびっくり。今はデータ解析やっているとかいっていたかな。良い再会があったのがデブサミ2日目の一番の収穫。こんど同窓会やりましょう。
朝一番のセッションは昨日の朝に比べて遅い人出。
Docker や Ansible などの話。いろいろ模索し続けている話。インフラ整備専任者が欲しいとのこと。ローカルホストに開発環境を簡単に構築できるというのは良いのだけれど、やはり管理コストが高い印象。
個人的にはやはりどこかのラックに自分の VM がある方が使う側も楽な気がしている。
事前の注意とか言い訳についての前置きが長かった。宣伝セッション。
お昼から帰ってきて会場に行ったら、既にまさかの満席だった。あきらめてソファで本を読んだり、kintone CAFE でコーヒー飲んだり。
プラットフォームの刷新にあたり既存のサービスや機能をきちんと UML を用いてモデリングしなおしてあるべき姿の議論を行ったというのが良いなと。
自分の本部でも今いろいろ可視化を行っているグループがあるのだけれど、散文的に書き出すのではなくてきちんとモデンリングするようにしたい。
Miiverse におけるマルチリージョン構成や多言語対応についての話。
各リージョンに対してどういったサーバとDB構成にしているのかについての説明は興味深かった。パフォーマンスもそうだけれど、サービスとしてどこの機能・情報をリージョン別に出し分けるかを念頭におく必要があることがわかった。なおコードベースは1つで環境変数で機能の出し分けをしているのだとか。
L10N については具体的な話で良かった。Miiverse 特有の話というよりは一般的に誰もが通る道的な。
Eraser Button Law など世界展開においてはやはり法的な事情があるというのもやはり大変なところのようだ。監視ポリシーは統一していとのこと。また投稿監視は関係会社がやっているとのこと(どこにアウトソーシングしているのかな)。
Miiverse もそうだけれど、どこも独自にコミュニケーションサービスを提供していくので、汎用コミュニティサイトはどういう路線でいくのが良いのかなと考えたり。
ガラガラだったし、15分ぐらい経っても本題に入らないし琵琶湖の説明が始まったので途中で出てきた。
及部敬雄氏の
Not プロセス導入 自分たちに必要なものは自分たちで選ぶ
という話が良かった。推進者がゴリゴリ推し進めるのではなくきちんとみんなで考えて試行錯誤していくところに本当の学びがあるんだなと。
セッションの一番最後に、スタンディングオベーションの号令があったのでそそくさと退席した。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会8回目。今日は第8章 技術的負債。
スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。あるいはウォーターフォールと違って返済していくチャンスがあるからでしょうか。
技術的負債。当初は
意図的に手抜きをしてすばやく仕上げるという意味
技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。
からきていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。
技術的負債ですが
大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。
ということで必ずしも罪悪感を感じる必要のあるものではないことがわかります。きちんと把握してコントロールしていくことが重要です。
ただ
技術的負債の経済的意味についての適切な認識
については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。
サイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。
あたりがポイント。
ということで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。
また実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。
プロセスをスクラムチームが調査するためのものだ。
2月の第15章 さまざまなプランニング以来、4回目の発表担当です。
半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。
本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。
と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。
付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。
ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。
改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!
なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。
今年は今日が仕事納めの日。ノートやカレンダーを読み返しながら1年をふりかえり。
2018年1月付で mixi事業部 部長を拝命して今年で満3年。3年やると事業方針・予算策定などの年次の事業活動についても自分なりのスタイルができあがってきてスムーズにできるようになってきたと感じている。年次だけでなく四半期毎・月次・週次のプランニングだったりデータ可視化やレポーティングなんかも同様だ。
来年・来年度はサービスのためにもっと攻めていきたいぞ。
昨年仕事納めのふりかえりで「午前中にミーティングをいれるのを極力やめてみる」としてみたトライは1年続けられた。「動かしたくないと言われた」「別のミーティングに先立ってやっておきたい」という2件だけ午前中に残した他はすべて 12:00 以降に調整できた。原則リモートワーク期間中に出席者の環境の都合でしばらく午前中にしたケースがあったけれど、それも今は午後に戻している。
午前中に生み出した時間は主にタスク管理の更新と細かいタスクのその場での実行を今はしている。毎日朝に時間を確保できるとリズムを崩さず仕事ができてストレスがなくて良い。タスク管理・実行をしているうちにあっという間に早めの昼食時刻となってしまい「午前中の集中力をクリエイティブな活動に活用」まではできていないのでここは来年改善したいところだ。
3年前から仕事納めの日は何か美味しいものを買って帰っている。今年も何か買って帰るよと数日前から期待してもらっていたのだが、そういえば今日はクリスマス。ケーキ屋は混んでいるだろうなと思いつつ帰りに渋谷スクランブルスクエアや渋谷ヒカリエに行ってみたところ、どちらも混雑していて長蛇の列。これは無理。
途中乗り換え駅の駅ナカや地元駅の駅ビルにも寄ってみたけれど、どちらもケーキ屋に行列ができていた。無理。
最後の望みはコンビニ。セブン-イレブンは品揃えが駄目だったのでさらにファミリーマートへ行ったところケーキに巡り会えた。ふう、手ぶらは免れた。第89回全日本フィギュアスケート選手権大会を観ながら美味しく頂いた。
今年もお疲れさま。
[ Naney と mixi ]
ノートのネットワーク構造を可視化するのに Obsidian のローカルグラフを便利に使っている。
プロジェクトマネジメントの支援として Obsidian を使う場合
みたいな感じでプロジェクトの親子階層や期間の階層に合わせてリンクでノートを構造化してみているのだけれど、ローカルグラフだといい感じにならないのよね。
ローカルグラフが見やすくなるように構造をちょっといじってみたりしたけれど、対して見やすくならなかった。リンクにもグラフ描画にも上位・下位概念が無いのでまあ当然だよね。
多次元の上位・下位概念を可視化するものではないと割り切って使うべきだったよ。
金王八幡宮にて初詣。 pic.twitter.com/UovY59Fhk6
— Naney (@Naney) January 19, 2022
最近 HiveQL クエリを実行して集計したりしている。 可視化は Google スプレッドシートで。 Google スプレッドシートは考察を一緒に書いておきにくい。
MkDocs で生成しているノートに一緒にチャートをおけるといいなと思って Chart.js をちょっと使ってみた。
MkDocs プラグインはなさそうなので、素で canvas 要素と script 要素を Markdown ファイルの中に書いて動かしてみた。
CSV ファイル (あるいは TSV ファイル / JSON ファイル) を読み込むようにできると管理が楽かな。
機会がある時にちょっとずつ使ってみよう。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。