Goodpic.comさんの
「オープンで無いソフトを書いたり使ったりするエンジニアはリスク」という考えとオープンな基盤の上に創られるシステムとはより。
テクノラティのエンジニアがいった、
「オープンで無いプロプライエタリなソフトを使ったり、書いたりするエンジニアは、特に小さなスタートアップ・ベンチャーではリスク要因になるんだよ。あるエンジニアが急に会社をやめたりしたときに、オープンなソフト、コンポーネント・モジュールで開発がされていれば、新しく担当になった人が、最小限の時間で状況を把握して、開発を継続できるから。」
という言葉から、金子さんが
リスクというと、無ければいいような気がしますが、リスクを冒さないと得られないモノもあります。リスクを取らないとリターンが得られないので、重要なのはリスクがコントロールされていること＝リスク・マネージメントという発想がまず第一の前提。その上で、オープンであるかどうか、どうにも議論が噛み合ない場合があるわけですが、実はお互いに当然だと思っていることが食い違っているのかも。
と指摘されている。これは、日米のオープンソースソフトウェアに対する意識の違いを表しており、
「オープンで無いことはリスクである」と考えている人と、「オープンであることがリスクである」と考えている人が、お互いにその違いに気づかずに会話していると、「なぜ？なぜ？」と端々で納得がいかないケースが多々あるのかなと。 しかもそこに、「リスクはマネージできればいい」という考えと、「リスクはとにかく避けるべきだ」という点でもすれ違っていると、話が平行線をたどる可能性大。
ということなのだ。
リスクの見える化
「リスクはマネージできればいい」というのはオープンソースソフトウェアに限らず非常に重要な概念だろう。プロジェクトに携わっていると一番心配なのはリスクの見える化ができていないことだ。
例えばアプリケーションの組み方に現れる。なにをもってリスクとすべきかという意見も分かれるだろうが、僕はコンポーネント・機能間の統合こそ、もっともリスクが高い部分だと思っている。そのため、浅い実装でも、ともかくをコンポーネント・機能つなげることを重視する。できるなら１つのビジネストランザクションが完結する形が望ましい。流通で言えば、商品の発注から納品・店頭出庫・売上までだろう。このほうが成果が見えやすく管理が行いやすいという利点もあるのだが、最も大切なのは見えないリスクを顕在化させられる可能性が高いからだ。
そして本番運用にも現れる。本番機に少しでも早くアプリケーションをのせて動かしておくべきだ。機能はなくてもいい。そしてデプロイ手順、移行手順の作業にも出来る限り早くを手をつけるべきだ。あるいは性能も同じだろう。性能テストしたい機能を定義し、それができたらすぐにテストする。逆に言えば、そういうことを考えて実装スケジュールは作成されるべきだ。
どんなにリスクが高い作業でも、リスクが見えており、管理されていればなんとかなる。怖いのはリスクがまったく見えない作業だ。だから事前にとりあえず触っておく。臭うものから手をつけるのは、リスク高いプロジェクトの鉄則だろう。
ゴールのための手段であることを忘れない
冒頭のオープンソースうんぬんという話も、スタートアップ・ベンチャーがリスクを避ける手段として採用しているわけで、そこには明確な最終目的がある。リスク管理で重要なのは、最終的なゴールへの認識を忘れないことだろう。だからそのゴールの提示が重要になる。
ソフトウェア開発プロジェクトのゴールは、実装完了でも、テスト完了でも、カットオーバーでもなく、クライアントが運用して成果をあげることにある。そう考えれば、本番環境で動いてこそのアプリケーションだと思えるわけだ。
全員がゴールを理解していればリスクが発見される確率も高い。逆に自分の作業領域だけを見つめてしまうことでリスクは地に潜る。そして、ある日突然現れてプロジェクトを転倒させる。
リスクが無いなんてありえない。見つけて、共有して、的確な人が退治する。それを営々を続けるしかない。最近の僕の仕事は、みんなを不安にさせることにある。「ほら、そこにもリスクがあるかも！」
