リアル-アジャイル開発実例
開発者が楽しく仕事できる環境とは(ペアプログラミング,開発合宿,偉くない管理職)
「偉くない管理職」という考えです。人を管理する仕事は上司の仕事であり、社員は上司の管理の下で業務にいそしむ、といった上下関係ではなく、例えば開発者が「この案件を10日後に完成したいので工程管理をして欲しい」と若い社員に管理をお願いする、といったものです。実際に最近では、新しく入った社員が年上の開発者のタスク管理を行う、という方法を試していますが、うまく回り始めているように思います。
最後の「偉くない管理職」と言う考え方。すばらしいと思います。物作りの楽しさをずっと続けたい人もいますしね。管理的な作業がえらいと言う考え方を変えたとき同じ会社の中だけでなく、会社同士の下請け、孫受け的な考え方も変わってゆくのではないでしょうか？
KYT(危険予知トレーニング)
最近ここ2・3年まえから、ソフトウェア開発にトヨタの生産方式をソフトウェアに取り入れる動きがあります。そのなかで、もっともよく、目にするのは、「オブジェクト倶楽部」の平鍋さんの翻訳や文章でしょう。最近の「オブジェクト倶楽部」のイベントでのプロジェクトファシリテーション(PF)の話の中でも「見える化」の話のなかで、製造業で良く行なわれる手法(朝会やあんどん)をソフトウェア開発に当てはめた説明がされていました。ここでは
リスク管理の手法として紹介されていました。
私自身、製造業に勤務していた時代に、工場研修で毎朝やらされました。そのときは「KY（危険予知）ミーティング」ではなく「KY（危険予知）トレーニング」とよばれ、リスク管理ではあるのですが、実際に当日や直近に作業する具体的な危険を周知するというより、現場作業での一般的な危険にはどのようなものがあるかを、1枚の絵をもとに朝礼出席者に一人一人が自分の発想でそこに潜む危険を挙げてゆくといった物でした。わたしは、そのネーミングがなんとなく、当時、ダサく思えて、その活動までも、意味あるものにはあまり思えませんでした。その他5S(整理・整頓・清掃・清潔・しつけ)とか、でも理屈で考えちゃだめなんですよね。慣れの問題ですね。毎日、朝、当たり前だと思っているような事柄でも、みんなでこれは危険だとかいいあっていると本当にそのような状況に遭遇したときに思考せず行動に移せる物だと言うことが、今にして見れば良く分かります。
ソフトウェアの障害はほとんどヒューマンエラーです。したがってこのKYTはシステム構築の上でのリスク管理に相当します。また、前述のミーティングとトレーニングの違いですが、トレーニングの方は、リファクタリングの「不吉な匂い」をかぎ当てる練習に相当することでもあるように思います。
エンタープライズ アプリケーションアーキテクチャパターン
読んだ内容を、社内で議論したが、私の説明のし方が悪いせいか、なかなかよさがわかってもらえません。組織階層を取り扱うのにSerializedLOBを利用する方法について説明したのだけど、ぜんぜん伝わらなかったみたい。RDBの達人みたいな人だったから、単純にSQL文で内容を確認できないことにかなり責められました・・・
グリッドのコントロール
DBをバインドできるタイプのもとバインドしないタイプのものを比較中、バインド型は表示までは非常に簡単なのだが、グリッドのセルのフォントや書式の動的に変更しようとすると非常に時間がかかります。いちちDBへアクセスが発生してしまっているようです。この使用しているコンポネントの問題かも知れませんが・・・どっちの方式に使用かな？
540,000行のテストデータ作成
プログラム作ればよかった、ついコピペ方式の安きに流れてしまいました。また、作らなきゃならないときがありそうなのに・・・
