6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

パフォーマンス改善のフレームワーク

Posted at

こんにちは。 ぬこすけ です。

フロントエンドであれ、バックエンドであれ、パフォーマンスのボトルネックを発見し、改善の施策を考えるケースがあるでしょう。

例えば、調査した結果、ある関数の処理がめちゃくちゃ時間かかっていたことがわかったとします。
あなたはこのボトルネックに対して、この関数のロジックを工夫して処理時間を下げるような施策を思いついて、ソースコードを試行錯誤して修正していきます。

job_kouji_stop2.png

待ってください
本当に関数のロジックを工夫するだけが施策なのでしょうか?
実はもっとたくさん施策があったりするんじゃないでしょうか?

例えば、「そもそもこの関数は必要ないから削除する」「メインスレッドだけでなく別でスレッドを立ち上げて関数を実行する」など色々施策はありそうです。

ビジネスの世界ではよく「 フレームワーク 」という言葉が出てきます。
「 3C 分析」や「 SWOT 分析」、「 4P 分析」などがよくフレームワークの例として挙げられます。

ビジネスにおけるフレームワークとは、意思決定、分析、問題解決などを行うときに活用でき、経営戦略や問題解決、業務改善などに役立つ、共通の考え方や思考の枠組み、分析ツールのことを指します。
https://www.ohmae.ac.jp/mbaswitch/_mba_framework/

フレームワークって、なんか強そうですね。
使う目的は色々ありますが、 1 つ挙げられるのは「 抜け漏れをなくすこと 」があります。
決まった枠組みで思考することで、「この問題の原因ってこれだけじゃないよね」「解決策はこれもあるよね」という感じに抜け漏れをなくすのです。

パフォーマンス改善の施策を考えるときもフレームワークに当てはめて思考できる と思うのです。

リスクマネジメントにおける 4 つの対応戦略

finger_count04.png

本題に入る前に、ちょっとリスクマネジメントのフレームワークについて説明します。

プロジェクトマネジメントの知識を体系化した PMBOK には、リスクに対応するために 「回避」「転嫁」「軽減」「受容」 という 4 つの戦略が紹介されています。

回避

リスクの発生を抑える戦略です。
例えば、「発注先が倒産しそうなのでその会社に発注しない」というのは「回避」に当たるでしょう。

転嫁

リスクを第三者に転嫁させる戦略です。
例えば、保険の契約は保険会社にリスクを移転しているので「転嫁」に当たります。

軽減

リスクの発生確率や影響範囲を抑える戦略です。
雨が降ったらびしょびしょになるリスクがありますが、傘を持つことでびしょびしょはある程度防げます。
これは「軽減」です。

受容

リスクに対して特に何も対策はしない戦略です。
「降水確率 10 %だし、傘持つのも荷物になるので傘は持ってこない」というシーンは「受容」になります。

このようにリスクに対する対応戦略には 「回避」「転嫁」「軽減」「受容」 という 4 つの戦略があるのです。

パフォーマンス改善の施策を考えるフレームワーク

パフォーマンスが悪化しているというのは、ある意味「リスク」と捉えられるんじゃないかと思います。
例えば、 EC サイトで画面の表示が遅いと購買意欲のあったユーザーが離脱する可能性が高まります。

パフォーマンスの悪化を「リスク」と捉えることによって、「リスクマネジメントにおける 4 つの対応戦略」でお話した 「回避」「転嫁」「軽減」「受容」という 4 つの戦略で施策を「抜け漏れなく」考えられます

回避

「そもそもこの機能いる?」 というところから話は始まります。
あまりユーザーから使われていないのにも関わらず、パフォーマンス悪化のボトルネックなのであれば、そもそも機能の削除を検討できるでしょう。

全部の機能は削除できなくても、一部だけ削除するといった施策も考えられます。

転嫁

転嫁は第三者にリスクを移転する戦略とお話しました。
この 第三者は色々考えられます

スレッドを第三者と捉えるのならば、マルチスレッド化は「転嫁」でしょう。

あるいは、サーバーも第三者と捉えることができます。
処理の負担が大きいので機能を API として分割して別サーバーを立てるのも「転嫁」ですし、
外部の高速な API サービスを使うのも「転嫁」と考えられます。

軽減

冒頭では次のような例を挙げました。

例えば、調査した結果、ある関数の処理がめちゃくちゃ時間かかっていたことがわかったとします。
あなたはこのボトルネックに対して、この関数のロジックを工夫して処理時間を下げるような施策を思いついて、ソースコードを試行錯誤して修正していきます。

この関数のロジックを工夫する施策は「軽減」といえるでしょう。

受容

あえて何もしないのも 1 つの施策です。
「費用対効果的に割に合わない」「やろうと思えば改善できるがコード量が増えたり複雑になる」など色々な事情があって対応を見送るのは「受容」です。

さいごに

リスクマネジメントのフレームワークである 「回避」「転嫁」「軽減」「受容」をパフォーマンス改善に転用することで、施策を「抜け漏れなく」考えられる ことをお伝えしました。

ブレインストーミングなどで パフォーマンス改善の施策を洗い出すときに役に立つ のではないかと思っています。

今回はフロントエンドやバックエンド関係なく、あらゆる分野のパフォーマンス改善に関わるお話でしたが、 Web のフロントエンドについてはたくさん施策を紹介していたりもしているので、ぜひこちらの記事もご覧ください!

今後の情報発信していくので、ぜひ ぬこすけ のフォローをお願いします!

参考

6
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?