Googleが検索順位を決めるために使っている「Googleページランク（PageRank）」の外部向け情報公開が、このたびついに停止されました。 ページランク（PageRank）とは、全てのWebページをGoogle独自の評価方法で、0～10の11段階にスコアリングしたものです。これは検索順位と極めて強い関係を持つものであり、SEO対策では非常に重要な指標となっていました。 かつては、Googleが無償配布していた「Googleツールバー」などで様々なサイトのページランクを知ることができましたが、そのツールバー上の情報も2013年にはデータ更新が停止され、ついにそのデータの取得すらできなくなっています。 ついに公開停止となったページランク、経緯は 2016年4月、アメリカと日本国内で確認不可能に 2016年4月、上述の「Googleツールバー」、もしくはその他のどんなツールを使っても、ペ

よく訓練されたアップル信者、都元です。さて、近年のSpring事情を語るのに避けて通れないのがSpring Bootです。 Spring Bootとは とは言え、正直Spring Bootは何をしてくれるコンポーネントなのか。これを一言で説明するのは実は非常に難しいです。なので、以下に私の思うSpring Bootの大事な特徴を2つ挙げますが、それだけがSpring Bootではない、という認識もしておいてください。 簡単起動 作ったアプリケーションの起動を簡単にできます。具体的には java -jar your-app.jar でOK。面倒くさいクラスパスの指定等不要で、単一のjarファイルで起動可能になります。 これは、スタンドアロンのアプリケーションでも、Webアプリケーションでも同じです。つまり場合によっては java -jar your-app.jar によって、Webサーバが立

私の仕事は StackOverflowの諸先輩方や Qiitaの分かりやすいまとめや 技術者のニッチなブログや 素晴らしいライブラリ、そのコミッター 言語を生み出した天才たち IDEの開発者 PCの製造者 その他ASP、インフラなど、多くの方が居て奇跡的に成り立っています 一人では何もできません 99％は他の方に頼っています ありがとう ありがとう

政府CIO補佐官。ITプロセスコンサルタント。 元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。 立教大学経済学部経済学科卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は９割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年よ

九龍城砦（正式名称：九龍寨城）は、1994年まで存在していた香港・九龍の九龍城地区にあった城塞及びそこにあった巨大なスラム街のことである。 香港がイギリスの租借地だった時代、九龍城砦だけは例外として租借地からはずされていたために、中国にも、イギリスにも法治権がなく、文字通りの「無法地帯」であった為、あらゆる犯罪の巣窟で、一度迷い込んだら二度と出て来れない場所と揶揄されるほどの、東洋一の魔窟でありスラム街だったという。 そんな当時の九龍城砦全景と、そこに住む人々の様子がわかる映像が公開されていた。

（画像：wikimedia commons） こんな記事を見かけました。 記者の眼 – 「アジャイル嫌い」はもうやめよう：ITpro http://itpro.nikkeibp.co.jp/atcl/watcher/14/334361/082400357/?ST=system&P=1 開発の経験が長い人からすると、「あーはいはい」と昏い目をしてしまうような記事なのですが、実際のところアジャイルを宣伝する本やブログなどは多く、「プロジェクトを始めよう！」となったときに、候補に上がることが多い開発手法ではあります。 しかし、現場の現実から言うと、安易にアジャイルを導入して失敗するケースは非常に多いです。 私は20件以上のアジャイルプロジェクトを見てきましたが、そのうちちゃんと成功していたプロジェクトはたったの3件だけです（ウォーターフォールは100件以上見ていますが、成功率はそんなに低くはあり

電通と博報堂は丸投げで中抜きしかやらない - はてな村定点観測所 そういえば、この前話題になったnetcraftさんの記事ですけど、SIについてもちょっと触れられていたので補足まで。 大手SIerでは基本丸投げできない 元請けがシステム開発の上流工程やマネジメント行っているので、丸投げではないというコメント欄の指摘がありましたけど、そういった能動的な理由以外にも、大手SIerではシステム開発を基本丸投げできない理由があります。 理由１　そもそも丸投げ可能な案件がやってこない 昔ならともかく、これだけ情報システムが身近になった現在、丸投げがカンタンにできるような案件はそうそうやって来ません。 ユーザ側も、システム投資について勉強してきてますので、きちっと妥当性判断します。 なので、まるっと丸投げできるような案件は、コスト割高になりがちな大手SIerには来ないです。 ※費用感合わず提案見送り、

巷ではオフショアが盛んです。コスト削減のため、日本国内と比べ安い賃金の中国、ベトナム、インドなどアジア諸国に仕事を依頼する企業が増えています。が、そこには恐ろしい罠が潜んでいます。 メールやskypeなどネット環境があれば、世界中の誰とでも仕事が出来るため、わざわざ高い人件費の日本人を雇う必要は無い、といった論調があります。 特にwebやアプリのプログラミングなどは、あらかじめ仕様を明確にしておけば、開発作業自体は共通言語の英語で進められるため、オフショアに向いている、と言われています。 オフショア開発とは、そんなに簡単に行くのでしょうか？ ここでは、実際に経験した本当にあった怖いオフショア失敗例を紹介します。 プログラム開発をクラウドソーシングでインド人エンジニアに格安で依頼 インド人エンジニアに逃げられた 受託開発会社のA社が、あるiPhoneアプリ開発を広告代理店から依頼された時の話

政府CIO補佐官。ITプロセスコンサルタント。 元・東京地方裁判所民事調停委員・IT専門委員、東京高等裁判所IT専門委員。 立教大学経済学部経済学科卒業後、NECソフト株式会社（現NECソリューションイノベータ株式会社）にて金融機関の勘定系システム開発など多くのITプロジェクトに携わる。その後、日本アイ・ビー・エム株式会社にて、システム開発・運用の品質向上を中心に、多くのITベンダと発注者企業に対するプロセス改善とプロジェクトマネジメントのコンサルティング業務を担当。独立後は、プロセス改善やIT紛争の防止に向けたコンサルティングを行なう一方、ITトラブルが法的紛争となった事件の和解調停や裁判の補助を担当する。これまで関わったプロジェクトは70以上。調停委員時代、トラブルを裁判に発展させず解決に導いた確率は９割を超える。システム開発に潜む地雷を知り尽くした「トラブル解決請負人」。2016年よ

前回の記事でSQLインジェクションの話は終わりにして、クロスサイトスクリプティングの話を書かせて頂こうと思っていました。しかし、6月5日に東京にて開催されたPostgreSQLカンファレンス2007でセキュリティをテーマに講演させて頂き、意外にブラインドSQLインジェクションをご存じでない方が沢山いらっしゃいました。40名ほどの聴講者の皆様にSQLインジェクションをご存じの方？とお聞きするとほぼ全ての方が知っていると答えたのですが、ブラインドSQLインジェクションをご存じの方は数名でした。 SQLインジェクションの常識 ブラインドSQLインジェクションの話をする前に、SQLインジェクションとその対策の常識について確認します。 SQLインジェクション対策として間違ってはいないが不十分な対策 エラーメッセージを表示しない（特にSQLエラー） ユーザ入力文字列をエスケープする これらはSQLイン

第42回PostgreSQL 9.0に見るSQLインジェクション対策 大垣靖男 2011-05-19

システム開発で失敗している会社は多く、全体の７割程度が失敗プロジェクトという話もあります。何をもって成功・失敗というのかによっても成功率は変わってくるかもしれませんし、成功・失敗の要因は色々ありますので、この手の話は簡単に答えが出ることはありません。 アクシアにお問い合わせいただくお客様の中には、システム開発は初めてという企業さんもありますが、過去に既にシステム開発を経験しており、そのシステム開発が不幸にも失敗に終わってしまったという企業さんがそれなりの数で存在します。 失敗の要因は一つでないこともあり複雑で一概には言えませんが、システム開発失敗の原因の一つには「システム開発会社の選定に失敗した」というものがあります。この業界には色んな会社があってそれぞれ全然違いますので、開発会社選びに失敗するというのもしょうがないかなという部分があります。 システム開発を検討している企業さんが発注先とな

システム開発の世界では”デスマーチ”という言葉がよく使われ、世のプログラマー達が自分達のプロジェクトのデスマーチ自慢をするという光景もよく見かけます。それだけシステム開発のプロジェクトは炎上することが多いということであり、システム開発の成功率は３割りくらいとも言われています。 成功率は31.1％ – 第2回 プロジェクト実態調査（対象800社） プロジェクトが失敗するからには何か理由があるわけでして、端的に誰が悪いかというと「顧客が悪い」か「開発会社が悪い」か「その両方」ということになります。 システム開発の業界というのはその構造自体に問題を抱えていると言わざるをえない部分がありまして、多重下請け構造で客先常駐なんかやっていたらそんなの失敗事例が量産されても当然だよなとなってしまうわけです。 そういう意味では、システム開発の実に７割にも及ぶプロジェクトが失敗している要因としては「開発会社が

昨日Twitterで投稿したツイートが結構たくさんリツイートされました。 顧客「要件伝え漏れてた件があるので急ぎお願いしたい」 弊社「その内容だと◯◯万円で納期はこれくらいです」 顧客「その要件が漏れたことでクレームが発生してます」 弊社「それは大変ですね急がないとですね」 顧客「その点も考慮いただき無償で対応してほしい」 どう思考したらそうなるのか — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) June 29, 2017 「この要件は言わなかったけどヒアリング甘かったお前らの責任だろ？いいからタダでやれ」という事案を吉野家に置き換えると「何で卵付いてないの？卵つけるか聞かなかったお前らの責任だろ？いいからタダで卵つけろ」となります。いかに鬼畜かおわかりいただけるだろうか。警察突き出して良いレベル。 — 米村歩@日本一残業の少ないIT企業社長 (@yonemu

IT業界に限った話ではありませんが、仕事をしているとたまにとんでもない顧客に出くわすことがありますよね。そんな顧客の対応をしているうちに精神的に消耗してしまうこともあるかと思います。そういう顧客とはできるだけ取引しないように注意はいますが、注意していても一定の確率でそういう顧客と当たってしまうこともあります。交通事故みたいなものです。 以前こんなブログを書きました。↓ 残業を求めてくる顧客はブラック企業です 本日はより具体的に、私が今まで出会ってきたとんでもないブラック顧客ｗをご紹介したいと思います。 ブラック度10%：「こうなると思ってました」を連発する システム開発ではこれから構築するシステムの仕様について、顧客と開発会社側で認識の齟齬が発生しないように、顧客の要件をヒアリングしながら仕様書に落とし込んでいきます。システム完成後の検収は基本的にこの仕様書に基いてシステムが正しく動作して

記事によると 某IT系の会社で採用をしているのだが、旧ソーシャルゲームの覇者からの流出人材の応募がいつまでたっても止まらない どうなっているのだろうと、少し調べてみたところ人事的・採用的に終了していたので少し書いてみる。 人事的に死にかけていると断言する理由 ■人材不足、人材の質の低下が酷い ・子会社の役員の顔ぶれを調べてみると、ここにもあそこにも見た名前、兼任役員の多さに気がつく - 言うまでもなく兼任では専任に比べて事業に集中できるはずがない - 連結1,400人の会社で、この兼任の状況であれば、良い人材が社内にいないことを自ら公表しているのと変わらない ・社員数が半減以下 2013年の公表値 1,762人だった従業員数が現在842人（※ただし連結では1,467人と記載あり） ■出世できない会社 ・前項でも触れた子会社の役員だが、概ね会社設立5年以内に入社メンバーという特徴がある -

Photo by Peter Rosbjerg こんにちは、髙田です。paiza新卒の事業立ち上げから事業推進・営業を担当しています。 自分の知り合いにも多いのですが、将来的に自分で新規事業を立ち上げたいと考えている方が最近増えているように思います。有名な「リーン・スタートアップ」をはじめ、起業に関する書籍も近頃はたくさん見かけます。 しかし起業について書かれた書籍を手に取ってみると、会社の立ち上げ方、組織の作り方などは書いてあっても、実際に「どうやって事業機会を見つけるのか？」「自分が情熱をもって取り組める事業にどうやって出会うのか？」といったことについては、ほとんどの書籍で触れられていません。 新卒事業の立ち上げに当たり、当初経営チームには「この事業は難しいのでは？」と言われ、自分自身も「本当に行けるのだろうか？」思っていたところから、どうやって事業性の確信を持てたのか、また「これがま

Photo by Jan こんにちは。谷口です。 ITエンジニアの方々の中には「いずれは起業を考えている」という方もたくさんいらっしゃるかと思います。 最近は会社員としての転職だけでなく、フリーランスや起業など、様々な働き方を選ぶことができます。また、起業については昨今のスタートアップの資金調達のニュースが出たり、起業家がブログ等で情報発信をしていたり、そういった情報を掲載した書籍も増えており、「自分もやってみたい！」と思われる方も増加しているようです。 ただ日本では、初年度に倒産廃業する割合が個人事業ベースで37.7％、企業ベースで20.4％倒産、廃業している（経済産業省「工業統計表」ベースの集計）という状態ですので、あまり調べもせずいきなり起業するということはお勧めできません。 特にWebサービス等の自社サービスで企業起業する場合は、どういった業界でビジネスを起ち上げるのか、どのような

Photo by Jeff Attaway 今回のpaiza開発日誌は片山がお送りします。 paizaの運営を始めて3年半ほどたちました。 大変なこともたくさんありましたが、ユーザー数もこの1年で約6万人ほど増えるなど、事業もだいぶ軌道に乗ってきました。 paizaはメディアビジネスなので、ITエンジニアと求人企業がそれなりの数集まらないと成り立ちません。初期投資もそれなりに必要だったため、最初のころは資金がすごい勢いで溶けていく割には先が見えない、まさにヒリヒリと「痺れる」毎日をすごしていました。 最近ではようやく事業も軌道に乗ってきましたが、ここまで来るためには、paizaを立ち上げる前に一度、新規事業立上げで失敗した経験がとても役立ちました。 今回は、その失敗から学んだことをまとめてみました。何かの参考になれば幸いです。 ■スタートアップ立上げをやってみて分かった失敗の法則 paiz