2013年11月24日

SZJ012 「イノベーション」にはまず気付くことから

システム開発において「気付く」という事は大変重要だと私は思っています。問題が潜在しているにも関わらず、それに気づかずに作業を進めてしまい、後になって問題が表面化してから気付く。
すぐに有効な対策を打てればいいですが、根が深い場合には致命的なダメージを被ることだってあり得ます。
納期を守り、コストを抑えて作業を行うには、問題となり得るポイントをしっかりと押さえてその発生を未然に防止する事が肝心です。
問題が発生してから対策を考える「後手後手」の対応ではなく、問題が発生する前に対策する「先手先手」の対応を行う。
ある種、システム開発の理想とする形ですが、この「先手先手」の対応を行うために必要な事とは一体何でしょうか?
私は次のような事を考えました。

●一歩踏み込んで考える
例えば、画面レイアウトを考える時、要求仕様を満たしているか、技術的に可能かといった点を重要視すると思いますが、そこで一歩踏み込んでユーザがこの画面を見てどう感じるかを考えてみてください。
ユーザが必要としている情報を表示しているか、ユーザの使い勝手が悪くないか、直観的に操作できるか等、実際そのような事はあまり考慮しなくてもユーザ承認は得られます。なぜならユーザは机上だけで判断しているからです。でも実際にプログラムが完成していざユーザが触ってみると、いろいろ問題が発生するものです。
いくらユーザビリティを考慮した設計をしても少なからず問題は発生しますが、設計時に何も考えなかったものと、その時想定される最大限の対策を盛り込んだものでは、問題の数やレベルに雲泥の差があることは想像に難くないと思います。

●「たら」「れば」結構
世間一般的には「あの時…していたら」「もし…していたら」とクヨクヨ考える事は良くないと事として知られていますが、私は「たら」「れば」は大変結構だと思います。
「たら」「れば」を考えれるということは、そこに問題があった事に気付いているということで、とてもポジティブな事だと思います。
今回失敗したのなら、次回は同じ失敗を繰り返さないように必要な対策を事前に講じればいいのです。
ただ、現在進行形のプロジェクトでは、「たら」「れば」を考える前に、今ある問題を解決する事が最優先ですので注意してください。「たら」「れば」を考えるのはプロジェクトが終わってからの方がよいでしょう。

成功したプロジェクトでは、苦労が少ない分問題点に気づく事も少ないでしょう。でも、気付くポイントというものは無数に存在していると私は思います。要はそのポイントを見つける「気付く力」をどれだけ持っているかだと思います。常にアンテナをピンと張って一瞬のすきも見逃さず問題の予兆に気付く努力することが重要だと思います。
イノベーションの糸口はまず気付く事、全てはそこから始まります。
posted by j.shiozaki at 17:41| Comment(0) | TrackBack(0) | 3分メモ

SZJ013 プロセスイノベーション

成功した時よりも、失敗した時の方が多くを学べる事は周知の事実だとは思いますが、できれば失敗したくないというのも人間の本心ではあります。
それゆえ、ある時試した方法が成功すると、失敗を恐れてずっとその方法をやり続けてしまいます。
でも失敗しないやり方が一番いい方法ですか?と問われるとどうですか?
あなたはその問いに対して自身をもって「YES」と答えられますか?

過去に成功した方法は、無数にある選択肢の1つにすぎません、他の方法を試しもせずに答えは出せないはずです。
確かに実績を重ねるたびにリスクは減り、ベストな方法に近づくかもしれませんが、もっと良い方法というものは必ずあるものです。
時にはリスクをとってチャレンジする勇気も必要だと思います。

しかし... ここからが本題ですが、

趣味でやっているのであればいざ知らず、仕事で果敢にチャレンジして玉砕しては元も子もないです。
飯の食い上げです。
新しい事に挑戦しつつも、いかにリスクを減らすか、私はこれからの時代を生き残っていく上で必ずぶつかる壁だと思っています。
まだこの壁を一気ぶち破るほどのインパクトを持った解決方法は発見できていませんが、とりあえず覗き穴ぐらいは開けられそうです。
そのために以下の3点を提案します。

@過去に実績のあるやり方をベースにしつつ、いくつかの工程で新しい方法を試す。
A新しい方法を試しつつ、実績のあるやり方で保険をかけておく。
B社内では試した事はないが、社外で実績を上げている方法を取り入れる。

もし、これらの方法を試して失敗したとしても、実績のあるやり方でリカバリできるので、致命的なダメージとなる可能性は低いです。
失敗したからといって、その方法が悪いわけではなく、やり方が悪いといった事も考えられるので、失敗のダメージが極小ならば、他のプロジェクトでも試してみてから結論を出すといった事も可能かと思います。
そうやって、少しずつ今までのやり方を「改善」していって、最終的には全プロセスにおいて過去を超える生産性を達成するのが目標です。

そして、それが私の目標とする「プロセスイノベーション」です。
posted by j.shiozaki at 17:42| Comment(0) | TrackBack(0) | 3分メモ