|
私は時々、こんなもの使えるのかな？と
疑問に思えるようなシステムの開発に、携わることがある。 ソフトウェアの開発を依頼する立場である顧客からすると 信じられないことかもしれないが、残念ながら事実である。 では、なぜそんなことが起きるのだろうか？ 考えられる原因は色々あるが、大きく分けると以下の２つが原因だ。 一つは、ソフトウェアを提供する企業の能力不足で もう一つは、顧客のソフトウェアに関する知識の不足。 「おいおい、客の知識不足が原因とはなんたることだ。お前たちはプロだろ」 と言われるだろうが、残念ながら現状は ソフトウェアを提供する企業の能力が不足しているため 顧客が本当に望んでいるシステムを提供できないことは、良くあることである。 もちろん全ての企業がということではないだろうし 立派な仕事をしている企業もあるはずだが 多分、立派な仕事をする企業は、かなり少ないように思える。 他の業界であれば、その道のプロが、顧客からの要求をきちんと整理し 最終的には顧客の要求を受け入れつつも、設計者として守るべきものは守るという さすがはプロだと思われる作業をこなすものだが ソフトウェア開発の場合は、顧客の言うことをなんでも受け入れてしまい 全体を通して見ると問題のあるシステムが出来上がってしまったり 最終的には「あなた達がこのように作って欲しいと言ったでしょ」など こうなったのは顧客の責任だと言わんばかりの ありえないことが起こっている。 このような状況で、まともなソフトウェアを手に入れるためには 顧客がソフトウェアに対する正しい知識を持つ必要がある。 但し、何度も言うが、これは本来ありえないことだ。 そもそもの原因は、企業の力不足であるが それを見破ったり、力不足なりにうまく使ったりする為には 顧客自身がある程度の能力を身に付ける必要がある。 そうしないと、大金を使っているにも関わらず 酷いソフトウェアが出来上がってしまい 変更に次ぐ変更や、大量のバグが発生し 無用なコストがかかってしまうことになる。 こんなことでは、ソフトウェアを導入することで作業効率を上げて より多くの利益を得るという、本来の目的を達成することが困難となってしまう。 ソフトウェアを開発するときには、それなりの知識を身に付けよう。 もしそれができないのであれば、知識のある人を探そう。 良いソフトウェアを手に入れるのは難しいことだ。 が、決して不可能なことではない。 顧客として、相当な努力が必要となってしまうだろうが 大金を無駄にしないためには、それなりに努力が必要だと思う。 私がこんなことを言うのもおかしいことだが ソフトウェア業界を変えられるのは顧客である気がする。 顧客の知識が高まれば、企業の誤りを指摘するとが可能となり 顧客が望めば企業も変化しざるをえない状況にならないだろうか？ 他力本願で申し訳ないが、一エンジニアたる私にできることは ブログで記事を書くとくらいである・・・  |
|
最近、こんな本を読んでみた。
「ユースケースによるアスペクト指向ソフトウェア開発」 まだ、半分くらいしか読んでいないけど非常に興味深い内容だ。 アスペクト指向自体は、何年も前から知っていたけど 紹介していることと言えば、ログ機能のような横断的処理に利用できる程度のことで ま〜面白そうだけど、どんなもんかね〜なんて思っていた。 ところが。 この本を読み始めて考え方が変わってきた。 さすがはオブジェクト指向の巨匠、３アミーゴの１人。 ユースケースとアスペクト指向を組み合わせると オブジェクト指向を実践したときに大きな問題となってくる 「処理の分散」に効果的に対処することができるようになる。 本のタイトルからして、まるでユースケースとアスペクト指向を 単に組み合わて使っているだけのような印象を受けるけど これは、新たなパラダイムと言えるほど、素晴らしい手法だと思う。 各クラスに分散してしまう処理を ユースケーススライスという概念を用いてまとめているのだが この考え方が本当にすごい。 もし、この方法でアプリケーションを開発したとすると 一体どんなシステムが出来上がるのか、非常に興味がある。 どのくらい保守が容易になるものか、是非体験してみたい。 あと、この本ほ読んでいると、クラスとは何なのか？など 今まであまり疑問に思ってなかったことについて、深く考えさせられる。 オブジェクト指向では、クラスの抽出が全てだったけど アスペクト指向では、クラスの意味が良く分からなくなってくる。 そもそも必要なの？という疑問すら出てくるほどだ。 ユースケースによるアスペクト指向などという 二つの方法を合わせたような名前ではなく なにか新しい名前を付けた方が良いと思う。 ホントにすごいよ。 最後にこの本は、ユースケースやUMLの利用方法についても 非常に参考になると思う。 私は、これほど実践的な例というものを、この本で初めて見た。 UMLの表現力も再認識できた。 何度も言いうけど、さすがスリーアミーゴ。 とりあえず、全部読み終わったら、色々と試してみようかな。 ■ユースケースによるアスペクト指向ソフトウェア開発 |
|
理想的な会社って〜
ん〜あとはなにがあるかな〜 時間に制限がなくて 報酬は頑張れば稼げて 車で通勤できて シャワーが何時でも使えて 健康的で自律した社員が居る。 以外に少ないな・・・ これだけかな？ 自分で、考えておいて、少ないって言うのもなんだけど こんな会社なら、探せばある気もするな。 理想を考えると、すごくハードルが高い気がしてたけど なんか意外だ。 これだけ？ みたいな感じがする。 でも、あと、欲しいものというか これだけあれば、そこにずーーーと居てもいい気がするな〜 なんで、普通の会社って、つまらないのだろう・・ やっぱり、色々と制限があるからかな？ ちょっとだけ、制限を緩めて優秀な人を集めた方が 会社として上手く行くと思うのは私だけでしょうか？ 是非、こんな会社作ってください(^_^;) |
|
その1では、作業時間が自由で、給与には成功報酬の制度がある
というところまで考えたので、更に、理想を追求して行こう。 【オフィスは田舎で、駐車場完備】 毎日の満員電車。 これに乗っているだけで疲れてしまうのは きっと、私だけでは無いはずだろう。 オフィスが、都心から離れた田舎にあれば 駐車場だって完備できるかもしれない。 ま、車を持っていない人や、運転が嫌いな人はどうするんだ！！ という意見もあるだろうが、車買って、運転好きになって貰おう。 【シャワー完備】 眠くなったときや、仕事で良いアイディアが浮かばないとき 散歩やジョギングができると、私は嬉しい。 ３０分くらい、仕事を忘れて体を動かせば 眠気を覚め、仕事の効率も良くなると思う。 で、軽く運動するにしても、夏は汗をかいてしまう。 そんなとき、どうしても欲しいのが、シャワーだ！！ 毎日、軽く運動し、良く食べて、良く眠る。 常に健康でいることが、集中力の持続力につながり 結果的に、仕事の効率が上がるだろう。 【入社試験】 ここまで、自由な会社があったとすると 社員一人ひとりが、自分のコントロールに優れていなければ 会社は、あっという間に無法地帯になってしまう。 そこで、重要になってくるのが、入社試験だ。 まず、入社試験の期間を、一ヵ月としよう。 少々長い気がするが、理想的な会社に入れるのなら 一ヵ月くらい頑張れるだろう。 そして、一ヵ月かけてすることは。 単に、「好きなように仕事をさせてみる」だ。 作業時間もすきなように、休みも好きなように 通勤も、運動も、仕事も、なにもかも好きなようにやらせてみる。 で、一ヵ月様子を見る。 一見、試験になっていないような気もするが 多分、自分をコントロールできない人は どんどん生活が崩れて行き、昼と夜が逆転したり 体調が悪くなったり、仕事が進まなくなるだろう。 逆に、きちんとコントロールできる人は 毎日コンスタントに仕事をこなし 作業効率も良くなっているはずだ。 こうすれば、だれが会社に必要かは、一目でわかるだろう。 だんだん、ネタが尽きてきた。 理想的な会社って、こんなもんなのかな？ いやいや、まだまだまだまだ(^_^;) |
|
今日、ふと思ったのだが
自分にとって、理想的な職場って、どんな職場だろう？ 私の場合、こんな会社があると 速攻、駆け込んでしまうかもしれない。 ■理想的な職場（ソフトウェア開発の） 【作業時間は自由】 私はスポーツをやっているせいか、非常に眠い時がある。 そんなとき、必死に眠さと戦うなんて、なんと馬鹿らしいことだろう。 眠さと戦って、苦しい思いをするだけで、仕事なんて全く進まない。 仮に、多少進んだとしても、間違いだらけで 後で間違い探しに時間がとられてしまい 結局、単にマイナスな作業をすることになっているだろう。 そう、眠い時は、サクッと寝よう！！ 但し、変に爆睡すると、睡眠のリズムが狂ってしまい 慢性的な寝不足になってしまうので 長くても、１時間程度で起きるなど対策は必要だが 眠い時は、寝るに限る。 という意味で、作業時間は自由にして欲しい。 【報酬】 報酬は、毎月固定の給料だとつまらないので 最低限の固定給と、成功報酬制度が面白い気がする。 営業が仕事を探してきて、それを自分たちで選び プロジェクトメンバーを集め、採算が取れるように調整し きちんと利益を出せたら、それを成功報酬として受け取る。 こんな制度があったら、燃えてこないだろうか？ 仕事に対して、すごく真剣になれると思うけどどうだろう？ その２へ続く |