「これって、ドメイン駆動設計？」という資料を公開しました。 - GoTheDistance
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す
業界が縮小しても、あなたの未来が閉ざされるわけじゃない。 - GoTheDistance
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道に寄せて。 マクロ的な見解は僕も同意見なので、特に言いたいことはないです。というか、僕自身も｢今後は受託開発を人月で請け負える(これが狭義のSIの定義です。)機会が減りますよ」という旨のエントリを結構書いています。だって、自分で見積もり書いて出してみたらやけに高いんだもん。この仕事がシステムで可能になっても、割に合うのかなって考えたこと結構あります。話がそれましたが、要は人月が出来ないとスペシャリティの無いやつは益々要らなくなるので、お前らマジ頑張らないと知らないよって話へと続いていきます。 でもね、こんなのどーでもいいんですよ。 やべーこの業界は先が無いからマジ頑張ろうかって思っても、何を頑張るんですかあなた。主語が無いじゃないですか。そこに至るロジックはあるんですか？自分が立っている世界の地図を考えてその成り立ちを考えることは
能力が高くても仕事を請けることは出来ない - GoTheDistance
エンジニアのキャリアを考えればフリーになったり起業したりするというのは王道パターンの１つであると言えます。いざその道を歩むとなれば仕事を自分で受注しなくてはならない。そこに存在する落とし穴が表題そのものなんですが、もうちょい詳しく書いてみます。 「取ってきて貰った仕事をする」ヒトが「自分で仕事を取ってきて請け負う」を目指すときに起こる一番の勘違いは「能力が高ければ仕事を請けることが出来る」というものだ。 ここでいう能力というのは、エンジニアで言えば｢Javaが書ける｣｢サーバー構築が出来る｣｢MySQLのDBAをやっている｣というような類のモノ。要はスペックと考えるとわかりやすい。単純な話だが、仕事を発注する企業やヒトは技術の専門家じゃないので、ある一定水準以上のスペックは「どんぐりの背比べ」にしかならないことが多い。スペックが高いというのは伝わりますが、伝わったところで「それはすごいです
富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance
全文は紙面でないと読めないのが残念ですが、非常に気になるニュースが飛び込んできました。 富士通、余剰ＳＥ変身作戦 富士通がグループで抱える約３万人のシステムエンジニア（ＳＥ）の大がかりな職務転換に乗り出した。一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。野副州旦元社長の急進的な改革路線を修正した富士通はＳＥ余剰問題で軟着陸を目指すが、クラウドの奔流にのみ込まれる危うさもはらむ。 富士通、余剰ＳＥ変身作戦 実は富士通グループさんには弊ブログを頻繁にご覧頂いておりまして、企業ドメインの中では最もアクセスの多いドメインであります。クロールしにきているのかなと思うぐらい。ブログで言及している「なんでもかんでも受託開発では、もうSIビジネスで成長することは出来ない」という危機
大企業で働くということ - GoTheDistance
梅田望夫氏の大企業で働くことについてのエントリの尻馬に乗ろうと思い続け、気がつけば尻馬が100マイルぐらい遠くなってしまったのですが、やっぱりこのネタについて書きたいことがあるので、エントリを書きます。すっげー長いエントリになってしまったので、気長に読んでください。連休の夜長にでも。 他の大企業はどうだかわからないけれど、少なくともウチの会社に限って言えば、以下のような事が言えます。 本部長レベル以上はやっぱりデキる人が多い 何にも考えなくても給料がもらえる仕組みがある 人がいっぱいいる、それだけでも意味がある 基本的に隣の部署が何をやってるかわからない 決定が棚上げされる うっとおしい社内業務が多い こんなところかなぁ。 ウチの会社は社員数4桁の会社です。そんな会社にあって本部長クラスになれる人は、どこか一味違います。先を見据えて物を考えていたり、政治力がすごかったり、オレ様全開だけど明
IT部門と経営の溝を埋めるために必要なたった1つのこと - GoTheDistance
もう何周目になるのでしょうか。｢情報システム部門が経営に貢献できていない｣というこの手の話は。 システム部門再生 - 経企部門が吐露する「システム部門への不満」：ITpro なんか色々ダメだしされていますが、重要なポイントは１つだけです。システム部門がビジネスに貢献するためには、自社の事業に対する理解が必要なだけではなく、その遂行手段である業務プロセスの理解が必要だ、という圧倒的な事実があることだけ。WhatとHowはクルマの両輪だと。で、この手の問題はシステム部門の問題ではなく経営の問題だという水掛け論が水びだしになるまで色んな人にされてFUDが残るのも味わい深いポイントであります。 自分達で管理できないものを改善できるわけが無い システム部門が業務プロセスの改善に貢献できない理由。突き詰めれば１つだけです。自分達で管理できずに、安易に外部に投げているからです。管理できないシステムをたく
交渉や調整で「やってはいけない」いくつかのこと - GoTheDistance
インターネットの備忘録（はてなブログ版）にインスパイアされました。交渉や調整で、僕が感じている「やってはいけない」ことを、便乗して書いてみます。 1. 相手の面子を潰してはいけない 自分の主張を通す為には相手の言っていることの弱点を突いて｢あなたが間違っている｣というものだと仮に思っているのであれば、あなたは色んな人の面子を潰しまくることになりますので、利害が絡む交渉ごとは一切お引き受けにならない方がよろしいかと思います。交渉下手な人間は、利害に関する交渉で行き詰まると相手の間違いを非難する方向にいきやすく、それは結果として自ら交渉を難航させる種を散弾銃で乱れ打ちしていることになります。 感情と感情がぶつかったら、もうそれは交渉ではありません。口喧嘩です。 2. 間違い探しに終始してはいけない 交渉や調整ごとは、どっちが正しいか的な軸で考えてはいけません。自分が正しいかどうかは、関係ありま
僕の最初の起業が失敗した７つの理由について - GoTheDistance
10代で最初のWebサービスを立ち上げたけど失敗したNeil Patelさんのエントリが面白かったので、英語で分かるITトレンド風にお届けします。 My reasoning behind creating a job board was that if I could make 1% of Monster’s revenue I would be a rich kid. Sadly Advice Monkey never made any money and within two years I closed it down. 7 Reasons My First Business Failed Petelさんが立ち上げたサービスはjob boardのサイト(AdviceMonkey)と言うサイトだったそうですが、2年間1円の稼ぎも生み出さなかったのでサービスを終了したとのことです。以下、
IT業界に求められる営業の姿を考えてみた - GoTheDistance
IT業界の営業かくあるべき論 - Togetterが面白かったので首を突っ込んでみます。 上記で言われている営業は「パッケージ導入やオリジナルでの受託開発業をやっているシステム屋の営業」という前提のようです。僕もこの前提で書いていきます。 良く聞く話ですが、エンジニアからすると最たる不満の１つに「営業は不勉強」というのがあると思います。自分が売り込もうとしている商品が技術を武器にしているのにも関わらず、システムや技術のことを知らずに言葉だけで売るのはいかがなものか、という問題です。 これらの知識が無いと何がマズいかと言うと、 顧客の要望のインパクトがどれほどのものかわからない。 できない事に対する代替案が提案できない。 判断できることが少ないのでスピードが落ち、エンジニアに負担がかかる。 などがあります。 システムの営業の難しいところは、顧客のニーズはあくまでシステムがもたらす効用(ソリュ
もしもIT業界の下請け構造が崩壊したら - GoTheDistance
みんな死にかけるかもしれないよ。 ひがさんのSI業界からはさっさと抜けだしたほうがいいを読みました。SIには未来が無いという最後通告のような文面のようにも取れます。江島さんのニッポンIT業界絶望論と併せて読むと、言わんとしていることの輪郭がより鮮明になるかと思います。ご一読を。 非効率極まりない下請け構造でシステムを作る時代が過ぎ去り、プロがはじめから高い品質を提供できるSaaSの時代が到来しているよ、と。ユーザーは必要最低限の投資で済む為、よりスリムで堅牢な企業体になる。IT屋も全部自分で出来るしお客さんが喜んでくれて嬉しいよねというWin-Winなシナリオ。 これが仮に未来像としましょう。そうすると、ちょっと考えれば分かる。ITのサプライサイドにとっては、本当に難しい時代に入るってことが。SaaSの時代というのは、僕ら業界にいる人間にとってみれば「多産多死の時代」ではないでしょうか？変
アジャイルって受託開発との相性が最悪な気がする - GoTheDistance
全くもって、その通りだなぁと思った。 初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。 「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え － Publickey ｢ウオーターフォールとは｣のラベル貼りの議論になるとめんどくさいから、とりあえず｢初期段階ですべての意志決定をしようとするシステム開発の進め方｣という定義で話を進めたいと思います。 滝 ｢要件定義｣→｢設計｣→｢実装｣→｢テスト｣という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフ
エンジニアの未来サミット0905に行ってきた - GoTheDistance
0905：エンジニア・サバイバル | エンジニアの未来サミット … 技術評論社へいって来たので、速報レポ書いておきますね。 本当は遅刻せずに行くつもりが、本人限定郵便なるものが午前中に来なかったことと弊社社長に捕まってしまい色々コミュニケーションとってたら遅れてしまい、第1部は1時間ばかり最初見れなかった＞＜ 第二部は、後ほどの実況ログをぜひご覧ください！津田さんメソッド、やっぱりすごい有益。この言葉使うの申し訳ないんですが、｢tsudaりに行く｣だけでも結構価値があるんだなーと思った。 こういうイベントって、特定のテーマに沿ったカッチリした結論なんて絶対出ないと思うんですね。パネルなんか特にそうですし。で、200人近くいたら当然各々の問題意識やおかれている状況は異なる。そんな中で、何か1つでも拾って帰って頂けるような言葉・気づきさえあれば、僕はそれでいいんだと思います。その意味で、今回の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
