ソフトウェアデザインスキルの促成を求めて、試しに模擬タスクでロールプレイしてもらってみた。

Webフロントエンドエンジニアでボルダリング暦が1年を超えた大須賀です。

登るたびに録画してるんですがGooglePhotoで数えたら944itemsということでもうすぐ1000本。仮に毎回1m登ってるとしたら総距離は御岳山ぐらいらしいです。

今回はそんな初心者クライマーがソフトウェア設計の話をします。

この記事のざっくりまとめ

• ソフトウェアデザインスキルって意図的に揃えるのは難しい
• 今回は模擬タスクを設計して実践してもらった
• はっきりとした効果は不明だが感触は良かった

目次

1. Webフロントの設計はなんとかなりやすい
2. なにを提供すべきか？
3. 模擬タスク設計
4. 経験は補完されたのか？
5. 興味深かったこと
6. まとめ
7. 付録: シナリオ

Webフロントの設計はなんとかなりやすい

昨今Webのクライアントの実装は幸せなことにフレームワーク・ライブラリにこれ選んどけば大体OK！というものが多く設計もそれらの流儀に則って進めていけば大きく迷うことはありません。

またアプリケーション固有の設計もいくらか積み上げれば新たに設計を考えるという必要も無くなっていき「右へ倣え」で多くのコードを生み出していくことができます。

この様な環境だとソフトウェアデザインについて会話することも減っていきチームとして意識が希薄になり、設計できる人とできない人にいつの間にか二分していたなんてことも起きます。

この記事は、前述の様なソフトウェアデザインを意識する機会が減った状況でもチーム内のソフトウェアデザインスキルを現場とは別の人工的な機会によって向上させる挑戦についての話です。

なにを提供すべきか？

(他者の)ソフトウェアデザインスキルを向上させたいとなった時どんなものを提供すればいいでしょうか？

これは経験を補完できるものが良さそうです。

ソフトウェアデザインスキルを構成するのは概ね以下の3要素でそれぞれの要素の間にはグラデーションが存在します。

• 知識: いわゆる書籍などから獲得できる体系化された知識で抽象度が高いもの。SRPなど。
• テクニック: パターン化されたものや、プログラミング言語依存の知識のことで体系化された知識を実践する上で活用されるもの。継承など。
• 経験: 知識とテクニックを状況に合わせて使い分けるための経験値のこと。「SRPに違反してるけどこれすぐ消すからいいから今回はこれで十分だな」など。

この中で知識・テクニックは独学がしやすく、一方経験は業務の中で多様な経験が積めるかどうかは運の要素があります。

この運に左右される部分に介入することでスキルの向上を再現できないか？というわけです。

そんなわけでチームメンバを実験台にして設計トレーニングを考えて実施してみたのでその様子と結果を紹介します。

模擬タスク設計

模擬タスクを設定してその設計をしてもらうことにしました。 (シナリオの詳細は記事の最後に)。

「ある日PdMから管理ツールにundo機能が欲しいと言われた。」というところからスタートして必要なコミュニケーションをしながら設計を終わらせます。

• 要求: とある管理ツールにundo機能がほしい
• 制限時間: 10分説明 -> 40分実践 -> 10分みんなでレビュー
• チーム人数: 2人1組
• PdM & BE Eng: 主催が代役

各チームはPdMやBEエンジニア(主催)と必要だと思った会話を行うことができます。

この時主催は事前に決めてあった設定をもとに回答します。

TRPGに親しみがある人はイメージしやすいかもしれません。

提出する成果物は以下の3点としました。

• 仕様
• 設計
• シーケンス

経験は補完されたのか？

定量的なものは測れませんが、主催の感覚と参加者のアンケート結果をみると良い方向に行ってるのかなと思っています。

アンケート結果

得たもの・成長できたこと

• いくつかのアイデアをvalidateすること。短い時間かdeadlineがある時、ブロッカーを見つけったら、アイデアを考え直すが必要
• undo機能の具体的な実装手段のノウハウ（deffered actionとして抽象するアイデア）
• 「知識・テクニック・経験」というソフトウェア設計スキルアップのための考え方を知れてよかったです。練習で他の人がどういう風に設計したのかも参考になりました。
• 与えられたタスクへ向き合い方, コミュニケーションの頻度 (もっと多くていい), アイデアや経験も大事だということ
• なぜその機能が必要なのかという理由を理解することの重要性を学びました。必要性を理解することで、今後進むべき最適な方向を選びやすくなります。

感想・次回への意気込み

• ゼロからパターンを考える機会が多くはないので、もっとやりたい。
• 会の構成がしっかり組まれていて、進行がスムーズと思いました
• 設計課題のパートは実務に近い感じにできていて、よい練習になりました。二人一組でやる方式も勉強になる部分が多くてよかったです。最終的に各チームのアイディアを総合してより良いソフトウェアデザインができあがりそうビジョンも
• 次同じような形態があれば，コミュニケーションの頻度を増やしてより適した仕様に近づけるようになりたい
• チームのシニアメンバーが、ほとんど同じアイデアを出していたことに驚きました。それを見て、自分もスキルをもっと伸ばしたいという気持ちが強くなり、良い刺激になりました。

その他興味深かったこと

目的のソフトウェア設計経験を補完するとは別に興味深いことがあったので共有します。

設計が得意なチームほどクリティカルな質問を早い段階でしてくる

このシナリオでは「要求の動機」「Undoを満たすためのBEの処理」この二つの確認が重要になる想定で、やはりシニアになるほどその質問をしてくるし、そのタイミングも早かったです。

これがある種ひらめきを必要とする部分で、まさに経験によるものなんじゃないかなと感じました。

そもそも「仕事」の認識のずれがあったことがわかった

完全に副作用なんですが「エンジニアの仕事ってこういうもんだよねー」という認識に一部ズレがあることもわかりました。

特に盲点だったのは「要求されたものをそのまま作らなければいけない」という思い込みがあったメンバもいました。

そういうメンバでも実際には「相談して仕様を変更する」ということ自体は発生していたと思いますが、意識としてはズレが生じているというのはまったく想定していませんでした。

これはまた別の課題かもしれません。

まとめと今後

設計スキルの向上とその再現性に課題を感じていました。その解決策として模擬タスクという手段をとり、定量的な改善は不明なものの感触としてはすごく良いものであったと思っています。

一方で「シナリオを用意すること自体の再現性」が課題です。今回アンケート結果が良かったのは形式意外にもシナリオのテーマが良かった部分があると思っていて「シナリオを用意し続ける」難しさは残りました。

以上で紹介は終わります。似たような課題をお持ちの方の参考になれば幸いです。

以下模擬タスクのシナリオ設定を付録しておきますので、興味があれば確認してみてください。

付録：シナリオ

概要: プレイヤーはWebフロントエンジニアとなってソフトウェア設計に挑む。

シナリオはPdMから「Undo機能をつけてくれ」と頼まれるところから始まる。

NPC: PdM

• Undo機能はうっかりミスを回復するために欲しいと思っている。
• うっかりミスは現在でも発生している。
• そのミスは管理ツールの複数の機能を手動で操作することで回復している。

NPC: BE

• いつも忙しそうだが、別に意地悪では無く、質問に回答はしてくれるが深掘りし返してくれる感じでも無い。（この辺は進捗をみて調整。）
• Undoに直接該当する機能は現在ない
• その操作は複数のDBレコードを更新している
• 更新対象のレコードは他の機能追加により少しづつ増えている
• その操作の一部はバッチによって処理される

模範回答

今回模範回答としては以下を設定する。もちろん「唯一の正解」という扱いではなく一例であって各プレイヤーの成果物は尊重されるべきである。

• 仕様: 操作後N秒間は操作の取り消しができる(Gmailの送信取り消し風)。これを実装としてはAPIリクエストをN秒遅延させることで実現する。
• 設計(抜粋): 特定の処理を遅延およびcancelできるReact hookを以下のインターフェースで実装する。 const { remainTimeSec, cancel, doOperation } = useDelayedOperation({handler:});

模範回答への道

• PdM になぜその機能が欲しいか聞くことで「うっかりミス」が防げれば他の仕様でもいいことがわかり、選択肢を広げることができる。
• またバックエンドの工数を取るべきか？というパラメータがやや弱まる。
• バックエンドに操作の取り消しについて詳細を確認すると「なんかめんどくさそうだな」ということがわかる。
• 特に複数のデータ更新が発生している上にその対象が増えていることからUndo APIを作っても継続的に保守する必要があることがわかり、要求通りの実装の優先度が下がる。
• 「操作を取り消す」のではなく「操作を遅延する」方向で考えていくと模範となる。(要ひらめき)

注意事項

• 学習目的であるため、無駄に難易度を上げる必要はなく適切な助け舟は出したほうが良い
• 集団で開催してしまうと1人がリードしすぎることが発生しやすいため、個別に実施されることが望ましい。
• 実践的には複数プレイヤーを同時に回すことになるためグループを形成する必要があるがその場合はスキルの近いプレイヤー同士で組むのが前述と同じ理由でよい。

時間配分について

本シナリオは2チームに対して1時間のMTGの中で実施される前提で設計されている。このため説明時間とディスカッションの時間を取る前提でセッションのタイムマネージメントが必要になる。 とくにディスカッションは短い経験を増幅する狙いがあり必須であるとしている。

ディスカッションの時間は15分を基準としつつ、セッションの進捗やプレイヤーの反応に合わせてトレードオフすること。