一気に成し遂げないソフトウェア開発を根付かせる考え方

はじめに

Zennを読まれているということはソフトウェアの開発を仕事とされている方が多いと思います。ソフトウェアの開発は楽しいものであると思いますが、仕事とされている方には辛いやつまらないといった感情が先行してしまうこともあるのではないでしょうか？
そのような原因の1つに開発の進め方に課題があるのではないかと思われます。例えば、体系的な手法をやっているつもりでもうまくいっている感じがしない、目的が失われ形骸化してしまっている、そもそもなんとなく進めている...などなど様々なパターンが考えられます。
この記事では、ソフトウェア開発を進める際に考慮すべき点を整理し、難しさを受け入れたうえで、どのように進めるとよいかを自分なりの言葉で紹介します。
最終的なやり方を押し付けるのではなく、「なぜその考え方になるのか」というプロセスを理解することを重視しています。

注意事項

• あくまで私の考え方です
• やり方を主張したいのではなく組織に根付かせることを目的とします。至るプロセスが大事
• どんな組織にも当てはまる万能な考え、やり方ではありません。
  • 組織の都合や特性に合わせた進め方を考えていくことに楽しみがあると思いますので自分たちはこうやっているよなどありましたらぜひ意見交換しましょう♪

考慮しなければいけないこと

「正解」への認知 時間的変化

いきなりですが...要件定義、設計、実装といった開発工程を踏んでいったときに正解を決めてから進めることは果たしてできますでしょうか？
わたしの答えは、YesでありNoです。
ある瞬間には正解となる設計や挙動があります。しかし、仕様変更やデータ量の増加によって、それが正解ではなくなることもあります。
また、短期間でも仕様変更は発生し得るため、現時点での正解はあくまで仮説に過ぎません。
そのため、正解を仮定したうえで実現方法を計画し、進めていく必要があります。

「正解」への認知 やってみなければわからないこともある

もう1つ、仮説の域を抜けられない理由として「実際にやってみなければわからないことがある」からです。
これは設計~実装のようにシステムとして形を作られてきたときに、思うようにできなかった、考慮が漏れていたと言われることが該当します。設計によって大枠の正しさや方向性を定めることができますがそれが絶対的に正解であるとは限りませんし、形にしてみない限りは夢物語かもしれません。
設計にものすごくこだわるのも良いですが、実際に手を動かすことでわかることがあるという事実にも目を向けなければいけません。

そもそも「正解」とは何か

何気なく「正解」と書きましたがそもそも「正解」とは何でしょうか。
ビジネスを進めるうえでシステムに機能を追加したいとなったときはその機能が動作することが1つの正解になるでしょう。そして、その方向に開発を進めていけば目的を達成することができるでしょう。
ただ、開発者の目線では動くことだけが正解なのでしょうか？
実際の開発現場ではただ動くだけのコードを書いただけでは受け入れられることは少なく、システムやソースコードの構造的に正しいかという判断も入ってくることが多いと思います。
つまり、ビジネス的な正しさを満たしつつソフトウェアとしての正しさも満たして上げることが正解として定義されているのではないでしょうか。

むずかしい

私がここまで主張した内容を考慮したうえでソフトウェア開発を行うにあたって目指すべき、追求すべきことは以下になります。

...むずかしくないですか？
挙げきれてないこともあると思うとこれを目指すというのはむずかしいと思うのが自然なことだと私は思います。それを目指すにあたって、辛いしつまらないと感じることがあってもしょうがないと思います。
ただ, ソフトウェアの開発を仕事としている人は向き合わないといけないというのも事実です。

目指し方

ここでタイトルにある「一気に成し遂げない」という考え方が出てきます。
本文の内容と絡めると、複数の正解(≒目的)を一気に成し遂げず1つ1つを成し遂げて状態遷移を行い続けたうえで目指していくべきではないかという提案になります。
ソフトウェア開発で言えば、ビジネス観点での正しさをシステムとして表現したのちにソフトウェア観点での正しさを求めにいく動きをするという2つのフェーズを設けて進めてみるということになります。

さらに分解する

一気に成し遂げないという考え方は1つの目的を成し遂げるプロセスの内部にも当てはめることができます。
例えばAという機能を作るための改修を一気に成し遂げようとせず、a -> b -> cと段階を踏んで成し遂げていくことが挙げられます。リファクタリングをしようとするときも一気に変えるのではなく変える範囲などをコントロールすることで段階を踏む事ができると思います。

正解が決めきれなくても進んでいく

むずかしいということもそうですが、正解として決めきれず仮説の域を出られないということや時間的な変化を受け入れなければいけないという観点からも「一気に成し遂げない」考えの根底にあります。
仮説から正解を導くためには検証をしてフィードバックをもらうのを繰り返して行動することに限るのではないでしょうか。
目的を達成するための状態を分解し、状態遷移ごとにレビューを受け、方向性を評価し続け正しいと思う方向に進んでいくことが必要になります。

※図は螺旋的な学習・改善プロセスを平面に表現しています。歪。

組織に根付かせるために

ここまでくればお気づきの方が多いと思いますが、アジャイルな考え方に基づく進め方の提案になっています。
ただ、アジャイルな考え方を実践するための体系的な手法を導入しても組織には根付かないと自分は思い回りくどく説明をしました。
手法そのものに注目するのではなく、何が課題としてあってそれを解消していくためにはどのようなやり方を取ると良いのかを辿ってメッセージングすることで、組織に所属していく人たちの自発的な行動を促し根付くことができるのはないのでしょうか。

最後に

ソフトウェアの開発は正解を決めきれない, そもそも正解は何かという観点で難しいと思います。
その難しさからつまらないという思考に至ってしまうことは往々にしてあると思います。
なので、まずはその難しさの根底を認知し受け入れることから始めましょう。
そのうえでどのようなやり方を講じていくかを考え実践していくことで、よくないループをよいループになるようにしていければ最高です。
また、組織への適用を前提に話をしましたが、個人でも同じ考えや行動を適用することは可能だと思います。
自分でやって良いと思ったら仲間を増やしていき、組織でうまくいく要因を認知したうえで楽しいソフトウェア開発を行えるようになっていければと思います。

余談

アジャイルな話をしているのでアジャイルソフトウェア開発宣言でも同じようなことが話されています。しかし、著名的な人が言っている、本に書かれているからというだけでは自分(たち)の意志になりきれていないかもしれません。
自分たちが経験的に知っていることと本に書かれていることを組み合わせて自分の意志として組み上げることが周りを巻き込み組織に根付かせるためには必要かもしれません。