改善 テストにおけるバグレポートの書き方
あるプロジェクトで「テスト工程の管理全般」が大きなミッションとしてありました。具体的には、テスターが起票したバグレポートを確認し、「する/しない」「するのであれば、いつまでにどのチームがやるか」などをスケジュールやリソースの状況を見て判断す...
改善 
ソフトウェア開発 プロジェクトの種々なこと
「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て…と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。1：全体像を見れない人、見ない人自分の担当分以外...
旧館より 文書化の指針
以前の「未来の自分を信頼し過ぎない」ことを書きました。とはいうものの、何でもかんでもドキュメント化するのではなく、いくつかの要因(例として必要度合い)から判断して作るか決めれば…とも書きました。私は、その判断基準に一つに「(その事柄について...
ソフトウェア開発 未来の自分を信頼し過ぎない
プログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。この「他者」には、そう遠くない「未来の自分」も含まれています。が、けっこう忘れてしまいがちです。色々な理...
改善 会議の費用対効果
IDEA*IDEAのミーティングで使えるちょっとした話法いろいろを読んで会議の費用対効果について考えたことです。会議の目的一口に会議といっても、色々な種類や目的があります。1：ディスカッションやブレーンストーミング結論が出すことに無理に執着...
旧館より 最高のプレゼンテーション―心をつかむ見せ方、話し方[読書感想]
最高のプレゼンテーション―心をつかむ見せ方、話し方プレゼン ＝ 「パワポ(PowerPoint)を作らな！！」＋「本番でのしゃべり！」となるのがだいたいの感じだと思いますが、この本はプレゼン ＝ (構成の善し悪しももちろん)始まる前の準備、...
改善 KPT法を使う場合に気をつけること
以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。 KPT法の優れている点は以下の3つと思います。1つ目：...
旧館より 教えてもらう、教える時に気をつけていること
仕事やバレーで教えてもらったり、教える(そこまでいかなくてもアドバイスする)ことが、ちょくちょくあります。↓は自分が教える = 伝え手の場合に気をつけていることです。1：論理や順序の飛躍をしない当たり前なのですが、せっかちな人程してしまいが...
旧館より 仕事に対する心構え
(プロパー、パートナー問わず)始業ギリギリ(1,2分前)にバタバタと出社して来る人がけっこういます。#フレックスの人は悠々～って感じですが。始業時間になればすぐに仕事をするか？と言えばパソコンも起動中だったりします。パソコンが起動してからも...
ソフトウェア開発 日常の意思決定にも使えるかも…狩野分析法
にて狩野分析法というものが紹介されていました。「Agile開発で～」と書かれていますが、Agileで無い場合でも使えそうです。実際には政治的な要因を始め様々な要素があるので、そうそう全て上手くは行かないかもしれませんが、少なくとも客観的判断...
ソフトウェア開発 ドキュメント修正の大事さ
プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。言いたいこと仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコードとそれらドキュメントとの乖離を出さないように...
ソフトウェア開発 テーブル設計の指針(備忘録)
最近、DB設計やデータモデリング等のDB周辺について集中して触れることがあったのでテーブル設計における指針を備忘録として書いておきます。サロゲートキーとナチュラルキー主キーの設定時に大きく2つの設計指針があります。1つは顧客マスタにおける顧...
旧館より 仕事が10倍速くなる最強の図解術[読書感想]
仕事が10倍速くなる最強の図解術報告書やプレゼン資料を作成する際に、図解化することで抜けや漏れが無いか(MECE)、また説得力のある論理構成になっているか？を確認し、質の良いものを造り出しましょうという内容の本です。※見栄えが良くなるレイア...
改善 自分が議事録を書く際に気をつけていること
「議事録」は社内外の会議、打合せ、レビュー等のアウトプットです。良い議事録を書く留意点、テクニックは色々あり、例えば…1営業日以内に書く記憶は曖昧で、かつ、あっという間に別のタスクが入ってくるので、早めに関係者に配布し、必要なアクションを起...
旧館より 昔は良かった？
年上の人と話すと、割と誰しもが感じる「昔は～だった」について、「自分もこうなったらあかんな」と自戒を込めて書きます。年上の方と話していると、時々「昔は…だった」という話が出てきます。昔の話を聞けるのは、自分の知らない年代、経験を知る事が出来...
日常 インプットとアウトプットのバランス
仕事ではインプットに対してどのようなアウトプット(成果物)を出すかが大事です。一握りの創造性豊かな人以外にとって、そのアウトプットの元ネタとなるインプットが存在していることが大半です。インプットは、書籍から、また、莫大な情報があるインターネ...
旧館より テスト工程
…とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。しかし現実は単体テストレベルのバグがわんさか…1日50個とか…出て...
旧館より Javaの格言―より良いオブジェクト設計のためのパターンと定石[読書感想]
仕事でJavaを使ってのシステム構築をしています。勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。で、思い立って以前に買って積読していた↓をちゃんと読んでみました。■(Javaの格言―より良いオブジェクト設計のため...
旧館より できるだけ文字を打たないことでミスを少なくする
文章やプログラムを書く時に効率性や質の向上の為に自分なりのルールや注意していることがあります。1つは前に書いた文章の揺らぎです。もう1つは低レベルな話ですが「出来るだけ文字を打たない」ことです。要件定義書や設計書等では同じ単語や文言(例：「...
旧館より エンジニアの特徴って高い「知的好奇心」
以前「お医者さん」だって全部の病気を知らないでしょ？で書いた「(知らないアプリケーションについて)頑張ればそれなりに答えれる事もありますがそれをしない理由」(ややこしい言い方)を自分なりに書きます。結構偏った見方かもしれませんが、自分を含め...