[DevDojo] Problem Solving - 2024

In this session, software engineering will be considered as pure problem solving, and the steps from problem recognition to solution will be explained, with reference to past projects.
This is the first content in the series written by a Principal Engineer.

Transcript

1. Problem Solving Apr 2024 DevDojo 30min @ryo-aoyama / Mobile Architect
2. What is "problem solving"? 問題解決とは？
3. What is "problem solving"? • Bug fixes バグ修正 • Refactoring リファクタリング • Performance improvement パフォーマンス改善 • Design a new system architecture 新しいシステムアーキテクチャの設計 • etc… その他 In engineering… エンジニアリングの場合は...
4. What is "problem solving"? Software engineering is purely problem solving ソフトウェアエンジニアリングは純粋な問題解決
5. Perceive problems 問題を捉える
6. Perceive problems There's two types of problem solving. 2種類の問題解決がある Negative problem solving ネガティブな問題の解決 Actions taken to resolve problems that have already occurred. (- to 0) 既に発生した問題を解消するための行動 Positive problem solving ポジティブな問題の解決 (課題解決) Actions taken to solve obstacles to achieving the goal. (0 to +) 目標達成の障害を解決するために取る行動
7. Perceive problems Negative problem solving ネガティブな問題の解決 It's important to get to the root of the problem and take permanent rather than temporary countermeasures, otherwise it creates a new technical debt. 問題の本質を捉え、暫定的処置ではなく恒久的な処置を取ることが重要。そうでなければ、新たな技術的負債を作る。
8. Perceive problems Positive problem solving ポジティブな問題の解決 Choose actions with a high degree of sustainability from a long-term perspective. 長期的な観点から持続可能性の高い行動を選択する。 Tech investment perspective is also important in this case. この場合、投資的観点も重要。
9. Perceive problems Critical thinking 批判的思考 A way of thinking that provides objective analysis and evaluation to make decisions without being driven by emotion or subjectivity. 感情や主観に流されることなく、客観的な分析と評価を行い、意思決定を行う思考法。 Don't look for reasons to affirm, but look critically at the problem and consider the nature of the problem. 肯定する理由を探さず、問題を批判的に捉えて問題の本質を考える。 Confirmation bias is your enemy. 確証バイアスを敵視する。 To get the problem right… 問題を正しく捉えるために…
10. Steps of problem solving 問題解決のステップ
11. Steps of problem solving Understand the problem 問題を理解する Analyze the problem 問題を分析する Define a goal & constraints 目標と制約を定義する Explore solutions 解決策を調査する 02 03 04 01 Evaluate solutions 解決策を評価する 05 Review the solution 解決策を省みる 06
12. Steps of problem solving Example problem 問題の例: Slow build performance ビルド速度が遅い
13. Steps of problem solving Understand the problem 問題を理解する 01
14. Steps of problem solving Understand the problem 01 • Clarify which type of problem it is, negative or positive 問題がネガティブとポジティブのどちらの種類なのかを明確化する • Identify the substantive impacts of it 問題の実質的な影響 (不都合) を特定する • Identify stakeholders, customers who are affected by or involved in the problem 影響を受ける、またはその問題に関与する利害関係者、ユーザー、顧客を特定する • Refer to the data to ascertain its severity データを参照して問題の深刻さを確かめる
15. Understand the problem 01 Slow build performance ビルド速度が遅い It's literally a negative problem because it is an existing problem in our daily development, but it also has a positive problem-solving aspect as we need a means of permanently preventing a significant deterioration in build time. これは日々の開発における既存の問題なので間違いなくネガティブな問題の解消だが、ビルド時間の悪化を恒久的に防ぐ 手段が必要であるため、ポジティブな課題解決の側面もある。(- to 0 to +) Steps of problem solving
16. Understand the problem 01 Slow build performance ビルド速度が遅い • Bad development productivity of all engineers 全てのエンジニア開発生産性の悪化 • Bad product lead time 製品のリードタイムの悪化 • Blocks simultaneous development each other 同時開発を相互に阻害する Steps of problem solving It leads to… この問題は下記に繋がる。
17. Understand the problem 01 Slow build performance ビルド速度が遅い Steps of problem solving Need to consider a long-term solution to prevent future regressions, not temporary improvement. 将来のリグレッションを避けるため、一時的な改善ではなく長期的な解決策を実施する。 Explore solutions with tech investment perspective, but avoid unprecedented ones considering the impact extent. 技術投資の観点から解決策を調査するが、その影響範囲の大きさを考慮して全く前例のないものは避 ける。
18. Analyze the problem 問題を分析する 02 Steps of problem solving
19. Analyze the problem 02 Steps of problem solving • Break down the problem into smaller 問題を小さく分解する • Do not misunderstand the essentials of the problem 問題の本質を見誤らない • Investigate root causes 根本原因を調査する Key point
20. Analyze the problem 02 Steps of problem solving Slow build performance ビルド速度が遅い • Build cache is not being used effectively ビルドキャッシュを有効活用できていない • Redundant builds due to insufficient modularization モジュール化が不十分なため、冗長なビルドが行われている • Using programming syntax that is overhead for compile time コンパイル時間のオーバーヘッドになるプログラミング記法を使っている • Too large source codes ソースコードが大きすぎる • etc…
21. Analyze the problem 02 Steps of problem solving Slow build performance ビルド速度が遅い • Build cache is not being used effectively ビルドキャッシュを有効活用できていない • Redundant builds due to insufficient modularization モジュール化が不十分なため、冗長なビルドが行われている • Using programming syntax that is overhead for compile time コンパイル時間のオーバーヘッドになるプログラミング記法を使っている • Too large source codes ソースコードが大きすぎる • etc… Non essential 本質ではない Root problem 根本原因
22. Steps of problem solving Define a goal & constraints 目標と制約を定義する 03
23. Define a goal & constraints 03 Steps of problem solving Goal 目標 A concrete, feasible, and measurable state of affairs that should be in place after the problem is solved. 問題解決後にあるべき具体的で実現可能、定量的な状態。
24. Define a goal & constraints 03 Steps of problem solving Constraints? 制約とは？ Unacceptable criterias for achieving the goal 目標を達成するための受け入れられない基準 Clarify what to achieve and what is unacceptable for the problem. 何を達成して何を受け入れないのかを明確化する。
25. Define a goal & constraints 03 Steps of problem solving Slow build performance ビルド速度が遅い • Reduce time per build by 30% or more 各ビルドの時間を30%以上短縮 • Divide modules into roughly 500+ to improve cache efficiency モジュールをおおよそ500以上に分割し、キャッシュを効率化する • 0 clean builds by ensuring idempotence of builds ビルドの冪等性を確保し、クリーンビルドを0にする • 0 redundant builds of the modules has been built somewhere else 既にどこかでビルドされたモジュールの冗長なビルドを0にする Goals
26. Define a goal & constraints 03 Steps of problem solving Slow build performance ビルド速度が遅い • Allows developers to use standard tools (e.g. Xcode) 開発者が標準的ツール (Xcodeなど) を使うことができるようにする • Do not make programming experience painful プログラミング体験を苦痛にしない Constraints
27. Steps of problem solving Explore solutions 解決策を調査する 04
28. Explore solutions 04 Steps of problem solving • Consider multiple alternatives because there mostly is no perfect solution ほとんどの場合、完璧な解決策は存在しないので複数の代替案を検討する • Do not stick to a solution from a particular point of view (maintainability, feasibility, efficiency, scalability, reliability, usability, evolvability, etc…) 特定の観点からの解決策に固執しない (保守性、実現可能性、効率性、拡張性、信頼性、有用性、発展性、など ) • Do not rely on uncontrollable factors (e.g. Efforts by individuals in large scale developments) 制御不可能な要素に依存しない (例: 大規模開発における個人ごとの努力 ) • It's hard to sustain a permanent effort 永続的な努力を維持するのは難しい
29. Explore solutions 04 Steps of problem solving Create an optimal solution from multi-dimensional perspectives 多角的な観点から最適解を導き出す Optimal solutions
30. Explore solutions 04 Steps of problem solving Slow build performance ビルド速度が遅い • Modularization with standard tools, pre-build stable modules, and share caches to each engineer via a hosting server 標準的なツールによるモジュール化、安定したモジュールの事前ビルド、ホスティングサーバを介した各エンジニアへ のキャッシュの共有 • Develop our own build support tool with a smart cache system 賢いキャッシュシステムを持つ私達独自のビルド支援ツールを開発する • Build with third party build systems (Bazel, Buck), and use remote cache feature サードパーティのビルドシステム（Bazel、Buck）を使ってビルドし、リモートキャッシュ機能を使う Potential solutions 考えられる解決策
31. Steps of problem solving Evaluate solutions 解決策を評価する 05
32. Evaluate solutions 05 Steps of problem solving • Solutions always come with trade-offs (usually smaller than the original problem) 解決策には常にトレードオフが付随する (通常、元の問題よりも小さい) • Evaluate it considering countermeasures for the trade-offs トレードオフへの対策も考慮して評価する Trade-offs should not require effort that is not commensurate with solving the problem トレードオフがその問題を解決する価値に見合わない努力を必要とするべきではない • Do proof-of-concepts to make sure its result 仮説検証を行って解決策の結果を確認する
33. Evaluate solutions 05 Steps of problem solving Exploration and evaluation of solutions can be repeated like PDCA (Plan-Do-Check-Act) until satisfiable results are obtained. 解決策の調査と評価は納得が行く結果が得られるまでPDCAのように繰り返す。 Explore Evaluate PoC Action
34. Evaluate solutions 05 Steps of problem solving Slow build performance ビルド速度が遅い • Modularization with standard tools, pre-build stable modules, and share caches to each engineer via a hosting server 一般的なツールによるモジュール化、安定したモジュールの事前ビルド、ホスティングサーバを介した各エンジニアへ のキャッシュの共有 The most standard solution, but there are few stable modules in the actively developed products. It requires a complex mechanism to detect module changes and update the cache. Also, it's simply difficult in fine grained modularization with existing tools. 最も標準的な解決策だが、活発に開発されている製品には安定したモジュールがほとんどない。その場合、モジュールの変更を検出し、キャッシュを 更新する複雑なメカニズムが必要となる。 また、標準的なツールでは細かいモジュール化が難しい。
35. Evaluate solutions 05 Steps of problem solving Slow build performance ビルド速度が遅い • Develop our own build support tool with a smart cache system 賢いキャッシュシステムを持つ私達独自のビルド支援ツールを開発する Development costs and maintainability are problematic because A to Z functions such as cache mechanisms or dependency detection must be implemented by our own. キャッシュ機構や依存関係検知など、 AからZまでの機能を独自で実装する必要があり、実装コストと保守性に問題がある。
36. Evaluate solutions 05 Steps of problem solving Slow build performance ビルド速度が遅い • Build with third party build systems (Bazel, Buck), and use remote cache feature サードパーティのビルドシステム（Bazel、Buck）を使ってビルドし、リモートキャッシュ機能を使う It has sufficient potential to achieve the target state of affairs. There were concerns in practical use, but there are many precedents, especially in the backend field, and also successful cases in iOS, notably Google and Lyft. The learning curve was the biggest concerns, so we ensure that making a clear strategy and provide well simplified build configurations. 目標とする状態を達成するのに十分なポテンシャルがある。 実践的な利用には懸念もあったが、特にバックエンド分野での前例が多く、 GoogleやLiftを筆頭に成功例も多い。 学習曲線が最も大きな懸念だったため、明確な戦略を立て、よく簡素化されたビルド設定を提供する。
37. Steps of problem solving Review the solution 解決策を省みる 06
38. Review the solution 06 Steps of problem solving Know where you are 現在の状態を把握する To what extent did you achieve the goals you set in step 03? ステップ3で立てた目標はどの程度達成できた？ Is there a chance to recurrence the problem? 問題が再発する可能性はある？ What are the remaining problems or trade-offs? 残っている問題やトレードオフは？
39. Review the solution 06 Steps of problem solving For the future これからのために Learn from the problem 問題から学ぶ Prevent recurrence 再発を防ぐ Standardize the solution 解決策を標準化する Keep improving 改善を続ける
40. The improved measurement data contains confidential information, which has been edited and removed for publication. 改善後の計測データには社外秘の情報を含むため編集して公開しています 。
41. Review the solution 06 Steps of problem solving Slow build performance ビルド速度が遅い Fast and reliable iOS builds with Bazel at Mercari メルカリiOSアプリのBazelを使った高速・高信頼性ビルド
42. Recap 要約
43. Recap • Problem solving is core of human activities, and software engineering is purely problem solving 問題解決は人間活動の中核であり、ソフトウェアエンジニアリングは純粋に問題解決 • Critical thinking help you to objectively look at the problem 批判的思考によって問題を客観的に捉える • Derive a successful solution in the 6 steps 6つのステップで成功する解決策を導き出す
44. Recap Understand the problem 問題を理解する Analyze the problem 問題を分析する Define a goal & constraints 目標と制約を定義する Explore solutions 解決策を調査する 02 03 04 01 Evaluate solutions 解決策を評価する 05 Review the solution 解決策を省みる 06
45. Closing