左のメモを見て、あなたはどのようなことが理解できたでしょうか？　「そもそも読む気がしない……」、そう感じた人もいるでしょう。 ビジネスパーソンや学生に限らず打ち合わせや講義、セミナーなどの発表内容などをメモすることは大変重要なことです。しかし、実際にメモのとり方を観察していると、ほとんどの人は個条書きでメモをとっています。自分が聴いた内容のキーワードのみ、あるいは大事だと思ったキーフレーズを、淡々と記録しているだけです。みなさんはどうですか？　自分の記録したメモを取り出して、いま一度確認してみてください。自分が聴いたこと、理解したことがすぐに思い出せましたか？ 個条書きメモは多くの問題を抱えています。すべて「文字」で書かれているために、一見してその内容や要素、関係性などをつかむのが容易ではありません。そのため、中身に含まれている問題点や解決策を発見しづらいという難点があります。さらに、記憶

「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回

Q:　個人事業主でSEをしていますが，契約を切られることが増え自信をなくしています。個人事業主で続けていくには限界があるのでしょうか？ スキルアップのため，個人事業主でSEをしていますが，ここ数年，二重派遣などの契約問題で，現場を切られることが増えました。 現場にアサインされたら，チームリーダーや時にはプロジェクト・マネジャーの補佐役として管理系の仕事を任されるので，スキルが原因ではないことは明らかですが，こう立て続けに契約を切られると自信をなくしてしまいます。 また，収入面での安定性も得られないため，社員や契約社員への転向も考えています。個人事業主で続けていくには限界があるのでしょうか？何か良い対策方法があれば，アドバイスをお願いします。 （SE／男性・37歳） A:　自分への自信を失うな。営業が不安なら，営業力のある仲間を集めよ 今回の金融恐慌が始まる以前から，IT業界では金融業界を中

友人から以下のようなメールが送られてきて、ホントなの？と聞かれた。 1. プログラマがコードを書く。バグはないと信じている。 2. 製品テストが行われて30個のバグが発見される。 3. プログラマは20個のバグを修正し、残り10個はバグではないとテストチームに説明する。 4. 再び製品テストが行われ、バグ修正の結果5つの機能が正しく作動しなくなっていることが発見される。さらに15個の新たなバグが発見される。 5. 上記の工程3、4を数回繰り返す。 6. マーケティング部が楽観的な開発計画に基づいた製品発表を行ったことや、営業部からの圧力により、製品が時期尚早に出荷される。 7. ユーザにより100個のバグが発見される。 8. プログラマが他社に転職する。 9. 緊急で新たに開発チームが組織され、ほぼすべてのバグを修正する。 その過程で新たに500個のバグが生まれる。 10. テストチームの

基礎的な学力を表す言葉として読み書きそろばんという言葉があるが、 私はプログラミングについても読み書きそろばんに当たるものがあると思っている。 まず読みというのは、プログラムを読む能力である。 たまに、人の書いたソースを見て、すぐに 「全面的に書き直さないと使い物にならない」とか、 「グチャグチャですよ」とか、 「気持ち悪い」といったことを口にする人がいるのだが、 多くの場合、なぜそのように感じるのかを聞いてみると、 単に自分が今まで書いてきたコードと違ったスタイルで書かれている、 ということだったり、ごく一般的なデザインパターンが使われているのに、 そのデザインパターンを自分が知らないだけで 「わかりにくくて読めない」などと言っていたり、 人のコードを使い物にならないと簡単に口にする人であればあるほど、 その人自身が使い物にならない、という傾向がある。 もちろん、全体の整合性を取るために

Webでコンテンツを表現する決まりである共通言語のHTML。世界共通語であるHTMLがここまできた道のりを知っておこう。 HTMLはコンテンツを表現するための決まりですが Webページ制作にかかわるすべての方向けのHTML超入門。前編の「まずはHTML。ハイパーなタグ付き言語」に続く後編ですので、まだ読まれていない方はそちらからお読みください。超初心者向けにHTMLが表現できることを説明しています。 前編で、HTMLが「画像やテキストなどのコンテンツをWebページに再現するための共通言語」であることがご理解いただけた方向けに、後編ではHTMLを取り巻く周辺技術についてさらに説明をしたいと思います。 Webの世界が一般的なものになって10年以上がたちます。ずっと一線で活躍していたHTMLにもいろいろと足らない部分が出てきました。足らない部分をどのような技術や思想で補ってきたかを見てみましょう

筆者はSEマネジャのあり方について，当プログで「SEマネジャはお客様を訪問せよ」「部下に任せよ」などと何回となく言及してきた。それは，SEマネジャがIT企業のビジネスを遂行する技術陣の要と考えるからである。IT企業では，この要のSEマネジャが強いと顧客からSE陣が信頼され，プロジェクトや提案活動はうまくいく。また，SEをチャレンジャブルなジョブにアサインでき，SEが成長し戦力も強化できる。これには読者の方も異論がないはずだ。 だが，現実のIT業界を見ると必ずしもそうではない。顧客を訪問しないSEマネジャ，営業に便利に使われているSEマネジャ，SEを顧客に塩漬けするSEマネジャ，部下のSEと技術的な会話がろくにできないSEマネジャなどもいる。筆者はそんな現状を鑑み，SEマネジャに“SEマネジャ頑張れ”という気持ちと，IT企業の経営陣に対しては“これでよいのか”という想いを伝える趣旨で書いてい

自由な発想を促すマインドマップ マインドマップとは、英国・ロンドン出身のビジネスコンサルタント、トニー・ブザン（Tony Buzan）氏が1970年代の初めに発案、提唱した「ノート記法」です。 言葉を時系列に個条書きにする一般的なノート記法とは異なり、まず中心に主題を配置し、そこから関連するキーワードやイメージを放射状に広げていく方法を取ります。 人間の思考パターンに合わせて開発されたマインドマップは、自由な発想を促し、ブレインストーミングに最適なツールであるといえます。そのためコンサルタントやプランナーなどを中心に広まっていますが、本来は職種や業種を問わずに利用することができるものなのです。

Twitterも調子悪けりゃ、はてなも調子悪そうですねえ。Twitterはやっと過去ログ見れるようになったと思いきや、突然気絶するし、はてなもスターとブックマークとハイクが日替わりランチ状態で不調。ま、なんとか正常に戻ったようですけどねえ。関係者の皆様、お疲れ様です。 ただ、このあたりのトラブル対応を見るに、正直言ってもったいないなあと思うところがあります。ワタクシは外食や宿泊などのサービス・接客業勤めが長く、「申し訳ございません」（＠高嶋政伸）奉行だったせいもあって、このあたりのトラブル対応にもったいなさを感じるのですよ。クレーム対応のイロハみたいな大げさな話じゃなくて、その手前の「お客様を怒らせないコツ」というのかな。 そこで今回は「ユーザーを怒らせない障害解決方法」について書いてみたいと思います。僭越ながら、特にはてなさん向けに。いつも利用してるわけなんで、是非お役立ていただけたら幸

こんにちは、大橋です。 教わり上手な人の8つの「TIPS」 が紹介されていましたので、私なりの教わるコツを伝えてみたいと思います。 なぜ、あの人には教えたくなるのか？　教わり上手な人の8つのTIPS 教える側も感じ方が様々ですので、すぐに上の記事にある8つの項目を試してもいい反応は得られないかもしれません。 楽しそうな表情も、教え側からするとにやついていると思われかねず、「TPO を考えなさい」とむしろ怒られてしまうことだって考えられますね。 ここは、ある程度の信頼関係が築けている関係であることが前提条件で、前述の項目を踏まえてお話を進めてみたいと思います。 【01】質問上手になれ 話し上手な人は意外にも聞き上手であるとよく言われます。程よいあいづちやフォローをしつつ、相手を気持ちよくさせて色々な話題を聞き出すことができるからです。 教えてもらう場合であれば、効率よく、かつ時間を有効に使い

それは、コンピュータは必ず壊れるということ。 先日拝聴した香取貴信氏の講演で聞いたことから、ずっと頭に残っている言葉がある。それは、「ディズニーランドのアトラクションが機械の故障で動かなくなってしまった場合、アメリカ人はリアクション大きく悔しがるが案外あっさり諦めてくれる。しかし、日本人は決して納得してくれない」といった感じのこと。 これを聞いたとき、私はとっても頷いた。アメリカ人についてはどうか知らないが、日本人にいたっては－少なくとも私の思う限りでは－まだコンピュータ完ぺき主義が残っていると思う。コンピュータはちゃんと動いて当たり前なんて思っている人を、まだまだ見かける。 こう思ってしまうのもきっと、かつて「安全と水はただで手に入る」と言われた国だからなんだと思う。マスコミの情報を鵜呑みにしがちな面もそうで、“そこに在るものは正しい”って思っちゃうんだと思う。でも、そんなことは絶対にな

昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保