「了解しました」より「承知しました」が適切とされる理由と、その普及過程について | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
あなたは「了解しました」と「承知しました」、どちらをよく使いますか？ 【アンケート】 「了解しました」と「承知しました」、どっちを多く使いますか？ — 菊池良 / Kikuchi Ryo (@kossetsu) 2016年2月25日 ツイッターでアンケートしたところ、こんな感じでした。わずかに「承知しました」の方が多いですね。 この2つの言い回しですが、「了解しました」よりも「承知しました」を使う方が正しい、とよく言われています。 僕がこれを初めて知ったとき、強い違和感を覚えました。理由は 「了解しました」をよく使っていた 日常でもビジネスでも「承知しました」を使っている人を見たことがなかった ある日、急に言われ始めた からです。「承知」が日常的な言い回しではなかったので、気になったんですね。 そこで調べてみたところ、いつから言われ始めて、どういう経路で定着したのかがある程度わかりました。
行動（スリップ）によるヒューマンエラーの種類
以下に事例と対策を具体的に紹介します。 １．習慣化した動作 同じ動作を繰り返し行っていると身体が覚えてしまい、違う場面でも無意識にそれをやってしまう事があります。 事例 スリップの例 一日中会社で多数の電話を受けていると、家でもつい「はい、○×商事です。」と名乗ってしまう。 休日に一日中仲間とポーカーをやっていたら、翌日仕事で製品を数える時に、１，２…10，Jack，Queen，Kingと数えていた。 習熟することで習慣化 人は習熟のために長時間にわたって反復して行為を行います。最初は各々の行為やそれに関するルールを意識して行っています。行為自体はぎこちなくても、その行為は意識下でコントロールされています。そのため、失敗してもすぐに気がつきます。 それが習熟するにつれ、一連の行為は無意識にできるようになります。そして、ムリ、ムダ、ムラなくできるようになり、ルールは意識しなくなります。それま
『錯覚の科学』が想像以上に凄い件について : マインドマップ的読書感想文
錯覚の科学 (文春文庫) 【本の概要】◆今日ご紹介するのは、3年半前に出た単行本が、未だ値崩れしていない作品の文庫版。 アマゾンレビューを見ても軒並み高評価ですし、当時なぜ本書を手にしなかったのか、悔やまれるほどの濃厚な1冊でした。 アマゾンの内容紹介から。「えひめ丸」を沈没させた潜水艦の艦長は、なぜ“見た”はずの船を見落したのか。ヒラリーはなぜありもしない戦場体験を語ったのか。―日常の錯覚が引き起す、記憶のウソや認知の歪みをハーバードの俊才が科学実験で徹底検証。サブリミナル効果、モーツァルト効果の陥穽まで暴いた脳科学の通説を覆す衝撃の書! 思わず付箋も貼りまくり！ なお、タイトルは「ホッテントリメーカー」作なんですけど、気持ち的にはその通りであります！ some guy in traffic on his cell phone. / Jim Legans, Jr 【ポイント】■1.運転中
ロジカルシンキングの弱点を考えてみた：ロジックを超えたロジックの話 – 佐藤航陽のブログ
ロジカルシンキングについて日頃から思っていた疑問をサクッと書いてみました。Wikipedia先生に聞いてみると、ロジカルシンキング（論理的思考）とは、 一貫していて筋が通っている考え方、あるいは説明の仕方のこと ビジネス書では、 物事を体系的にとらえて全体像を把握し、内容を論理的にまとめて的確に伝える技術 なんて説明されてたりします（定義は議論があるところですが、ここでは触れません） 現代社会の多くの意思決定において、ロジカルシンキングはとても大事です。例えば、社内で新規事業をする時に担当者がプレゼンする場合や、経営者が投資家に説明する場合などです。 筋が通らない矛盾があれば却下されるでしょうし、大多数が 納得できるようなロジカルな説明ができれば、意思決定はスムーズに進みます。 このロジカルシンキングの弱点は、他人を説得する際には絶大な力を発揮する一方で、物事の成否を見極めるには、それほど
エンジニアを定量化なんてしてはいけない - smellman's Broken Diary
ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ 話の発端は、 俺がDMTCについて知ってること，またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。 内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。 僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること このつながりを活かして、 国内外のIT企業で働くエンジニアのスキルを定量化しよう というひとつのテーマにいきつきました。 http://maximum80.me/archives/821 この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。 ものさし
2020年のエンジニア像 ～ エンジニアがこの先生きのこるには？ で話してきました - UNIX的なアレ
5/16(金)にCTOによるCTOのためのこんなイベントで話してきました。 http://peatix.com/event/33718 前半のプレゼンテーション CTOという立場である以上、自分自身が技術者としてどうあるべきかだけでなく会社の風土をどうしていくべきか。そしてその風土に合わせてどういう人を採用していくべきかという仕事が出てきます。 今回はそのあたりに焦点を絞ってお話をしました。第一部でつかった資料はこちらです。 他社さんの事例もすごく興味深かったです。特に、cookpad舘野さんのエンジニアの評価基準の話はすごく具体的で参考になりました。 後半はパネルディスカッション 後半は、パネルディスカッションです。他社さんの事例がいろいろ聞けたのは個人的にもすごく勉強になりました。 「めんどくさいおじさんにならないようにしよう」「成功体験おじさんにならないようにしよう」みたいな感じです
老害が「害」と言われる本質は正しいフィードバックを受けられないまま固定観念を強めて他者に「呪い」をかけるから - 太陽がまぶしかったから
photo by Tiggrrr42 老害の本質 大学の恩師に会社辞めたいって言った。 とりあえず５年がんばれという定番の説教をくらった。 これまでお前みたいな学生をたくさん見てきた。お前とは経験が違う。 そういわれてしまうと反論できない。 誰にも分からない未来の話をするとき、経験の寡多を問題にするのは卑怯だ。 読みました。「老害」的な考え方については仕事をはじめとした様々な場面で相対することがありますし、私もある意味では「老害」扱いされても仕方がない事をしている自覚があります。 例えば、基幹系システムの運用開発においては既に多数のステークホルダーを巻き込んでしまっており、「失敗しない」が最重要視されます。その前提においては、僅かに生産性を上げるためにやりかたを変えて、そのトレードオフで失敗の確率を上げるぐらいなら短期的には不合理であってさえも現行踏襲を選ぶべきだという保守的な意識が強いで
自分の考えに賛同してもらえない時に「伝え方の問題」だと態度に出すのは影響力ゲームの負けパターン - 太陽がまぶしかったから
「伝え方の問題」じゃやない 科学的事実や数学などの明白な論理が通用する分野ではない事において、自分の考えに賛同してもらえない時に「伝え方の問題」だと最初に考えてしまうのは危険だと思う。殆んどの人は殆んどの場合において、結論部分が正しく伝わっているからこそ手放しで賛同できないわけで、そこを疑えない態度を見せられると余計に心が醒めていって、影響力ゲームの負けパターンになる事が多い。 「よーく考えて」「話せば分かる」「ちゃんと理解してない」もそうで、同じ結論にならないのは情報量の差異によるものだと思い込んで、とにかく参考情報を伝えようとしても無駄である。必要なのは自身の内部的なプロセスを伝えることではなく、相手の結論部分の差異から逆算して相手側のロジックに乗っかることであろう。その上で補正可能かどうかを見極めないと考えを改めることはまずない。 相手の立場に立つだけでは意味がない 相手の立場になっ
「頭おかしいぞ！」はイノベーションの瞬間（かも）
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 「イノベーション」とは、多くの企業が掲げ、大多数の経営者が口にする言葉である。そして、多くの場合、それは掛け声のみであって、実態が伴うことはない。なぜならば、イノベーションという概念には誰もが賛成するが、“イノベーションを実行に移すこと”には多くの人が反対するからだ。 4月9～10日に開催された新経済サミット2014において、Oracleの最高経営責任者（CEO）Larry Ellison氏は、他の人が誰もやっていないこと、つまりはイノベーションを実行に移そうとすれば、頭がおかしいんじゃないかと言われるが、それは本当にすごいことを見出したのか、あるいは頭がおかしいかのどちらかであるという趣旨の発言をした。つまり、イノベーションを起こそう
自分の思考のクセという「箱」から出たいときに参考になる５冊 - ビジョンミッション成長ブログ
自分の思考のクセはありますよね。考え方が習慣になっている。 よく言われるのは、マイナス思考とプラス思考がありますよね。 スキーマ（思考のクセ）を知る方法 - 黒猫のひとりごと わたしもこういうことをこのところ考えているところでした。 批判的に考えることが良いこともありますし、プラス思考で考えることが良いこともあります。状況によるところがあるでしょうし、状況を見ながら両方考える。 視野の広さが大切だと感じています。自分が知らないこともあると考えてみることがとくに大切ですね。なぜなら、全部が見えている、わかっているわけではないですから。わかっていない中で判断すると、適切な判断はむずかしいでしょう。 で、自分の思考のクセ、自分の「箱」から出たいときに参考になる本を紹介します。 自分の思考のクセという「箱」から出たいときに参考になる５冊 １ 自分の小さな「箱」から脱出する方法 ２ BCG流 最強の
デザインの科学『インタフェースデザインの心理学』
「ファミコン『ドラゴンクエストIV』のパッケージイラストの主役が、一番小さく描かれているのに、最初に目に入ってくるのはなぜか」 これについて、中村佑介氏の解説が目鱗だ→【イラストの見栄えが良くなる】中村佑介先生の公開講座が凄い！。本来は目立たせたいもの（主役）を大きく描くのが原則だが、彩度とコントラストを増やすことで、見やすい画面作りをしているという。 だが、もう一つ、このデザインには「主役」を主役たらしめるテクニックがある。それは以下の通り。 1. 人は、人の顔に一番興味を持つ 2. 人は、画面の中で、顔を最初に見る 3. 人は、画面の顔の視線の先に注意を向ける この原則を知ったのが、本書だ。人はどのように認知し、判断し、行動し、そしてエラーを引き起こすのかについて、ウェブやアプリのデザイナー向けに、「100の指針」という形でまとめたもの。 「嘘のレベルは伝達手段で変わる」や、「読むと理
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） - やまもといちろうBLOG（ブログ）
【書評】『なぜ、システム開発は必ずモメるのか？ 49のトラブルから学ぶプロジェクト管理術』（細川義洋・著） 読んでいて、実用書なのに涙が止まらない本に巡り会えたので謹んでお奨めさせていただきます。 その名も、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』。何がヤバイって、いちいち掲載されている項目がヤバイ。いきなり「何度も要件を追加してくるユーザ」ですよ。まるで弊社の某顧客ではないですか。 大項目からして「設計」から「プログラミング」、「テスト」とか進む先々にびっしりと地雷が敷き詰められているんだろうなあと悪い汗をかかずにはいられない世界が広がり、最後にはお決まりの「契約」。いやー、読んでいてぞくぞくしますね。特に「仮発注書だけで作業に着手してしまったら？」とか、なんか見透かされているようですよ。まあ、業界的には往々にして起きがちなことを一般論として書い
ウェブエンジニアの生存戦略 - mizchi's blog
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
「怒鳴っても人間は変わらない！」史上最悪の工場を変えたシンプルな教え【LHベストヒッツ】 | ライフハッカー・ジャパン
誰かがミスをすると私たちは腹が立ち、怒鳴ることもあります。怒る理由はミスをした人の行動を変えたいためです。しかし、いくら怒っても彼らの行動は変わらないどころか、反抗的になることさえあります。 100万人以上のメンバーが所属する非営利政治活動グループ「Demand Progress」の設立者で代表のAaron Swartz氏は、「重要なのは人間を変えることではなく、仕組み（システム）を変えること」と述べています。 今回はSwartz氏が米・ゼネラルモーターズ社（以下、GM）の事例をもとに「史上最悪の工場を変えたシンプルな教え」について語ります。 米・ゼネラルモーターズ社の実験 米・カリフォルニア州フリーモントにあるGMの工場は最悪の状態でした。当時の労働組合長は「戦いの毎日でした」と振り返ります。「働いている時間より抗議活動をしている時間の方が長かったのです。ストライキは日常茶飯事で、毎日が
ストレスを加速！エンジニアを駄目にする魔の座席表｜【Tech総研】
「会社に来ると気が重い」「仕事に集中できない」「上司とうまくいかない」ストレス状態にハマッたエンジニアたちのオフィス。その間取りや雰囲気にはどんな共通点が……？ エンジニアを蝕むオフィス環境について取材した。 私たちが毎日長～い時間を過ごすオフィス。その環境は、働く側のストレスに影響するらしい。そう、ときには自殺に追い込まれることも……。 企業のオフィス環境に詳しい認定ファシリティマネジャーの住吉正勝氏によれば、ある座席レイアウトを採用した企業では、一時期、自殺者が多発したそうだ。 「当時その会社では、真っ白な壁を前にして学校の教室のように机が並び、いちばん後ろに管理職が座るというスタイルを採用していました。社員を後ろから、監視する形になっていました」（住吉氏） 別の外資系企業では、エンジニアのワークスタイルに合わない座席レイアウトのせいで彼らのモチベーションが下がり、一時期、離職者が増え
プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 （家族や友人などプログラムを知っていない人間に話しても分からない、という事もある） プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
残業をしない会社を作るために - GoTheDistance
みんな大好き社畜ネタ。表題に書いていることは全く同感。 長時間労働・サービス残業は自分の価値を下げ企業存続を危うくする | Act as Professional - hiroki.jp 個人レベルなら残業は搾取なので逃げろで済むんですが、会社を変えようとすれば「労働者のレベルは一定水準のレベルに言っているのに、組織としての労働生産性はクソ」という現象をまじめに考えざるを得ない。その時に感じたことを書き連ねます。 長時間労働やサービス残業については、まず根本的な問題として、個人の自助努力で減らせる残業には限界があることを認識しないといけない。自分が生産性を上げて頑張っても、誰かの仕事を待っていたら残業が大きく減ることはない。底が空いたグラスに幾ら水を注いでも、ねぇ。個人レベルにおいて残業を減らそうとすると、頑張るのではなく頑張らないのが最も合理的になるというのが実際の所。僕もサボリーマンレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ログミーBiz
一生懸命働いていますか？
