月: 2022年8月

ChromeのデベロッパーツールのNetworkタブでは、アクセスしたページとやりとりされたリクエストやレスポンスについて、その内容や所要時間を確認することができます。
そして、Networkタブで確認した内容は、harファイルと呼ばれるファイルに出力し、保存することができます。

harファイルを出力する手順は以下の通りです。

【手順】

１．Chromeを立ち上げる。

２．F12でデベロッパーツールを立ち上げる。

（「その他ツール」→「デベロッパーツール」、Ctrl+Shift+Iでも可）

３．「Network」タブをクリックする。

４．録画状態なら停止する（画像中③が赤丸ならクリックして黒丸にする）

５．既に出力されているリクエスト・レスポンスを削除する（画像中①をクリック）

６．「Preserve log」にチェックを入れる（画像中②のチェックを入れる）

７．録画状態にする（画像中③をクリックして赤丸にする）

８．ブラウザ上で任意の操作を行う（リクエスト・レスポンスが記録される）

９．画像黄枠内で右クリックし、”Save all as HAR with content”をクリック

１０．ファイル保存ウインドウが開くので、任意のフォルダにharファイルを保存

ちなみに、harファイルはjson形式で保存されています。
そのままでは人間の目で確認するのが困難ですが、”HTTP Archive Viewer“のようなページでharファイルを解釈することで、ChromeのNetworkタブのような表示形式に加工することができます。

いかがでしたでしょうか。

Webシステムの開発ではリクエスト・レスポンスの調査・確認が必要になることが少なくありません。
そこでharファイルが役に立つので、harファイルの扱いには慣れておいた方が良いです。

このような細かいテクニックはこれからも展開していこうと思います！

要件が「現行踏襲」である案件の代表的なリスクとして、「現行の仕様を調査してその仕様に合わせる工数、が過小評価されやすい」というリスクがあります。
そして、要件が「新たな導線を追加する」である案件は、一見現行踏襲でないように見えて、実際は現行踏襲案件と同じようなリスクを抱えます。

今回は、私が体験した案件を例に出して説明します。

今回例として挙げるシステムは、「営業員がプランを勧めて、最終的にエンドユーザーが個人情報を入力する」という営業システムです。
この営業システムのUIは、前半の営業員画面と、後半のエンドユーザー画面に大別できます。
前半は営業員が使うことを想定したシンプルな画面であり、プランを表示・入力する機能があります。
後半はエンドユーザーが直接目にするリッチな画面であり、個人情報を入力する機能や、入力内容を確認する機能があります。

この営業システムについて、「営業員によるプランの勧誘もエンドユーザー画面上で行うようにして、エンドユーザーだけで操作が完結するようにしたい」という要件の保守案件が発生しました。
システム的に見た場合は、前半の営業員画面だけではなく、別のエンドユーザー画面（以下「新エンドユーザー画面」）でもプランの表示・入力を可能とする、というものです。言い換えれば、前半の導線を増やす、というものです。

ここまで説明したことを図に表すと以下の通りです。

新エンドユーザー画面もエンドユーザーが直接目にするため、リッチなUIが必要になります。要件として示されたデザイン案も、これまでシステムでは取り入れていなかったデザインが採用されていました。
そのため、見積もりの段階では、リッチなUIに対応することが焦点に置かれ、技術的なリスクが重く見られました。

しかし、技術的な問題は、一旦技術検証が済んでしまえば、その後にリスクとして顕在化することはありませんでした。
代わりに、実際にリスクとして顕在化し、工数増大の原因となったのは、現行踏襲のリスクでした。

新エンドユーザー画面では、営業員画面と同じ機能を提供する必要があります。
また、最終的には後半のエンドユーザー画面に合流するため、内部的なデータ構造も営業員画面と同じように保持する必要がありました。
更に、営業員画面と新エンドユーザー画面では、見せ方の違いにより入力順や入力内容が微妙に異なっていたため、単純な機能移植で済むというものでもありませんでした。

これらの要因により、「現行仕様をデータ構造まで踏み込むレベルで調査・理解した上で、営業員画面と新エンドユーザー画面の差異に気を付けながら仕様を策定する」という作業が発生しました。この作業の工数は、見積もり時点では過小評価されていました。
そして、設計工程の工数増加や、仕様考慮漏れによるテスト工程での大量のバグ検出に繋がりました。

いかがでしたでしょうか。

「要件が現行踏襲である案件は危ない」というのは良く言われることですが、要件に「現行踏襲」と書いてなくとも似たようなリスクを持つ案件というのも存在します。
この類のリスクは、「要件に現行踏襲と書いてあるか」という観点ではなく、「現行の仕様にどの程度合わせ込む必要があるのか」という観点で見つけるべきです。

これからも、今回のような教訓を広めていきたいと思います！

「アンカリング」とは、先に与えられる情報をベースに意思決定してしまうことを指す心理面の現象のことであり、心理学の用語です。
この現象は交渉の場面で役に立ちます。
先に厳しめの要求を出すことで、その要求をベースに交渉を進めることができます。
厳しめの要求を出した後、相手に合わせて譲歩するのですが、厳しめの要求をベースに譲歩をすることができるので、こちらが飲めるギリギリのラインよりもこちらにとって有利なラインで交渉を成立させることができます。

ITシステム開発の受注者としては、工数の見積もりの場面で応用できます。
工数を正確に見積もることができる案件であれば正直に見積もりを出せば良いのですが、不確実性がありそれが難しい案件ではある程度のリスクバッファが必要になります。
「不確実性コーン」と呼ばれる有名な研究成果があるのですが、最も初期の段階では見積もり工数に±4倍のブレが発生します。
（詳しくは、「見積もり概論」社内勉強会用のパワポの３ページ目を参照して下さい）

そこで、リスクバッファを確保するために、交渉で工数が削られることを見越して多めの工数で見積もるということをします。
（最低でも、不確実性コーン上での最悪のケースを想定した工数で見積もりを行った方が良いです）
発注側が想定している工数から4倍以上も離れている場合は流石に工数を削るように要求されることが多いのですが、その場合はお互いに考えている要件や工数をすり合わせた上で、要求を満たすのに最低限必要な要件と、それに基づいた工数が決まることになります。
始めに多めの工数を出しておくことで、その結果として平均的な工数よりも多めの工数を確保できることが多くなり、リスクバッファを確保しやすくなります。

なお、多めの工数を出す理由としては「楽をしたい」「儲けたい」といった理由ではなく、あくまでもリスクバッファの確保なので、開発者が開発期間の長さに安心して平時からリスクバッファを食いつぶすようなことがあってはなりません。
そのため、開発者には逆に厳しめのスケジュールを伝えて、スケジュールの調整をしたりします。そうすることで、スケジュール的な余裕が生まれ、不測の事態が起きた時に取れる選択肢が広がります。

いかがでしたでしょうか。

今回紹介したような手法は多くの経験者が実践していることだとは思いますが、形式知として広まることは少ないかもしれません。
形式知として広まっていない以上、知らない・実践していない方がいても不思議ありません。
そこで、心理学のような学問の知見を借りることで、手法を形式知として表現することが容易になり、手法を広めやすくなります。

これからも、多くの人が知らず知らずの内に使っている手法を形式知として広める、ということをしていきたいと思います。