プロダクトのための技術力をどう上げるか: ⓪なぜ技術力は必要とされるのか

イントロ

自分は「どうやったら技術力を上げられるかな」という点に興味があり、また最近では「組織から継続的に"成長"を与え続けられるのだろうか」という点に興味がある。
まずは自分の中の認識や仮説みたいなものを形式知としてみようと、取り留めなく散文を吐き出していたのだが、その中で幾つか重要なエッセンスがある事に気付いた。

「取り留めなく」と書いたが、実際に気づいた事や感じた事を1つの文書に纏めようとすると、実際かなり散らかってしまっている(し読むのも書くのも疲れる)。なので、ポイントを絞りながらそれぞれを複数の文書に分け、現在の観点・思考を表して見ようと思った。
この記事がその第1段である。

あくまで「自身の内にあるこんがらがった思考を解きほぐしておきたい」というのが大きな狙いであり、セルフ壁打ちのような効果を期待して取り組むもの。

記事の作成のためのメモ

ビジネス対する要求は複雑化し続ける
ゆえにソフトウェアも必然的に複雑化し続ける
要求に応えるためには「リスク」が避けられない
- このリスクをミニマムにしていく事が重要
何がリスクを増大化させるか
- 本質的な命題の難しさ。「答えのない問い」であること
- 打手の少なさ。
何がリスクを最小化させるか
- 仮説を築き、世に問うまでを短くする
技術力の価値 = アジリティを高く保つ武器といえる

本論

まずは「そもそも技術力とは何のために求められるのか」という所を考えてみたい。

勤めている会社などにおいて、「組織の技術力を高める」という命題が標榜されたとする。以下の疑問が湧く。

「技術力」という言葉を安易に使いすぎなのでは、という嫌いがある
- 自分もそうだし、恐らく他人もそう
そもそも「技術力」というのが何であろうか？っていうのが曖昧なままで過ごされている気がするし、あるいは「目的」なき「手段」として存在が許されていないか？とすら思う

この中核にある「技術力」という概念、これに対する「なぜなのか」「なにであるのか」を真正面から捉えることなしに、「それを高める」という夢は叶えられないのではないか。つまり空中分解しかねない。
今回のテーマは、そうした問題意識を下地として思考を試みたものだ。

以下、先に社内向けに書いた文章が先に公開するに至ったので、そちらをベースに転記。
(・・・なかなか主語がでかい話であり不安はあるけど。。)

「目的」から考える技術力

技術力が開発に何をもたらすのか？おおよそ、これらの3つの価値を提供するものと考えている。

スピード
品質
妥当性

この3つを兼ね備えると「アジリティ」っていう価値がもたらされ始めるはず。何故アジリティとやらが必要なのか？どう良いのか？は、noteのマガジンで秀逸なのものがある。是非読んでみてください。

note.com

これらのパラメーターが強化されることから、「技術力が高まることは勝ちにつながる」ものといえる。

スピード

開発するスピードが「良さ」なのは特に説明いらないと思う。ソフトウェアやシステムを進化させるのが我々の仕事なのだから、同じ仕事が10時間を必要とするよりも2時間で終わった方が良い。

品質

品質は、例えば「バグを生まない」とか「拡張性が高い」とか「読みやすい」とか。ざっくりいうと「良いコード」というのは「品質」って言葉に代替可能だと思う。もっと言うと、結構「品質の高いコードとはどんなものか？」に対しての回答は人それぞれかもしれない。1つの示唆として、品質という話であればマーティンファウラーの記事に気付きが多い。

martinfowler.com

「どう良いのか」は語れる。が、「何であるか」は難しいかも知れない。むしろ、「良いコードとは」という問いに対する答えを、個々人が持っていると良いと思う。(自分の場合、長らく「リファクタビリティ」が良いコードを言い表すものだと思ってたけど、最近はもう少し広い意味で「書き換えやすさ」かなーって感じ)

妥当性

(コレが1番分かりにくいかな?)
例えば「RDBにするか検索エンジンを使うか」みたいな選択はあるし、ECSかGKEかみたいな選択もある。そこを失敗すると、サービスのスケーラビリティの問題だったり(非)機能要件への適合が難しくなったり。ソフトウェアで言っても、例えばよりミクロな話、外部ライブラリを使うか自前で薄いコンポーネントを使うかみたいな選択とか。オーバーエンジニアリンクになるか、腐敗臭のするデザインになるか?という所にも繋がる。

そしてアジリティ

この3つが満たされれば持続的な成長を維持し続けられるようになるでしょ、それを保証するのが「技術力」だよ、と。
アジリティとは「機敏さ」という意味で、これがあると「柔軟さ」が獲得される。
この「柔軟さ」がビジネスの価値を高める、成功の確度を上げるための強力な武器になる。

anti複雑さ

なぜ「ビジネスの進化には柔軟さが必要」か？

そもそもの大前提として、「ビジネス」は複雑であり、ビジネスを微分したものである「ソフトウェア」や「ソフトウェア開発」も複雑なものである。
何がマーケットに受け入れられるか？自社、競合を取り巻く環境は？顧客や潜在的なターゲット層の「気分」は？
それらは正確に「計測」することも難しければ、正解を教え導いてくれる師範もおらず、更に悪いことに「次の瞬間には状況が変わっている」ということが常である・・・という、複雑さ。

そんな複雑な問題に、どう対処していくか？ 1つのアプローチが「実際のマーケットに、1回でも多く問い、フィードバックを回収し、また次の一手を打つ」というもの。

アジリティを得ることで、「素早く・小さく失敗し、地に足のついたフィードバックを元にして、要改善点を克服し、また素早く世に問う」というループを回せるようになる。
「1発の大振りで成功するかわからないから、100回打席に立ち、その度にフォームをチェックし、修正し、珠に当てにいく」というもの。その逆に、「大振りをするための準備が整うまで、打席に立たないでいる」となれば、フィードバックを得ながら改善をするための(あったはずの！！)機会が損なわれいてく。必然的に、失敗へのリスクが高まる。

アジリティと、スピード・品質・妥当性

とにかく「打席に立つ回数」が必要、ということで「スピードが重要になる」。
スピードが遅いと、打席に立てる回数が減り、「失敗した時に取り返しがつかない」という硬直性も高まる。また、少ない打数で上手くやるには、非常に綿密で高度で正確な「予測」が必要になる。・・・市場はあんなにも気まぐれな生き物だというのに！

品質はどうだろうか？
これは、先に上げたファウラーの記事に詳しい。「内部品質の低下は、速さの逓減をもたらす」というもの。付け加えるのであれば、外部品質だって、低下すれば顧客の離反を招く・・・すなわち「得られるフィードバックの量が減る」という結果をもたらすはず。

最後に妥当性。
「適切な選択」というのは、そもそものスピード(初速)に大きな影響をもたらす。あるいは、「初期の誤った選択」は、後に取り返しのつかない致命的な「負債」となるかもしれない。これも、やはり硬直性を生じさせる。

結局、スピード・品質・妥当性はそれぞれ不可分であり、また高いアジリティを実現し維持し続けるためには、これらを突き詰め続ける必要があるのだ。

「複雑さ」に対する補足

「ソフトウェア開発は本質的に複雑さを伴うものである」という点について。
「変更しやすい」ことを以て「ソフト」な資産、と称される。裏を返せば、「変更されること」が存在価値として織り込まれている、とでも言うべきか。そうやって、次々に「進化していく」ことが宿命付けられている。

「なぜソフトウェアは進化する(させられ続ける)のか」という論点について、論文があるという。

いわく、「使われ続けると、利用者(やその代理人たるプロダクトオーナー)からの要求が生じ、それに応えることで進化を求められる」「ゆえにソフトウェアは進化し続ける(複雑さを増し続ける」ように考えられる。

ソフトウェア開発はとても複雑なものである。

アジリティを備えたプロダクト組織になる

何のために会社がありビジネスをやっているのか？といえば、経済的な価値を生み出すためだと思う。それは、顧客価値を中心に生み出される付加価値の総和である。
顧客価値は創るのが難しい。そのために、複雑な問題に挑む必要がある。
複雑な問題に立ち向かうための武器がアジリティ。
そして、(働く上での)技術力の目的・・「何のための力なのか？」という問いに対して、今の所の自分の見方が「プロダクト開発のアジリティを高めるため」である。

それって、我々に何かメリットありますか？

ここまでずっと「ビジネス」「組織」を主語において話をしてきたので、「なぜ良いのか」がピンと来にくい。
なんだか「正論」という感じで、それが「開発者1人1人にとって関係のあることなのか」については、説得力を持っていないような。

「高いアジリティを持つ組織」で働く、というのは開発者にとってどんな体験だろうか？
結論から言えば、恐らく「そこで働いていてワクワクしながら開発に携われるようになる」というものだと思う。

開発に対するモチベーションというのは人によってそれぞれだというのを前提としつつ、広く共通するのは「何かを良くしたい」という想いではないか。
例えば「ユーザーを喜ばせたい」とか「自分の納得が行くような綺麗なコードを書きたい」とか「より高いパフォーマンスを実現したい」とか。
そうした際に、組織がアジリティをもって開発できていたらどうなるか？恐らく、これらの前向きな気持ちを持った人たちには嬉しいと開発体験につながると思う。

「ユーザーを喜ばせたい」人たちにとっては、「開発コスト(時間、リスク)が高いから難しい」という理由で、望ましい機能の実装提案を却下される場面が減り、「良いと思えるものを作って、リリースする」ことに集中できている状態。或いは「新機能をデリバリーする」ことへの組織が持つコストが低く抑えられることで、リリースした後にユーザーの反応を観察し、取り入れながら更に良い機能を開発していく！というのに集中できる。
これらはスピードが低ければ難しいし、品質が低いようだと「保守に当てるリソース」によってエンハンスメントやアイディア出しのための力が逼迫されることになる。

「良いコードを書きたい」という人たちにとっては、実践的なツールやサービスの導入も、しっかりリスクをコントロールした上で試してみることも出来る。
開発者というのは、『ソースコートを通じて活動する」のだから、ある側面では「自分たちのプロダクトのユーザー」でもある。自分たち自身を「ユーザー」として、開発体験についてのフィードバックとそれを踏まえた改善のサイクルをクルクルと回しながら「より良い開発」を獲得できる事が重要。
プロダクトと一緒に開発チーム自体が進化のペースを保ちやすい状態だ。「高い生産性を生む」という価値実現に向けて、不確実性を制御しながらの前進がもたらされる。

そして深く広い見識と自信から来る「妥当性」は、品質・スピードを安定的に支えるために欠かせない。もし妥当性に関する意識が低いようであれば、「なんでもやってみる」の後の棚卸しが実現せず、負債が貯まり続け硬直性の増加を招く。

「どんな願望もアジリティによって叶えられる」・・・などと言えば眉唾物になるが、しかしながら、実際問題として「前を向き本質的な”コト”に意識を向ける」ための基礎力として「アジリティ」というのは非常に重大な価値を持つ。その獲得のために、やはり技術力というのは重要な下地となる。

—✁—切り取り線—✁—
なんか偉そうな文体で書き始めてしまったばかりに！！
あまり気持ちが籠もらないのですが！！

「技術力つけるときっと楽しい事をたくさんやりやすくなるぜ〜〜！！」って思っています！！！！という事！！！

あ〜〜〜〜楽しいことやりたくない！？！？
楽しいことって、どうやったら出来るんだろうね！！

??? 「 アジリティです、アジリティについて考えてみるのです・・・ 」

って感じ
—✁—切り取り線—✁—

結び

結局の所、組織人としての観点から考えれば、働く上での「何が目的か」というのを平たく言えば「ビジネスを成功させるため」となる。
しかし、ビジネスやプロダクト開発は複雑で大変に難しい。成功の確度を上げる必要がある。その為には「いかに柔軟に動けるか」、「高速にフィードバックループを回せるか、すなわち『問う・観察する・学ぶ・活かす』のステップを繰り返せるか」に拘る必要がる。それがアジリティという言葉で表せる。
そのアジリティを実現する事こそが、開発組織にとっての『技術力の価値」ではないか？と、自分は考えている。
ざっくりと「技術力」というと余りにも大味な表現になるが、「スピード」「品質」「妥当性」という、それぞれが相互に密接に関わりつつも個々が重要な意味を持つエッセンスに着目し、拘り、磨きたい所。

「ビジネスを上手くやる」のに集中できている状況において、人は「コト」へ集中し、本質的な価値創造に取り組めるようになる。
すると、それが「ワクワク出来る開発業務」へと至るはずだ。

その辺りを追求することで、「ビジネス的な価値」「自身の欲求に対する回答」の折り合いがつく場所に到達できるのではないか？と考えている。