これまでの記事で触れた内容をもとに、10年後の開発がどうなっているのか、どのように企業がソフトウェアを内製しているかを予想してみます。
そしてその先にある、個々の能力を発揮しやすい社会が実現することで、企業はこれまでよりトータルコストをかけずに質の良いデジタルサービスを素早く提供, 維持, 改善できるようになっていくと考えています。そして結果的に、企業は本当の意味でデジタルサービスを内製するようになっていくのでしょう。
人材の流動に伴う変化 – https://www.tc3.co.jp/gig-economy-software-development-3/
目次
これまでのおさらい
第一話では、ソフトウェア業界が抱える問題や、それらが解決された未来の姿を概観しました。現在の開発体制は、個人の能力に期待し、問題解決にコミュニケーションを重視する形になっています。悪く言ってしまうと密結合で運任せな開発体制です。
続いて第二話では、既存の枠組みの中で人材の流動性を高めることで生じる品質劣化やコスト増の問題について詳しく説明しました。社会の枠組みも徐々に変わっていき、これらの問題の解消に取り組んでいることがわかります。
前回の第三話では、人材の流動性が高まることで生じる課題とニーズを予測しました。オンデマンドに人材を活用する開発プロセス、個人の能力を活かす小さな単位の経済活動、鮮度と質の高い情報伝達手段が必要になってきます。
10年後の開発
まずは10年後のソフトウェア開発に関わる人たちの変化について想像してみましょう。
10年後の事業会社のメンバーは、高度な情報リテラシー教育を受けた世代で構成されると考えられます。彼らは今の平均的なシステムエンジニアと同等の能力を持っていると想定します。さらに、彼らの生産性や基本的な能力は、機械的なサポートによって大幅に向上することが予想されます。
ここで、これらの人たち(※)を便宜上「プロダクトオーナー (PO)」と呼びましょう。POは、自分たちの事業に関連するニーズを見つけ出し、事業を進化させ、拡大するアイデアを練り、実現することが使命です。
※ スクラム開発のPOだと一人をイメージしますが、ある程度複雑でイノベーティブなデジタルサービスを作る事業の責任を負うため、複数人でPOの役割をカバーするだろうと想像しています。
開発者を見つけるフェーズ
事業アイデアが決まり、ソフトウェアを作成しようとするとき、それが複雑な仕組みを要するものであるなら、まず開発者を見つける必要があります。初期段階では社内に開発者を雇わず、外部に依頼するでしょう。これは、事業が安定するまで社員の抱え込みコストをできるだけ避けたいと考えるためです。また、10年後は開発者が多く個人で活動しており、世界中の開発者と簡単に繋がりを持てるようになっていることも要因です。そのため、少し割高でも外部に依頼し開発速度を高めることが、時間と共に減るプロダクト価値の機会損失とのトレードオフを考えれば合理的でしょう。すでに安定した事業を持つ企業では、ソフトウェアアーキテクトなどの役割を担う専属開発者が数名いるかもしれません。
未来の開発チーム体制
ソフトウェア開発では、多くの情報変換工程が存在します。従来の一般的な例として、POがコンサルティング会社に業務要件の整理を依頼し、さらにコンサルティング会社が開発会社を選定し、システム要件の整理を依頼し、最終的にフリーランスや別の開発会社に実装を依頼するといった体制があります。企業間やプロジェクト体制の多層化による情報変換コストは無視できないほど大きくなっています。
今後は、技術や教育の進化により従来の情報変換工程が徐々に短縮され、最終的にPOと開発者が直接繋がる形になると予想されます。このような理由から、ソフトウェア開発をはじめとする多くの組織が下図のようにネットワーク型に進化していくと考えられます。
新しいチーム体制で求められる役割
このような社会が実現したと仮定した場合、POからソフトウェア開発を依頼される人にはどのような能力が求められるのでしょうか。
POはUIUXデザイナーらと共同で精度の高いプロダクト要件を練り、解像度の高いUIデザインを含むシステム要件を用意できると考えるのが妥当です。
その後、専門的な視点から要件をブラッシュアップし、開発する工程が残ります。
新しいチーム体制では、以下の二つの役割が重要になります:
1. ソフトウェアアーキテクト (SA)
2. インディビジュアルコントリビューター (IC)
役割名は便宜的に現在すでにあるイメージしやすいものを選択しています
それぞれの役割について説明します。
ソフトウェアアーキテクト
役割: 複数のICと連携し、POの要求を最適な方法で実現する。
複雑なソフトウェアを作るには専門知識を持った多くのICに仕事を依頼する必要があります。要求をタスクに細分化し、こういったことを実現するならこういった知識を持った人にこう依頼をすると質の良いものが早くでてくるということがわかるスキルを持っています。
事業に対してもある程度の責任を持つことになるでしょう。
主な仕事内容:
– プロダクト要件の改善提案
– システム要件の解像度向上
– アーキテクチャ設計
– タスク分割
– ICへの実装依頼
– UAT指摘のタスク化
インディビジュアルコントリビューター
役割: SAと協力しながらPOの要求を把握しつつ具体的なタスクを最適な方法で実現する。
ソフトウェア開発に関する知識を広く持ちながらも特定の技術領域に特化しています。
一つのプロジェクトに複数のICが入れ代わり立ち代わり関与します。また、ICはタスク単位など様々な報酬形態で同時に多くのプロジェクトに関わります。
主な仕事内容:
– システム要件の改善提案
– SAの作ったアーキテクチャのレビュー
– 負債を残さない成果のアウトプット (e.g. 実装)
– 他ICの作ったアウトプットのレビュー
開発プロセスについて
このPO、SA、ICが効果的に協調してソフトウェアを作る開発プロセスについては社内では実践的に考えらていますが、長くなってしまうため今回の記事では割愛します。
少し触れると、この開発プロセスは複雑なソフトウェアを効率よく作る際のベタープラクティス(※)のようなものです。この三者間の情報のバトンをどのタイミングでどのように受け渡すかという問題として考えると、開発体制に潜む様々な問題に対してアプローチしやすくなり、複雑なソフトウェアをQCD (品質, コスト, 納期) 良く作る手助けになります。
※ なぜベストではなくベターなのか
ここに書いた内容はどちらかといえば、事業会社とソフトウェア開発に関わる人々、双方が高い価値を提供し、対価を享受できる公正なソフトウェア開発とはなにかを考えていったとき、こうであってほしいという願望から来ています。ある視点だけを切り取り誰かのベストを突き詰めれば公正でなく倫理的に正しくないと思われることを選択してしまうかもしれません。私達はそういう未来を望んではいないため、あえてベターと書いています。
あとがき
TC3では GigOps と呼ばれる、こういった世界で必要とされる開発プロセスやツールを作っています。開発プロセスや一部ツールに関してはすでに実プロジェクトに適用しつつフィードバックと改善を繰り返しており、ここに書いたような体制で開発もして効果を検証しています。さらにこの体制における情報伝達ロスを軽減するためのツール群が多く作られていくことで、オンデマンドにスケールする開発体制を維持しながらも、さらに効率的に質の良いソフトウェアを作ることができるようになると期待しています。
この記事の続き「“GigAgile” もう一つのアジャイル開発」もぜひご覧ください。
Author: Yuki Sanada
