プロフェッショナルなら政策メッセージを使え - かとじゅんの技術日誌
あけましておめでとうございます。今年もよろしくお願いします。 引き続き、ロジカルシンキングの話。前々回、前回と論理の基礎をざっくりと述べた。 同僚や上司、顧客から、納得を得るために必要なこと 〜演繹法〜 同僚や上司、顧客から、納得を得るために必要なこと 〜帰納法〜 これ以上深い論理学の観点には触れずに、、、今回は論理的な表現としての「メッセージ」（命題ともいう）について触れたい。*1 メッセージのタイプは４つあります。 事実メッセージ 評価メッセージ 政策メッセージ 希望メッセージ 簡単に説明すると、 事実メッセージは、単なる事実を述べる命題。 評価メッセージは、ある事柄に対する自分の評価を述べる命題。 政策メッセージは、政策を提言したり、何かアドバイスする命題。 希望メッセージは、依頼や希望を述べる命題。 となる。 この4つのメッセージを理解すると、コミュニケーションや意志決定が円滑にで
ブコメとコメントについての回答 - なからなLife
そろそろ内製回帰について一言いっておくか。 - なからなLife について、結構いろいろな反響をいただきましたので、そのいくつかについて、こちらにまとめてレスしていきたいと思います。 開発者は、自分たちが作っている製品なり商品をもっと分り易く伝えなくてはならないね。 http://b.hatena.ne.jp/imai78/20091225#bookmark-18144775 内製でも外製でも、アピールはもっとやっていい（やるべき）と思います。 ござ先輩のエントリにも 経営は基本的に技術屋のことなんかわかるわけないんですよ。 http://d.hatena.ne.jp/gothedistance/20091226/1261808023 という一文があるとおり、相手が勝手にわかってくれるようになるのを待つんじゃなくて、こちらからわかってもらうためのアクションが大事だと思います。 経営者に伝わ
そろそろ内製回帰について一言いっておくか。 - なからなLife
最初に、誤解のないように宣言しておくが、自分は内製回帰厨である。 だがしかし、 受託モデルのSIerよりも価値を出せない内製部隊なんかイラネ。 システムを作ること自体が目的化している内製部隊なんかイラネ。 何のためにシステムを作るのか？ 何のために内製部隊としてそこに存在しているのか？ 作業の手戻りを気にして、利用者が要求仕様を固めないと動けないとか、使い勝手の悪い仕様を押し付けてくるとかするのは、内製外製問わずクソだと思うが、内製の方が乗り換えが効かない分タチが悪い。 仕様は「もらう（受動）」じゃない、「まとめる（能動）」だ。 仕様をもらってコードに落とすことしかできないなら、低賃金人海戦術なアジア各国との単価競争にさらされて当然だ。 内製エンジニアは受託のエンジニアに比べ、仕様をまとめる活動に際して有利な条件、環境が与えられている。 会社間のカベがないことで、いろいろな情報を拾いやすく
SIer にとっての最新技術 - SiroKuro Page
最新技術を一式、SIer に与えるとする。 まずは RoR を与えてみよう。「RoR で作れば生産性が高まる」という噂を聞いて、SIer は興味を持つ。そして【自分のやりたいことが RoR で実現可能か否か】を調べはじめる。実現できなかったら【どのようにすれば RoR で実現できるか】を調べはじめる。そして RoR は SIer に使われずに終わる。SIer の生産性は元のままだ。SIer がしたかったことは、独自の規約を作ることだった。独自規約が RoR の規約と衝突し、結局のところ RoR は使用されたが活用はされなかった。 次に、適当な KVS を与えてみる。実行速度が上がるという噂を聞いて、SIer は興味を持つ。しかし KVS から手を引くのはとても素早かった。高度な SQL が動かせず、また諸々の政治的理由により【安価な】 KVS は【高価な】 RDBMS に敵うことはなかった
ポタージュを箸で飲む技術 - SiroKuro Page
「ご飯はちゃんとお箸で食べなさい」と躾られて以来、素直にそれを守っている SIer 「箸で食事することが日本古来の伝統だ」と習慣や風習を頑固に守っている SIer 「この箸は両親の形見なんです」と箸自体に特別な意味を見いだす SIer そういう SIer が、いざポタージュを食卓に出されると、箸でポタージュを飲もうと四苦八苦をし始める。 「箸を使う技術力が試される時だ」と自らを奮い立たせるが、そんな技術力を試して欲しいなんて周囲は全く望んでなんかいない。 苦労して得られるものは満足感しかない。 とある SIer は先割れスプーンを発明した。 また別のとある SIer は、ポタージュをマグカップに入れることを考案した。 彼らは四苦八苦する SIer を尻目に、有意義な食事を楽しんでいる。 そんな「ひとつ抜きん出た SIer」にならなければならない。 多くの SIer は、目の前にあるのがポタ
第2回 開発力の向上工期半減を目指す
開発期間半減に向けた七つの取り組み 倍速開発は七つの取り組みで実現する。開発工程だけでなく、要件定義段階からメスを入れて効率化を図る。 「要件定義段階のミスは、大きな手戻りにつながる。上流の作業品質強化は生産性向上の必須条件だ」と、技術開発本部副本部長の木谷強ソフトウェア工学推進センタ長は話す。 上流作業の強化の一環で、同社が来年4月から本格的に開始するのが、要件定義書のレビューだ。技術開発本部が各プロジェクトの要件定義書に点数を付けて客観的に評価する（図2）。 点数を付けるために、同社はまず、「要件定義書に何を記載するべきか」を規定。同社の開発標準や国際標準のドキュメントを参考にし、全5章、18節からなる「要件定義ガイドライン」として昨年9月に作成し、さらに採点の仕方を「要件定義書スコアリング手順書」としてまとめた。 ソフトウェア工学推進センタの大杉直樹シニアエキスパートは「形式的に正し
Google App Engineでコードを書くと、処理のひとつひとつが課金に見える
先週末、ちょっとしたプログラムをGAE/Jで動かして実際に使ってもらってみたのですが、そうすると、いままでテストでちょこちょこやってたときには全部のDaily Quotaが0%だったものが、数%の数字を示すようになります。 これを、ちゃんとプロモーションして多くの人に使ってもらおうとすると、課金が発生したり制限にひっかかったりしそうです。 で、たとえばDatastore APIの呼び出し回数がヤバいとして、API呼び出しを減らすためにキャッシュしようとすると、MemcacheのほうのAPI呼び出し回数がヤバくなってきます。 で、じゃあということでデータストアにデータを置くようにすると、保存量の制約で課金がかかってきます。で、それならと、データストアに置くのはシリアライズしたデータにしてデータ量が最低限になるようにすると、今度はその処理をするためのCPU時間で課金がかかってきます。 コードを
着実に進むビジネスインテリジェンスの利用
ITmedia エンタープライズとITRは「ビジネスインテリジェンス」の読者調査を10～11月に実施した。過半数の企業がビジネスインテリジェンスの利用に前向きであり、活用も過去に比べて進んでいるという実態が明らかになった。 ITmedia エンタープライズと調査会社のアイ・ティー・アール（ITR）は10月下旬、「ビジネスインテリジェンス（BI）」に関する読者アンケートを実施した。6割以上の企業がビジネスインテリジェンスの利用に前向きな姿勢を示していることや、現場のスタッフを中心にツールが使われていることが分かった。ビジネスインテリジェンスの活用も過去の調査に比べて進んでいる。データ分析の利用形態や利用企業の感想なども踏まえて、企業の現状のビジネスインテリジェンスの活用動向を考察する。 調査概要 目的：企業のビジネスインテリジェンスツールの活用や今後の導入意向を考察するため 調査方法：Web
第12回 価値を描くための“自分改革”
ビジネスとITの摩訶不思議な世界を“創発号”に乗って旅する匠Style研究所。第9回から前回までは、価値の正体を追い求めてきました。今回からは、企業の問題から離れて、自分自身を見つめる旅になります。会社の問題や課題の前に、自らを見つめ直し“自分改革”を起こしてみましょう。それはきっと会社の問題解決や、本質的な課題発見につながることでしょう。 今回は、みなさんの自分改革のきっかけになるよう、僕が取り組んでいる自分の中での改革について話しましょう。みなさんの自分改革に、少しでも参考になれば嬉しいです。 価値を描いていないエンジニアリング 僕自身が仕事に物足りなさを感じていた頃は、「画期的なプログラミングをしたい」とか、「ユーザーの要望を実現する素晴らしい設計をしたい」とか、「もの凄くためになる開発方法論を作りたい」などと思っていました。そのような夢を追い続けてはいましたが、何か物足りなさを感じ
“ITゼネコン”という言葉は、とてつもなく失礼だ！
最近、コンピュータ・メーカーや大手システム・インテグレータを称して“ITゼネコン”というらしい。しかし、これはとてつもなく失礼な言い方だ。もちろん、建設会社に対して、である。 少し前だが、ある中堅ゼネコンの情報システム担当者と会ったとき、そのゼネコンの社長がシステム・インテグレータに対して激怒したという話を聞いた。その“事件”の発端自体は、システム開発が遅れ納期に間に合わなくなったという、ITサービス業界にはお馴染みのものだ。しかし、その話を聞いた社長は、担当のシステム・インテグレータを許せなかったという。納期に遅れそうでも、どんなことしてでも間に合わせるのが仕事。その社長の常識からいうと、システムの納期遅れなど信じられない事態だったらしい。 「ゼネコンのプロジェクト管理能力はすごい。我々はその足元にも及ばない」。大手システム・インテグレータからも、そうした声が漏れてくる。実際、建設業界は
第3回 「大企業だから」「中堅だから」という固定的発想ではダメ
情報システムの“ユーザー企業”にとって、情報システムをどう活用すれば競争力を強化できるのか。ITベンダーやシステム・インテグレーターなどの営業トークや提案内容を見極めるうえで何に留意するべきか。ITベンダーなどに何かを求める以前に、“ユーザー企業”が最低限考えなればいけないことは何か――。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、情報システムの“ユーザー企業”の経営者・担当者の視点から、効果的な情報化のための発想法を解説する。 第1回と第2回で、情報システムの活用を誤るダメな“ユーザー企業”の3つのパターンのうち、「流行に踊る“ユーザー企業”」と「業種で物事を考える“ユーザー企業”」の2つを挙げました。 ダメな“ユーザー企業”の3つ目のパターンは、会社の「規模」で物事を考える姿勢です。 この姿勢は、企業規模が
2009-11-21
雨はないかなぁ〜 朝晩は寒そう なんとなく寝る前に思いついた言葉 続きを読む 朝起きた直後にふと思いついた言葉 続きを読む
業務知識の豊富さをアピール 見積料金の見直しに腐心
自社の知名度の向上やパッケージソフトの拡販につながりそうな案件だ。業務知識を武器に、商談は順調に進んだ。ところが見積額と顧客の予算に1000万円の開きがあった。 「この案件を受注できれば、関東地区では無名に近かったアイルの知名度を一気に高められる。何としても受注したい」。 大阪市に本社を構える中堅SIerであるアイルのシステムソリューション事業部大阪営業グループねじ製造・流通チーム係長である樋口隆洋は、こう意気込んだ。電子機器用ねじなどの生産・販売を手掛ける、神奈川県のユニオン精密に声を掛けられた、2008年2月のことである（表）。 このとき、ユニオン精密は生産管理システムの再構築を検討していた。同社の取締役で工場長を務める雨森和彦は、アイルに打診する以前からシステム構築の委託先の選定を進めていたのだ。 雨森は有力候補として、ITベンダーのA社とB社に絞り込んでいた。だが、いずれの提案も決
過半数が要求精度向上図る---利用企業が進める満足度向上策
中でも最も多い取り組み策が，「発注先に伝える要求の精度を高めている」こと。回答件数は，半数を超える896件である。要求をしっかりと固めて発注することが，情報システムや，それを構築したIT企業に対する満足度を高めるというわけだ。 要求精度を高めるといっても，その具体的な取り組み策は様々だ（図2）。以下では，代表的な取り組み策を紹介する。 要求定義は利用者の義務---JTB 「IT企業に“ITのプロ”としての義務を果たしてもらうためには，我々利用者にもやるべきことがある」──。JTBの野々垣典男IT企画部長は，利用企業が果たすべき役割の存在を，こう強調する。 野々垣部長が指摘する利用者の義務とは，「要求定義」である。情報システムに求めることを明確にしたうえで，IT企業に提示する。そこでは，あいまいさをなくし，IT企業に伝えた要求がぶれないようにする。 利用者からの要求が変わらなければ，開発途中
ワークVSライフ＝デスマーチ：プログラマで、生きている：エンジニアライフ
10月のお題は「就活生からの『ITエンジニアの仕事についての質問』」ということですので、ワークライフバランスとデスマーチについて、わたしの考えをちょっと書いてみます。 IT業界に足を踏み込もうとしている方々の関心事の1つに「ワークライフバランスを保てるのか」というものがあるらしいです。 この業界は私生活を犠牲にして仕事に捧げている人ばかり、とか思われてるんですかねえ。個人的には、どの業界だって似たようなもんで、IT業界だけが特殊ってことはないと思ってるんですけど。 わたしは「仕事（残業）と私生活の両立はうまくいっているか」と問われたら、「だいぶうまいこといってる方だと思う」と答えます。 今の会社に入って3年ほど経ちますが、1カ月で20時間を超えたのが1回、10時間を超えたのが1回、年の半分以上は残業ゼロという状況です。有給休暇もきっちり全部消化します。世間様が想像するプログラマライフから、
業務システムの再定義－閑話休題（３） (mark-wada blog)
役に立つためのシステムがもつべき要件 これまでビジネスの役に立たないシステムを作り続けたというようなことを書いたが、役にたたないシステムとはどんなものを指しているのだろうか。逆に役に立つシステムの要件とは一体何なのだろうか。 そこで一応つぎの3つを上げることにしている。 1．ビジネス要求をはじかないこと 2．とにかく安いこと 3．継続的な改善ができること 最初の「ビジネス要求をはじかないこと」というのは、こうしてほしい、こんな機能があるといいと言ったのにできあがったら実現できていなかったので使わないといったことがないようにという意味である。 ここには2つの問題があって、要求定義をしてもそれがどう実装されているのかを確認するのがずっと先になるということと、実現手段がないことがあるということである。実現手段がないならないと言わないといけないし、実現手段があったとしてもすぐに見せなくてはいけない
ミッションクリティカルに仮想化は使えるか？
ミッションクリティカルに仮想化は使えるか？：仮想化時代のビジネスインフラ（7）（1/2 ページ） 仮想化技術はミッションクリティカルシステムには使えない――そんな意見をよく耳にするが、本当にそうなのだろうか？ 周りの意見や評判をうのみにせず、自ら調べ、考えれば、仮想化技術を生かす領域はまだまだ広がる。 仮想化技術は重要なシステムには向いていない？ コスト削減という目的をきっかけに、多くの企業がサーバ仮想化に取り組んだことで、仮想化技術は“使って当たり前”のものになりつつあります。これに伴い、ユーザーの関心事も「仮想化技術とは何か？」から、「仮想化技術はどこまで使えるのか？」といったレベルに移行しつつあるようです。 そんな中、よく耳にするのが「比較的重要度の低いシステムなら問題ないが、取引先が絡むようなミッションクリティカルシステムには、仮想化技術は使えない」といった意見です。ミッションクリ
素人が素人のまま仕事を出来てしまう - みねこあ
PHP はやはり良くないツールなのかもしれないと思いました。 私は PHP のことを良く知らないので、単なる「思いました」なのですが、PHP に関するいろいろなエントリと、私の ASP での底辺開発現場の経験を ミックスすると、どうもそのような気がしてくるのです。 これまで 「PHP 酷い」を聞いても、それでも PHP 自体に罪はなさそうにおもっていたけれど、今回はじめて「実は PHP にも罪があるんじゃないかしら」と疑問におもった次第です。 そんな疑問のきっかけになったのは、関数禁止令です。 * * * 筋肉炒飯 - 【逆説】PHP を使いつつ思考停止をすると頭脳が腐敗する さんのエントリはなんかすごくデジャブで、一連の PHP ネタの中では、群を抜いた共感度 No.1 でした。 私が見たのは ASP での開発現場でしたが、 別に他のプログラミング言語であれば劇的に改善するというものでは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『内製する以上は｢すごい｣ものを作らなければ、意味が無い。 - GoTheDistance』へのコメント
自分戦略研究室 ― ＠IT自分戦略研究所