前回は、人材の流動性が高まることにより顕在化する課題について触れましたが、今回はその先にある変化について探っていきたいと思います。
目次
ソフトウェア開発の進化
現代の複雑なソフトウェア開発は、職人生産の時代からリーン生産の時代に変わってきているようです。工業製品のたどった歴史のように、一人の職人技でどうこうできるものは少なくなり、複数の人や機械がダイナミックに協調してモノを作り出す仕組みが重要視されてきているとも言えます。
リーン生産について補足すると、この方式の元になったトヨタ生産方式では、Just In Time な製造、自動化が柱となっており、それを応用したリーンソフトウェア開発が、アジャイル開発の文脈にも影響を与えています。詳しくは下記参考をご覧ください。
参考:
– リーン生産方式(Wikipedia)
– 『トヨタ生産方式』の感想メモ
– リーンソフトウェア開発(Wikipedia – En)
工業製品と言ってしまうと、一部のプログラマーからすれば、この流れは心から歓迎できるものではないかもしれません。同じソフトウェアを作っていながらも、プログラミングの技術を単なるユーザーに価値を提供するための手段としてしか見ない層が増えることが懸念されるためです。ですが私はむしろそうはならないと考えています。誰かの手段は誰かの目的でしかありませんし、そこに優劣の差はありません。一歩下がって、この国で暮らす人々の生活でさえも、国からすれば手段と言えます。ソフトウェア開発においてもそれは同様で、多くの異なる目的を持った役割が求められ、それらが効率的に作用することで成立します。ある意味で、ソフトウェア開発におけるリーン生産はチームスポーツの側面があります。刻々と変わる戦況に対してあらゆる戦術を実行できなければ、価値のあるソフトウェアは作れません。また、メンバーへの信頼と尊敬を持たなければ、チームの一員として認められずに戦力外通告を受けてしまいます。ソフトウェア開発に携わるメンバー全員の根底にそういった思想がないと、本質的なリーン開発には辿り着けないと考えています。
話が脱線してしまいましたが、橋とビルでもそれぞれ作り方が違うように、ソフトウェアにはソフトウェアの作り方があります。さらにはウェブアプリケーションと組込みアプリケーションでも異なる作り方が要求されています。他のプラクティスを参考にできることはあっても、それを真似すれば必ずしも成功するとは限りません。氷山モデルを参考にすれば、今見えているソフトウェア開発におけるプロセスやツールは、長い年月をかけて作り上げられてきた様々なパターン, 構造, メンタルモデルの上に最適化されたものと捉えることができます。これらの要素はゆっくりと変化するものから、突然大きく変わるものまで様々です。革新的な発明により、今まで普及していていたツールが使われなくなり、それに伴いプロセスが形骸化してしまうことや、新しいプロセスが導入されることで、これまで価値の見出されていなかったツールに日の目が当たることもあります。
例えば、ロジックの不具合が致命的な損失に繋がるアプリケーションにおいて使われる、形式手法 (Wikipedia) というものがあります。リリースサイクルの速さを求められるアプリケーションでは、この手法は準備に時間がかかるが故に採用されることが多くありません。ですが、AI が人間の曖昧な要件からそのパターンを網羅的に列挙した形式を推論することができるようになると、人間はそれをちょっと手直しするくらいの手間をかけるだけでよくなり、形式手法はソフトウェア開発において、これまでより使われるようになると予想できます。
物事の進歩・発展は、
あたかも「螺旋階段」を登るように起こる。
横から見れば上に登っていくが、
上から見れば元に戻ってくるように見える。
螺旋階段を登る社会 より
今後の変化
このソフトウェア開発の潮流が今後どうなっていくのか、特にソフトウェア開発に掛かるコストで比重の大きな部分、そしてリーン生産において大事な人材の流動性の観点から、どう変化していくのかを探っていきたいと思います。
※ 課題の背景に関しては 前編の「人材の流動性にまつわる課題」をご覧ください。
課題1: 従来の開発プロセスではベロシティが上がりにくくなる
考えられる原因
- 人が数ヶ月単位でいなくなるので、組織に知識が溜まりづらい。
- 人の入れ替わりサイクルに比べ、研修期間が長すぎる。
- 個々の能力に頼り過ぎてしまい、戦術が発展しない。
ニーズ
暗黙知から形式知へ、さらに純度の高まった暗黙知から形式知というサイクル (SECIモデル – Wikipedia) を効率良く回せることが Scrum の普及している一つの要因だと考えられています。人材の流動性が高まることで、このサイクルにおける共同化 (Socialization) が欠けてしまうためにベロシティが上がらなくなるのでしょう。そうなると、現在普及している Scrum に代表されるプロセスに替わるもの、もしくは Scrum + α による共同化を手助けする新しいプロセスの需要が増えると考えられます。その他にも、Scrum の経験値を貯めたチーム単位で、様々な事業会社の開発プロジェクトを渡り歩くといったことも多くなると予想できます。
課題2: タスク単位の生産性が上がる一方、プロジェクト全体で生みだされる価値は落ちてしまう
考えられる原因
- 個人の生産性を可視化することで、その指標を上げることが目的になってしまう。
- 質より量をこなす人にタスクが集中し、劣化した質によるしわ寄せに他のメンバーの時間が吸い取られてしまう。
- 経験値が組織内に貯まらないために同じ失敗を繰り返してしまう。
ニーズ
これまではプロジェクトに人を長期間抱え込むのが当然であったため、その前提の戦術が普及しています。その上では、プロジェクトの生産性を上げる責任を個々人の働きに委ねるという方針が最適解とされてきたように思います。このメンタルモデルのまま単純に人材の流動性だけが高くなってしまうと、そこからくる問題がより顕在化してしまい、短絡的に人材の流動性を抑えようとする思考になってしまいます。
似たような例でいえば、機能追加時にデグレが起こったとき、それを検知できなかったリリース前の動作確認や機能追加した人の能力が原因だと決めつけてしまうようなものです。本来なら機能追加しやすいよう、新規開発の時点でコードを綺麗にし、自動テストを入れておくべきだったのかもしれません。
開発における多くの役割を社員だけで担い内製化をしようとする動きも、人材の流動性が問題の原因だという思考も一つの要因かと思います。内製をするにしても、流動性を持たせるべき部分とそうでない部分の濃淡があるにも関わらず、現時点ではどうしても人材は流動しないという固定条件があるが故の局所解に陥ってしまうのです。
質より量も短期的に見れば良い解とも言えるのですが、チームや事業を強くするための中長期的な解を得るためには、もともとの課題をさらに俯瞰して見る必要があります。そうすると、生産性の高さのボトルネックが、メンバーの流動性に関わらず別のところにあったと発見できるかもしれません。
考えられる解としては、暗黙知に頼りすぎていた部分を技術で形式知に変えるというものです。これは Shift-left アプローチの一種で、問題をより早いタイミングで潰し後ろに持ち越さないようにすることで、問題解決にかかる時間の総量を縮小するという考えです。
課題3: コミュニケーションに掛かるコストが生産性を大きく下げてしまう
考えられる原因
- 組織内のコアな人たちと、外から来た人たちという壁ができる。
- 公開可能な情報と、そうでない情報の整理に時間が取られる。
- 時差や文化の違いで情報伝達が思ったように上手くいかない。
ニーズ
人材の流動性が高まれば、リーチできる人材の幅も広がります。そうなることで戦術の幅が広がります。コストのかかるところが時差であれば、同じ地域に住む人を集めプロジェクトを作れば良く、組織の外と内という壁がコストであれば、情報の格差を減らすよう可能な限り情報をオープンにするのも大事です。また、情報を暗黙知のままにしておかないようにしようという力も強く働くでしょう。その結果、形式知化される情報とその運用の質が高まり、引き継ぎや研修にかかるコストを減らし、サイロ化しにくい人材の流動に強い組織を築くことができます。また、役割間のコミュニケーションをいかに最適化するかに関しても大幅な改善の余地はあり、その役割に特化した人もチームに参加するようになるかもしれません。組織の内側で部署やチームの流動性を高めるといった試みをしている企業も何年も前から耳にします。そこで培われたノウハウは人材の流動性が高まった社会においてより活かされていくものと思います。
課題を超えた先にあるもの
人材の流動性の高まりはこれからも加速していくでしょう。その中で価値のあるソフトウェアを作っていくためにも、これまで通用していたやり方に固執せず、刻々と変わる戦況に対してあらゆる戦術を柔軟に考え実行する力が求められています。そしてその先にある、個々の能力を発揮しやすい社会が実現することで、企業はこれまでよりトータルコストをかけずに質の良いデジタルサービスを素早く提供, 維持, 改善できるようになっていくと考えています。そして結果的に、企業は本当の意味でデジタルサービスを内製するようになっていくのでしょう。
人材の流動に伴う漠然とした不安
上記のようなソフトウェア開発に直接関連した課題だけでなく、以下のような漠然とした不安もあると思いますので蛇足かもしれませんが、補足したいと思います。
「人材の流動性を上げること」 イコール 「企業が社員を解雇しやすくすること」に繋がらないか
企業視点で見れば解雇は一時的にキャッシュフローを上げることに繋がりますが、企業を構成する人々の信用を失ってまで高めたもので企業の価値は上がりません。よって解雇以外の選択肢で流動性が高くなると考えています。例えば、フルタイムの社員を必要以上に増やさずに、フリーランスと大小問わずタスク単位の契約をするようなことが今後増えていくと考えています。
サイロ化された個の知識に頼らなくても良くなるのであれば、成果主義が加速し殺伐とした組織になるのではないか
成果とはなにかという問いにどう答えるか、流動性に関わらず多くの組織にとって答えの出ないテーマです。そのゴール設定やインセンティブ設計は組織を形成する大きな要因です。殺伐とした力による支配をあえて設計し成長する企業もあります。少なくとも流動性が高くなれば、自分に合った組織を選びやすくなるでしょう。
年功序列を信じて尽くしてきたのに、それがなくなってしまうのではないか
人材の流動性は時代のニーズであり、その企業の理念を曲げてまで達成しなければいけない目標ではありません。企業のオーナーも年功序列をやめることで長年培ってきた社員からの信頼を失うことは避けたいはずです。そうではなく、人材の流動性の高さを有効活用し、今いる人たちではできなかったことを外からきた人たちと共に成すプロジェクトを新たに立ち上げ、企業の新しいビジネスモデルを作っていくような成長戦略も取れるはずです。
起こり得る良いこと
最後に、人材の流動性の高まりに派生して生まれるであろう良い効果についても触れておきたいと思います。
時間単位の生産性が上がる
多くの情報が形式化され、仕事の In と Out がはっきりすることで、コミュニケーションコストが減り、本質的な成果にフォーカスすることができます。柔軟な粒度の仕事と報酬の設計ができるようになり、個々の生活にフィットする働き方が選べるようになります。ジョブ型雇用もその一つです。解決したい課題が大きいので In / Out がはっきりしていないようにも見えますが、従来の仕事から比べると問題がクリアになっています。
組織へのエンゲージメントが高まる
依頼者側は明確な役割と公正な報酬で仕事を依頼することになり、それにより従来のお客様と提供者という関係から生まれる権威勾配が減り、組織の内と外の壁は薄くなるでしょう。また、仕事の選択肢が増えることで自身が持つ Vision のベクトルの合った組織を選択できるようになります。
無理に働かなくても良くなる
例えば体調不良で仕事をしてなにか成果を出しても、その質が悪かったらそれに依存した他の人の成果にも悪影響を与えてしまいます。ゆっくり寝て早く治して万全の体調で働くことが全体最適に繋がります。人材の流動性の高まりは、特定の人へ依存を減らし心理的にも休みやすい環境を作ると考えています。それでも仕事をしないといけない大事なときもありますが、流動性が高まるほどにその頻度も減っていくでしょう。
この記事の続き「10年後の開発 – Gigとソフトウェア開発」もぜひご覧ください。
Author: Yuki Sanada
