「書く」のは特別な道具 - naoyaのはてなダイアリー
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
議事録の書き方 Part2 : LINE Corporation ディレクターブログ
はじめまして。１月入社、ネトアニ等担当しているタカハシと申します。 部署の中で一番の新入りなので、定例会議等の議事録をよく作成しています。 議事録については、すでに「議事録の書き方 基礎講座」という名エントリがあるのですが、今回は、その続きを勝手に書いてみたいと思います。 初心者向け、そして、部署内の定例など、それほど形式ばっていないミーティングでの議事録を対象にした内容です。 議事録を作成するメリット 議事録の作成を依頼された時、「面倒だな」と思ってしまっていませんか？ 特に、入社したばかりで同じ部署の人の名前ですらうろ覚え、取引先の会社名なんて聞いたこともない！という状態だと、メモを取ろうにも皆が何を言っているかまったく分からなかったりしますし。 しかし、議事録を作成するという使命を持って会議に臨むと、 ・理解しようと一生懸命になる ・手を動かすことで記憶しやすくなる というメリットが
苦情メールに返信するとき意識すること - 頭ん中
ウェブのサービスを運営してると ご立腹の方からメールをいただくこともある。 そういうメールにご返事をする場合に これを意識しておいた方がいいな、 と思っていることをいくつか。 もちろん事情はその都度違うので いつも同じ対応をするということではないけど、 基本的な考え方として。 たとえ正当な訴えでなかったり 単なる誤解に基づくものであったりしても ちょっとの配慮で穏便に済むならその方がいいですね。 できるだけ早く返信する 時間が経てば経つほど 「無視された感」が高まって 余計によろしくないことになってしまうから。 すぐにご返事できないときは 「すぐにご返事できないのであらためて」と すぐにご返事する。 できることとできないことを明確にする 何らかの対応を求められていて その要求が正当なものである場合、 できることがあるなら 何ができるかを明確に伝える。 ただし、どう考えても正当な訴えではなか
MOONGIFT: » テキストから各種ドキュメントへ変換する「txt2tags」:オープンソースを毎日紹介
開発用のドキュメントと、提出用のドキュメントと二つ書かなければならないことがある。どちらも似たような内容だが体裁が異なる。だがそのためにコストをかけるというのは非効率的だ。 テスト文書 この手のソフトウェアは数多く存在するが、開発ドキュメントの管理にWikiエンジン（DokuWikiなど）を使っているなら、これの利用はありかも知れない。 今回紹介するオープンソース・ソフトウェアはtxt2tags、一つのテキストフォーマットから各種文書形式に変換するソフトウェアだ。 txt2tagsはすでに7年も開発が行われているソフトウェアで、テキスト文書から各種ドキュメントに変換する機能がある。特にWiki（Wikipedia/MediaWiki形式）、gWiki（Google Code向けWiki）、DokuWIki、MoinMoinのWiki系フォーマットに対応しているのが利点だ。 HTMLでの生成
ブロガー必見！ 文章上達のための 12 と1/2のルール | Lifehacking.jp
12 and ½ Writing Rules | Pick the Brain な、長かったです…。こんなに苦労をしたのは博士論文を書いた時以来かもしれません。何かというと、夏あたりからずっと続けてきた一つのプロジェクトに、今日やっと一区切りを打つことができたことです。 最近ブログを書くペースが落ちていた理由は、このプロジェクトの最後の調整にかかりきりで、なかなか時間がとれなかったからだったのですが、それだけの犠牲を払ったこともあって、満足のゆくものができあがりました。 まだ詳細は書けませんが、「原稿用紙200枚くらい」といえば、なんとなくその作業量に納得していただけるのではないでしょうか。 文章を書くことはとても楽しいのですが、「楽しい」と思える部分は最後にやってくるというのが辛いところです。その途中は、「ああしよう、こうしよう」と何度も何度も書き直しをする連続です。 「もっと上手に文章
文章の書き方 - あどけない話
2006年に IIJ の新人研修で「文章の書き方」という講義を担当しました。そのときの資料を何人もの人に個別に差し上げていたのですが、それも面倒になってきました。新人研修の担当者に問い合わせたところ、公開しても問題ないとのことでしたので、資料を公開します。 「文章の書き方」の資料
テキストに知性があるかないかを見分ける10のポイント - ハックルベリーに会いに行く
面白いとは何だろう？「知識」のプライオリティは下がっている町山智浩さんのブログを読んでいたら、興味深い一節に突き当たった。 オイラはものをあまりよく知らない。昔はそれを恥ずかしく思っていたし、よくバカにされてきた。でも、今はなんとも思わない。なぜなら、ネットの時代、知識は誰でも簡単に拾えるようになったので、知識そのものに価値がなくなったからだ。いや、それは言い方が違うな。本当に物知りなのか、ネットで拾っただけの知識なのか見分けることが困難になったからだ。ちょこちょこっと検索して、それを散りばめれば物知りに見える文章は作れる。「鎮」という漢字が読めない知ったかぶり「雑学王」 - ベイエリア在住町山智浩アメリカ日記 なるほどこれは確かにそうかも知れない。インターネットやIT機器の発達で、情報というものはこれまでと比べて格段と調べやすく、また引き出しやすい環境になった。だから、以前のようにそれを
なぜ「勉強はできたのに仕事はさっぱりな人」がいるのか？：IT＆ウェブ業界の転職をサポートする「CAREERzine」（キャリアジン）
メディア部門では、インターネットで加速するメディア環境の中で、翔泳社が得意とするテーマを深掘りしながら様々なドメインで最適化されたメディアビジネスを展開しています。
こどものもうそうblog | 文章を書いたらチェックしたい17の項目
Selected Entries 文章を書いたらチェックしたい17の項目 (09/18) Categories WORKS (594) 講座 (236) game (153) BOOK (373) computer (23) iPhone&iPad (2) MOVIE (48) music (38) News Dig (23) PLAY (136) publication (52) web (20) web game (26) すごいよ！ (45) カード (15) ゲームをつくろう (3) ゲーム実習 (14) コックリさん (11) 気になるの (109) 写真 (24) 日々 (128) 萌え発想 (32) Archives August 2017 (1) April 2017 (1) December 2016 (1) November 2016 (1) October 2016
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
業務フローとデータ・モデリングの設計のコツがいよいよ公開
ITベンダー9社が参加する業界団体「実践的アプローチに基づく要求仕様の発注者ビュー検討会」は2008年3月18日、外部設計を発注者に分かりやすく進めるガイドラインを公開した。業務フローとデータ・モデリングの2つだ。同日開催した記者会見では、今後の普及展開活動を情報処理推進機構（IPA）のソフトウェア・エンジニアリング・センター（SEC）が引き継ぐことも明らかにした（写真）。 ガイドラインは設計書の書き方とレビューの進め方の“コツ”を体系化したもの。外部設計手法そのものではない。業務フロー設計を進めるための「システム振る舞い編」では35個の書き方のコツと23個のレビューの進め方のコツを記述した。同じく、論理データモデル設計を進めるための「データモデル編」では書き方で16個、レビューで31個のコツを記述した。 ガイドラインの目的などを記した「概説編｣と、ガイドラインを読み進めるための用語30個
perldoc.jp
このサイトは Perl の公式ドキュメント、モジュールドキュメントを日本語に翻訳したものを表示するサイトです。 サイト内の翻訳データは、有志が翻訳しているperldoc-jp/translationから取得しています。 最近の更新 / RSS commitログから最新の50件を取得しています。稀に翻訳者とcommitした人が違う場合があります。また、修正のcommit、登録しただけで未翻訳のものも含まれる場合があります。 2024-02-04 github.com ppc0018-module-true / melonsode 2024-02-03 Data::Dumper Dumper(2.183) / melonsode 2024-01-25 github.com ppc0016-indexed-builtin / kobaken 2024-01-08 perlclassguts(5.
超便利！ ビジネスに役立つ無料サイト： いつでもどこからでもオンライン上の文書にアクセス、共有も可能！「Googleドキュメント」
● ここがオススメ！ 文書作成、表作成、プレゼンテーション作成機能を持ち、オンラインで使える無料のWebアプリケーション。馴染みやすいメニューや右クリックによる操作で、オフィス系ソフトに慣れた人ならすぐ操作が把握できる。オンラインでさっと作成して、複数ユーザーでの文書共有や、共同編集にも対応する。Webページとして公開も可能だ。 ● Googleのアカウントを取得すれば、誰でも無料で利用可能 「Googleドキュメント」は、オンラインで使える無料の文書作成・共有サービスだ。Googleのアカウントを取得すれば、無料で誰でも利用可能だ。 作成した文書などのデータはオンライン上に保存しておけるため、作業場所を選ばない。1つのデータを共同で編集したり、あるいは複数の共有ユーザーに閲覧だけ許可指定する機能を持つ。作成したファイルは、そのままGoogleドキュメントに保存するほか、ハードディスクなど
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
5分で人を育てる技術 (25)“文書が上手いと言わせる”5つのテクニック(中篇)：芦屋広太一つ...
・先方より，当方が提示した処理画面の操作性が問題なので，見直してほしいとの要望があった。 ・上記については，当方にて検討することで了承いただいた。 ・また，先方から，社内の情報提供に使いたいので，弊社が提供するシステムの機能と画面イメージをメールで送ってほしいとの要望があった。 ・上記については，後日メールする旨返事をした。 ・東氏より，当方のシステムを使ってみたが，非常に分かりやすいとの感想があった。弊社のシステムは特に問題ないのではないかと思われる。 ・戸塚氏からは，上司に説明したところ，テストについてもよろしくお願いしたいとの指示があったとの話があった。 ・これに対し，当方からは，一緒に相談しましょうと回答した。 ・次回の打ち合わせは来週の水曜日くらいとの話になったが，その日は東氏の都合が悪いかも知れないとの話になり，結局，その場では決められなかったため，後日調整しましょうという話に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.lpi.or.jp/linuxservertext/
Linux JF (Japanese FAQ) Project. (Japanese)
実践的アプローチに基づく要求仕様の発注者ビュー検討会 - NTTデータ
[Think IT] 【楽々デブドックを書こう！】開発☆ドキュン