サウスポーなエンジニアの独り言サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。旧館よりあるフリカエリにて。2017年11月5日Tweetあるフリカエリをして、しばらく時間が経ってから思ったことです。性格やクセに起因する、固有の行動特性は、『簡単』には変わらない...と思いました。変わるには、それなりの意志の強さが必要だったり、周囲の状況の変化...変えなくてはならない程のなにかがあった等...が必要だと思います。「分かっちゃいるけど止められない(変えられない)」みたいなニュアンスです。KPTを使ったフリカエリで、メンバーの一人がProblemに「コミットの間隔が長すぎることにより、手戻り」を上げていました。コミット頻度が高いファイルを、3日ほどコミットせずいたところ、それが原因で手戻りやマージ作業による工数増を招いたとのことでした。私はちょうどKeepに「頻繁なコミット」を上げていました。いくつかのメソッドとそのテストコードを書いてコミットするというリズムでプログラミングをしていました。ディスカッションして、このプロジェクトではCI...継続的インテグレーション...の導入をしており、ユニットテストの自動化もその試みの一環なので、その状況下で長い期間コミットしないのは、そのメリットを十分に活かせていないよね...となりました。そのような経緯もあってTryに「頻繁なコミット」をあげてフリカエリが終わりました。フリカエリ直後の数日間は、頻繁にコミットしていたようですが、しばらく経つと元のリズム...数日かローカルで掴みっぱなし...に戻っていました。本人も分かってはいるものの...「あぁ~、やらなくちゃいけないですねぇ~(苦笑)」という感じです。Problemに対応するTryをもう一歩踏み込んで、個人の解決能力だけに期待するのではなく、チームとして改善できることはないか?(そしてそれが結果としてチーム力アップにつながる)という視野を持って考えることが必要だったと思います。※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。コメントをキャンセルメールアドレスが公開されることはありません。保守開発に求められる要素の違いシステム開発の要素の1:新規開発(スクラッチ)と2:保守開発(機能追加)があります。#保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。...日常の意思決定にも使えるかも...狩野分析法http://d.hatena.ne.jp/masayang/20071213/1197534511にて狩野分析法というものが紹介されていました。...人によって違う「ゆっくり」お客様や同僚から言われる「この仕様をドキュメントにまとめてもらえますか?急いでいないので、”ゆっくり”で良いですよ」という言葉。...変更履歴を論理的に見ておかしいと思わないのは...仕事での行動基準...うまく言えないのですが「これを気をつけて欲しいなぁ」的な内容...を考えることがありました。...PREV「相性の合う/合わない」と「仕事のできる/できない」NEXT「お世話になりました」エントリを見るのはツライものですギルドワークスの現場コーチ。「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。様々な規模のSIerでのシステム開発を経て今に至る。DevLOVE関西を主催。(14)サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。