旧館より 同姓同名がいることを想定する あるサービスについて、メールで問合せた時の話です。 その返答には「××についてのお問い合わせは○○部の木村(仮)にまで」とありました。 この名字しか記述がなかった部分に「?」と思いました。 同じ部署に同姓の人がいても対応できるのでしょうか?... 2008.06.07 旧館より考え方
日常 「従業員」満足度調査 本人が望む、望まないは別として「顧客満足度調査」等のようなアンケートに答えたことが1回はあると思います。 その兄弟で「従業員満足度調査」なるものがあります。 「自分の会社にどれほど満足しているか1~5段階で教えてね」というそのまんまなもので... 2008.05.13 日常旧館より
ソフトウェア開発 ペアプログラミング―エンジニアとしての指南書[読書感想] ペアプログラミング―エンジニアとしての指南書 著者:Laurie Williams, Robert Kessler 翻訳:長瀬 嘉秀, 今野 睦, テクノロジックアート 今の小規模プロジェクトで、ペアプログラミングをしていました。 2人チー... 2008.05.12 ソフトウェア開発旧館より書籍
旧館より 新規開発と保守開発に求められる要素の違い システム開発の要素の1:新規開発(スクラッチ)と2:保守開発(機能追加)があります。 #保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。 新規開発はその名前の通り「一から」システムを作り上げていき、生み出されるソース... 2008.04.16 旧館より開発プロセス
ソフトウェア開発 仕様を縦断する視点、横断する視点 外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。 レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。 そこではある要求仕様が、その該当画面(とそこで定義されている機... 2008.04.15 ソフトウェア開発旧館より
旧館より 「名前」で呼んでいますか? 仕事、プライベートを問わず人をどのように呼んでいますか? TPOによりますが大きく分けると2つに分かれます。 1:「鈴木さん」「佐藤君」「田中ちゃん」(笑)と固有の名前で呼ぶ人。 2:「君(きみ)」「あなた」「お前」と固有の名前で呼ばない人... 2008.04.14 旧館より考え方
旧館より 速効!SEのためのコミュニケーション実践塾[読書感想] 速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS) 著者:田中 淳子 私が定期購読している雑誌「日経SYSTEMS」の前身である「日経ITプロフェッショナル」の初期に連載を加筆、修正して単行本化したものです... 2008.04.07 旧館より書籍
改善 テストにおけるバグレポートの書き方 あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。 具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断... 2008.04.06 改善旧館より開発プロセス
ソフトウェア開発 プロジェクトの種々なこと 「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。 1:全体像を見れない人、見ない人 自分の担当分... 2008.03.30 ソフトウェア開発旧館より
旧館より 文書化の指針 以前の「未来の自分を信頼し過ぎない」ことを書きました。 とはいうものの、何でもかんでもドキュメント化するのではなく、いくつかの要因(例として必要度合い)から判断して作るか決めれば…とも書きました。 私は、その判断基準に一つに「(その事柄につ... 2008.03.21 旧館より考え方
ソフトウェア開発 未来の自分を信頼し過ぎない プログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。 この「他者」には、そう遠くない「未来の自分」も含まれています。が、けっこう忘れてしまいがちです。 色々... 2008.03.05 ソフトウェア開発旧館より考え方
改善 会議の費用対効果 IDEA*IDEAのミーティングで使えるちょっとした話法いろいろを読んで会議の費用対効果について考えたことです。 会議の目的 一口に会議といっても、色々な種類や目的があります。 1:ディスカッションやブレーンストーミング 結論が出すことに無... 2008.02.28 改善旧館より考え方
旧館より 最高のプレゼンテーション―心をつかむ見せ方、話し方[読書感想] 最高のプレゼンテーション―心をつかむ見せ方、話し方 プレゼン = 「パワポ(PowerPoint)を作らな!!」+「本番でのしゃべり!」となるのがだいたいの感じだと思いますが、この本はプレゼン = (構成の善し悪しももちろん)始まる前の準備... 2008.02.10 旧館より書籍
改善 KPT法を使う場合に気をつけること 以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。 ※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。 KPT法の優れている点は以下の3つと思います。 ... 2008.01.22 改善旧館より開発プロセス
旧館より 教えてもらう、教える時に気をつけていること 仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。 ↓は自分が教える = 伝え手の場合に気をつけていることです。 1:論理や順序の飛躍をしない 当たり前なのですが、せっかちな人程してし... 2008.01.08 旧館より考え方
旧館より 仕事に対する心構え (プロパー、パートナー問わず)始業ギリギリ(1,2分前)にバタバタと出社して来る人がけっこういます。 #フレックスの人は悠々~って感じですが。 始業時間になればすぐに仕事をするか?と言えばパソコンも起動中だったりします。 パソコンが起動して... 2007.12.25 旧館より考え方
ソフトウェア開発 日常の意思決定にも使えるかも…狩野分析法 にて狩野分析法というものが紹介されていました。 「Agile開発で~」と書かれていますが、Agileで無い場合でも使えそうです。 実際には政治的な要因を始め様々な要素があるので、そうそう全て上手くは行かないかもしれませんが、少なくとも客観的... 2007.12.17 ソフトウェア開発旧館より
ソフトウェア開発 ドキュメント修正の大事さ プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。 言いたいこと 仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコードとそれらドキュメントとの乖離を出さないよ... 2007.12.13 ソフトウェア開発旧館より
ソフトウェア開発 テーブル設計の指針(備忘録) 最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。 サロゲートキーとナチュラルキー 主キーの設定時に大きく2つの設計指針があります。 1つは顧客マスタにお... 2007.11.29 ソフトウェア開発旧館より
旧館より 仕事が10倍速くなる最強の図解術[読書感想] 仕事が10倍速くなる最強の図解術 報告書やプレゼン資料を作成する際に、図解化することで抜けや漏れが無いか(MECE)、また説得力のある論理構成になっているか?を確認し、質の良いものを造り出しましょうという内容の本です。 ※見栄えが良くなるレ... 2007.09.01 旧館より書籍