2005-04-22 18:37:46

いきなり見知らぬ開発プロジェクトに放り込まれた時の対処法

テーマ:ソフトウェア開発

ソフトウェア開発業界のよくある話として、ひとつのプロジェクトが終わったら、すぐに次のプロジェクトという使われ方をする人が多い。しかも最初から入れるわけではなく、すでに始まっているプロジェクトに途中参加するということも結構ある。

 

 

ソフトウェア開発の現場というのは、ルーチンワークなり、定まった仕事があるわけではなく、猫の手でも借りたいんだけど、簡単な作業があるわけではなくて、新しい人がいきなり入ると構ってもらえないということが多い。そこで、いきなりプロジェクトに放り込まれた場合の対処法について考えたい。

 

 

最初に認識しておかないといけないのは、いきなり放り込まれる時点で、プロジェクトが切羽詰っていると思った方がよいということだ。余裕のあるプロジェクトは人に余裕があるので手伝う必要がないからだ。

 

 

また、実力がわからないうちは誰もかまってくれない。何を任せていいかわからないし、スキルレベルは話を聞いてもよくわからないからだ。といっても、いきなりさらりとプログラムを書いてみせるというのも難しい。目に留めてもらうためには、まずは会話からである。

 

 

例えば、会話の端々に出てくる専門用語をうまくコントロールできるかどうかで、理解度がわかるというものである。当然、わからない用語が出てくると思うが、「ソフトウェア開発業界内での共通用語」と「組織/業務における専門用語」の2種類を区別できていて、前者がうまく扱えていれば、後者は教えてくれるだろう。前者については質問すると素人と思われ、後者については質問しないと素人と思われるので注意が必要だ。

 

 

最初は、仕事が与えられなくて暇かもしれない。しかし、ここで仕事をくれくれとせがむのも考えものだ。タスク割り振りする人は忙しいので、新しく入ってきた人に仕事をくれと言われても仕事の説明をする時間がなかなかとれないからだ。手持ち無沙汰でも、じっと我慢して本を読むなりして相手が暇になるまで待つのも仕事だ。

 

 

暇なら、業務に関係ありそうで、かつ1人でできるものを勝手に作って、評価してもらうのもよい。手当たり次第に今まで書かれたドキュメントを読み込んで、誰に聞かれるまでもなく当初の目的と現在の内容との乖離(ギャップ)を把握してみよう。

 

 

他の人はみな忙しく仕事をしているので、ドキュメントを振り返ったり、仕様に立ち戻ったりということをあまりしていない。一番状況を把握できる立場にいるのである。このチャンスは有効に利用しないといけない。全体を把握して、適切な状況説明ができれば、もう勝ったようなもんである。

 

 

まずは信頼関係を作ること。実力あっても、信頼されていなければ仕事は任せてもらえない。待っているだけではなかなか信頼も獲得できないし、自分の実力も発揮できないということだ。まだスキルが足りなくても、信頼されていれば教えてくれることもあるだろう。

 

 

急にプロジェクトに放り込まれても、慌てず騒がず、落ち着いていれば、それだけで一目おかれるような気もするけれども。生き生きしたソフトウェア開発プロジェクトになるように心がけましょう。

AD
いいね!した人  |  コメント(15)  |  リブログ(0)
2005-04-20 22:05:09

プログラムは分岐と分岐以外の2種類で構成されている

テーマ:ソフトウェア開発

プログラムを勉強する時に、まず最初に行うのが「Hello World」を画面に表示することである。そしてその次に、データの種類、演算子、制御について覚えることになる。あまりに最初に出てくるので無意識的に使っていることが多いと思うが、プログラムは次に進むか、分岐するかのどちらかしかない。例外処理も分岐の1つだ。

一般的に、分岐が多くなればなるほど複雑になるといえるだろう。逆に言うと、分岐以外の部分は経路が1本なので複雑になりようがないのである。スパゲティコードと呼ばれるものは、分岐に分岐が積み重なって、流れが判断できなくなるところに問題がある。分岐と分岐以外を明確に分離したら、プログラムの構造が作る人にも見る人にもわかりやすいのではないか。

 

初心者がプログラムを学ぶ時に難しいと思われることの1つに、複雑になった1つのメソッドを複数のメソッドに分割する方法があまり明確でないということがあげられる。

 

共通なメソッドを切り出すのはわかりやすいが、それ以外にもただ単純に長いから分割せよと言われてもどこで分割していいのかよくわからない。そこで明確な方針として、分岐と分岐以外に分離するというのはどうだろうか。分岐用のメソッドは分岐ロジックだけに思考を集中できるので、少々冗長になるかもしれないが、バグの温床となるのを防ぐ事ができるだろう。

 

また、分岐は全て管理すべきものである。ラクだからという理由でコーディングの段階で勝手に分岐を増やすということは本来ありえない話なのだが、同じメソッドでいろいろなことを処理させようとすると、勝手に分岐が増えていく。そうならないためにも、分岐と分岐以外を明確に分離したほうがよいと思われる。

 

APIだライブラリだという前に、プログラムの構造はどうすれば必要以上に複雑にならないか、ということを考えないといけない。分割統治も分割の仕方を間違えたら意味が無いということだ。どんな高度な言語でも、考え方次第で複雑にもなるし簡単にもなる。MDAだから簡単になるとかは脳みそ思考停止状態である。キーワード1つで複雑さが解消できるわけではないのだから。

 

※ 以前に書いた「IF文を極力減らすと見晴らしのいいプログラムになる」も、この記事の内容と重複している部分がありますので、興味がある方はどうぞ。

AD
いいね!した人  |  コメント(19)  |  リブログ(0)
2005-04-14 00:42:08

検索技術はIT業界で仕事をする上で最初に学ぶべき技術の1つ

テーマ:WEBサービス

一昔前では考えられないくらい、インターネットが発達したため情報量が爆発的に増え、またそれに伴い検索サービスが高度で高速になった。という文句はすでに使い古されている感があるが、仕事の中身は旧時代のままである。

 

なんのことかというと、YahooやGoogleで検索キーワードを入れて欲しい情報を調べようとしているが、誰も検索の仕方についての知識を社内で共有しようとしないため、検索に無駄に時間を使っているのではないかということである。

 

特に新入社員や、新しく入った人に対しての教育では、ぜひ検索に関する技術についてもカリキュラムに含めて頂きたい。1日調査に費やすのと、3分で回答を取得するのとでは大きく異なる。また、インターネットは万能ではないので、当然欲しい情報がない可能性も考えなければならない。どこで見切るのかも1つのポイントである。

 

検索している時間は確かにコストであるが、調査せずに作り後で後悔する可能性もある。なので短い時間で情報が取得できるのであればそれにこしたことはない。そういう意味で昔と仕事の仕方も変わらざるを得ない。なのに、検索技術という大事な部分を各個人任せにしてしまっていては、効率があがるものもあがらない。

 

まぁ探すものが曖昧であれば、検索キーワードも曖昧になるのでなかなか見つからないし、探すものがはっきりしてれば、検索キーワードも絞り込めるので、見つかりやすいというだけのことなのかもしれない。知らないものは探せないし、言葉に出来ないものも探せない。検索の限界を知って、検索する時は目的をもって、すばやく探せるようになれば、仕事もきっと素早く処理できることだろう。

AD
いいね!した人  |  コメント(29)  |  リブログ(0)
2005-04-08 11:40:48

納期と予算はプロジェクト外で決定される。仕様はプロジェクト内で決定できる。

テーマ:ソフトウェア開発

ソフトウェア開発プロジェクトの初期段階は、情報量が圧倒的に少ない中で仕事を進めていかなければならない。これから作り始めるものについての情報は、プロジェクト参加者のそれぞれの頭の中にあるが、全員の共通認識が出来ていることはまずありえない。

 

最悪なのは、誰の頭の中にも完成イメージがなく、「誰かが考えているだろう」と全員が思っているという場合だ。こういう場合は、あの人が大丈夫だと言っているからなんとかなるだろう、という甘い考えの元、わかりやすいところから作り始めて後で泣くという、典型的なアンチパターンである。

 

顧客側が持っているイメージを、開発側に過不足なく伝えるのは難しい。多く伝えすぎると見積もり段階でコストがあがりすぎ、少なく伝えると本当にやりたかったことが出来ない状態で納品される。なので、イメージを紙に最初に落としこめないのであれば、予算ありきでプロジェクトを開始するしかないのである。

 

顧客は予算をどこからともなく捻り出す際に、納期も設定してしまう。投資した予算をいつぐらいまでに回収できるかという目標を立てて、それに伴いプロジェクトスケジュールを決めるからである。納期は予算に紐づいていて、その時点でプロジェクトのライフタイムが決定する。

 

そのような事情から、プロジェクト開始時点では、予算と納期は顧客側により決定されてしまっている。どちらもそれより短く、安くする方向にしか力は働かない。プロジェクトにアサインされた人がコントロールできるのは仕様だけである。プロジェクトの目的は提示されているが、それをどう解釈するかはプロジェクト内部でコントロールできなければおかしい。要求仕様はあくまでも仮のもので、その裏にある真の目的を見定める必要がある。

 

表に出てきている要求仕様をそのまま形にするのではなくて、最終的にどうしたいのかから逆提案して、そっちの方がより目的に適っている、と顧客に納得してもらえれば、すぐに仕様は変わるのである。開発側の特徴というかノウハウというのはその部分である。

 

インターネットに公開されている技術要素を知っているだけでは、顧客になんの影響も与えない。開発コスト削減だけでは顧客は反応しない。顧客の中に入っていって、技術と目的を結びつけて始めて顧客が反応するのである。

 

予算や納期がコントロールできないと嘆くのではなくて、仕様をコントロールすることで予算内、納期内になんとかするのが、プロジェクトマネージメントであると思う。

いいね!した人  |  コメント(0)  |  リブログ(0)
2005-04-02 20:59:41

プログラマはどうやって修行するべきか?

テーマ:ソフトウェア開発

以前ならいざしらず、今の企業は新卒採用も中途採用もどんどん採用基準がいっしょになってきている。採用基準がいっしょということは、その後の待遇も同じということを意味する。極端に言うと、新人教育しなくなるということだ。大手の一部は新人をみっちり研修して囲い込もうとするが、それ以外の企業は即戦力だけを求めるようになっている。


新人教育しないのであれば、プログラムやシステムについての一般的な教養を学ぶ機会は、専門学校や大学に託すということになる。だが大学もコンピュータのエクセルやワードの使い方以上の、システム寄りのことを教える学科は少ないし、専門学校でビジネス系ソフトウェアの作り方のカリキュラムというのはあまり聞いたことがない。


そもそも、大学も専門学校も、教える先生自身がどこまでソフトウェア開発に関わったことがあるのかというと、それほど経験がない場合が多い。だいたい一人でプログラムを組ませて終わりである。あまり仕事向きの教育とはいえない。


さて、企業はもう教育してくれない、という前提にたつと、プログラマになりたい人はどうすればいいのか。OJTという言葉が今でも流行っているらしいが、意味は「職場で仕事しながら自己研鑽してください。でもそんな暇あったら上司の命令を聞いて手を動かしてね」ということなので、職場で違うことするのは無理である。


プログラマがどうやって自分を鍛えるのかというと、やはり会社以外の場所で修行をするしかない。Javaの仕事につきたければ、Javaのプログラムを自分で書いて修行するしかないのである。転職する時、次の派遣先に行く時に、自分のスキルシートにどう書いてあれば相手の企業に受け入れてもらえるか、を逆算して修行に励むのだ。


修行の基本は時間の確保である。時間がないと何もできないので、どうやって時間を確保するかをまず考えないといけない。そう考えると残業でずっと張り付きという状況はなによりもまずいのである。時間さえ確保してしまえば、修行自体はどういうやり方でも構わない。自分で全部やるもよし、他人を巻き込むもよし、オープンソースコミュニティに参加するもよし、別の仕事を自分で受けるもよしである。


修行の目的は、ソフトウェアを完成させること、ではない。あくまでもそれは副次的な要素である。一番重要なのは、新しいことに挑戦して、できるだけ多くの失敗をすることである。新しいことをやって失敗せずにソフトウェアが完成したとしたら、何も新しい発見がないということである。発見は失敗からしか生まれない。失敗するというのは、思ったことをやってみたらうまくいかなかったということだ。これを繰り返すことで、その技術についての限界や特徴が掴めるのである。


会社が教えてくれないから、いつまでたってもスキルがあがらないと嘆いていても始まらない。自分で修行した分だけ将来的に返ってくると考えて、修行に励むのがこれからのプログラマとしての生き方のように思う。人材不足→時間不足→負担増→人が辞める→人材不足・・の悪循環は、企業が解消するしかないのだが・・。

いいね!した人  |  コメント(1)  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。