言葉が導く誤ったイメージ

2012/04/27 17:00:00

 IT 業界では、「上流」や「下流」と言った言葉で表す工程があります。上流工程では要件定義などを行い、下流工程では実装やテストを行うといった感じで用いられることが多いのですが、これらの言葉には、誤ったイメージが今もつきまとっているように思えます。

 その最たるものが「上流工程は、能力的に優れている人間が担当する」というところではないでしょうか。

 もともと、これらの言葉は、ウォーターフォールモデルにおける工程を踏まえた形で用いられています。作業工程には順番があり、先に行う必要のある要件定義や基本設計などを「上流」とし、プロジェクトの後半に行われる実装作業やテストを「下流」と表すものです。ここまでは特に誤りはなく、適した表現だと思います。ですが、ここに「SEはプログラマの上級職」という間違った思想がまじることで、おかしなイメージをつきまとわせているのではないでしょうか。

 過去のコラムでも少し書きましたが、プログラマが育つことでSEになる、という考え方自体を私は賛同していません。

 なれるかもしれないし、なれないかもしれない、その人その人の特性がプログラマに適しているかSEに適しているかが重要な点であり、一般社員がある程度年数を務めて主任などの職位に上がるようなものとは、位置づけが異なるのだと思います。

 プログラマに求められる能力とSEに求められる能力は別物で、どちらが上でどちらが下、という考え方自体が根本的に間違っています。今の時代、プログラムができないSEは非常にたくさん存在しますし、SEもできるプログラマも同じくらいたくさん存在します。

 携わる案件の規模にも影響しますが、小規模なプロジェクトではSEもプログラマもあまり分けずに開発を行う場合も多々あります。他にも商売上の理由でSEと記述することもあります。このような状況を見ると、そもそもプログラマとSEを分けて考えること自体が不毛で、すべてをひっくるめた形として「エンジニア」で統一してしまってもいいのではないか、とも思います。

 そうなると、難しくなるのが「評価」です。現在はプログラマやSEといった職種をある種の職位としても考え、プログラマなら単価はこれぐらい、SEなら単価はもう少し乗せて、というようにされている企業が多いのではないか、と思います。

 この方法に近い形で、内部での評価も行われている場合が多いです。プログラマなので給与はこのぐらい、SE になったのでもう少し給料を上げる、などです。人材の適切な評価は非常に難しい問題なので、言うは易し行うは難し、そのものです。しかし、現在、多くの企業で用いられているこの方法は、能力に基づいたものではなくそれ以外の要素で評価を行っている、というのは疑う余地がないのではないでしょうか。年功序列な思想を否定するわけではありませんが、それに見合う実力を発揮されないのであれば、疑問を抱かざるを得ません。

 年齢を重ね、多くの経験を積んできたのだからSE としての作業ができるか? と言われれば「必ずしもそうではない」、経験を重ねた人の方針に従えば大丈夫か? と聞かれても「必ずしもそうではない」となります。年齢も経験も、すべてのケースに有用に作用するかどうかは良違いには言いきれません。

 しかし、年齢や経験に過剰な期待や信頼を寄せてしまうことは、どうしても避けられないでしょう。確率的に考えると、よほど目新しいことを行わないのであれば、今までの経験を有用に生かすことができるはず、と考えることが多く、事実それらはあまり間違ってはいないことが多いです。だからといって、本当にイメージしたどおり経験の高い人が属しているので安定した開発を行えるかとなると、まったくもってそうではないケースが増えてきているようです。

 このように考えていくと、「上流工程を担当する人は能力が優れている」という考え方は実態を正しく表していないことが分かると思います。

 上流工程を行う人は、概要レベルから考え、システムの基本設計として落とし込む、そのような分野に秀でた人、であるはずなのです。「はず」と濁った言い方をしなくてはならないのは心苦しいですが、残念ながらそのようなケースは数多くあります。この問題を良い方向に進めるためには、ユーザー側から今よりもっと多く指摘をしてもらう必要があるのではないか、と思うほどです。外部からの圧力は、改善を進めるために非常に効果的です。問題がないのに圧力をかけるのは感心できませんが、あまりに問題と思える場合には、ぜひとも圧力をかけていただきたいものです。

 言葉から受ける誤ったイメージは、他にもいろいろあると思います。イメージに惑わされず、常に考え、本質を見誤らないようにしていきたいものです。

 今回は、よく話題に上る上流・下流を例にしましたが、他にも同じように惑わされる言葉というのが、いたるところに潜んでいるので、注意が必要です。自分で調べてみる、自分で考えてみる姿勢は、これからますます重要になるのではないでしょうか。
 

最も大切なコミュニケーション

2012/03/30 9:00:00

 SkypeやLINEなどのツールが有名になり、コミュニケーションの世界もゆっくりとした変化が見えるようになりました。メールやチャット、メッセンジャーも含め、今では多くのコミュニケーションツールが存在しています。これらを公私問わず利用されている方がほとんどではないでしょうか。

 ここまで発達する間に利用されていたツールと言えば、郵便・電話やFAXであったと思います。先ほどのようなツール類が多く登場してきてはいますが、今でも利用されている割合は多く主要なコミュニケーションツールであることは間違いありません。

 このように多くのツールが登場してきているにもかかわらず、私たちはコミュニケーション上で多くの問題を起こしています。文章表現で誤解を招いたり、言葉のあやで相手に不快な思いをさせる事などは時代を問わず発生しています。これらはツールでは解決できない部分であり、ツール類が進化したために難しくなっている部分なのではないでしょうか。

 もともとコミュニケーションの基本は、実際に対面して言葉を交わすことにあると思います。相手と向き合い、その表情を見て、言葉を聞いて、雰囲気を感じ取るものでしょう。非常に多くの情報がコミュニケーションを成り立たせるために必要であったと思います。頭では意識していないだけで、視覚・聴覚などから得る情報を基に、さまざまな思考や感情を組み立てています。
 ツール類の登場により、その場に居合わせなくともコミュニケーションがとれる時代にはなりました。ですが、直接会って話す事と比較すると、どうしても得られる情報の欠落が発生します。電話であれば相手の表情など目に見える部分であったり、メールであればさらに加えて声質など耳から得られる情報であったりと、言葉を交わすことはできるけどそれ以外の要素を失うことになります。これら失われた情報が存在するために、本来向き合って会話していれば発生しなかった問題が発生してしまうのだと思います。

 そのあたりを考慮すると、どこまで実際に会っている状況に近づけるかどうか、がコミュニケーションツールとして重要な指針になってくるのではないでしょうか。恐らくは同じような考えの基に、テレビ電話やテレビ会議システムなど、映像と音声を扱うツールが出てきたのではないかと思います。確かにこれらツールは非常に便利で、場所を問わないコミュニケーション手段として非常に重宝されますし、活用されているところも多いでしょう。互いに離れた場所にいながらも、近くにいるようなコミュニケーションが取れるというのはものすごく大きなメリットです。

 しかし、どれだけツールが発展しても最も効果的なコミュニケーションは「実際に会う」事なのは否定しようのないところです。

 散々ややこしい状況に陥っていたとしても、実際に会って話をすることで無事解決、という話も少なくありません。便利だからといってツール類に頼り切ってしまうのではなく、時には基本に立ち返ったコミュニケーションをとることでよりスムーズに物事が運んだり、新しいつながりが生まれたりするのだと思います。

 今は非常に便利な世の中ですので、遠隔地で行われているイベントであってもUstreamなどで中継が行われたりしますので、実際に現地に行けなくとも参加できるようになりました。ですが、やはり可能であるならその現場にいることこそが、最も高質なコミュニケーションなのではないでしょうか。

 「電話でいいや」「メールでいいや」と言わずに、直接会って話をしてみると、自分にとっても相手にとってもプラスとなる事が多いのではないでしょうか。自戒の意味も含め、できるだけそのような場を増やしていくよう行動していきたいものです。

後手後手となるソフト屋に未来はあるか

2012/02/29 9:00:00

 開発業務に長い間携わっていると、何かしらの問題が発生した際、その時点で対応せず後で対応しようとすることがあると思います。その理由はさまざまで、時間や予算の都合から、単純に技術レベルの問題まで、多種多様です。しかしその中で、私が違和感を覚える問題として「WIndows 7(Vista や Windows Server 2008 を含む)対応」があります。

 この問題は、今利用している・取り扱っているアプリケーションがそのままでは Windows 7などの新し目のOSに対応せず、利用できない、あるいは何かしらの問題が発生するというものです。対応としては、Windows 7のXP Mode利用や、OSのダウングレード権を利用するという方法があり、アプリケーションの改修を行わずに新規OSを利用する形を採っている企業はそれなりにあるかと思います。特に最近では、仮想化環境を利用して古いOSを自己責任の下で利用し続けるという手段も増えてきているようです。

 これの何が問題と感じているかというと、「Windows 7などの新しいOSが世の中に登場してかなりの年月が過ぎているというのに、いまだ持って対応が行われていないアプリケーションが存在する」という点です。

 世の中に Windows 7が登場したのは2009年9月です。Vista であれば 2006年11 月、Windows Server 2008 は2008年2月と、どれも登場してから2年以上の時間が過ぎています。これぐらいの時間があれば、アプリケーションを新しいOSに対応させることにほとんど問題はありません。ですが世の中に存在するアプリケーションでは未対応のものがかなり残っています。

 Windows XPのサポート期間もあと約2年、2014年4月に終了します。このころには Windows 8が恐らく登場しており、Windows XPは4世代前のOSとなります。このタイミングでアプリケーションの対応が行われているならば、まだどうにかなるでしょう。

 ですが、残されている時間と今まで過ぎた時間、どちらが長い時間であったかというと、今までに過ぎた時間の方が長いのです。その長い時間を過ごしていても、対応が行われなかった物が、残り時間の中で対応されるかというと、あまり期待できるものではないでしょう。

 私はこの問題について、「開発側の体質・風土的な要素が原因となっているのではないか」と思います。もともと対応できる企業であれば、ここに至るまでに対応は行っているはずです。しかし対応できていないということは、「対応する技術がない」か「対応する考えがない」となるのではないでしょうか。

 後者であれば、現行アプリケーションに変わる別のアプリケーションを用意するなど、違う方向での対応が行えます。しかし前者のような企業では、何かしらの理由をつけて対応を先延ばしにし、そのまま時間切れとなった際でも後継アプリケーションを用意しないなど、購入・利用してくれているユーザーに対して不利益を与えることも十分あり得ます。

 同じ業界にいる人間として、きれいごとと言われるかも知れませんが、このような対応を開発側が採ってはいけないと思います。できるのであれば、このような企業が1つでも減っていく事こそ、これからの業界が発展するために必要な事とまで感じます。淘汰とかではなく、良い意味で切磋琢磨することが、さらなる進歩に必要なのではないでしょうか。

 もしこの文章を読まれているユーザーが、新しいOSになかなか対応されないアプリケーションを利用しているのであれば、一度その理由を問い合わせてみるのも良いでしょう。その時、どのような答えを返すかにより、今後の付き合い方を考え直す必要があるかもしれません。

 はっきりとした答えを言わず、どこか煙に巻くことばかり言うのであれば、要注意です。その企業には、対応に必要な「予算」や「人材」などが不足しており、どうにもできなくなっている可能性があります。

 また同じ開発側の立場で、話に出た対応されていないアプリケーションを抱えているのであれば。すぐにでも何らかの方針を打ち出すことが必要だと思います。

 もう少し後で、というのはもうあってはいけないのです。それはめぐりめぐって自分達の身に降りかかってくることになります。その時に慌てることがないよう、少しずつでも何か行動することが必要なのではないでしょうか。

大は小を兼ねない

2012/01/31 9:00:00

 Windows 8が来月にはベータ版が提供されるかも、という話が流れており、新しい物が続々と目に付くようになってきたと思います。Apple関係ではiPad3が登場すると言われ、AndroidはAndroid 4.0搭載モデルが続々と販売されてきています。Windows Phoneは残念ながら日本においてそれほど活発ではありませんが、海外では新機種の登場などこちらも多くのニュースが飛び交っています。

 この流れを見ていると、徐々にではありますが入力デバイスがタッチ式へと切り替わっているのではないかと感じています。

 タッチ式のデバイスは、登場してから結構な年月が過ぎていますが、銀行のATM や、iPhoneといった個人所有のデバイスなど、場所を限定した状況でしかなかなか目に触れることはありませんでした。しかし、今では個人所有のデバイスはほとんどがタッチ式デバイスで、タッチできないものの方が珍しい状態です。携帯型ゲーム機である Nintendo 3DSやPlayStation Vitaでもタッチ入力が当然であり、その機能を生かしたソフトが増え始めています。

 しかし、業務の世界では、まだまだ活用されていないのが実態です。これは今までの歴史的経緯も関連しますが、まだまだキーボードが主流なのではないでしょうか。

 個人的な考えとしてキーボードを否定するわけではありません。ただキーボードに囚われすぎているのではないか、という危惧はあります。タッチ式デバイスが登場した時は、「わざわざタッチして入力するのが面倒」といった感想を持った方が多いのではないでしょうか。ですが今やタッチ式の方がスムーズに入力することができるよう、ソフト的な工夫も含めて環境が整備されています。

 このような状況になっている今でも、業務システムではキーボード以外に入力を行いやすいデバイスが普及していません。せいぜいバーコードスキャナなどです。それ以外にも RFID 等の「手入力する必要のない仕組み」が登場していますが、まだまだ導入するにはある程度以上の体力(資金力)が必要です。

 このように、業務の世界とそれ以外とでは、状況にかなり差が出てきています。過去を振り返ると、個人向けと業務向けでは、業務向けの方が先進的な物が多く、個人向けは極論すると「お遊び」と酷評する人もいるほどでした。ですがこの図式は現在において逆転していないでしょうか。
 一部の企業を除き、個人向けの方がより先進的に技術や仕組みを取り入れ、企業向けはどちらかというと保守的に危険を冒さないようゆっくりと進もうとしているように見えます。そのような基本姿勢の違いもあり、進歩する速度がものすごく速くなった最近では、個人向けと企業向けとの間にかなりの差が開いてしまっているのではないか、と感じます。

 IT業界に関わる1人の人間として、このあたりは非常に良くない兆候だと思います。本来であれば、個人用・業務用区別なく「適しているものを利用する」というのがあるべき姿勢なのではないでしょうか。それが業務用となると「規模が大きい」「時間がかかる」と言われ、ほんの少しでも手をかけない、というケースが非常に多いです。それが積み重なって、気が付いた時にはかなり取り残されている、という状況に陥っているのではないでしょうか。

 このあたりは開発を請け負う私たちにも、一因があると考えています。私たちも商売なので、より大きい売上やより大きい粗利を求める活動がどうしても大きくなります。受注できること自体は非常にありがたい話で、同じ受注であればより大きい金額を扱いたくなるのは、企業としてもある種当然の姿勢です。

 しかし、今のご時世を踏まえると、これまでに行ってきた「ある程度まとめて」の受発注よりも、「小出しに少しずつ」改善を行っていく形の受発注であることの方がメリットは大きいのではないかと思います。

 大きな改善はそれだけ失敗する確率が高くなり、投資した金額にそぐわない結果も発生しやすくなります。反面、小さく改善を行うことは失敗したとしてもまだ回復の余地があるかもしれませんし、完全に失敗だとしても、被害はそこまでの深手ではありません。

 なにより少しずつ改善を行う方法であれば、今よりもスピーディーに行動できる点が、大きく改善するよりも優れている点ではないでしょうか。大きく改善しなくてはならない場合も必ず存在していますが、その前に少しずつでも変化していくことがもっと重要なのではないでしょうか。

 最低限の必要な部分に改善する範囲を絞り込むことは、リスクを減らし、かかる負担も減らします。そして、これは開発だけに留まらず、すべての行為においても共通したものなのかもしれない、そう私は思います。

 タッチ式デバイスを少しずつ取り入れてみることで、それをきっかけにして、さらに改善できる点が思いつくかもしれません。「こうでないとならない」と思っていた部分が、実は違う方法を採用するとさらに便利になることだって十分あり得るのです。まったく違う業界の話題が新たなアイデアにつながることもさほど珍しくはありません。

 私のように提案する側も利用してもらうユーザー側も同じように、少しずつの改善を行うようやり方を変えていくのが、今現在から今後につながるベターな方法の1つなのではないでしょうか。私はこのあたりをよくよく考えながら過ごしていきたいと考えています。

金額と人月、そして価値

2011/12/28 17:30:00

 私のようなエンジニアは、仕事としてアプリケーションの作成やシステムの作成・提供を行っています。受託開発やパッケージの提供などをユーザーに対して行い、対価としてある程度の金銭をいただいているのですが、近年その姿に対して少々違和感を感じるようになってきました。

 もちろん私はできた人間には程遠いので、「金銭を頂く事自体に抵抗がある」とかそのような類ではなく、提供しているシステムに見合った価格なのか、という点において感じています。

 一般的に何らかの物を販売をする、となるとその価格というのはかなり複雑に考えて決められています。どれだけの量を販売するか、どれだけのリソースを利用するか、どのくらいの期間をかけて行うかなどなど、まさしく多様に富む要素を用いて考えられていると思います。ですが、自分が行っているようなシステム、特に受託開発な面においては基本的に「かかる時間」を主たる要因として金額が決定されているのではないでしょうか。俗に言う「1人月いくら」という世界です。

 これが店舗販売では、先ほどの一般的な例に倣った形になりますので単純な「1人月いくら」な世界での価格決定はありません。では何故受託開発においては、このような物差しを用いる事が当然となってしまったのでしょうか。

 私はこの業界で働くようになってせいぜい十数年なので、それ以前の流れというのはよく分かっていません。ただ、そこに至るまではいろいろと苦労があったのではないかと想像はできます。ご存じの通りエンジニアが行う作業というのは、定量化が行えるような類ではありません。その中でも見積を行い、発注してもらい、売上を立て、利益を得るためにはどうしても何らかの指標が必要なのは間違いありません。

 このような状況下で考えられた「人月」という算出方式は、実際のところ非常に簡略化されており、ユーザー・ベンダ双方にとって「なんとなく」イメージしやすいものであると思います。ここで重要だと感じているのが「なんとなく」という点です。

 本来であればシステムやソフトウェアの価値に対して金額を決める、または決めてもらうというのがあるべき姿なのだとは思います。ですが、実際にそのソフトウェアやシステムがどの程度の価値なのか、質問されて答えられたにしてもその幅は物凄く広くなってしまうのではないでしょうか。ある物に対しての価値観は、それこそ人によって異なってしまいます。そうなるとどうしてもある種の体力勝負的な世界になり、価格が勝負の主軸であり価値は二の次、に陥りやすくなるかとも考えてしまいます。それを防ぐためにも何らかの指針は必要です。そこで作られたのが「人月」という仕組みなのだと思います。

 この人月については多くの問題点が指摘されていますが、これに変わる方式で一般に浸透しているものは殆ど見受けられません。その理由もさまざまで、経営側で適正な価格を導出するのは非常に難しいという点もありますし、社員の技術力に対して適正な単価を設定することが難しいという点もあります。また、仮に価格を適正に決められたとして、それが買う側に対してアピールできるものであるとは限りません。買う側にとってみれば、開発に関わる技術者の単価はあまり関心がなく、結果として提供されるシステムの価格が重要であるからです。

 物の価値というのは大変難しいものだと思います。作る側の価値観と使う側の価値観というのは、ほとんどが一致しないものです。ですが一般に販売されるあらゆる物を見回すと、ITシステムだけがかなり特殊な金額付けを行っているのではないでしょうか。

 価値ではなく作業量に対しての金額付けを行っている状況を踏まえると、金額以上の価値を提供できている事例はかなり少数なのではないか、とも感じます。

 使う側としては価値に対して金額を払う流れになることで受けるメリットは増える事と思うので、現状の作業量に対しての金額付けは、あまり歓迎されないでしょう。反対に、作る側としては、作業量以上の価値を生み出すことはそうそう簡単にできるものではありませんので、価値に対する金額付けはほぼ行わないでしょう。

 現状はこのように互いの思惑もあり、膠着状態のようになっているのだと考えます。ここで「なんとなく」互いに通じるものとして人月が存在しているのではないかと私は思います。あくまでも「なんとなく」ですが。

 ただし「なんとなく」であろうとも互いに通じるものさしがある価値は大きく、大半の商談においては人月が最も使われているのはこれの表れではないでしょうか。

 ここまで金銭面から人月について考えてみましたが、この問題はさらに多くの要素が関連していきます。価値に対しての金額設定を行う場合には、技術者に対してある程度実態に見合った評価が行える必要があります。そこに切り込もうとすると、恐らく価値を生み出せる一部の人達、高い生産性で作業が行える人達が残り、今いる半分以上のエンジニアは、今よりも低い評価が行われるのではないでしょうか。

 競争と言う面ではまったくもって正しい姿ですが、それは必ずしも幸せな結果を生み出すとは限りません。むしろ厳しい結果が待ち受けています。恐らく経営層としては、技術者に際限なく高い能力を持つことを推奨しますが、そこについていくことができる人は一握りです。そうなると、支払われる報酬は「期待する水準を満たしていない」という理由のもとにさらに減少する事が予想されます。すると技術者は徐々にこの世界から去り、高レベルな人達だけが残ることになると思われます。これを良しとするか否かは、いろいろな考え方があるかと思います。

 突き詰めると人月の問題というのは、開発側が提供する価値に対してどのような金額的価値を認めるか、という点に纏められるのではないでしょうか。相手ありきの商売ですので、開発側だけの都合でどうこうできるものとは言いがたいですし、使う側だけの都合というわけにもいかないでしょう。ただ、互いにこのままでは良くないという気持ちを持たれている割合が大きいと思いますので、この問題への対応は長い時間をかけて、ゆっくりと変化していくのではないかと私は思います。

 ただ、急激な変化がないとは言い切れないのはいつもの通りですので、そうなった時にも困らないよう、提供できる価値を高める行動というのは常に心掛けていきたいものです。

@IT Special 注目企業
@IT Special ラーニング

エンジニアライフ 最新の投稿コラム

@IT自分戦略研究所 新着記事

エンジニアライフ スポンサー

コラムニスト プロフィール

Ahf
「試される大地」で働くエンジニア。
貪欲に前へ進もうとやみくもに生きています。

2012年5月

    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

バックナンバー

月間バックナンバー

検索

Powered by TypePad
- PR -
@IT Special 注目企業
インデックス

@IT Special ラーニング