＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- ＠IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
仕事と国語力
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-09-03 15:55
るぱんです。
バランス良く・・・じゃないですか？ 一部の人には我慢ならない話かも知れませんが。。。 バランス良くって、一番難しいと思います。 | ||||||||
|
投稿日時: 2004-09-03 16:24
NAL-6295です。
個人的に、手段としてよく
太字の方を取りますね。 やる気のある伸びる人は、標準化された中身を見て成長してくれるかなという期待もあります。 勿論、やる気の無い人も、それに則って作業してみたら案外うまくできたことで気をよくしてやる気出してくれないかな。という期待もあったりします。 #欲張りかなー _________________ 「伝える」とは「人に云う」と書く。 http://d.hatena.ne.jp/NAL-6295/ | ||||||||
|
投稿日時: 2004-09-03 16:46
るぱんです。
パターン化標準化をしていくと、 「パターン化されているんだから誰でも出来るだろう？」 とパターンをどんどんこさえていく人も片方では存在しますよね。 全体量との兼ね合いによると思います。 僕は全体量と、重要度と比べて判断するようにしています。 重要な所は認識していれば、「敢えて手作業」とかもたまに織り交ぜたり・・・。 | ||||||||
|
投稿日時: 2004-09-04 01:52
「思ひて学ばざればすなはちあやふし」というわけで、古典的名著には
目を通しておいたほうがよいと思うですよ。 あと、プレゼンテーションにしてもディベート術にしても、それはそれで 大事なことですが、もとの話からはあさっての方に飛んでいって しまってるような... それはさておき。 説得力のある報告書とはどんなものか？なんてことを考えてみると... 「見たままの単なる事実に対して考察を加えて、根拠に支えられた 意見（主張）を立てる」ということができているかどうか、ってのが 重要なポイントのひとつでしょう。 # ドクサからエピステーメーを立てる、とゆーことです。 で、これはたとえばトラブル解決のときにやっているのと同じ ことなわけで。 | ||||||||
|
投稿日時: 2004-09-04 10:14
それを具体的な構造としてあらわすとピラミッド構造になるんですけどね、このあたりのくだりは、このスレで記述しました。このあたりについてもっと勉強したいあるいは 問題発見、問題解決の一般論みたいなことを知りたいというのであれば、これらの本をお勧めします。 ちなみに私は読んだだけで、あんまり実践していません（笑） 考える技術・書く技術―問題解決力を伸ばすピラミッド原則 http://www.amazon.co.jp/exec/obidos/ASIN/4478490279/qid=1094259839/ref=sr_8_xs_ap_i1_xgl/249-7173070-0450734 問題解決プロフェッショナル「思考と技術」 http://www.amazon.co.jp/exec/obidos/ASIN/4478490228/ref=pd_sim_dp_1/249-7173070-0450734 問題発見プロフェッショナル―「構想力と分析力」 http://www.amazon.co.jp/exec/obidos/ASIN/4478490341/ref=pd_bxgy_text_2/249-7173070-0450734 | ||||||||
|
投稿日時: 2004-09-04 13:27
ども、ほむらです。
やっぱ皆さん国語とプログラミングって関係が強いって思っているんですねぇ。 僕なんかだと国語と言うよりもいろんな意味での丁寧さの方が ポイント高いんじゃないかなと思っていたりするのですが。。。 最近だとプログラムに関しては何をするのか何のための処理なのかを 本人が理解せず仕様書だけで組み立てているような場面もあるみたいですけどね^^;;; ---------- (古い話でごめんなさい＞＜) はゆる氏へ
プログラミングのスキルを上げる方法は人それぞれだと思います。 記述部分以外への影響度を考えられないのか。 そもそもプログラム自体を組み立てることが出ないのか。etc 何ができないのか。 まずはそれを本人達で発掘させれるようなことを考えてみたらどうでしょう？ それをするために僕が一番有効だと思うのがつっこみですね^^;; 答えを言うのではなくて、質問する形でのつっこみです。 具体的にはどうなっている？とか。こうした場合にここはどうなる？など すでにやっているかもしれませんが、つっこまれないように努力させる事ができれば ＝スキルアップということになるんじゃないでしょうか? ぼくの場合だと 考えることの大切さ も しみこませていくことができたらなぁと自分の下にいる子達にも願っていたりします。 るぱん氏
議事録についてはその先輩の考え方と僕も同じです。 僕はいつも議事録には決定事項・課題(宿題)とその完了期日・議事内容を分けて 書いてもらうようにしています。 理由は議事録を見れば後で簡単に状況を理解できるからです。(知らない人であっても) 特に、決定となぜそうなったかの議事内容は大切だとおもいます。 (知らない人には理由もなく決定されたことになるため) すでに決定したことについて変更があるのならそれはそれで必然なのかもしれません。 だけど以前の決定がなぜ下されたのか、 それに対して今回の変更後の決定は妥当なのかという比較も必要ですよね。 議事録には一般的な書式なる物がないので難しいところと言えば難しいと思いますけど 書くべきところは書くべきじゃないかなと思います。 ＃ 書類作成がヘタな人に議事録書かせてみると修行になるかも ＃ 赤入れで書き直しに近くなるかもしれないけれど(笑 ＃ 議事録って難しい。。。 | ||||||||
|
投稿日時: 2004-09-04 13:43
ども、ほむらです。
-------- ぽんず氏へ
提出する相手にもよるかと思いますけど絵にして表現することもポイントかな思います。 文章では抜けていても見落としがちであったりごまかされたりしても 絵にしてしまうと表現されていないことが表現されますから。 それを読み取れることも一つのスキル(or経験)だと思いますし。 ＃報告書と言うよりは資料といった意味合いの方が強いかもしれませんが。。。
あと、独りよがりにならないこと。かな？ むかしＴＲＰＧという遊びをしていた時代に思ったことは 他人は自分が思っているほど自分の考えを理解してくれないと言うことでした。 その関係で僕が文章とかで説明するときにはなるべく 読み手の想像が介入しないようにしているつもりです。 ＃それでも抜けがあるのは経験不足と言うところでしょうか(笑 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.