改善 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 旧館より書籍
改善 自分が議事録を書く際に気をつけていること 「議事録」は社内外の会議、打合せ、レビュー等のアウトプットです。 良い議事録を書く留意点、テクニックは色々あり、例えば… 1営業日以内に書く 記憶は曖昧で、かつ、あっという間に別のタスクが入ってくるので、早めに関係者に配布し、必要なアクショ... 2007.07.29 改善旧館より
旧館より 昔は良かった? 年上の人と話すと、割と誰しもが感じる「昔は~だった」について、「自分もこうなったらあかんな」と自戒を込めて書きます。 年上の方と話していると、時々「昔は…だった」という話が出てきます。 昔の話を聞けるのは、自分の知らない年代、経験を知る事が... 2007.07.14 旧館より考え方
日常 インプットとアウトプットのバランス 仕事ではインプットに対してどのようなアウトプット(成果物)を出すかが大事です。 一握りの創造性豊かな人以外にとって、そのアウトプットの元ネタとなるインプットが存在していることが大半です。 インプットは、書籍から、また、莫大な情報があるインタ... 2007.07.07 日常旧館より考え方
旧館より テスト工程 …とは言っても、学校の「期末試験」でなく、システム開発での「テスト工程」のことです。 今のプロジェクトが、そろそろお客様先での結合テストに入る…と、スケジュール上なっています。 しかし現実は単体テストレベルのバグがわんさか…1日50個とか…... 2007.06.16 旧館より
旧館より Javaの格言―より良いオブジェクト設計のためのパターンと定石[読書感想] 仕事でJavaを使ってのシステム構築をしています。 勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。 で、思い立って以前に買って積読していた↓をちゃんと読んでみました。 ■(Javaの格言―より良いオブジェクト設計... 2007.06.03 旧館より書籍
旧館より できるだけ文字を打たないことでミスを少なくする 文章やプログラムを書く時に効率性や質の向上の為に自分なりのルールや注意していることがあります。 1つは前に書いた文章の揺らぎです。 もう1つは低レベルな話ですが「出来るだけ文字を打たない」ことです。 要件定義書や設計書等では同じ単語や文言(... 2007.04.01 旧館より考え方
旧館より エンジニアの特徴って高い「知的好奇心」 以前「お医者さん」だって全部の病気を知らないでしょ?で書いた「(知らないアプリケーションについて)頑張ればそれなりに答えれる事もありますがそれをしない理由」(ややこしい言い方)を自分なりに書きます。 結構偏った見方かもしれませんが、自分を含... 2007.03.24 旧館より考え方
旧館より 「コンビの成熟度合い」がアウトプットに与える影響 企業にはジョブローテーションがあると思います。部署内での担当替えだけに留まらず、部署間の異動、転勤もあります。 #組織の強さや未来像を意識しているかは分かりませんが…。 適性の見極めやゼネラリスト育成を目的としたジョブローテーションは大事で... 2007.03.17 旧館より考え方
日常 「お医者さん」だって全部の病気を知らないでしょ? 仕事、プライベート問わず「パソコンの事」を質問されると結構困ります。 自分の知っている/使っているアプリケーション、OSに関する質問であれば、それなりに答えられます。 もし、答えが分からなくても、(経験上)当たりをつけて調べれば、それなりの... 2007.03.07 日常旧館より考え方
旧館より 経験値の絞り方 同年代なのに驚く程、人間的器や知識、考え方の成熟度合いに驚く人もいれば、いくら年上でも「なんだろうなぁ」と思う人もいます。 また若手技術者(技術者に限った話ではありませんが)を見る時にも同じようなことがあります。 そういう風景を見ているうち... 2007.02.24 旧館より考え方
旧館より マルチスレッド 仕事の振り方が下手な人がいます。 「自分」しかその仕事が出来ないわけでもないのに、それを抱え込んでしまい、気付いた時には「両手いっぱいに仕事という名のボールを抱えて」いっぱいいっぱいになっています。 A,B,Cの3つの仕事があります。 Aは... 2007.02.03 旧館より考え方
旧館より 情報の欠如 仕事柄、(全てが等価値で無い)いくつもの情報から判断を必要とすることがあります。 もちろん、上司も私以上の無数の有形無形の情報から判断しています。 役職や立場が上になればなるほど、情報がたくさん入ってくるようになります。 一方、その情報は詳... 2007.01.20 旧館より考え方
旧館より 文章の揺らぎ どんな職種でもそうですが、ことSEになると「他者に意図を過不足なく伝える」資料(文章、図形問わず)を書くことが多くなります。 ここで言う他者とはお客様・・・この場合は提案書や要件定義書・・・の場合もあれば、プログラマー・・・この場合は設計書... 2007.01.13 旧館より考え方