インフラ整備専任者が欲しいとのこと。ローカルホストに開発環境を簡単に構築できるというのは良いのだけれど、やはり管理コストが高い印象。ある方が使う側も楽な気がしている。「DevOps」やってみた。気づいたこと、陥ること、見直すところ。川瀬敦史氏(日本アイ・ビー・エム)事前の注意とか言い訳についての前置きが長かった。和智右桂氏(グロースエクスパートナーズ)お昼から帰ってきて会場に行ったら、既にまさかの満席だった。用いてモデリングしなおしてあるべき姿の議論を行ったというのが良いなと。自分の本部でも今いろいろ可視化を行っているグループがあるのだけれど、散文的に書き出すのではなくてきちんとモデンリングするようにしたい。おけるマルチリージョン構成や多言語対応についての話。各リージョンに対してどういったサーバとDB構成にしているのかについての説明は興味深かった。パフォーマンスもそうだけれど、サービスとしてどこの機能・情報をリージョン別に出し分けるかを念頭におく必要があることがわかった。コードベースは1つで環境変数で機能の出し分けをしているのだとか。ついては具体的な話で良かった。特有の話というよりは一般的に誰もが通る道的な。世界展開においてはやはり法的な事情があるというのもやはり大変なところのようだ。監視ポリシーは統一していとのこと。投稿監視は関係会社がやっているとのこと(どこにアウトソーシングしているのかな)。どこも独自にコミュニケーションサービスを提供していくので、汎用コミュニティサイトはどういう路線でいくのが良いのかなと考えたり。佐藤由紀氏(マイクロアド)ガラガラだったし、15分ぐらい経っても本題に入らないし琵琶湖の説明が始まったので途中で出てきた。自分たちに必要なものは自分たちで選ぶという話が良かった。推進者がゴリゴリ推し進めるのではなくきちんとみんなで考えて試行錯誤していくところに本当の学びがあるんだなと。セッションの一番最後に、スタンディングオベーションの号令があったのでそそくさと退席した。小綺麗に見せるだけの素材写真を多用しているスライド多かった。従ったクレジット表示を読み取れない小さな文字で入れている的な。キャッチーだけの飾り。「いついつのイベントで話します」的なのも結構多かった。この発表はこの発表で完結するのが良いと思う。【日記】9連休なシルバーウィークが終わりました。晴れてここ最近にしては暑い朝でした。疲れはきっちり取れた感じです。細かくプロジェクトを分けるのをやめてしばらくやってみたのですが、やはり分けた方が便利でした。プロジェクトに入れた方が見通しが良いです。チームとボードを追加。粒度で可視化・管理できると良いので。スクラム」を読みたい人が集まる勉強会8回目。スクラムのコアコンセプトの部でわざわざ技術的負債について1章割くというのがふーんという印象でした。ベロシティに大きな影響を与えるので避けて通れないというところでしょうか。技術的負債を抱えるということは、今後の作業のための時間を担保にした融資を受けるということだ。きていて、後々返済する必要が出てくる代わりに先に経済的効果を得ているものを指しています。単純にまずい設計や実装のことまで技術的負債と世間で呼ばれていることがありますが、個人的には違和感を感じています。本書ではナイーブな技術的負債と呼んでいますね。技術的負債ですが大切なのは、どんなプロダクトであっても技術的負債からは逃れられないということだ。私はここで、技術的負債をなくすよう努力しましょうなどと言うつもりはない。仮にそんなことができたとしても、負債をゼロにするためには大変なコストがかかるだろう。いうことで必ずしも罪悪感を感じる必要のあるものではないことがわかります。把握してコントロールしていくことが重要です。技術的負債の経済的意味についての適切な認識については、正直なところなかなか正確に見積もれることがない気がします。技術的負債を生むという選択をした時にそこまで見積もる余裕がない、あるいはあっても先のことなので詳細化しきれない、そういうケースが多いのではないかと。技術的負債バックログを作るサイズが大きいものは方法2の方が時間をとって返済しやすく、サイズが小さいものは方法3の方が「フィーチャーよりも優先度が低くていつまでも返済されないということがない」ので返済しやすいようです。作業中に偶発的な技術的負債が見つかれば対応できるところまで対応する。スプリントごとに既知の技術的負債のいくつかを返済対象として対応する。価値をもたらすフィーチャーの開発と関連するものを一緒に進めることで金利の高いものから勧められる。スプリント」だとか「リファクタリングスプリント」などといった言葉がチーム内で出てきたら、危険信号だ。いうことで、技術的返済のみに注力するのは価値を提供し続けるというのに反するで望ましくないとありました。実際のところ利息がほとんど発生しない技術的負債もあるので、きちんと見極める必要がありますね。スクラム」を読みたい人が集まる勉強会の22回目。スプリントレトロスペクティブ。プロセスをスクラムチームが調査するためのものだ。さまざまなプランニング以来、4回目の発表担当です。「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。スプリントレトロスペクティブに使う時間60分未満で有益なスプリントレトロスペクティブをするのは難しい。書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。インサイトバックログ付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。デジタルツールを使っている場合は残すという運用をするかもといったぐらい。アクションの決定ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。アクションはスプリントバックログへ改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。改善アクションを実施したいのであれば、分離してはならない。統合すべきである!なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。(月)部門のソフトウェアエンジニアスキルマップ部門としてソフトウェアエンジニアでカバーできていない領域があってどうするかとか、学びたい/育成したい領域がいろいろあるとか、個別に課題感を聞くようになってきた。ソフトウェアエンジニアの表)を作ってみた。習熟度は順序尺度なので誤解しないよう数字ではなく記号で。表で記号を埋めていくという観点ではなく、コミュニケーションの上での共通理解のツールという観点で使っていきたい。事業の部長をしています。日記(兼パーソナルナレッジベース)です。※内容は個人的見解であり所属組織とは関係ありません。