スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
開発工程でSEが書く文書の基本 − ＠IT自分戦略研究所
「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 SEはさまざまな文書を作成する必要があります。その中でも、提案書や要件定義書の作成に悩むSEは多いようです。なぜなら、これらは「顧客に読んでもらわなければならない文書」だからです。 本連載では、「誰にでも分かる」提案書や要件定義書を作成するための文章術を解説します。ただし、分かりやすい文書を作成するには、文章術だけでは十分ではありません。必要な情報を顧客から引き出すためのコミュニケーション、文書全体の構成も重要です。 第1回では、SEが作成する文書はどのようなものかを概観します。第2回では、情報を引き出すための顧客とのコミュニケーションのポイントを説明します。第3、4回
アーキテクトを目指すITエンジニアのための「要求分析」：Road To IT-Engineer / ITエンジニアの生きる道：エンジニアライフ
前の方が質問されているように、最近は変化が多く激しく感じます。 社内外統廃合による人事、新技術発表による変化など始めにこれで決定したはずですとはなかなか言えない状況です。 要求仕様からさらに基本設計など後工程も変化するはずですから、いちいち書き直すのは膨大な手間隙がかかります。 変化にすばやく、なるべく負担をかけずに対応する方法があるならお聞きしたいです。 インドリさん、 高橋です。多忙にしていて返答が遅れました。大変失礼しました。 要求分析についてのアウトプットが多いので、後々の変更要求に対応するのが大変ではないか、というご質問と理解しました。 要求分析の成果物は基本的に要求モデルのみと考えています。 (私の場合、ロジックツリーの目的/手段での階層表現) 記述のあった関与者利害関連表、WHYツリー、流れとつなぎ図などは、要求をまとめるための手段という位置づけです。 そのあたりの説明は次回
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
