イトウ アスカ blog 2007年5月17日 「プログラマーの次のキャリアパスがSEだとばかり考えている人はプログラミングをなめている

 結構ある話ですが、プログラマーはキャリアをつむとSEになるということがよくあります。そのSEってなんなのかイマイチ判然としなかったりもするのですが、少なくともプログラマーが下でSEが上というのはあらゆる面(職場の立場、給料)で言えることは間違いないです。

ドキっとするなあ。「SEとは何ぞや?」

たぶん、ソフトウェア開発業界の根深いテーマである。自分の知る限りでも、似たような状況。なぜプログラマは「いわゆるSE」と比較して冷遇されがちなんだろうか?

ここから先の話は自分の経験にもとづく話である。
よって、世の中一般に通じる話かどうかはわからない。しかしながら、概ね心当たりのある人は多いと思う。

極端な話、数々のPMをやって、多くの「人の使い方による失敗」を経験した立場から言うと、月に200万円出しても使いたいプログラマはいるし、20万円/月ですら払いたくないSEもいる。(まあ究極的にはビタ一文払いたくないケースもままあるわけだが)

そもそも、「上流工程」を行う役割になればなるほど高くなる理屈も、つきつめて良く考えていくとおかしい気がする。

要件の内容によっては、50万円/月のSEがやる仕事だって、300万円/月のプログラマがやる仕事だって、もっと言えば、30万円/月のコンサルがやる仕事だって、あるんじゃないの?

つまり、発注者が抱えている課題(要件)がどんな種類・範囲・水準・内容であるか、によって、必要なスキルや担ってほしい役割は変わってくるはずだし、必要スキルや必要役割によって、コンサル、SE、プログラマといった職種に関わらず、価値が変わってくるはずだ。

しかしながら、現実には、「7月からSE5名、9月からPG10名」といったレベルの技術者募集がまかり通っている。

何の仕事なのか、何をしてほしいのか、どういう条件なのか、予算はいくらなのか、発注者が提示し、その条件にあった候補者を集め、実際に会って話すことにより真偽を確かめる、それが普通なのだが、なぜかそうなっていないことが多いのである。

原因の1つは、慢性的な人材不足というのが影響していると考えている。募集の時点でいろいろ細かい条件を提示してしまうと、応募の間口が狭くなる。必然的に、人の集まり方が悪くなる。

このあたりは、「明日の自分を創る」でふれた人月ビジネスという悪しき形態がまねく悲劇の1つだろう。

もう1つの原因として、昨今、発注時には必ず3社以上に声をかけるだとか、そんな慣習が大手になればなるほど暗黙裡に実施されている。2次請、3次請は当たり前のITゼネコンピラミッドにおいて、階段上にいる各プレイヤーがそれぞれ3社に依頼を出したとすると、末端においては20社以上に声がかかっていることもある。

この結果、著しい量の仕事の引き合い情報が市場をかけまわる。結果、「仕事の依頼”だけ”は黙っていても腐るほど来る」という状況が生まれる。そして、1つ1つの依頼に対する力の入れ具合、期待度は相対的に低くなり、候補者探しのための営みは限りなく省力化・短絡化され、やっつけ仕事になっていく。

こうしたことが積み重なって、結果として「7月からSE5名、9月からPG10名」といったレベルの話が蔓延する。

結局のところ、人月ビジネスという「ぬるま湯」に漬かっていること、および1つ1つの取引依頼への対応を「やっつけ仕事」にしてしまっている我々の姿勢が、問題解決をできなくしてしまっているのだろうと痛感する。

ホームページを作る人のネタ帳PHPが出来るという事で採用した新人は、PRINTの時点でもうわからない

彼らがつまずいていたところは、for文とif文を徹底的に教えてみてはどうかと提案した。
なぜなら、printはそういった一つの流れがあって始めて意味を成すものであって、単独でprintする意味というのは確かに理解できない部分もあるからです。

そこで気が付いたんですが、ホームページを作るというスキルが全くない人は、実はprintでつまずく事も無いんです。
彼らがprintを受け入れられない理由はそこにあったのではないかと思う。

感覚的には同感。面談で「PHP出来ます」という言葉をチェックせずに信じた時点で採用側の負けだとは思うが、程度の差こそあれ、昨今似たような境遇に陥ることはよくある。

しかし、こうした人のばあい、ifやfor以前に、まずそもそもプログラムが何故必要か?何のためにプログラムつくるの?ってところから教えるべきなのかも知れない。

事例にあがっている< ?php print "こんにちは";?>ってのは、C言語でいえばK&Rの有名な”Hello, world.”のノリだけど、要するにこれすなわち、プログラムとはなんぞや?ということは知っている前提で成り立つ「事始め」であるということか。

やっぱプログラミング初心者に対していきなりWeb系プログラミングってのは敷居が高いよ。まずはstdin/outを使った処理系でソートや検索のアルゴリズムから教えるのが良いと思う。急がば回れ。

ライブドアの新blogサービス「nowa」にご招待されたので、使ってみた

半年間で50万件の開設見込む、ライブドアの新ブログ「nowa」が5月末に正式スタート(CNET Japan 2007.5.8)

 ライブドアがこれまで提供してきた「livedoor Blog」は中・上級者向けの高機能なサービスという位置づけだが、nowaはライトユーザー向けに機能性よりもシンプルな操作性を重視しているという。

mixiとblogの中間+Twitterみたいな感じですね。

mixiほど濃密じゃないけど、blogよりは荒野を歩いている感もない。

どっちかというと新しいものにパッと反応する進んだ人達向けというよりは、その後ろを走っているもっと多くの人達をターゲットにしてそうな雰囲気。UI的にも。縦アイコンメニューが分かりやすいし、全体的にごちゃごちゃ感がなくていい。

昨今、星の数ほど出ているAPIサービスをマッシュアップしまくった結果、何がしたい画面なんだろう?っていうのがわかんなくなって、ごちゃごちゃになっていくサイトが多いと思うので。(マッシュアップ中毒みたいな)

あと、仮想通貨(ポイント)の使い方は、SLっぽい流動性がありつつ、モチベーションにもつながるし、無差別書き込み抑止にもなっていて、良い仕組みだな~と感じた。

今後SBMが加われば、よりALLinONE度合いが高まり良いと思ったりするが、ぜひ「ごちゃごちゃ感」を感じさせない洗練されたUIを維持し続けてくれそうなライブドアに勝手に期待!

いま間借りしているレンタルサーバXREA.COMでも、PEARを使いたい。
ってことで、インストールを試みた。

うるめねっと技研 – Linux派 –」というところで先人の知恵が入手できる。感謝。

実際、ほぼ書いてあるとおりにすればインストール完了。
1点、びびったのは、index.php というのがインストールディレクトリにあると上書きされる。自分の場合は本blogの index.php がモロ上書きされる場所にあったため、go-pear.cgi でインストールされる index.php は pear.php と名前をインストール画面で変えておく。

go-pear.cgiの実行の様子
go-pear_1 go-pear_2

次に、index.php(自分の場合はpear.php)を呼び出して、個々のPackageをインストールする。先人の教え通り、依存関係が解決できずちょっとウザイが、まあそんなに依存が深いのも多くなさそうなので地道にPackage検索&インストールを繰り返す。

PEAR::Package::MDB2のインストールは、こんな感じ
go-pear_6

とりあえず必要なPackageをインストールしたら、PEARのディレクトリ書き込み権限を外すのを忘れずに行う。

Packageインストール完了後に、戻るアンカーをクリックすると以下のエラーが。array_walk_recursive()が未定義ですか。
そっか、これPHP5用だった。自分のサーバは何も考えずに動かすとPHP4になるんだった。

Fatal error: Call to undefined function: array_walk_recursive() in /virtual/ookawara01/public_html/PEAR/PEAR/Frontend/Web.php on line 850

でも問題の箇所のソースを見ると「Package詳細情報出力」らしいし、メニュー押せば戻るのでとりあえず放置。

MDB2のお試しソースをアップして動かす。あれ?あっさり動いた。PEARのパスを指定していないのにどうやって動いたんだろう。
・・・もしかしてPEAR::Package::MDB2は既に入っているのか?
・・・うーん、じゃ試しに、たぶんデフォルトで入れたりはしないであろうPEAR::Package::Image_Graphのサンプルソースをアップして呼び出すと・・・やっぱり未定義エラー。

で、PHPソース先頭に、
set_include_path('/virtual/ookawara01/public_html/PEAR'.PATH_SEPARATOR.get_include_path());
してやると、動いた。(Fontがないと怒られたのでそこのソースはコメントにしたけど)

ということは・・・PEAR::Package::MDB2はやっぱりデフォルトインストールされてるの?
stableなPackageはインストール済とかいうオチか?

まあいいや。どうせ自分で入れたほうを使う予定だし、そのうち調べよう。

Posted in PHP.

「情報サービス産業に明日がなくても構わない from 雑種路線でいこう by mkusunok(2007.5.13)」

情報サービス産業に対しては,人月単価ベースのビジネスモデルがいけない,エンジニアを使い捨てている,高い単価でオフショアとどう戦うのか,とかいろいろなことがいわれているし,どっかに活路がないものかなとここ数年いろいろ調べたりもしたのだけれども,最近ふと別に情報サービス産業に明日がなくても構わないじゃないか,と考えるようになった.

 う、痛いところを突かれまくり。

 自分が今まさに「人月単価のビジネスモデル」を数百名規模で実践する仕事をやってるだけに。

 ここでいう情報サービス産業って、どっからどこまで?という漠然とした疑問は感じるものの、それはさておいて、その情報サービス産業っていう概念のなかにきっと含まれているであろう我々の商売が、人月という単位を媒介してしか商取引を語れない状態にあるとしたら、それはやっぱり問題なんだろう。

 これは、つまるところ、顧客と我々の距離感、立ち位置の問題なんだろうか。

 我々は、あくまで顧客のビジネスプロジェクトにおける一要素でしかなかったシステム開発というものを、独立した仕事・プロジェクトにしてブラックボックス化することによって、そこから利益を搾り取っている。

 そして顧客自身も「コンピュータは訳の分からない難しいもの」として思考停止状態になり、本来は顧客自身が考えるべき領域までまとめて、あるいは酷いときには、ビジネス目的すら満足に考えきらずに、目的そのものをシステム化にすり替え、我々に丸投げしてきた。

 こういったことが、少なくとも数年前までは、幅を利かせてきた(少なくとも自分の周りでは)。

 しかし多くの人が気づいているように、インターネット、オープンソース、Web、SaaSといった一連の潮流が、我々に「丸投げ」しなくても顧客自身がITを活用していける状況を創り上げた。

 ビジネスという「目的」と、システム開発という「手段」の隙間は、昔と違って、もう殆ど塞がっているのに、それに気づいていない(ふりをしている)顧客と我々。そして、強引に隙間を作っていくための道具として人月ビジネスというものが使われているのではあるまいか?

 単純に、人月を増やす方向にシステム屋のインセンティブが働くことも問題だ。無駄な機能を増やすことに(お金さえ確保できれば)あまり罪悪を感じない。そして、人月の差額で儲けるために、人材コストを削る。

 新技術の習得やスキルアップなどの生産性向上の結果として工数削減ならばまだよいのだろうが、技術者の質を落とすっていうのは、仕事の完成品質を落とすことのみならず、出来ない技術者が「だましだまし仕事をもらって食っていける」状況を作ってしまうことにつながり、問題だ。

 うーん、まとまらなくなってきた。とにかく、会社も個人も、立ち位置を改める必要があるような気はする。少なくとも、目指す立ち位置としては、

  1. より顧客側へ:ITを駆使した、ビジネス自体の立ち上げ、運営、拡大、に寄与できるような能力(コンサル+企画+開発+事業化)をつける
  2. より我々自身側へ:あくまで道具屋として生き、しかし、より使いやすい道具創りにいそしむ
  3. 新たなプレイヤーへ:自身でサービスを立ち上げ、運営する
  4. モラトリアム:そうは言ってもすぐには変われないし暫くは現状維持改善で頑張る

 というようなパターンが考えられる。

 会社という単位で考えたら「新たなプレイヤーへ」っていうのは一番選ばれる確率が低そうだけど、個人で考えたら、やっぱりmkusunokさんがいっているように「新たなプレイヤーへ」っていうのが楽しそうだ。
 または現実を考えると「より顧客側へ」か。

 結局は、なかにいる人のそれぞれが選択した結果として、今の状況がある。

 だから、状況を変えるには1人1人がそれぞれの制約のなかで「新たなプレイヤー」を目指し、そのうちそうした人達のなかから出てくる成功者達が、主要なロールモデル(収入面なども含めて)として認知されれば、徐々に変わっていくだろう。

 技術者個人と、ビジネスをしようとしている人(顧客)が、一致するか、限りなく近い位置でコミュニケーションをとれるようになれば、人月ビジネスに隠れて結果的に成果以上のコストを食ってしまう人材の淘汰にもつながるのではないか。

 というわけで、最後は「要は中間のオブラートおよび搾取をやめるべし」的な凡庸な話になったけど、稚拙ながら、自らその状態を目指して日々前進する次第。