会社から「頼りにされる」危険性 - ひがやすを blog
エンジニアは、誰でも、人の役に立ちたいと思っているものです。そして、人から頼りにされることに、喜びを感じる生物です。でも、この「頼りにされる」状態は、危険な状態であることもある。 頼りにされるあまり、多くの仕事がその人に任されることになる。できる人に、仕事が集中するのは、よくある話で、その人は、回りの期待にこたえようとして、遅くまで残業して、休日も出社したりする。この状態が、一過性のものだったら良いんだけど、慢性的なものになると、肉体も精神もぼろぼろになっていく。 仕事が慢性的に過度に集中している人は、一度じっくり考えてみたほうが良い。会社は、「あなた」のことを頼りにしてるけど、実際のところはこき使ってるわけですよ。俺なら、ピンチのときにできる人に仕事をいっぱい頼むことはあっても、それを慢性的には行なわない。だって、その人に壊れて欲しくないから。 仕事が慢性的に過度に集中している人は、会社
java.util.Dateをjava.sql.Dateにきちんと変換する方法 - ひがやすを技術ブログ
多くの人はこうやればいいと思っているかもしれません。 java.util.Date d = new java.util.Date(); java.sql.Date d2 = new java.sql.Date(d.getTime());確かにこれでも一応変換はできますが、きちんと変換してはいません。java.sql.DateのJavadocを見るとこう書いてあります。 SQL DATE の定義に対応させるために、java.sql.Date のインスタンスでラップされたミリ秒の値は、インスタンスが関連した特定のタイムゾーンで時間、分、秒、ミリ秒をゼロに設定することで、「標準化」する必要があります。 つまり、java.util.Date#getTime()をjava.sql.Dateにただ渡すだけでは不十分で、「特定のタイムゾーンで時間、分、秒、ミリ秒をゼロに設定しなければいけない」のです。そ
Seasar2から卒業しよう - ひがやすを技術ブログ
人は、新たな環境で経験を積んでいくと、少しずついろんなことが出来るようになり、そのうち、その環境では、何でも自分の思った通りに出来るようになります。 「おら、強ぇ」状態。 これは、素晴らしいことなのですが、一つ問題があります。成長が止まってしまうことです。 人は、知らないことを経験したり、つまずきを乗り越えたときに、成長します。知らないことがほとんどなくなったり、つまずくことがなくなったりすると、成長が止まってしまうのです。 Seasar2.4、S2JDBC、SAStrutsと開発してきて、通常のサーバーサイドJavaは、十分にやりきった感がありました。このままこの場所にいるのは、心地いいんだけど、成長が止まってしまうのが不安でした。 人って不思議なもので、一定の能力でとどまるってことが出来ないんだよね。成長が止まると、能力は落ちていく。 自分はどこか、ドラゴンボールの悟空に似ているところ
良いエンジニアの育て方 - ひがやすを技術ブログ
人を育てるというのは、とても難しい。 なぜなら、育てる方も未完成な人間だから。 ちょっと経験値のある未完成な人が、経験値の少ない未完成な人と、ともに冒険をし、ともにレベルをあげていくことが、人を育てるってことだと思う。 人を育てようと思うと、どうしても上から目線になってしまう。上から目線だと気持ちも相手に伝わりにくい。気持ちが伝わらないと相手もうまく成長してくれない。 だから、人を育てる機会があったら、ともに冒険をする仲間を持ったと考えよう。きっとその方がうまくいく。 それでは、自分の話をしよう。自分というよりは自分たちの話かな。 2010年、自分は、昼間、ブラ三をやりながら、新規ビジネスの企画を考えたり、プロトタイプを作っていたりしていた。ブラ三をやっていたのは、当然ソーシャルアプリというものを学ぶためだ。ブラ三の能力はかなり向上したけど、仕事ではたいした結果が出せなかった。特に企画考え
残業を悪とするチームを作ろう - ひがやすを技術ブログ
長時間労働やサービス残業は、基本的には会社の問題であり、上司の問題です。 例えば、大手SIerで長時間労働やサービス残業が発生するよくあるケースを見てみましょう。 会社は、ワークライフバランスを向上させるために、年間360時間以上の残業をしてはいけないというルールを決めたとします。この段階で、会社は残業は社員のために良くないと認識しています。 現場は、社員の稼働率を上げるためにオーバーワーク気味に仕事をアサインします。仕事がないときに備えて、仕事があるときは、多めに仕事を振るのです。これが間違いなのですが、たいていの現場は、このように行動してるでしょう。つまり、仕事があるときは、多めに振られているので残業することが前提なのです。 ここで、会社の作った残業規制のルールが効いてきます。上司は、会社のルールがあるので、月30時間以上の残業をつけることを基本禁止します。「残業をつけることを禁止する
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを技術ブログ
ぼくは水曜日にTokyo Cloud Developerの集まりに出た。 そこで、LLのひとから、「Google App Engineは、Python版以外にJava版も出たけど、サンプル見たけど、たくさんコード書かなければいけなくて、正直どこがいいのか教えて欲しい」という質問があった。 blogに名前を出していいかの了解を得ることを忘れたので、ここには、LLの人としか書けない。 ぼくは、そこで一言申し上げた。あるいはそれは、「申し上げた」というような生やさしいものではないかも知れない。端的な言い方をすれば、ガツンと言ってやった。 客観的に見て、ぼくはガツンと言ってやったと思う。LLな方々を前に、「いまどきのフレームワークは進化しているから、言語による差なんて余りない。仮に、Javaのほうが二倍コードを書く必要があったとしても、開発の中でコードを書いている時間より考えている時間のほうが圧倒
スーツなSpringとギークなSeasar2 - ひがやすを技術ブログ
国産のOSSについて見てみると，Rubyは「◎」，Seasar2は「♪」，運用管理ツールのHinemosは「♪」，Rubyベースのバグトラッキング・システム影舞は「○」，プロジェクト管理ツールのProject Keeperは「♪」となっている。 正直なところ、大手SIerがSpringではなく、Seasar2を選ぶ可能性は少ないでしょう。 一番の理由は、Seasar2は、電通国際情報サービスの影響が強いように見えること。競合する可能性ある会社の影響の強いフレームワークは、よほどのことがない限り選ばないと思います。 某N社の幹部が「Seasar2は、電通国際情報サービスが開発しているから、使わない」といっていたと、風のうわさで聞いたことがあります。「電通国際情報サービスが開発している」ってのは、はっきりいって間違いです。うちの会社は、何人かのコミッタに給料を払っていて、就業時間中にSeasa
ソーシャル素人がソーシャル系ビジネスをやりながら学んだこと - ひがやすを技術ブログ
2010になって、私は感じました。ITの流れが変わった。 これからの主役は、エンタープライズではない、ソーシャル系のビジネスだと。 勘違いしないで欲しいのは、エンタープライズ系のビジネスがだめだと言っているわけではないということです。今という瞬間なら、エンタープライズ系のビジネスは重要でしょう。 しかし、儲からないし、未来はない。 これが下記のエントリにつながってきます。 SI業界からはさっさと抜けだしたほうがいい http://d.hatena.ne.jp/higayasuo/20110111/1294718077 サービスを考える人と、プログラムをする人は、求められているスキルが違うから、両方をやるのは難しいんじゃないというような、眠たいコメントもあったけど、誰もができるようなことをしてたんじゃ、それは金になりません。 誰もができないことができるから金になる。人と差別化できなければ、そ
Slim3 Preview release - ひがやすを技術ブログ
Slim3の正式リリースは、来年の一月くらいになりそうですが、ドキュメントも最低限のものはそろったので、今の段階のものをPreview版として紹介しておきます。 サイトへは、http://slim3.org でアクセスしてください。 Getting Startedをやり、Slim3 Datastoreのドキュメントを読み、Online demoをみれば、Slim3のことは把握できるようになっています。 Oneline demoからソースも見れるようになっているので、動かしながらソースを確認することができます。Online demoは、IE6で見るとレイアウトが崩れていますが、これはIE6を使うなというメッセージということで。(IE7,8では未確認) Slim3は、Google App Engineに対して最適化されています。 例えば、最近、App Engineで問題になっているのは、spi
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
人間的魅力がない人はリーダーになれないのか - ひがやすを技術ブログ
小野さんのところでこんなつぶやきがありました。 今九州大学の授業なんだけど、「リーダーになるためには人間的魅力が必要だと思いますが、人間的魅力がない場合にはどうすればいいでしょうか」なんという質問！ この後に、清水さんの「だれでも努力次第でリーダーになれる」というのは詭弁だという話に続きます。 「だれでも努力次第でリーダーになれる」 僕はそれを詭弁であり欺瞞だと思う。 優秀な開発者になるのとも、マネージャになるのとも違う。リーダーになるのは、純粋に性格、才能なのだと思う。 この話の詳細は小野さんとこに shi3zさんが私について、「嘘を平気でつける人間」であり、それ故に「欺瞞に満ちた人間」であると言っている理由は、九州大学の授業に参加している生徒達に対して、shi3zさんが「君たちは僕のようには決してなれないから、才能ある人間の邪魔だけはしないようにしてほしい」というスタンスである(彼曰く
SIerの解体と再生 - ひがやすを技術ブログ
ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの
海部さんと梅田さんに知って欲しいオープンソースの三つのポイント - ひがやすを技術ブログ
最初に謝っておきます。「オープンソースについて知らないのなら軽々しく書くな」というのは言い過ぎですね。だれでも自由に物を書く権利がある。ただ、変なことを書かれても困るので、知っておいて欲しい重要なポイントを書いておきます。 参考にしていただけると幸いです。そうじゃないと、また、それは違うよと指摘しないといけなくなるから。 最初に、オープンソースとは何なのかは、正しく理解して欲しいし、違うものをオープンソースと読んで欲しくない。お客様と話すときでも、お互いに思い違いが発生しないように同じ単語は、同じ意味になるように最初に調整しますよね。あれと同じことです。 オープンソースの定義は、http://www.opensource.jp/osd/osd-japanese.htmlに載ってます。でも、難いですよね。普通の人に説明するには難しすぎます。 個人的には、「オープンソースとは、ソースが公開され
梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ
例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働
浜口さんに贈るSI業界を良くする方法 - ひがやすを技術ブログ
浜口さんの言葉には、ブクマや突っ込みを生み出す何かがありますね。 したがってシステムの大規模化は、必然的に想像以上のコストアップと信頼性リスクの増大を招くものであるとの認識が必要になる。 きました。想像以上のコストアップだそうです。 そんな浜口さんに贈ります。今よりコストダウンさせて、SI業界を良くする方法。 例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。 プログラム設計書は、自然言語で書きます。プログラムは、プログラミング言語で書きます。どっちの言語が、プログラムを書くのに適しているかといえば、誰が考えても、プログラミング言語ですよね。 いきなりプログラミングはできない人もいるから、プログラム設計書が必要だという人もいるかもしれませんが、それは、間違っていると断言しましょう。 いきなりプログ
不況の今こそ畑を耕せ - ひがやすを技術ブログ
日本IBMのリストラが始まった - yvsu pron. yasで、不況のときに安直にリストラすると、中長期の利益を失うリスクがあるというエントリを書きました。 安直なリストラのどこに問題があるのでしょうか。一番の問題は、「人」という会社で最も重要な資産を失ってしまうことです。 人の首を切ることは直ぐにできるけど、人を育てるには時間がかかります。中長期の利益を生み出すのは、やはり人です。人という大切な資産を失ってしまったら、利益を生み出す源泉がなくなってしまうのです。 下請けに頼りすぎれば、システム会社として持つべき技術や機能の低下は避けられない。それでも業界を覆う下請け依存症は年々悪化の一途をたどっている。 正社員をリストラして、その分は、下請けに頼るとしましょう。一時的にはコストが下がるかもしれないけど、かわりに技術という大事なものを失ってしまう。 別にこれは、リストラだけに限ったこと
「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ
自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか？ 自社と外注先との間の契約がどのようになっているのかご存じですか？ それを目の当たりにしても同じことを言い続けられる自信はありますか？ そういうことはスーツの仕事とレッテルを貼って見て見ぬ振りをしてませんか？ それでいて業界を変えたいなどといいますか？ 業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。 バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。 新規取引をさせていただくときの最初の顔合わせに同
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
