旧館より

あるサービスについて、メールで問合せた時の話です。その返答には「××についてのお問い合わせは○○部の木村(仮)にまで」とありました。この名字しか記述がなかった部分に「？」と思いました。同じ部署に同姓の人がいても対応できるのでしょうか？サービ...

システム開発の要素の1：新規開発(スクラッチ)と2：保守開発(機能追加)があります。#保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。新規開発はその名前の通り「一から」システムを作り上げていき、生み出されるソースコー...

外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。そこではある要求仕様が、その該当画面(とそこで定義されている機能)...

仕事、プライベートを問わず人をどのように呼んでいますか？TPOによりますが大きく分けると2つに分かれます。1：「鈴木さん」「佐藤君」「田中ちゃん」(笑)と固有の名前で呼ぶ人。2：「君(きみ)」「あなた」「お前」と固有の名前で呼ばない人。呼ぶ...

あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断す...

「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。1：全体像を見れない人、見ない人自分の担当分以外...

以前の「未来の自分を信頼し過ぎない」ことを書きました。とはいうものの、何でもかんでもドキュメント化するのではなく、いくつかの要因(例として必要度合い)から判断して作るか決めれば…とも書きました。私は、その判断基準に一つに「(その事柄について...

プログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。この「他者」には、そう遠くない「未来の自分」も含まれています。が、けっこう忘れてしまいがちです。色々な理...

IDEA*IDEAのミーティングで使えるちょっとした話法いろいろを読んで会議の費用対効果について考えたことです。会議の目的一口に会議といっても、色々な種類や目的があります。1：ディスカッションやブレーンストーミング結論が出すことに無理に執着...

以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。　　KPT法の優れている点は以下の3つと思います。1つ目：...

仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。↓は自分が教える = 伝え手の場合に気をつけていることです。1：論理や順序の飛躍をしない当たり前なのですが、せっかちな人程してしまいが...

(プロパー、パートナー問わず)始業ギリギリ(1,2分前)にバタバタと出社して来る人がけっこういます。#フレックスの人は悠々～って感じですが。始業時間になればすぐに仕事をするか？と言えばパソコンも起動中だったりします。パソコンが起動してからも...

にて狩野分析法というものが紹介されていました。「Agile開発で～」と書かれていますが、Agileで無い場合でも使えそうです。実際には政治的な要因を始め様々な要素があるので、そうそう全て上手くは行かないかもしれませんが、少なくとも客観的判断...

プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。言いたいこと仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコードとそれらドキュメントとの乖離を出さないように...

最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。サロゲートキーとナチュラルキー主キーの設定時に大きく2つの設計指針があります。1つは顧客マスタにおける顧...