2008【EC開発体験記-人財-】あなたはSuperになるべきだ何をやるにしても一番重要なのは「人」だ。どれだけ優秀な人材がいるかによってプロジェクトの成否が決まる。優秀な技術者がキーマンでいればプロジェクトは成功し、いなければ失敗する。IT業界で開発プロジェクトを経験した人は皆同じことを感じているだろう。成功したプロジェクトには、必ずといっていいほど天才的なプログラマーがいて、その人がキーマンとなって開発をすすめている場合が多い。大きなプロジェクトでも、全体の80%~90%を数人だけで担当していることもめずらしくない。これはいつの時代でもそんな感じのようである。すばらしい人材の有無によってプロジェクトの命運が分かれることは間違いない。今回のプロジェクトでは、特に優秀な人材をどれだけ集められるかということに、かなりの神経を使った。これはとても大変なことだった。優秀な人材はまずいないし、いても非常に忙しくて、とても参加できそうにない。IT業界では非常に好景気で、猫の手を借りようと思っても、猫すらいない状態で、普通の人材すら見つけるのは困難だった。このような背景があったので、今回のプロジェクトでは、できるだけ社内の人材を活用すること、また、負荷をかけてしまうことになるが、これまで開発に携わっていただいた優秀な技術者を中心にせざるを得なかった。これにはかなりリスクを伴うが、うまくいけば開発工数を抑えることができる。優秀な開発者には2倍お支払いしたとしても、それ以上のOutputを期待できる。力仕事は社内の人材を使い、PMは私自身が担当する。それが最も効率的に思えた。本来であれば大手ベンダーにお願いするSI案件であるものを、社内プロジェクトの体制で臨んだのである。社内プロジェクトでは、責任の所在が曖昧なので、万一完成しなかった場合のリスクが大きい。いうか、できなかった責任はベンダーではなく間違いなく自社ということになるだろう。考えてみると、プロジェクトが失敗してしまった場合には、たとえIBMであったとしても責任とって何かしてくれるわけではない。(大手ベンダーに請負ってもらう方は、それが現実だと肝に銘じておいたほうがよい)私は開発のイメージをもっていた。それは、IBM時代のPM経験というより、XMLコンソーシアムにおけるイメージの方が近い。XMLコンソーシアムの各社の代表は、成果物の責任をともなうような契約があるわけでもないのだが、皆が一つの目標に向かってまっしぐらに開発をすすめ、苦労を重ねながらでも最後はいいものを作りあげる。これは参加したものしか分からないのかもしれないが、とても独特で不思議な開発手法だ。iPlatの開発をイメージしながら今回のプロジェクトに臨むことにした。この方法でやるためには次のような社内外の担当者の意識改革が必要だと思った。自分たちも開発に参加するという意識をもってもらい、開発の主体となるように仕向けた。あることだが、発注者が特権的な意識があるような錯覚をしている。お金を払っているのだから何でも発注者のいうことを聞くべきというのが理屈なのだが、これをやってしまうと優秀な技術者ほど芳しくない結果を生む。補足すると、自分のいうことを忠実にやれ、ということは要するに、少なくとも優秀な開発者以上に自分が優秀でないと結果は出せない。見渡したところ、社内の人材で開発者より優秀な者はあまりいなかった。社内の人は逆に開発者を信頼して謙虚に接する必要があると思った。請負業者に対して厳しく接しないと損という人もいるが、人心の妙で結果的に発注者が損をすることになる。要求仕様があった場合には、思い切って開発者の判断において優先順位を下げることを容認した。社内担当者にとって無視されると困るが、いつかは作るよといえば大抵、納得してもらえる。社内の担当者に対しては要求内容を明確にしてもらう必要があった。リストを整理すると皆の意見を集約したような曖昧で無責任な要求が散見されるようになる。「誰の要求か」を特定できない場合には検証できないので非常に困る。ごもっともな事が書かれてあっても、それを言った人が特定できないのであればすべて削除することにした。要求する人には、まず最初に作る理由と効果の説明、さらに作った後のしっかりした検証を求めた。「言いっぱなし」を認めず、必ず検証を求めたので、作業が大変なのか黙ってしまう人もいた。後に個々のコストが算出されるようになると軽々しく言うこともなくなった。その結果、本当に作るべき要求だけが残ることになった。開発者に対して私が求めたのは、高度かつ先進的なITスキル、円滑なコミュニケーション、情熱と信頼である。先日、ある友人がなかなかよいことをいった。「IT技術者は医者や弁護士のようにクライアントの信頼を得られなければならない。優秀なIT技術者は、医者や弁護士のような高いレベルの仕事をすべきだと思う。クライアントが何が困っていて何をしたいのかをよく聞いて善意でもってソリューションを見い出す。その際、技術者は具体的な方法や手段は一任されることになり、細かい指示ではなく命題や目的だけを考えて結果を出さなければならない。何か調子の悪い現象が報告されたら「それは仕様です」とはいわず、迅速に悪い現象に対応するか、その改善案を提案すべきである。夏の開発のピーク時に、開発者の増員を図ったことがあった。契約の内容が派遣と同じような時間給であり、納期も短かったため、残念ながら中途半端な結果に終わってしまった。本人たちは、しっかり完成させなきゃという気持ちはあるものの、契約がそのようになっているので、どうしても机に座っている時間を基準に考えてしまう。「MTGに出席する時間は仕事に含まれるのですか?」と聞かれたとき、私は非常に不愉快な気分になった。「MTGに出るのは何のため?効率よく仕事をするためじゃないの?他にもっと効率よく仕事できれば出なくて結構だよ。」いつのまにか時間をかけて非効率な仕事をやる方がオイシイことになっている。時間をお金に換える発想から、結果をお金に換える発想に転換しなければ、お互いにメリットはない。そのうち彼ら自身の向上心もなくなってしまうだろう。今後、この手のサービスを利用することはおそらくないと思う。PHP?私が暮らしのデザインにやってきて早いもので1年。本当にあっというまに過ぎてしまった。ここでは開発中のものを含め5つほどシステムを構築したのだが、ただ、単に作ったというわけでなく、いろいろな研究をやってきたつもりだ。時間的にも体力的にも余裕がなかったので、研究と言えるほどちゃんとやったわけではないが、実験というと立場上まずいので、ここでは研究ということにする。私にとって最も大きな命題は、オープンソースの活用であり、LAMPだけで基幹システムを構築するという点につきる。そもそも、Web2.0を積極的にやろうという意気込みで始めたプロジェクトだったので、LAMPの採用は必然的だったのだけど、MySQL、とりわけPHPの経験が乏しく正確に評価できてなかったこともあり、基幹システムを作るにはかなり冒険的だった。更新系や連携部分などの重要な部分だけは、Javaで作られたReflex(これはこれで実験といわれてもしょうがないが)を採用することにした。することで、安全性というか、安心感が高められることになった。Javaだと安心かというと、稼動実績や情報が多いこと、歴史が長く安定していること、それから、最後の最後は自分の経験。どんなにトラブっても自身でFIXできる自信があったのが一番大きい。ついでにPHPを勉強して、Javaとの比較もできる。やってみようということで、ハイブリッド形でやることにした。プロジェクトでは、サービス志向を取り入れた次のポリシーで開発した。画面系はPHP(JavaScript)で作成する。プロバイダに対してはXMLかJSONでアクセスするプロバイダはReflex(Java)で作成する。JSPなどの画面は一切なし。iTextで作成する。バッチはJavaもしくはPHPかシェルこのJavaとPHPのハイブリッドは効果覿面だった。PHPによる圧倒的な画面生産性の高さは、Strutsに辟易していた私にとって衝撃的であった。画面を作るならPHPであり、Javaで画面を作成してはならないという結論に達した。後には戻れないだろう。以前、あるプロジェクトでS2Strutsを使ったことがあるのだが、これと比較すると感覚で1対100ぐらいの差がある。Favorである私であっても、そんなものに興味すらなくなった。第一、モックアップをJavaでやろうなんて発想自体、どうかしている。同じ言語を使えば、画面とビジネスロジックがシームレスになる分、何かメリットがあるように思えるが、逆にこれが画面とビジネスロジック開発の分業を阻害した要因になっていると思う。(結局は同じ人が画面もビジネスロジックも両方作ってるんじゃない?だから画面依存のコードになってしまって生産性を下げているんだよ。)どうせなら異なる言語で分かれた方がスッキリするし、そうすれば、PHPを知らないJavaの開発者は画面に触れなくなる。なってはじめて並行開発は可能になるものだと思う。JavaとPHPの両方を経験してみて言えることだが、Javaをどうひいき目に見ても、画面開発には向かない。Javaにはよいところもあり、PHPより勝る点は多くある。先ほども述べたが信頼性・クオリティの点は勝ると思う。iTextを使えば、XMLから簡単にPDFを作成できるので、納品書や請求書などの出力に利用している。これはこれで便利な機能だ。それに、私は最も初心者向けの言語はJavaであると思っている。これを含め、Javaの本領発揮する場面は後日述べたいと思う。APIの認証をどうすべきか考えている。次のようなケースをどうするか。「既存のWebサイトがあり、既にユーザIDとパスワードによる認証によって、ブラウザでデータを提供している。MVCモデルについて一言いっておくかなーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。vol82のWebAPIデザインの鉄則」に触発されたので書こうと思う。commitが可能である。いうイベントが開催された。Google、Amazon、SalesForce、Microsoftの4強+Niftyの、豪華面子でタイトルの通りごった煮にふさわしい感じの内容となった。ガチンコでお願いします8月12日、OracleがGoogleに対して訴訟を起こした。Oracleの持つJavaの知的所有権(特許および著作権)を侵害していることが理由とのこと。この問題はよくわからないので自分なりに整理してみることにした。(ただし私は法律には素人で間違いも多いと思う。Application)でサーバサイドをどうすべきかについて述べたいと思う。今、MEANが注目されている。OutputStreamをInputStreamに変換するOutputStreamからInputStreamに変換するにはどうしたらいいか。Pipeを使ってもOutputStreamと互換性がないので簡単にはいかない。Docsにオンライン・ファイルストレージ機能を追加するという発表があった。お題は、「フロントエンドエンジニアが主役のBaaSを作った話」です。Analyticsを使ってウェブサイトのトラフィック情報を収集しています。詳しくは、プライバシーポリシーを参照してください。