タグ

___会社職場と___考え方に関するcyokodogのブックマーク (35)

  • 日本のホワイトカラーの生産性を上げるには1 - SQLer 生島勘富 のブログ

    のホワイトカラーの生産性が世界的に低いらしい。なぜ、日のホワイトカラーの生産性が世界的に低いのか。いろんな理由があると思いますが、システム開発会社である私の考えは、ホワイトカラーの生産性を上げるという使命を持った我々システム会社が十分機能していないということが、非常に大きな理由の一つだと考えております。 そこで、どうすればシステム会社が十分に機能し、日のホワイトカラーの生産性を上げることに貢献できるかを考えてみたいと思います。 一番の問題は原因は、システム会社がいまだにウォータフォールモデル開発に拘っていることにあると考えています。 ウォータフォールモデル開発では、プログラムを作る前に仕様書(基的に紙)という形でユーザに設計を承認して貰うわけですが、グラフィカルな画面を紙で表現されてもユーザには完全にイメージできるものではありません。というよりも、「書いている人でさえイメージで

    日本のホワイトカラーの生産性を上げるには1 - SQLer 生島勘富 のブログ
    cyokodog
    cyokodog 2010/06/07
    これ大事→「ビジネスロジックはストアドプロシージャに入れる必要があり..」ユーザ企業としては業務ロジックはデータと同じくらい大事。Javaなどで実装せずDBに格納しておいてください。
  • オープンソースをHackできることの意味 - GoTheDistance

    オープンソースを使いこなすことには、間違いなく優位性がある。そして、それはオープンソースを使いこなせないことにとてつもないハンディキャップをおっているという認識が必要である。 これは、単なる経済合理性の話である、ハッカーがどうだとか、オープンソースがどーだという話ではない。ベンダーにロックインされることが自社の競争優位性に繋がるのか否か。もし競争優位性に繋がらないとしたらオープンソースを利用するしかない。それしか選択肢がないのである。 2010-03-21 - 未来のいつか/hyoshiokの日記 よしおかさんの上記エントリを読んで、僕も同様の問いを抱いているのだけどうまく言葉に落とせなかった。 要はOSSをハックできる企業や人材とのパートナーシップがいかに強力なものか。事業価値をいかに高めるか。それが直感として正しいということなのですが、先週全く違う業界で事業展開している2つの会社の取締

    オープンソースをHackできることの意味 - GoTheDistance
  • PR:受託開発の限界を感じ、SIerからユーザー企業へ

    リーマンショック以降、情報システムの「内製化」に注力するユーザー企業が増えている。アウトソースによる社外流出コストの削減や、開発の効率化・迅速化など、さまざまなメリットが期待されているからだ。ただし、その実現のためにはまず、情報システム部の役割の見直しや体制強化が命題となる。 今回紹介する湯堅隆さん(30歳)は、ホームウェア・生活雑貨・インテリアなどの卸・小売事業を展開する『有限会社エフ・ケーコーポレーション』で、情報システム部を1人で担っているITエンジニア。大手ユーザー系システムインテグレータ(SIer)に6年間勤務していたが、受託開発の限界や内製化の必要性を感じて、2009年、情報システム部での新たなキャリアをスタートさせた。SIerからユーザー企業への転職――その決断に至るまでの経緯と、現在の業務内容や仕事のやりがいについて話を聞いた。 2003年、大手ユーザー系SIerに新卒入

    cyokodog
    cyokodog 2010/04/02
    モチベーション
  • ユーザを混乱させない表組みのコツ (ユーザビリティ実践メモ)

    ウェブサイト制作において、多くの情報をいかに整理してユーザに伝えるかは重要なポイントの1つです。よく使われる方法として表組みがありますが、今回は実際の事例をもとにしたケーススタディを通じて、ユーザを混乱させない表組みのコツをご紹介します。 表1はよく見かける表組みの例ですが、実際にユーザの立場に立ってこの表を使用してみると、いくつかの問題点があります。 同種の情報をユーザは区別できない 表1の問題点として、 日付という同種の情報を多く掲載しているため、ユーザには各情報が何の日付を意味しているのか区別できず、分かりにくい列数が多いために、セル内に折り返しが発生し、読みにくい ことが挙げられます。 特に、1つ目の問題点は、表が縦に長い場合にユーザを混乱させる要因の一つになります。なぜなら、画面サイズに収まりきらないほど表が縦に長い場合、下にスクロールしていくと「開催日」などの項目名が画面から消

  • RDBMSの時代の終わりが見えてきた - きしだのはてな

    クラウドと一緒にやってきたもの 最近、クラウドが流行ってます。 GoogleMapResuceから始まって、MicrosoftのAzureまで、大手のクラウド製品が出揃った感じ。 で、そこで、こんなクラウド製品が出ましたというときに、必ずといっていいほどそのクラウド用のデータベースの説明があります。そして、それはRDBMSではありません。 GoogleだとBigTable、MicrosoftだとSQL Data Services、あとはAmazonSimpleDB。どれも、基的にはひとつのテーブルにハッシュコードでアクセスするようになっています。 ほかのクラウド製品も、Oracle Coherenceだったり、楽天のRomaだったり、非RDBMSのデータストレージを提供します。 クラウドというわけではないけど、mixiのTokyo TyrantやApache CouchDBも、RDB

    RDBMSの時代の終わりが見えてきた - きしだのはてな
  • Webアプリで動的型付言語や開発管理が流行りIDEが流行らなかった理由などなど - きしだのHatena

    考えてみた。 ここんところ静的型付けなんか不要な空気になってたり、プログラムの内容よりも品質だとか開発管理の話題のほうが盛んだったり、IDEはあると便利だけどなくても大丈夫って雰囲気だったりする理由。 この10年Webアプリケーション花盛りだから、その理由はWebアプリケーションの構造にあるとして考えた。 Webアプリケーションの構造 で、まずはWebアプリケーションの構造。 字が汚いけど、左からブラウザ、アプリケーション、セッション、DB。 赤文字は、左がプログラム実行、右がデータの永続と書いてある。つもり。 Webアプリケーションでは、ブラウザからのリクエストを受けて、プログラムが動き、データベースの情報を処理して返す。 ブラウザ側でプログラムが動くことはあるけど、入力補助程度であまりたいしたプログラムは書かないので、主にサーバー側のプログラムを組む。 このとき、サーバー側のプログラム

    Webアプリで動的型付言語や開発管理が流行りIDEが流行らなかった理由などなど - きしだのHatena
    cyokodog
    cyokodog 2010/01/05
    「サーバー側はデータベースへのアクセスを代理して行うだけになって処理はもっと単純になる」ajax+ストアド業務ロジックの構成が多い昨今、特にそう感じる
  • ひがやすを「SIerは顧客の良きパートナーとなれ」 - @IT自分戦略研究所

    「クラウド」や「内製化」で変わりつつあるIT業界。その中で従来型のSIerはどうなるのか。そこで働くITエンジニアはどうするべきか。講演やブログを通じてSIerエンジニアについて提言を行ってきたひがやすを氏へのインタビューから、2010年の「自分戦略」を立案するためのヒントを探ろう。 第4回|1 2|次のページ 1週間にわたってお送りしてきた特集「SIerの未来、エンジニアの未来」。最終回は、システムインテグレータ(SIer)に勤めながら従来型のSIerに数々の提言を行ってきた、Seasarフレームワークの開発者ひがやすを氏に、SIerが今後どうなっていくのか、ITエンジニアはどうあるべきかを聞いた。 2010年のあなた自身の「自分戦略」を考えるうえで、参考になれば幸いである。 ■ 従来型SIerは崩壊する ―― 今年はSIerにとって苦しい年となりましたが、今後SIerはどうなっていく

  • 選んだのは「内製回帰」の道――ひとり情シスの挑戦 - @IT自分戦略研究所

    ITコスト削減によるユーザー企業の「内製化」の波が生まれている。SIerに外注するのではなく、自社のシステムを自ら作り出す。そうした「内製化」にこそビジネスとシステムの未来があると信じ、SIerからユーザー企業へと転身したエンジニアが、「内製化の可能性」と「やりがい」について語る。 第2回|1 2|次のページ 「GoTheDistance」というブログを運営している湯と申します。簡単に自己紹介させていただきます。 2003年に、とあるユーザー系大手システムインテグレータ(SIer)に新卒で入社し、プログラマ、開発リーダー、プロジェクトマネージャ(PM)、コンサルタントというキャリアを歩んできました。 振り返ってみると、とても恵まれたキャリアを歩ませていただいていたと感じます。ですが、さまざまなユーザー企業さまのお話をお伺いしているうちに、システム開発は「内製」に向かうべきである、と感じる

  • IBMの問題はアメリカナイズされた老害 - ひがやすを blog

    IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ

    IBMの問題はアメリカナイズされた老害 - ひがやすを blog
  • プログラミングファースト開発の必要性 - ひがやすを技術ブログ

    ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

    プログラミングファースト開発の必要性 - ひがやすを技術ブログ
  • 伊藤直也の「アルファギークのブックマーク」 - 誤解から賞賛へ。Ajaxで再評価されたJavaScriptから学ぶこと

    Googleマップによる“Ajax”の隆盛 最近、「Ajax」という言葉を耳にすることはありませんか? Ajaxとは、「Asynchronous JavaScript + XML」の略称で、「えいじゃっくす」と呼ばれています。このワード、半年ほど前に突然盛り上がりだして、いまではWebエンジニアの間ではお馴染みの言葉になっています。 今年の2月に、Googleが「Googleマップ」という地図サービスのベータリリースを行ないました。 地図に関するサービスは、これまでも数多く存在していますし、特にYahoo!やその他大手ポータルのそれは高機能かつデータベースも充実していて、実用性十分です。そんな地図サービス界隈に、いまになってGoogleが乗り込んでくる、というので、Webな人たちは固唾を呑んでそのリリースを待っていました。 そうしてリリースされたGoogleマップは、人々の期待を裏切ら

  • プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ

    人によってプログラム設計書の定義が違っていそうなので、最初に定義しておきます。ここでいうプログラム設計書は、ほとんどプログラムと対応するようなロジックが記述されているようなものです。 プログラム設計書を作るのは「誰が書いても同じコードにするため」だけでなく、元請けがレビューするためでもあります。元請けがプログラミング言語を読めないので、日語に落としてレビューします。コードを書いてからプログラム設計書を作ることもあります。 プログラミングがあまりできない人が、ちゃんとしたプログラム設計書はかけないのと同じように、プログラミングできない人が、プログラム設計書のレビューはできません。 当然だよね。プログラミングができないのなら、プログラミング言語を自然言語に翻訳したプログラム設計書を理解できるはずがない。 できるとしたら、誤字脱字、単語が統一されていないとか、日語が変だとかそんな指摘くらい。

    プログラミングできない元請けがプログラム設計書をレビューするという矛盾 - ひがやすを技術ブログ
    cyokodog
    cyokodog 2008/04/15
    いい事いいますね。要は何のためのプログラム設計書かと。仕様書に細かな長々したSQL書いてあっても、メンテするとき信用できないよ。ソース見なきゃ安心できん。
  • プログラマが仕様を決めればいい - GoTheDistance

    最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部

    プログラマが仕様を決めればいい - GoTheDistance
    cyokodog
    cyokodog 2008/04/11
    SEは顧客の立場で要件定義の整理、プログラマはそれ以降設計・製造をという考え方。全工程一人で担当の方がおもしろいっていうのは確かにそう。自分も8年間程そんな感じだが責任も大きいけど得るもの大きい。
  • 技術が枯れる瞬間の見極め - ひがやすを技術ブログ

    ギークなら、わくわくするような新しい技術をいつも試してみたいと思っているでしょう。しかし、現実の開発の現場では、ギーク以外の人がほとんどなので、新しい技術には興味がないわけです。たぶん、新しいことを覚えること自体面倒だと思っているでしょう。 そういう中に新しい技術を導入するには、「生産性が高くなる」「開発が楽になる」ということをまわりに納得してもらわなければいけない。最初は、反対されるでしょう。自分が責任取るからと強引に導入しようとするときに、考えて欲しいのは、その技術の枯れ具合です。 新しい技術なので、枯れていないのは当たり前です。なにかあったときに、頼れる場所があることが重要です。頼れる場所とは多くの場合、MLやフォーラムなどでしょう。そこでのレスポンスが早ければ、多少枯れてなくても何とかなります。 何とかなるとはいえ、枯れていない状態が長く続けば、それだけ利用者の負担も増える(MLな

    技術が枯れる瞬間の見極め - ひがやすを技術ブログ
    cyokodog
    cyokodog 2008/04/07
    昨年teeda採用した身としてはとりあえず安心。アップロード機能実装されたみたいなので今度試そう。
  • WEB+DB PRESS Tech Meeting [資料&動画]|gihyo.jp … 技術評論社

    当日の講演資料と動画を公開です。 動画はニコニコ動画を利用して配信しています。ニコニコ動画のアカウントをお持ちでない方でも,gihyo.jp上で動画を再生できます(コメントの書き込みはできません)。 動画の最後でニコスクリプトを使ったアンケートを行っていますので,ニコニコ動画のアカウントをお持ちの方はご協力いただければ幸いです。動画をクリックすることでニコニコ動画の該当ページへアクセスすることができます(ニコニコ動画のマイリストはこちら)。 今回の動画公開にあたって,gihyo.jp用に新たなニコニコ動画プレーヤーを作っていただきました。この場を借りてニコニコ動画の方にお礼を申し上げます。 JavaScript Tips & Technique IT戦士amachangが最近のJavaScriptのテクニックやTipsについてご紹介します。

    cyokodog
    cyokodog 2008/04/02
    はぶさんのプレゼンがとてもすばらしい。ファンになった。