2025年3月12日水曜日

DysonV8 Slim Fluffy レビュー

DysonV8 Slim Fluffy レビュー

DysonV6からの買い替えをしたのでレビュー

価格

  • 新品 29,800円

購入時期

  • 2025/02/01

ゴミ捨ての方法がかなり変わった

  • ストッカーを上に持ち上げて下から捨てるタイプになった
  • 楽だがとにかくほこりが飛び散るのが面倒
    • なので自分は大きめの袋を用意して掃除機のストッカー部分を覆うくらいにしてから捨てるようにしている
    • 捨てた後は軽く水で霧吹きするとなお飛び散らない
    • 袋はある程度ほこりが溜まったら交換
  • 気楽にゴミを捨てられるようにはなったが逆に捨てすぎてストッカーを上げる部分がぶっ壊れないか不安

ノズルヘッドが小さい

  • 隙間の掃除もできるようになった
  • が下に滑り込ませすぎるとヘッドが上がってしまい奥まで掃除できない
  • また Slim のノズルヘッドはホイールが付いている箇所が 4 箇所ありまっすぐ掃除する分にはやりやすいが横に曲がったりするのがやりにくい
  • またホイールの転がりが悪くなるのが早くなる気がするのでシリコンスプレーとかはこまめに刺すことになるかも

静音

  • V6 に比べて静音になった
  • キーンって感じからブオーンって感じになった
  • 音を気にするならいいかも

やや重い

  • 本体部分はやや重くなっている
  • Slim タイプであればモータヘッドからパイプ部分に関してはかなり小さいのでその分軽い

付属品も改良されていた

  • 毛付きブラシが良くなっていた、ほこりがブラシに付いてもすぐに取れるようになった印象
  • ブラシ自体の素材も変わったっぽい

メンテナンスする部分はあまり変わってなさそう

  • 頻繁にストッカーのゴミを排出していればフィルタに関しては前よりも変えなくてもいいかも
  • モーターブラシの部分はたぶん同じくらいの感覚で掃除することになりそう
  • バッテリはまだ新品だから不明、一応容量は 2400mha なのでやや上がっている

吸引力

  • 気持ち強くなっている気はする
  • MAX モードは相当強くなっている
  • フィルタの手入れ状態にもよる気はするのでフィルタの手入れは重要

ボタン

  • Dyson は昔からパワーオンのボタンがタクトスイッチ式で押している状態じゃないと動かない
  • V8 の場合そのボタンが V6 に比べ重くなっており少し力を入れないとボタンが押せない
  • ゆえに長時間掃除機をかけていると指が疲れる

最後に

全体的に見ると V6 のほうがいいような気もしています
dyson の型落ちはだいぶ前のバージョンでも全然やれる気がします
その割にすごい安いのがいいです

投稿者 時刻: 0 コメント
ラベル: ,

2025年3月9日日曜日

iPad mini 6 レビュー

iPad mini 6 レビュー

mini2 からの乗り換え

価格

  • 中古 43980円

購入時期

  • 2025/03/07

バッテリー残量

  • 82%
  • さすがにハズレでした

日本語入力でキーボードを分割しないとフリック入力できない

  • 分割すればできるが分割すると英字入力時も分割されてしまう (英字の場合は分割してほしくない)
  • ちなみに分割する方法はキーボードを表示して右下のキーボードマークを長押し -> 分割でできる

Dock 邪魔

  • 下からスワイプしたときにホーム画面に行かずに Dock だけ表示してしまうことがある
  • これはコツでカバーするしかなくて下からスワイプするときに一瞬ではなく少し長めにスワイプして止めるとAppスイッチャーになる
  • もしくは4本指上スワイプでAppスイッチャーになる

TouchID を押して画面のロックも解除したい

  • デフォルトだと TouchID に指を置いただけでは画面は真っ暗で解除できない
  • 先に画面をタップするかボタンを押してから TouchID をしないとロック解除できないので不満
  • FaceID はない

自動ロック

  • デフォルト2分で短い場合は15分などにする

充電はType-c

  • 自分はまだライトニング端末があるのでケーブル2本持ちが不便 (iPhone14 と Airpods)
  • M1 Macbook と接続するのはすごい簡単、M1 のバッテリーケーブルが使えるので

バッテリーの交換難易度

  • 少し高めな印象
  • ディスプレイさえ外せばなんとかなるかも
  • 外部に依頼すると1万円を超えてくる (けど安全)

最後に

さすがに mini2 はもう限界でした
mini は今までビューワーでしか使ってなかったのでサイドカーとかも試してみたい

投稿者 時刻: 0 コメント
ラベル: ,

2025年3月8日土曜日

M1 Macbook Air レビュー

M1 Macbook Air レビュー

買ってだいぶ経つが一応
10年頑張った MacBook Air late 2014 からのアップデートなので全体的には満足

購入時期

  • 2024/09/07

価格

  • 中古 71000円

スペック

  • M1 Macbook Air
    • CPU8コア
    • GPU7コア
    • メモリ8GB
    • ディスク256GB
    • USキーボード

英字キーボード縛りにすると新品の本家かフリマじゃないとなかなか手に入らないので辛い

  • 中古市場だとほぼJISキー配列しかない
  • ただ新品だと M1 はもう買えないし M3, M4 は高い
  • なのでフリマ系で探した

TouchID 便利

  • タッチするだけでロック解除できる
  • しかもガッツリ触らなくても一瞬サラっと指を置くだけで解除できるのですごい (本当に認証できているのか不安になるくらい

性能もそこそこ

  • M2 pro mac mini の半分くらいだが開発するには十分
  • LSP の起動や各種アップデートなどはだいぶ速くなった

ファンレス

  • かなり静か
  • ただ計算処理するとかなり熱がこもる印象
  • 重い計算処理をする場合には熱を逃がすような手段が必要かも (扇風機、ヒートシンクなど)

やっぱり作業するにはラップトップが便利

  • M2 pro mac mini はかなり重い処理 (機械学習のモデル動かすときや、Xcode ビルド) のときには使うが日常使いではほぼ使わなくなった
  • M2 は毎日マイニングを頑張っている

天板がよく汚れる

  • 自分の環境が悪いだけかもですが付属の充電ケーブルを M1 Macbook Air を閉じて天板の上に置いて保管しておくとなぜか天板がすごく汚れてしまう
  • なのでケーブルと本体は必ず離して保管するようにしている

前のマシン補足

  • 購入時期 2014/12/21
  • MacBook Air 13インチ
  • 1.7GHzデュアルコアIntel Core i7（Turbo Boost使用時最大3.3GHz）
  • 8GB 1,600MHz LPDDR3 SDRAM
  • 256GBフラッシュストレージ（PCIeベース）
  • バックライトキーボード (US) + 製品マニュアル（日本語）
投稿者 時刻: 0 コメント
ラベル: , ,

2025年3月3日月曜日

kasaca キックボードの前輪がハンドルで制御できないときの対処方法

kasaca キックボードの前輪がハンドルで制御できないときの対処方法

概要

ハンドル部分のネジが緩んでしまいハンドルを回しても前輪が一緒に回らないときの対処方法を紹介します

ハンドルのネジ部分を締め直す

前輪タイヤとハンドルを逆方向に回すことで締めることができます

前輪タイヤとハンドルが90度にならないことがありますがこれはあとから調整できるのでとにかくしっかり締めましょう
タイヤを右手でハンドルを左手で持って逆方向に回せば締まっている感じがわかると思います

ハンドルの角度を調整する

六角レンチでハンドルを固定している部分を緩めます

するとハンドルの角度が調整できるのでタイヤとハンドルが垂直になるように調整します
垂直になったら再度六角を締めれば OK です

その他メンテ

  • 各六角ボルトの部分はしっかり締めておく
  • ブレーキがしっかりかかるようにブレーキ部分の三角コーンみたいなネジをしっかり締めておく
  • タイヤの回りが悪い場合には軽くシリコンスプレーをかけてあげる

最後に

小学生くらいがガッツリ遊びまくるとあっという間に各種ボルトが緩むのでしっかりメンテしましょう

投稿者 時刻: 0 コメント
ラベル:

2025年1月18日土曜日

Backpack Hero プレイメモ

Backpack Hero プレイメモ

過去に Slay the Spire をやりましたが同じようなゲームがあったのでやってみました

ゲーム概要/目的

  • クエストをクリアして街を発展させる
  • クエストおよびアイテム収集のコンプ
  • 一応ラスボスがいる

価格

  • 1380円

プレイ時間

  • 約69時間

好きなアイテム/レリック

  • サンゴ
    • これで0コストの武器を生成しまくって殴りまくるゲーム

ラストステージにいくには

  • すべてのキャラの開放
  • すべてのキャラのチュートリアルクエスト消化
  • すべてのキャラで3層までを2回クリア

でビーコンが設置できるようになるのでそのあとパースで潜れば OK
ビーコン設置後にコンスタンスに話かけないと親父が3層にいることがわからないので話しかけること

4層はラスボスしかないので倒すとエンディングが始まる
エンディング後はゲームを一度ダウンさせて再度スタートすると自動でオーデリアに帰っていてかあちゃんとの会話になる
更に必要なキャラに話すと各キャラのハードモードクエストが開放される

余っているスパークがあればマシューに渡せばアイテムと交換してくれる

エンディング画面ではゲームを終了させるしかなさそう

クリアクエスト数/発見アイテム数

  • クリアクエスト数 -> 43
  • 発見アイテム数 -> 836/903

難しかったクエスト

  • トート
    • ほぼすべてのクエストが難しい
  • ポシェット
    • ガラスの一族 (仲間を死なずに進めるのが難しい

強いなと思ったビルド

基本的には0コストビルドは全部強かったです

パース: バランス

とくかくバランスが強いなと思った印象です
ブロックも上げつつ武器もそれなりにかつ全体にまんべんなくダメージを与えられるビルドが安定して強かったです

マチェーテ＋ 木の葉のカタールでリセットしつつ叩くビルド

砥石＋0コスト武器で強化して叩くビルド

春の宝珠で強い武器コストを0にして攻撃するビルド

こんな感じで宝石と防具をバランスよく置くだけでもそこそこ戦える

トート: 斧＋ペレットコンボ

正直これはチートレベル

横に広げて斧を並べて使い切ったらペレットで回数をリセットすることで無限に殴れるビルド
アイテにトゲさえなければ絶対勝てます

以下は実際にプレイしている動画です

トート: 廃棄メイスビルド

簡単にビルドできるのがいい点です
とにかく0コストの彫刻を集めまくっていっぱいになったら投げて廃棄しそのあとでメイスで叩くだけです
エナジーがあるだけいいのでエナジーが増えるレリックがあると更に良い

サッチェル: 0コスト＋魅了

サッチェル自体かなり強いので正直0コストビルド以外でもいけるかなとは思います
特に0コストのナイフ or ハンマービルドはトートの無限ループレベルで強いです
口笛で適当に魅了をばらまいてから叩けばいつの間にか敵全員がこちら側にいます

ハンマーは置きまくるだけでも強い

サッチェルのナイフは別ポケットにあるナイフ数に応じてダメージが上がるのでポケットも意識すると強い

ポシェット: バランス

パース同様バランスが強い印象です (というかこれしかない

ブロック寄せ
加速もあり200以上になるケースもある

CR-8: バランス

チャージを何回も往復させてたくさんアイテムを通るようにすればだいたい強くなる

防御グリッドやレーザーガンのようにチャージを可能な限り走らせてから最後に当てると簡単に強くなる

キャラクタ強い順

  1. サッチェル
    • 魅了とかいうチートスキル持ち
  2. CR-8
    • 全自動パース
  3. ポシェット
    • パース＋仲間あり
  4. パース
    • これがベース
  5. トート
    • 彫刻自体が難しい、正直無限ループコンボじゃないとクリアできないレベル

裏技

ご利用は計画的に

  • ほしいアイテムを入手する
    • 宝箱や敵の直前でセーブしいらないアイテムだったらタイトルに戻ってやり直す
  • 研究のリセマラ
    • パースの一番はじめのダンジョンでレアアイテムをじいさんからもらってほしいアイテムだったら即死んで研究の材料にする
    • なかなか出ないことがあるので普通にクリアするほうがいいかも
投稿者 時刻: 0 コメント
ラベル:

2024年12月7日土曜日

2024 できたこと・できなかったこと

2024 できたこと・できなかったこと

去年に引き続き今年もやりました

できたこと

時系列

去年の目標だった「ヒゲの脱毛」「iPhone 買い替え」は無事達成できた
また「新しい趣味」はクレーンゲームに挑戦できたのがよかった
いろいろと去年の目標を達成できた年だったと思う

何もアウトプットがなかった月もあったが数でカバーできてよかった
上記に記載はないが引き続き断捨離はできた
AI 関連のアウトプットに力を入れることができた

iOS アプリを全部野良アプリとして再公開できたのはよかった
Android、golang、Ruby の自作アプリもちゃんと管理できた (ライブラリの管理やリファクタなど)

Youtube 活動はやや少なかった

その他

  • ブログ執筆数: 238 (12/08 時点)
  • Podcast エピソード数: 3

ブログの投稿数は前年どから20%ほどあがった
Podcast 4->3 と減少した

0じゃないだけいいと思うようなった

できなかったこと

  • Youtube Live (去年に引き続き)
  • 新規アプリ開発 -> 今年はできた

SwiftUI に挑戦して新規アプリを公開できたのはよかった
Youtube Live は戒め

来年の豊富

  • 引き続き断捨離 and アウトプット
  • 何か資格取る

アウトプットは全体的に多めにできたと思う
管理するアプリがまた増えたので効率的に管理できるようにしたい

ある程度の身辺整理が落ち着いたので挑戦というより安定と効率化を重視するようになった気がする

投稿者 時刻: 0 コメント
ラベル:

2024年12月3日火曜日

自分はレビューいらない派です

自分はレビューいらない派です

ChatGPT 先生と相談しやはりいらないという結論に至りました

レビューの意義やメリットについてはここでは触れません、またそれらも人それぞれの感性があることを前提に進めます

この記事は全面的にレビューを批判する記事になっています

自分のレビューに対する考え要約

  • レビューでバグは潰せない
    • それならばE2Eなテストを増やそう
    • ちなみにテストを書くにも嫌い (特にユニットテスト)
  • 情報共有の意味があるならレビューではなく直接タスクを与えたほうが価値がある
  • 静的解析、テストなどシステムにすべてまかせるような仕組みを作るべき
    • それがないから人間(レビュー)に頼ってしまう
  • 作ってくれた人は全面的に信頼している
    • どうしてもその人がレビューしてほしいと思うのであればやるべき
    • 作ってくれたコードに文句を言いたくない、文句があるなら自分で直せばいいだけ
  • そもそもレビューは同レベルの知識を持つ人でないと意味がない
  • バグのないアプリは存在しない
    • 自分は常にそう思っている
    • バグがある箇所や時期を踏まれていないだけでどんなアプリにも必ずバグはある
    • もしくは全く使われていないだけか
  • 上記踏まえて時間の無駄、逆にやらないことによる時間を有意義に使える

ChatGPT先生との相談ログ

以下先生に相談したログです
フォーマットなどは崩れていますが可能な限り読みやすいようにしています

Q: コードレビューについて質問です。自分はコードレビューは意味がないと思っているのですがあなたはどう思いますか？

A:

コードレビューが意味がないと感じる理由を教えてもらえますか？その理由によっては、コードレビューの意義を再考したり、効率を改善したりするアプローチが見つかるかもしれません。

コードレビューは多くの現場で以下のようなメリットをもたらすと言われています：

品質の向上
バグの発見や設計の見直しが行われ、コードの品質が向上します。複数の目で見ることで、自分では気づけないミスや改善点が見つかることがあります。

ナレッジ共有
他の開発者がコードを読むことで、プロジェクト全体の理解が深まり、属人化を防ぐことができます。

スキル向上
レビューを受けることで、自分のコードスタイルや設計に対するフィードバックが得られ、スキルが向上します。レビューする側も他人のコードを読むことで学びを得ることができます。

規律の向上
他人に見られることを前提にコードを書くため、コードの可読性や設計を意識するようになり、結果としてチーム全体の基準が引き上がります。

ただし、意味がないと感じるケースも理解できます。例えば：

形式的で深掘りしないレビュー: 表面的なコメントや惰性で行われるレビューでは、実際の改善につながりにくい。
過度な批判や不毛な議論: レビューが対立の場になると、効率が下がるだけでなく、チームの雰囲気を悪化させる。
時間がかかりすぎる: レビューが長時間に及び、進捗が遅れる。
もし具体的な課題があるのであれば、それに応じた解決策を一緒に考えられます。たとえば「短時間で効果的なレビューの方法」や「建設的なフィードバックの仕方」などについて話すこともできます！

Q: 自分がコードレビューが意味がないと感じる理由は以下です「コードレビューをしてもバグがゼロになるわけではない」「コードレビューに情報共有の意味があるのならコードレビューで情報共有しないで直接コードを修正するようなタスクを与えて情報共有したほうが効果もある」「時間の無駄」が主な理由です

A:

コードレビューが「意味がない」と感じる理由、納得できる部分もあります。それぞれのポイントについて考察と改善のアイデアをお伝えします。


1. コードレビューをしてもバグがゼロになるわけではない
考察: 確かに、コードレビューをしてもバグがゼロになる保証はありません。バグは多くの場合、コード以外（設計、要件定義、使用環境など）に起因することもあります。また、レビューでは見逃しが発生する可能性も高いです。

改善アイデア:

レビューの目的を明確化する: 「バグをゼロにする」ことを期待するのではなく、「主要な設計ミスや重大なバグを減らす」「可読性やメンテナンス性を向上させる」ことに焦点を当てると現実的です。
ツールを活用: 静的解析ツールやテストフレームワークで自動的にバグを検出できる部分を先に排除し、コードレビューの負担を減らす。


2. コードレビューより直接修正タスクを与えた方が効果がある
考察: 「修正タスクを与えることで学ぶ」というアプローチは効果的です。ただし、修正を行う本人がプロジェクト全体の背景や他の影響を理解していない場合、不適切な修正が増えるリスクがあります。

改善アイデア:

ペアプログラミング: 修正タスクを与える代わりに、タスクを行う開発者とコードの知識を持つレビュー担当者が一緒に作業する。これにより効率的な情報共有が可能。
モブプログラミング: チーム全体で特定のコードを修正しながら、全員で学び合う場を作る。
事前の知識共有: タスクを与える前に、該当箇所に関連する設計や背景知識をしっかり共有しておく。


3. 時間の無駄
考察: 時間がかかりすぎたり、効果を実感できないコードレビューは、無駄と感じやすいです。特に、形式的で建設的な議論が生まれないレビューは、コストに見合うリターンが得られません。

改善アイデア:

軽量レビューの導入: 大規模なコードレビューではなく、小さな変更を頻繁にレビューすることで、時間を節約しつつ質を保つ。
レビュー基準の明確化: 「何を確認すべきか」をチームで明確にして、効率的なレビューを目指す。
ツールの導入: GitHubやGitLabなどのプラットフォームを活用して、変更箇所のみをピンポイントでレビューする。


代替案：コードレビューを廃止した場合のリスク評価
もしコードレビューを完全に廃止した場合、以下のリスクが考えられます：

コードの品質や一貫性の低下
属人化の進行
他メンバーのスキル向上や学習機会の減少
これらのリスクを受け入れられる場合は、より直接的なアプローチを選ぶのも1つの方法です。ただし、チームメンバー全員の合意と運用ルールの徹底が必要です。

Q: コードの品質や一貫性の低下はユイットテストやエンドツーエンドテストで補えると思います。属人化の進行はレビューではそもそも補えません、実際にコードを書けるレベルになって初めて属人化の解消になります。他メンバーのスキル向上や学習機会の減少、これもレビューでは補えません。属人化の部分の回答と同じです

A:

なるほど、非常に筋が通った主張ですね。コードレビューのメリットとして挙げられがちな点が、他の方法で代替可能であるという視点は重要です。以下の観点であなたの意見を深掘りしつつ、代替アプローチについて考えてみます。


1. コードの品質や一貫性について
あなたの言う通り、ユニットテストやエンドツーエンドテスト（E2Eテスト）は、バグ検出や動作保証の観点でコードレビュー以上に効果を発揮することがあります。さらに、コードの一貫性についても、自動化ツール（PrettierやESLint、StyleCopなど）を使えば、レビューに頼る必要がほとんどなくなります。

代替アプローチ:

テストカバレッジの向上: ユニットテストやE2Eテストの割合を高め、レビューではチェックしない項目をカバー。
CI/CDの整備: 自動テストとコードフォーマットチェックをCI/CDパイプラインで実行し、レビューを通さずに品質を担保。
注意点: ただし、レビューはコードの「意図」や「設計」にフォーカスできますが、自動化ツールはその部分を補えないことがあります。テストで検出できない設計ミスや冗長な処理を防ぐための仕組みが必要です。


2. 属人化の進行について
属人化の解消には、「コードを書けるレベルになる」ことが不可欠であるという点に同意します。コードレビューだけでは、確かにそれが実現しない場合も多いです。

代替アプローチ:

ペアプログラミングやモブプログラミング: 直接的にコードを書きながら学ぶことで、知識共有とスキルアップを同時に実現できます。
ローテーション制度: 特定のタスクや機能領域について定期的に担当者を変える。これにより、複数のメンバーが同じ部分を理解する機会を得られます。
技術共有会: チームでコードや設計について定期的に議論し、属人化を減らす。


3. スキル向上や学習機会について
コードレビューはスキル向上の一部を担うことがありますが、必ずしもそれが最適な手段とは限りません。レビューのコメントが表面的だと学びは少なく、実際にコードを書く経験には遠く及ばないという意見は非常に妥当です。

代替アプローチ:

トレーニングタスクの設定: 開発者が新しい技術や設計パターンを学ぶための小さなタスクを与え、学びの機会を明確化。
メンター制度: 経験豊富な開発者が他のメンバーを指導し、実践を通じて学ぶ環境を整える。
レビュー以外のフィードバック: リアルタイムでのコード解説や設計レビューセッションを設ける。


結論
あなたの意見の核は「レビューだけではこれらの課題は解決しきれない」という点にあり、それは正しいです。加えて、レビューは一つの手段に過ぎず、それがチームにとって非効率であるならば、他のアプローチを導入すべきです。

チームとして以下のようなプロセスを試してみる価値があるかもしれません：

コードレビューの目的を再定義: レビューを行う場合でも、レビューの対象や方法を限定し、設計や意図に焦点を絞る。
自動化と実践型アプローチを組み合わせる: テストやCI/CDの自動化に投資しつつ、学びの場としてペアプログラミングや技術共有会を導入。
コードレビューを必須にする必要はありません。チームの状況や課題に合わせて柔軟にプロセスを設計することが最も重要です。

Q: ではコードをチェックできる自動化された環境がありかつチーム内で属人化を解消するコードの知識を共有する体制になっているのであればレビューは不要という認識でいいでしょうか？

A:

その通りです！コードをチェックする自動化された環境が整っており、かつ属人化を解消するためのコード知識共有体制が機能しているなら、コードレビューは不要と言えるでしょう。

以下にその条件を整理します：


1. 自動化されたチェック環境
静的解析ツール: コーディング規約の遵守や潜在的なバグ検出を行うツール（ESLint、SonarQube、Checkstyleなど）が適切に設定されている。
テスト自動化: ユニットテスト、統合テスト、E2Eテストが十分にカバーされており、CI/CDパイプラインで実行される。
コードフォーマットツール: PrettierやBlackなどでコードのスタイルを自動整形し、見た目のレビューを不要にする。
セキュリティチェック: 依存関係の脆弱性チェックやコードのセキュリティスキャンを自動化している。


2. 属人化を解消する仕組み
ナレッジ共有の文化: ドキュメント化や共有会、コードベース全体の可視性が確保されており、誰でも理解しやすい体制になっている。
ローテーションやペアプログラミング: 特定のタスクや機能領域が特定の人に依存しないように、メンバーが交代でコードを触る機会がある。
実践を通じた学び: 他のメンバーが既存のコードを理解しやすいタスク設計やコーディングの実践が行われている。
コードの意図を記録: 関数やクラスのコメント、設計ドキュメント、コミットメッセージで十分にコードの意図が伝わるよう工夫されている。


3. レビュー不要とする前提条件
以下の質問に「はい」と答えられる場合、レビューは不要と考えられます：

バグの発生率が許容範囲内か？
→ テストや静的解析でほぼ十分にバグが防げている。
チーム全員がコードの目的や設計を理解しているか？
→ 共有体制が機能し、メンバーがコードを理解している。
新メンバーが独立して貢献できるまでの時間が短縮されているか？
→ ドキュメントやナレッジ共有によって属人化が解消されている。
チーム内の信頼が高いか？
→ メンバー間の信頼が高く、他人のコードが問題なく利用できる。


検討ポイント
レビューを廃止する前に以下も確認すると良いでしょう：

トライアル期間を設ける: レビューを完全に廃止する前に、レビュー頻度を下げたり、特定のケースでのみ行う運用を試してみる。
データの計測: レビューをしないことで、バグの発生率やリリース速度がどう変化するかを測定する。


結論
「自動化されたチェック環境」と「属人化を解消する仕組み」が整備されているのであれば、レビューは不要であるという認識で問題ありません。それどころか、その環境が機能している場合、レビューを行うことが逆に非効率になる可能性もあります。

重要なのは、チームにとって最適なプロセスを柔軟に設計し、定期的に見直すことです。このアプローチがあなたのチームにとってベストな選択肢になることを願っています！

相談した結果感じたこと

レビューは一つの手段に過ぎず

確かにこれには同意した
強制するものではなくあくまでも「手段」であるということ
そういう意味でも自分はレビューという手段の優先度はかなり低い

あなたのチームに合ったプロセスを模索するのが重要

確かにこれも同意した
チーム内でレビューに重きを置いていることを上も理解してそこにコストを割くことを容認してくれている場合はじっくりやっていいと思う

ただそれでもコードの内容を知らない人にレビューしてもらっても何も意味がない気がする

データの計測: レビューをしないことで、バグの発生率やリリース速度がどう変化するかを測定する。

これも同意
むしろデータ計測やサービス効果測定みたいなものは初めからあってもいいと思う
ただどうやるかと何を評価項目にするかとどう抽出するかはかなり難しい気がする

最後に

最後は ChatGPT 先生を言いくるめたような感じなってしまいましたが最終的には自分の意見に同意してくれたのでよかったです

参考文献

投稿者 時刻: 0 コメント
ラベル: ,
登録: 投稿 (Atom)