ロジカルシンキングで開発要求に応える
「無茶な追加開発の要望を断りたい」「新しい開発プロセスを受け入れてほしい」。ITエンジニアが直面しがちなこれらのシーン。論理思考を生かした説得術で乗り越えよう。 出典：日経SYSTEMS 2014年1月号 pp.50-57「困った時に役立つロジカル説得術」 記事は執筆時の情報に基づいており、現在では異なる場合があります。 新たな取り組みを社内関係者に認めてもらいたい 新しい技術や開発プロセスをプロジェクトで採用するには、上司や経営幹部といった社内の関係者の説得が必要になることが多い。新しい技術やプロセスの採用には失敗のリスクが伴う。こうしたリスクに敏感な上司は、既に実績が豊富な手段の採用を求める姿勢になりがちだ。大規模なシステムとなればなおさらである。 2016.11.10 ユーザーに問題解決の優先順位を認めてもらいたい 受け入れテストで不具合が相次いで見つかり、利用部門の担当者から「すべ
悪文と良文から学ぶロジカル・ライティング 目次
ITエンジニアにとって文書作成技術は欠かせません。日常のメールのやりとりにはじまり、要件定義書、機能仕様書、企画の提案書など、上司やチーム、顧客などに対して、文章でコミュニケーションをとる機会がとても多いからです。 本連載では、論理的にわかりやすい文章を書く「ロジカル・ライティング」のノウハウを伝授します。ITエンジニアが日常的に用いるであろう文章を例に使い、どこが悪くてどう直せばいいのかといったポイントをわかりやすく解説します。実践すれば、誰でもすぐにわかりやすい文書が書けるようになるはずです。 連載目次 ●オリエンテーション ・ITエンジニアにとって「書く技術」とは？ ●文書の全体構成を組み立てられるようにする ・内容を大きく分けて項目を立てる ・適切な順番で項目を並べる ・話の階層をそろえる ●文章表現の基本ルールをマスターする ・主語と述語を対応させる ・修飾語と被修飾語をはっきり
IT Pro 記者の眼 : 昔の“常識”，今の“非常識” - ハンガリアン記法について
かつては“常識”だったのに，今ではそうでなくなっている――ソフトウエア開発の世界では，そんな知識や習慣がめずらしくない。10年以上のキャリアを持つ開発者の方なら，思い当たるものがきっとあるはずだ。 例えば，昔は「すでに動作しているコードに変更を加えてはいけない」というのが常識だった。汚いコードに手を入れようとして先輩にしかられた経験のある方もいらっしゃるだろう。ところが今では，「リファクタリング」の名のもとに将来問題が発生しそうなコードを修正する作業がむしろ推奨されている。EclipseやJBuilderなどのリファクタリング支援機能を搭載した開発環境も増えており，今やリファクタリングは完全に市民権を得たと言ってよいだろう。 オブジェクト指向技術の浸透，変化が大きな要因 もちろん，常識が変わった背景にはオブジェクト指向開発の浸透といった開発手法の変化があることは間違いない。あらかじめアプリ
1つの仕事で3日間に100本のメールを書きながら心の平衡を保つ方法
相当な量だと自分で思った。1月28日から30日にかけて送受信した電子メールの件数である。2014年から請け負っていた、ある仕事が大詰めを迎え、50社を超える企業と連絡を取り合った。その仕事に関連して送受信したメールの件数をざっと数えてみると、受信が28日に49件、29日に43件、30日に70件、合計162件。発信が28日に37件、29日に20件、30日に40件、合計97件。この原稿を書いている1月31日に、メール用ソフトウエアの画面に表示された件名を数えただけなので、実際に読んだり書いたりした件数はもっと多い。1件について数回やり取りしている場合があるからだ。しかも、これら以外に様々な仕事に関係する連絡、ITpro編集部が原稿を編集し投稿する際の諸連絡、企業のニュースリリースなどが送られてくる。 普段からかなりの件数のメールを読み、返事を書いているが、1月末の3日間は滅多にない体験だった。
第１回 100％テストしました！？
（ユーザー企業にて） 情報システム部 S部長：先週カットオーバーしたばかりなのに、もうバグが出たそうじゃないか。 開発会社のPM：軽微なものでしたし、そんなに心配いらないと思います。 S部長：100％テストするはずじゃなかったのかね。 PM：その通りです。100％テストしたと報告を受けています。 S部長：おかしいじゃないか？ 100％テストしたのなら、なぜテストでバグを見つけられなかったんだ？ 実は「ちゃんとテストしていない」なんてことはないだろうな。 PM：そんなことはないと思いますが、確かに説明が欲しいところですね。 （開発会社にて） PM：今回は100％テストするということだったのに、「なぜバグを見逃したのか説明しろ」とS部長が言ってきている。本当は100％やってないんじゃないかと疑っているふうだった。 ITエンジニア：そんなことないですよ。約束通り新規の機能はちゃんと全部テストしま
オープンブック・マネジメント
経営指標の徹底した公開、財務関連の教育研修、権限委譲、成功報酬制度などによって従業員の自律的な行動を促し、企業を活性化しようとする経営思想。 最近、会社員の間で「誰でも分かる決算書」といった類の書籍が人気です。景気の先行きがここまで不透明になると「ウチの会社や取引先は大丈夫なのか」と心配になります。決算書の読み方を一から勉強して現状を確認したいという気持ちが、こうした書籍を購入する動機の1つなのでしょう。 経営者としては、従業員が会社の業績に関心を持つのは歓迎すべきことです。いまや、従業員が経営者と同じ視点で考え、自ら判断し、積極的に行動するような企業でなければ、厳しい競争に勝ち残れないからです。 ◆効果 従業員が自ら動く 1990年代後半から米国で注目され始めた「オープンブック・マネジメント」とは、自社の従業員に財務諸表をはじめとするあらゆる経営指標を公開しようという経営思想です。良い数
プロジェクト・マネージャの「やってはいけない」---目次 - プロジェクト・マネージャの「やってはいけない...：ITpro
プロジェクト・マネジメントのアンチパターンを徹底解説 プロジェクト・マネジメントにはセオリーがある。セオリーを知らずに，あるいは軽視して，失敗するプロマネは少なくない。現場でたたき上げたベテランの凄腕PMが，現場でプロマネがやってはいけないことを解説する。 関連サイト： ■メール編 ■やる気編 ■要件定義編 ■会議編 ■報連相編 ■協力会社対応編 ■品格編 ■課題管理編 ■変更管理編 ■コミュニケーション編 ■外注管理編 ■姿勢・資質編 ■計画＆進捗管理編 ■品質編 ■姿勢編 理由無き要求は機能化してはいけない プロジェクト事務局を軽視してはいけない 過去の成功体験にとらわれてはいけない 自己研鑽を怠ってはならない 目的を忘れてはいけない ■プロジェクト完了編 完了条件をあいまいにしてはいけない 完了報告会を省いてはいけない 成功・失敗要因を不明確なままにしてはいけない フィードバックを忘
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PMO（プロジェクトマネジメントオフィス）を生かす