ソフトウェア開発の鉄則は"協調"と"ソーシャル"? エバンジェリストのススメ

現在、そしてこれからのソフトウェア開発のあり方を考えるには、ビジネスシーンにおける、ソフトウェアの位置付けの変化に注目せねばならない。以前であれば、確立されたビジネスモデルの中に、IT を活用することでより効率性や利便性が高まった。ソフトウェアはあくまでビジネスのサポート的な存在でしかなかったのだ。それがやがてビジネスモデル自体に IT が組み込まれるようになると、ソフトウェアはもはや欠くことのできない存在となっていったのである。

このような変化に応じ、ソフトウェア開発の手法にも変化が求められるようになってきた。かつては意思決定を行うのは主に開発部門であったが、やがてビジネスとのつながりが強まるとともに経営者の意思決定が必須となった。さらに現在では、マーケットやコンシューマーの動向に合わせて迅速にソフトウェア仕様を変えなければなくなっているのだ。

今日のソフトウェア開発が抱える課題

アトラシアンのテクニカルエバンジェリスト、長沢智治氏はこうコメントする。

「Time to Market でソフトウェアを開発し提供しないことには、マーケットへの訴求は難しくなったということです。そんな現在のソフトウェア開発の意思決定者は、マーケットやコンシューマーだと言ってよく、もはや情報システム部門の枠組みを大きく飛び越えてしまっています」

またソフトウェア開発の現場では、かつては自分たちの得意とするプラットフォームでのみ開発を行えば良かったのが、今ではクラウドやIoT(Internet of Things)の普及に伴い、なじみのないプラットフォームであってもその技術も使わなければ求める成果が期待できなくなっている。これにより、タイムリーな開発と合わせて、多様な技術の駆使も求められているのだ。今日のソフトウェア開発にはそれだけ難しい選択肢が立ちはだかっていると言えるだろう。

しかし今では、技術の発展とともに、市場や利用者への直接的なリーチや、変更が可能なデプロイ方式がとれるようにもなり、ビジネスの状況に合わせてソフトウェアを見直し、進化させて行くことも可能になった。そこで重要なのが、ビジネスのリズムに合わせてソフトウェアを継続的にデリバリーすることである。

例えば、当初に立ち上げたサービスでは意図しなかったかたちでユーザーから評価を受け、それによりサービスや機能が変わることも考えられる。

「ツイッターやフェイスブックなどもスタート時の目的や内容は今とは異なるものでした。サラリーマン向けに開発したサービスが、提供してみたらサラリーマンには受けが悪く、その代わりに女子高生に受けた──そんなケースも想定されるのです」(長沢氏)

だからこそ、ソフトウェアをコンシューマーに試用してもらう期間を設けることの意義が高まっているのだ。そして試用結果を反映するためにも、ソフトウェア開発プロジェクトには機敏かつ柔軟な動きが求められているのである。

統制型マネージメントから自律型マネージメントへ

このようなソフトウェア開発をとりまく環境の変化にも関わらず、多くの国内企業では旧態依然とした開発手法が取り入れられているのが実情である。

長沢氏は、「ビジネスプロセスが確立していた時代であれば、開発内容への組織内の合意も得やすく、また得意な技術だけを使えるため確実性も高かったと言えるでしょう。しかし、現在の技術は不確実性が高く、また、その時のビジネスニーズを踏まえたうえで優先順位を決めないため、合意も得られにくくなっています」と強調する。

そこで近年注目されているのが、いわゆるアジャイルな開発モデルである。使ったことのない技術を使用すれば、これまでの熟練したプロジェクトマネージャーに権限を集中させる「定義済みのプロセスモデル」では通用しなくなる。過去に経験がない技術を用いて新たなビジネス価値を創出するというこれからのプロセスモデルには、チャレンジに応えられる「実測駆動のプロセスモデル」が適しているのである。この実測駆動のプロセスモデルでは、工程、人と成果物は連動し続け、全工程に注力したプロジェクト管理が必須となる。スキルと経験はプロジェクトを進める中で練っていくことになる。

「リーダーがプロジェクトのほとんどを把握し、個々のチームはサイロ化しても問題なかった統制型マネージメントではなく、リーダーも知らないことがあり、チーム指向で相互にフォローし合うという自律型マネージメントへと転換しなければなりません」(長沢氏)

自律型マネージメントを可能にする開発支援ツールとは

最新のビジネスニーズに合致したソフトウェアを開発するためには、実測駆動のプロセスモデルを自律型マネージメントでまわしていかねばならない。しかし、一般的な開発支援ツールではその実現は困難だ。例えば要件項目の記述で最も多く使われているExcel の場合、プロセスやチーム内でのつながりを盛り込むことができず成果物の単品ができあがるだけとなってしまう。既存の ITS(Issue Tracking System)にしてもバックログとタスクに関してはなんとかつながりがあるものの、企画からデプロイまでのトレーサビリティを創出、維持するには作り込みや人的負担を伴ってしまう。

「たとえ自力で作る体力とリソースのある現場であったとしても、その仕事は本業ではないはずです」と長沢氏は指摘する。

また開発支援ツールを自前で作りこんだ場合、担当者が異動したり退職したりするとプロジェクトが引き継げなくなるリスクもある。

そこでアトラシアンでは、プロジェクト管理ツール「JIRA 」と開発支援ツール「Stash」、「Bamboo」と情報共有ツール「Confluence 」を中心に、さまざまなツール連携を活用することで、ソフトウェア開発現場の追跡可能性と粒度を踏まえた全社的な開発支援を可能にしているのである。

アトラシアンのモデルではレポジトリのデータを二重で持たないことから、レポジトリ間のやりとりをシンプルにしており、ユーザーはそれぞれのレポジトリやデータの同期などのつながりを意識する必用がない。例えば、企画部門と開発部門の連携の場合、企画スタッフがConfluence 上で要件化したいセンテンスをハイライトすると、そのまま要件を作成して JIRA へと反映できる。そして開発チーム側が対応可能だと判断し意思決定すると、企画文書の中に自動的に反映されるのである。

これまで、企画側が企画文書に盛り込んでいても、開発側のコンディションが十分でなく対応できない要件が発生するといったケースはよくあった。それが情報共有することでブラックボックスだった開発側のコンディションを企画部門で把握できるようになるなど、部門間での協調を実現するのである。

「無駄な打ち合わせも省けて効率化にもつながります。 JIRA と Confluence の連携はお客さまからの評判がとてもいいですね。 JIRA は開発者向けのツールなので企画スタッフにとっては必用以上の情報を扱うためハードルが高かったのですが、使い慣れた Confluence のインターフェースから見られることで気軽にコミュニケーションできる点が特に評価いただいています」(長沢氏)

また、アトラシアンの製品群ではソースコードやビルド、バックログなど既存システムとの組み合わせも可能だ。いずれアトラシアン製品への統一を図る際にも、ユーザーのニーズに応じ移行ツールを提供しているので容易に行えるのである。

キーワードは「協調」と「ソーシャル」

改めて長沢氏は、現在そして今後のソフトウェア開発のキーワードとして「協調」と「ソーシャル」の 2 つを挙げる。

「開発部門とビジネス部門、企画部門の協調はもちろんですが、ソフトウェアを作って終わりではなく運用経験から得たアイディアを要件にして構築していくといったサイクルをまわしていく DevOpsへの取り組みが欠かせなくなるでしょう。また、ソースコードに変更があったら必ずビルド成果物に反映するなど、それぞれ異なる粒度の情報をユーザーの必要なレベルへと落とし込んだうえでのソーシャルな仕組みもますます重要性が増していきます。これまではコードならコード、設計なら設計しか見なかったのが、今はソーシャルな力を発揮してそれぞれが持っている知見をどんどん浮き彫りにしていき、それを共有していかないといけないのです。われわれが提供しているのは、それぞれに注力しながらも、情報が有機的につながるための仕組みです」(長沢氏)

アトラシアンでは、協調とソーシャルを実現するツールを、現在のソフトウェア開発だけでなく、財務や人事などさまざまなチームにも提供していくべく開発を進めている。

「ソフトウェア開発の手法はほかの業務にも応用できます。当社としても多様な業務で使っていただけるよう、製品を進化させていきます」──最後に長沢氏はこう力強く宣言した。