若手メンバーのスキルアップのための相談に乗っていると, うまい設計ができるようになる, 仕様の整理やメリット・デメリットの判断がうまくなる, あるいは技術の引き出しを増やすにはどうしたらよいか, という話がよく挙がる. この手の話題にいつも同じようなアドバイスをしていると気づいたので, 説明を楽にするために書き下しておく. ソフトウェア開発の話だけど, もしかしたら一般的な仕事のやり方の話だと思っても成立するかもしれない.
文脈
ソフトウェア開発のプロジェクトを進めるとき, 少人数の精鋭だけで開発するなら極論するとカウボーイコーディングでも成立するかもしれない. そうでなければ, たとえばスクラムのように, なんらか段取りをチームでマネジメントし, 不確実性を下げるためにどういう方法でアプローチするか検討し, 仕様を固めて細かいタスクに分解するプロセス(以降ざっくり「ソリューションを定める」プロセスと呼ぶことにする)が必要になる. みたいな話が以下に書かれている.
こういったことをチームでルール化された開発プロセスとしてやるにせよ, 熟練のカウボーイが勘と手癖でやるにせよ, どこかで誰かが「この要件を満たす最善の方法は何か」を考える必要がある. 「最善」とは必須でない要件を多く満たせることだったり, 非機能要件を満たすことだったり, 工数が少なく済むことだったり, いろいろな観点がある.
別の言い方をすると, やりたいことを実現するためにどういう方法でやればいいか, ミスると望まない結果になるリスクをどう回避するか, つまり方法不確実性にどう対処するかという話. 熟練のカウボーイはよい方法の選択のしかたを経験的に知っているが, キャリアをスタートしたばかりの新米メンバーはどうやってこのやり方を身につけたらいいのか?
松竹梅メソッド
そこで便利なのが松竹梅メソッド. この方法は僕が考えたわけではなく, ベストな方法かどうかもわからない. ただ, 一定の効果はあるし, 僕もかつて駆け出しの頃に当時のメンター(
id:hakobe932さん)に「こうやってはどうか」と言われてやってみたところ非常に役立ったため, 以来ずっと意識して愛用しているやり方. ごくありふれたやり方だとも思う(が, ソフトウェア開発文脈でまとめたものがぱっと見つからなかったためこれを書いている).
たとえば懐石料理店などで, コースメニューが松・竹・梅の3つに設定されているのを見たことがあるだろう. 松は豪華だが一番高く, 梅は安いが少し物足りない. 竹は間を取ったもの. この3択は, 営業やマーケティング文脈で竹を選ばせるための手法として紹介されることが多い. どうして竹を選んでしまうかと言うと, 松と梅として極端なパターンを提示されると, 間を取った竹が妥当なものとして説得力が出るからだろう.
ソフトウェア開発においても, 妥当な結論を導くためにこの手法は有用. ソリューションを定める上で, 以下のような3つのプランを考え, それぞれのメリットとデメリットを並べて検討する.
- 松
-
- 時間がいくらでもあるならこうする, という理想的な方法
- 非機能要件など技術的な観点では考えうる最高の方法
- あるいはチャレンジングな技術を使ったり, なんらかのブレイクスルーが必要などリスクの高い方法
- 竹
-
- 松と梅の中間
- なるべく松と梅のいいとこ取りを考える
- 梅
-
- 必須の要件を満たし最小限の工数で済む方法
- やっつけ仕事, 技術的には「汚い」やり方でよい
- 負債になりそうとかは気にしない
松と梅のいいとこ取りをすれば竹プランとしていいものが導けるとも考えられるが, どちらかと言うと3つのプランを考えるプロセスが大事.
たとえば, 松プランとして技術的には最高だがやるとなったら莫大な時間がかかってしまう方法を思いついたとする. 続いて竹プランを考えるにあたっては, 技術的には妥協してもよいから時間はもう少し短縮しようと思うだろう. このときしばしば, 実は技術的にとくに妥協することなく大幅に時間を短縮する方法があることに気づいたりする.
あるいは, とにかく急ぎでやることだけを目指して梅プランを1つ考える. 梅プランのデメリット(おそらく技術的にイケてない部分だろう)を解消するために, 松プランの一部の方法を無理ない範囲で少し妥協した形で入れてみる. すると案外これで技術的なこだわりはほどほどの良いプランになったりする. 若いうちは技術的に尖っていてカッコイイことをやりたくなりがちだから, それをいい塩梅に薄めてくれる(梅だけに).
はたまた, 自分ではもう竹プランとして「こうやったらよい」がわかっているつもりで, 説得材料として3つのプランを考えている場合. 松として「もっと理想的な方法」を考えてみて, もしその方法でもとくに追加の工数はかからずリスクもないことがわかれば, もはや竹は捨てて松プランでよく, 当初考えていたよりも良い方法を思いついたことになる.
これが唯一のやり方なわけではないし, 3つしかプランを挙げてはいけないわけでもないが, とりあえず3パターン考えようとすることでやりたいことを実現するリスクの低いやり方を探索できるという, 手軽なツールだと理解されたい.
書き方の例
探索・思考・検討のためのツールではあるものの, 我々はチームで開発しているから他のメンバーを説得する必要もあり, 思考の形跡は書き残しておいた方がよい. あとでもう少し細かい仕様や設計についてまとめるときにも, 採用しなかったアプローチのメリット・デメリットの議論を記載したいだろう. 将来, 自分や他の仲間が過去の設計意図を知りたくなったときにも検討時の様子がわかった方がよい.
と言ってもそんなに仰々しいものを書く必要はなく, やり方とそのメリット・デメリットを以下のように羅列するだけ. ソフトウェア開発においては, やり方の部分はもう少し詳細に書く必要があるかもしれない(そもそも「やりたいこと」にもう少し細かい話があるだろう)が, 文脈を知っている人がわかる程度の箇条書きでよいと思う.
やりたいこと: 実現方法の検討・判断のやり方を若手メンバーに習得してもらう
- 松
- 隣に座っていっしょに検討・判断するのを何回かやって徐々に自分でやってもらう
- ⭕ その人に合わせた細かなコーチングが可能
- ❌ かなり時間を取られる
- ❌ 教え方がスケールしない
- 竹
- やり方をブログにまとめたものを見せて, 実際にやってもらった結果をレビューする
- ⭕ 繰り返し使える
- ⭕ やり方を忘れてもあとから参照できて自習しやすい
- ⭕ レビューするのは別の人でもよい
- ❌ 最初にブログにまとめるのが少し大変
- 梅
- 「松竹梅でプランを出してみよう」とアドバイスだけする
- ⭕ 楽
- ❌ そう言っただけではぜんぜん伝わらないかもしれない
- ❌ うまくやれたかどうかのフィードバックがなく, 上達しないかもしれない
こんな雑な例でも実際に書いてみると効果があって, 最初は「何度も説明してて面倒だからブログにまとめるか」というだけ, つまり単に「こうやったらよい」というプランだったのが, 他のプランも並べてみると梅プランのデメリットの「フィードバックがなく, 上達しないかもしれない」が竹プランにもそのまま当てはまってしまうことが明らかになった. そこで竹プランには「結果をレビューする」とつけ加えることにした.
いざ書くときに「一番高級なのって松だっけ? 梅だっけ?」となってしまう人は以下のように覚えよう.
梅は「しょっぱいやつ」と覚えてます
— INA Lintaro (@oarat) 2022年8月24日
良いところ
簡単
プランを3つ考えて箇条書きでまとめるだけなので, 素朴で簡単. 「うまい設計を考える」とか「よい技術的判断をする」といったことは実際に場数を踏むことが大事な割には, どうやって練習したらいいのか非常に難しい. その点, この手法はとりあえずやってみるにはあまりにも簡単. すぐやろう. 今, やろう.
1つのやり方に固執せずに済む
無理にでも複数のプランを出すことになるから, 最初に思いついた一つのやり方に固執しなくて済む. 人間は一つのことに囚われてしまうと他のことを考えられなくなる傾向があるように思う. 意識して「他には?」と思いを巡らす機会を作ろう.
説得力が出る
メリット・デメリットを比較できるし, 文字で書いてあることでレビューもできて, 複数人での議論を反映して合意を取るのもやりやすくなる. 「こういうやり方もあるんじゃない?」という指摘をされるまでもなく, 検討済みだと見たらわかるから話が早い.
引き出しが増える
松プランは一見「まぁ無理かな」と思えるものでも気軽に案として出せるから, もし本当に理想的にできるならどうしたいかで考えることができる. そして一旦はそれが本当に実現可能か考えることになるから, 「やれることだけやる」環境では思いつかないようなやり方も真剣に考えるだろう. それによってやれることの幅は広がっていくはず.
他のやり方
ブレインストーミング
プランのアイディアを出すだけならブレインストーミング等をした方がよいと思うかもしれない. 松竹梅メソッドを使おうとして何も案が思い浮かばないなら, 人を集めていっしょにブレインストーミングしてもいいだろう.
Design Doc および ADR
仕様や設計とそのメリット・デメリットについてまとめるなら, Design DocやADR (Architectural Decision Record もしくは Any Decision Record)を書いたらいいと思うかもしれない. これはこれで書いたらいいと思うが, どちらかと言うとこれらは技術的な意思決定の結果を残すためのものだから, その意思決定をするための検討段階で使う方法論は別途必要なように思う.
メリット・デメリットの分析
プランを複数挙げてメリット・デメリットを書き出して, どれがベストか選ぶ方法はなにかしら他にもっと洗練されたやり方があるかもしれない. 松竹梅メソッドでは松や梅はおそらく捨てることになるプランで, どうせいいとこ取りした竹が採用されるだろうからこの部分を真面目にやることはあまり想定していない. もし現実的なプランをたくさん出して検討する場合はもちろんきちんとメリット・デメリットを分析した方がいいだろう.
あるいは, 松プランの工数が比較的小さくて済む場合は真剣に悩むことになるかもしれない. しかも, どれだけ工数をかけてもよいかの問題だから技術的な判断だけで決まることでもない. そういう場合は, やろうとしていることの意思決定者(たとえばスクラムでやっているならプロダクトオーナー)向けの松竹梅を書いて選んでもらうといいだろう. このとき工数の見積もりは3つのプランすべてに対して実際にプランを採用する場合と同じ精度で済ませておくことになる.
おわりに
究極的には最高の方法を思いつきさえすればどんな手法を使ってもよい. ただ, 闇雲にやってもあまりうまくいくように思えないし, 大仰なやり方を学ばなければできないというのでも困る. 今すぐ少しでもうまくやるために最初の一歩を踏み出すにはこれくらい簡単な方法がいいんじゃないかと思う.
追記 2022-09-09T18:02:16+09:00
ブックマークコメント
id:yukky2000
IT（＝情報処理）関係なのにぜんぜん情報処理的じゃない方法論を使ってるなぁという感じはした。そんなもんなのかなぁ。
どうしてこの話を情報処理の話だと思ったのか(そして「情報処理」としてどんなものを想定しているのか)わかりませんが, この話は情報処理ではなくソフトウェアエンジニアリング, つまり工学の話だと思っています.
ウィキペディアにいいことが書いてあったので引用しておきます。
工学は大半の分野で、理学の分野である数学・物理学・化学等々を基礎としているが、工学と理学の相違点は、ある現象を目の前にしたとき、理学は「自然界（の現象）は（現状）どうなっているのか」や「なぜそのようになるのか」という、既に存在している状態の理解を追求するのに対して、工学は「どうしたら、（望ましくて）未だ存在しない状態やモノを実現できるか」を追求する点である[注釈 1]。或いは「どうしたら目指す成果に結び付けられるか」という、人間・社会で利用されること、という合目的性を追求する点である、とも言える。
したがって工学では安全性、経済性、運用・保守性といった、実用上の観点の価値判断が重要である。使用できる時間・人員・予算等といった資源の制約の中、工学的目的を達成するための技術的な検討とその評価を工学的妥当性と言い、工学的な性質の分析には、環境適合性、使いやすさ、整備のしやすさ (Maintainability)、生涯費用（ライフサイクルコスト）など、（質量、速度などのある意味、即物的で一意的に測定できる性質とは違った、人間がある配慮のもとに構成した） <<評価方法>> が必要なものが多い。そうした評価方法の開発も工学の重要な分野とされる。
工学 - Wikipedia
工学は科学を基礎とし, 科学の重要な要素の一つは再現可能であることだと思っています. 松竹梅メソッドを工学上の一つの手法と思うと随分と素朴ですが, 「熟練のカウボーイがやっているうまい設計やメリット・デメリットの判断を再現可能にする」ことを目的としていて, れっきとした工学的アプローチだと思っています.
