BPMとSOAを組み合わせてビジネスバリューを最大化するSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
ユーザサポートでめちゃくちゃ感謝された経験について話す - はてなポイント３万を使い切るまで死なない日記
もう１５年前にぐらいになるが、僕の仕事のやりかた、ユーザにたいしてどうやって向き合っていけばいいかについての信念を決定づけたある事件について語ってみようと思う。ほぼ懺悔にも近い。 ぼくが企画したモデムがバカ売れした。無名のブランドだったのにもかかわらず発売した瞬間に、秋葉原のショップで１番の人気モデルになった。理由は他者のモデムが無骨な段ボール箱にはいっていて、いかにもコンピュータの部品っぽかったのに、ぼくのモデムはカラフルな化粧箱をつけて、とても初心者が使いやすそうに見えたからだ。実際、簡単そうにみえる化粧箱をつくるのに何回もつくりなおして半年以上もかかった力作だった。 当時windows95が登場してインターネットが話題にのぼりはじめたあたりで、いままでマニアのパソコン通信ぐらいしか用途がなかったモデムをインターネットという単語に引き寄せられた大量の初心者が買い始めた時期で、とにかく簡
和魂と洋才と残業したい人々(上) - マーケットの馬車馬
筆者が海外のオフィスにお邪魔した時、最初に違和感を感じたのは電話だった。オフィス中に反響しそうな勢いでビービー鳴っているにもかかわらず、誰もその電話を取ろうとしないのである。こちとら「誰の電話が鳴っていようと、3コール以上通話相手を待たせるべからず」という鉄則を叩き込まれてきたクチだから、これはどうにも落ち着かない。3コール目くらいからソワソワし始め、5回、6回、と心の中で指折り数えてしまう。集中力もへったくらもあったものではない。7コール目くらいになると救いを求めて秘書の方を見るのだが、これまた泰然と無視なさっておられる。どれだけ大物なんだ。さぞかし名のある家の出に違いない。次からはマダムと呼ぼう。 そういう益体もないことを考えている間に、電話のコールは十を数える。こちらは何もしていないのに既に疲労困憊である。流石にこのころになると、周囲も電話のことを気にかけ始めるのだが、その態度は明確
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
TABLOG:ダメ会社の不振事業によく見られる50の症状 @V字回復の経営【書評】 - livedoor Blog（ブログ）
2009年04月25日 ダメ会社の不振事業によく見られる50の症状 @V字回復の経営【書評】 今日は、私にとって「金字塔」かつ「バイブル」的なビジネス書を読み返し、再度、頭にINPUTし直している。 GEのジャック・ウェルチが書いた「ウイニング勝利の経営」も、素晴らしい本なのだが、日本語で書かれたビジネス書の中で、この「V字回復の経営」ほどに「実践的」かつ「実戦的」なものを知らない。 とくに危機的な状況に陥った事業の建て直しに取り組む事業責任者の方が、この本を読んでないようでは、それだけで真剣味に疑問符を付けられてもおかしくない、そんな本なのだ。 ちょうど1年ほど前に、この本に出会ったとき、手にとって数ページをめくり、読みだしだけで、興奮にツバをゴクリと飲みこんだものだ。私は、あまり本に書き込みをしながら読む習慣はないのだが、この本については、ラインマーカーが、そこかしこに引かれることとな
SOA普及を困難にしている要因を探る
「サイロ化したシステム群を統合しよう」という掛け声はよく聞かれるが、実際にそれを推進しようとするとさまざまな問題に直面する。システム統合プロジェクトに求められる情報システム部門の役割やスキルから考えてみよう。 2008年12月、＠IT情報マネジメント主催の勉強会「SOAアーキテクト塾」が都内で開催された。年末近い日程であったが、現実に即したSOA導入の勘所、そして疑問に答えるという本セミナーに対する期待は大きく、会場はほぼ満員だった。 勉強会は、まず株式会社豆蔵 ビジネスソリューション事業部 シニアコンサルタントの岩崎浩文氏の基調講演があり、続いて日本オラクル SOAアーキテクト本部の岡嵜禎氏を迎えてのパネルディスカッション（モデレーターはブレインハーツ株式会社 谷川耕一氏）、最後に参加者からの質問に答えるという形式で進められた。以下、セミナー内容の要点をまとめ、「SOAを実践するための解
シムシティーの仕組み
シムシティーを作り始めていちばん最初に考えたのは、街を一種の生き物のように表現できないかってことだった。 僕が街についてどう考えているかはすでに説明したけど、大事なのは街を構成する建物とか道路じゃなくって、そこでどんな活動が行なわれているかってことだと思うんだ。道路を車が走り、電車が動き、人々が動き回り、常に要素が変化し続ける“動きのある”システム。街を表現する方法っていうと誰でも地図を思い浮かべると思うけど、僕は動きがない地図じゃなくって、たとえば飛行機から眺めた街、動きのある世界をディスプレイに表現しようって考えた。それこそが僕の考える街の姿だからね。 それともう一つ考えたことは、プレイヤーに伝える情報をできるだけわかりやすく、それも“面白い”って思えるような形で表現しようってことだった。シミュレーション・ソフトっていうとたいてい数値や図表がたくさん出てくるけれど、数字が並んでいるのを
C-teamで作るバナー広告の効果がスゴすぎてひいた話 : けんすう日記
今、C-teamというサイトの開発に関わっているのですが、あまりに効果が高くてスゴイので、結構ショックだったので紹介します。 C-team 今までWebディレクターとして、バナー制作をしたり、自分のサイトのバナーを制作会社に頼んでいたりしたんですが、これがいかに非効率だったかということを思い知って反省したので、紹介してみます。 自分の関わっているサービスをスゴイスゴイ言うと宣伝くさくなるので避けてたんですが、これは本当にびっくりしたのです。通常のバナーの作り方 通常のバナー広告って以下みたいな手順をふむことが多いですね。 1. 宣伝したいサイトの運営者(ディレクター)が欲しいイメージを制作会社に伝える 2. 制作会社のデザイナーさんがいくつか作る 3. そのバナーでよさそうなものを運営者が選んでそのバナーを出す ここでの問題は、1も2も3も「こういうのがいいんじゃないか」って勝手に想像して
「5枚プレゼン」のレイアウトを理解する
本連載では、「1枚企画書」に続いて竹島愼一郎氏が提唱する「5枚プレゼン」をPowerPointで実践する手順を全5回で紹介します。即断即決を可能にするのが以前に紹介した「1枚企画書」ですが、プランニングの王道はやはり複数枚の企画書です。ただし枚数は5枚に限定するというのが秘中の秘策です。 第2回では、5枚プレゼンのトップとボトム、導線の作り方、流れのデザインなどについてレクチャーします。 ※本記事は「ビジネス極意シリーズ パワポで極める5枚プレゼン」から一部抜粋し、編集・再構成したものです。 レイアウト――「5枚プレゼン」のトップとボトム 「5枚プレゼン」のそれぞれのページが、どういった内容でどう見てほしいのかを瞬時に理解してもらえるよう、見出しのフレーズを書き入れておくといい。タイプとしては、ページの一番上を利用した「トップ型」、一番下の「ボトム型」、トップとボトムが呼応した「問答形式型
ASCII.jp：これぞ完璧企画書――「1枚企画書」パターン実例3題 ｜パワポで極める「ビジネス極意」
本連載では、竹島愼一郎氏が提唱するインパクト抜群の「1枚企画書」をPowerPointで作る手順を全5回で紹介します。社会人になったらWordやExcelだけでなくPowerPointも使いこなせなくては、社内や取引先でのプレゼンに勝ち抜けません。しかし、ただ単に企画書をPowerPointで再現しただけでは、印象に残るプレゼンにはほど遠く、居眠りを誘う会議になってしまうことでしょう。 「1枚企画書」の最終回として、本書が出版に至った企画書の実例を含む、「プレゼン力の高い企画書」を3種類ご紹介します。実際の成功事例を踏まえてPowerPointをフル活用すれば、皆さんの仕事もきっと成功に近づくはずです。 ※本記事は「ビジネス極意シリーズ パワポで極める1枚企画書」から一部抜粋し、編集・再構成したものです。 Table of Contents プレ企画書1――飽和市場の「新商品企画書」 ■
エンジニアにとって働きやすい環境に必要な８つの要素 - ITで世の中をもっと便利に
ふと、独立起業するにあたり、 エンジニアにとって働きやすい環境とはどんな環境なのかを考えてみました。 自分が今働いている会社の環境、そこから導き出される不満、 その不満を解消するにはどういう環境を用意すればいいのかをまとめてみました。 1.給料が自分の納得できる金額である 給料が高いにこしたことはありませんが、 大事なのは自分がその金額に満足できるかどうかだと思います。 給料というのは永遠の課題であり、半分以上の人は満足できていないと思います。 例えば、よくある不満として挙げられるのが 他の人が自分よりも仕事をしていないのに給料が高いという不満。 もちろん、能力が低い（スキルが足りない）から同じ仕事をするにしても 時間がかかってしまい、残業が増える、その結果として給料が増えると いうのはどこの会社でもよくあることです。 能力があり、仕事や開発をサクサクできる人ほど ハイパーフォーマンスなは
IT業界で楽しく仕事をするための10カ条 - ＠IT
「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします（編集部） 2009年、日本の春は多くの学生さんたちが卒業し、また社会で活躍し始める時期です。 IT業界は3K、7Kなどと、いろいろネガティブな面も取り上げられます。けれども、「ものづくり」の楽しさや、人の役に立つ仕事として＠ITで取り上げられるような業種で働こうと考えている人も多いことでしょう。 なんとなくIT業界を選択した人から、もしかしたらあまり気が進まないのに、IT業界に入ってしまった人がいるかもしれません。その一方、プログラミングやコンピュータに関する事柄がとても好きでIT業界に入ってきた人もいるでしょう。 本記事では、IT業界を目指している学生さんや入社間もない新人に向けて、より楽しく
リーダーが抱える20の悪い癖
元GE会長のジャック・ウェルチ氏をコーチした経験を持つエグゼクティブコーチングの第一人者によると、組織の上に立つリーダーは共通した悪い癖を抱えているという。 「問われるコーチング力」バックナンバーはこちら 前回、自己分析によりリーダーは自分の強みと弱みを把握すべきだと述べた。今回はリーダーが陥りやすい「20の悪癖」について紹介したい。 以前「偽装事件を引き起こす不健康組織16の兆候」のコラムでも触れたが、リーダーの自己変革に欠かせないので改めて説明する。20の悪癖とはジャック・ウェルチ元GE会長をコーチした、コーチングの第一人者であるマーシャル・ゴールドスミス氏が、著書『コーチングの神様が教える「できる人」の法則』で指摘したものである。経営者やリーダーの多くは次のような悪癖を持っていて、それが職場に悪い影響を与えているという。 1. 極度の負けず嫌い 2. 何かひと言価値を付け加えようとす
プログラマの誇りを減衰しないビジネスモデルを - GoTheDistance
アツいエントリなんで思わずTBうってみる。 この業界の問題、それはプログラムが、新人〜3年目の作業と位置づけられていることだ。 プログラマーの誇りを見せ付けろ - 山本大＠クロノスの日記 正確に言うと上級プログラマも初級プログラマも同じ値段で評価されるってことが弊害である、ってことだと思います。予めXXX万円で作ってねという予算が決まっていて、その予算をオーバーしないことだけが成果の基準にあることが問題だと考えます。このルールにおいては、極論ですがコード品質が高くても低くても大差が無くねっていう力学が働きます。 基本的にニッポンの受託開発のプロジェクトの場合は、大きく２つのプレイヤーがいます。 案件を立ち上げてお客さんへのコミット権限がある人・会社 立ち上げた案件をシステム化してデリバリする人・会社 ですが、今の流れでは工程が分断されちゃっているので、案件を立ち上げる人とシステム化してデリ
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
従来のソフトウェアエンジニア人事工学が決定的に間違っている点 : 404 Blog Not Found
2009年02月06日05:30 カテゴリArt 従来のソフトウェアエンジニア人事工学が決定的に間違っている点 ここまでは、誰もが同意するだろう。 従来のソフトウェア工学が決定的に間違っている点 - kwatchの日記 仕事が高度になればなるほど、属人性は排除できないし、人材の替えはきかない。問題を解決できない人間を100人集めても、問題は解決できない。問題を解決できるのは、問題を解決できる能力を持った人間だけ。頭の悪い大人100人より、すごく頭のいい小学生1人のほうが、成果物が出る。ソフトウェア開発はそういう類いの仕事。 にも関わらず、 ソフトウェア開発も同じような体制にしたほうがいいのではないか。生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。 とならないのはなぜか。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【連載】今さら聞けない RFPによる調達&提案ガイド (4) 適切な調達実現には体制作りが重要 | エンタープライズ | マイコミジャーナル
長文日記
「その発想はなかった！」と言わせる技術を身につけよう～仕事の幅を広げる19の発想技法
kousyoublog.jp