Europe: Software as a science -ヨーロッパにとってソフトウェアは「科学」
Japan: Software as production -日本のソフトウェアは「製造業」
India: Software as a service -インドのソフトウェア産業は「(プロフェッショナル)サービス」
U.S.: Software as a business -アメリカのソフトウェア産業は「ビジネス」
確かに自分が開発で経験したのは「製造業」だった。
一報、サービスを作ることと、ソフトウェアを作ることには
「『あと1週間あったらきれいなコードで出せる』がソフトウェアで、『今リリースしてPVが増えるなら、何でもいいから出せ』がサービス」と、いうエピソードがある。
コードや仕様書を印刷して納品し、紙の重さで報酬が決まるような受託開発ならともかく、
自社開発でサービスをてがけるような仕事ならコードを綺麗に書いたり、リファクタリングしたりは乱暴に言えばどーでもよく、
「とにかく早く、リリースする」のはこれからもっと重要、必須になると思う。
(相反するようですが、テストは重要。ちゃんとテストはする。「早く出す=テストやらない」ではないです。当たり前ですが)
リファクタリングが必要になる頃はサービス自体に見直しや置き換えが必要になる頃だろうから、そうなればどうせ作り直しです。
リファクタリングで実行が速くなるというのなら、ハードやインフラを高性能なものに置き換える力業のほうがてっとり早い。
最近流行のクラウドで、高スペックのサーバに置き換える方法がお手軽。その頃には収益があり置き換える元手はあるだろうから。
元手がないのなら、それは運用の見直しが必要かと…。
「コードの再利用」という話もありますが、コードというよりノウハウというかスニペットを溜めておいて、
「こういうときは確かこうやれば…」みたいな感じで拾ってきて組み上げていく感じになるんだろうなと想像。
と、いう話を書いたのは、自社内の開発部が「きっちり作りましょう」的な進め方をしていて、
チケット駆動やらレビュー制やらを取り入れているのは良いのですが、
端から見ていると進め方が冗長(要望よりリファクタリングを優先していたり)で、
その割にはリリース直後にバグが見つかったりとクオリティはどうよ?という感じなので。
「クオリティ上げられないなら、がんがん作ればいいじゃん」と思ったわけです。
開発部に口出しできる立場でないので…要するにチラ裏です。
0 件のコメント:
コメントを投稿