okinawa_se_log

34歳 2020年3月1日IT企業に転職しました。2年くらいSQLとJAVAに取組んで、今は主にPMとして活動してます。学びをメモがわりにツイートしていきます。

[okinawa_se_log @StudyRestart]

読書について
読んで終わりにせず、筆者の主張を抽象化して、自身の考察まで行わないと意味がない。一度読むだけでは考察までいきつかないので、複数回読む前提で1回目は読み返すポイントに当たりをつける。

[okinawa_se_log @StudyRestart]

ドキュメント、プレゼンレビューポイントメモ
・始める前にルールを読む
・自己顕示や他者攻撃は無意味なのでやらない
目的
・ドキュメントやプレゼンの品質向上と作成者/発表者の成長
・レビュワーの成長
・組織的なチェック機能の向上
・組織的なマインドの統一
検討中
レビュー精度を上げる成果物

[okinawa_se_log @StudyRestart]

良いドキュメントを描くために本を読んだのでメモ
良いドキュメントの定義
・ドキュメントの目的は読み手と書き手のゴールを達成すること。（双方に目的がある。）
・ユーザビリティーが良いこと。
・書き手が伝えたいことが読み手に一意に伝わること。

[okinawa_se_log @StudyRestart]

Fit&Gapメモ
当たり前だけど、Gapを埋める際にまずはパッケージとして、「できる」、「できない」を明確に伝える→できない場合の代替え案を詰める。っていう流れにしないと、課題が終わらない。

[okinawa_se_log @StudyRestart]

NWメモ
L2から学ぶ。Macアドレス→ポートに一意に割り振られる。IPアドレスで宛先が指定された際に、ARPにてMACアドレスを特定して通信する。

[okinawa_se_log @StudyRestart]

【負荷試験メモ】
大まかな方針。日中の平均ログインユーザー数、1ユーザーあたりの平均ログイン回数、ユーザーの操作割合、操作に関連する画面遷移を集計して、リクエスト数とシナリオを決める。

[okinawa_se_log @StudyRestart]

Fit&Gapメモ
もちろんGapが出るのは当たり前だし、クライアントの宿題にすることもあるけれど、少なくとも要件の確定のために、何を詰める必要があるのか、どの部分がGapの大元になっているのか、その部分はベンダー、クライアントともに妥協の余地はあるのか、は整理しないと一生要件が詰まらない。

[okinawa_se_log @StudyRestart]

ADサーバとのシングルサインオン要件で顧客と会話することがあり、そもそもADの機能について把握してなかったので調べたメモ。
管理下のPCのパスワード管理、操作ログの追跡、アクセス制限、アプリ配布。

[okinawa_se_log @StudyRestart]

【負荷試験メモ】
同時リクエスト数の要件を算出するために、アクセス集中率や安全率の他に、対象システムが「業務システム」等のシステム特性もパラメーターとして必要かも。
不特定多数のユーザーが任意でアクセスするシステムと業務に必要な職員が義務としてアクセスするシステムでは想定が異なる

[okinawa_se_log @StudyRestart]

リソースが枯渇してるって言うけど、どの作業にどれくらい工数がかかるのか、計算してチームの生産性やタスクの期限を踏まえて、定量的に状況を評価しないと、ただ忙しいに終始しちゃうよね。まずは測ることから。

[okinawa_se_log @StudyRestart]

セッション数、リクエスト数、コネクションプールの設定も事前に確認し、かつ検証が必要。

[okinawa_se_log @StudyRestart]

【負荷試験】
試験の目的、前提、目標、構成、シナリオ、結果を整理する。できそうな気がしてきた。

[okinawa_se_log @StudyRestart]

心理的安全性、自由に発言できる環境が無ければ、様々な知見のある優秀な人を採用したり、革新的なことを思いついても、組織的に能力や発想を活かせる可能性は低い。と、感じた日だった。

[okinawa_se_log @StudyRestart]

【負荷試験メモ】
平均使用ユーザー→1日の平均ログインユーザー
平均アクセス数→1ユーザーの平均ログイン数
アクセス集中時間→システム特性による

ここまででスループットの目標値を決める。
その後、ログイン後の処理の割合によりシナリオを決める。

[okinawa_se_log @StudyRestart]

一定時間の処理量→スループット
処理にかかる時間→レインテンシ
適切なスループットの目標設定から始める。

[okinawa_se_log @StudyRestart]

負荷試験、現時点で分かってるダメなこと。
・同時接続率と同時リクエスト数（多重度）が一緒になってる。
・サービス提供期間経過時のデータ増加量の根拠が適当。
・計測すべきリクエストの種類の検討が不足してる。

[okinawa_se_log @StudyRestart]

「自社システムをモダン化させるぞ」って開発部門全体で息巻いてたんだけど、ふとシステムの現状を確認したら、実施した負荷試験が前提条件、シナリオ共に適当だったみたい。正しい評価をするためネットで評判の良い「Amazon Web Services負荷試験入門」を読んで適切な評価方法を学んでみよ。