「アジャイル開発とスクラム」を読んで

「アジャイル開発とスクラム」という本を読みました。

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

アジャイル開発にはちょっと前から興味を持っていて、できるところから、CI（継続的インテグレーション）やBTS（バグ・トラッキング・システム）を導入して下地を作り、そろそろ本格的に始めてみたいなと思っていたところでした。
その中でも特にスクラムに興味を持っていたのですが、いかんせん経験がないのでちょっとビビっていたところで、この本に出会いました。

書いている内容は、スクラムの基本的な紹介と、それを実践した日本の事例とインタビューが中心。
何より良かったのは、日本の事例で、日本特有の問題に直面しながら解決していった先人たちの、「想い」が書かれていたこと。
技術的なことや、対策的なことも重要なんですが、それより何より、「なぜそうまでしてアジャイルを取り入れたのか」を読めたことで、自分の中でも想いが強くなっていきました。

やらなきゃいけないことも、課題もたくさんありますが、ちょっとモチベーションは上がりました。
システム開発に携わっている人なら、とりあえず読んでみて損はない一冊だと思います。

要件定義についての幻想

仕事の話。

最近お客さんのところに行っていて思うことは、要件定義で用件が固められるなんて幻想は抱いてはいけないということ。

これはやり方の問題ではなく、「不可能」だと認識する必要がある。

8割も決められれば御の字、実際には6〜7割程度しか決めることなんて出来ない。

決めることが出来ないのだから、変わる可能性があると認識しておかなければならない。

それは当然リスクな訳だけど、決まったと決めつけて進めるよりは百倍良い。

しかしそうなると、お金をどうするかと言うことになる。

お客さんとは、要件定義の段階で出てきた分のお金しか見積もってない。

でも、追加機能のために追加料金が必要。

当然、追加で支払ってもらうべきだが、なかなかうんと言ってくれないお客さんもいる。

あとは、要件として上がってはいたけど、細かい仕様で追加が必要になってしまった場合。

これはさらに請求しづらい。

向こうが言ってないとも言えるけど、こちらが聞き漏れてるとも言える。

業務のプロは向こうだが、システムのプロはこちら。

どちらのせいとも言い難い。

結局どれも、要件定義で要件が確定できないリスク分を見積もりに見込んでなくて、追加はその都度ってことをなぁなぁに進めると問題になりやすい気がする。

さらに言うなら、そもそも要件定義で確定した分を見積もって作るって形が難しくて、何か確定可能なものをベースに要件やシステムの開発範囲を柔軟にする方が良いのではないだろうか。

たとえば、上限金額を決めてしまって、その中で出来ることしかやらないとか、毎月の金額を決めて、毎月一定量の開発を行うとか（納品のない受託開発として最近有名かな）。

なんにせよ、複雑化してるシステム開発において、ウォーターフォール型の開発はいろいろと無理がありすぎる。

同時に、ウォーターフォール型の受注（という表現が適切かはわからないが）も無理があるので、違う契約の仕方、開発の進め方を考えなければならないのではないか。

それが、今の会社にいて出来るかどうかは、また別の話だけど。

就職活動の問題点

就職活動は、インターネットの登場で大きく様変わりしました。
就職情報サイトに登録し、気になる企業にエントリーし、履歴書を送ったりWEBテストを受けていく。
面接を受けていくスタイルは変わらないと思いますが、それを同時に何社もこなしていくという形は昔は考えられないことでした。

インターネットの登場によるメリットは、とにかく多くの情報を得ることができるようになったこと。
十数年前では知り得なかった企業と出会うことができ、自分の可能性を広げることができるようになったと言えるでしょう。
また企業の側も、広く全国から人を集めることが容易になったため、より優れた人材が集まる可能性を高めることができます。

ただ、逆に情報が増えたことによって、問題点も多くなりました。
簡単に情報が手に入ることによって、情報の取捨選択をこれまで以上にしなければならなくなりました。
たくさんエントリーできることによって、たくさん選考を受けなければならなくなりました。
企業側もたくさん呼べることによって、選ぶ手間が増えました。
競合する企業の数も増えたため、簡単には入社してくれなくなりました。

なにより最大の問題は、無駄が多くなりました。

100社のエントリーは当たり前、ということは、100社分のエントリーシートを書く時間が無駄です。
そのうち面接を何社受けるのかは分かりませんが、入らない会社の面接は極端に言えば無駄です。
企業側も、受からない人に対する面接などの時間を作ることは無駄です。
内定出しても辞退されてしまったらそれも当然無駄。

とうぜん、必要な無駄もあります。
何社か受けるのは、保険のために必要だったり、落とす前提でも何人か選考するのは、よりよい人材を集める上で重要です。
ただ、それが度を過ぎてしまっていないでしょうか。

就職活動の理想は、企業と学生が一対一でマッチすること。
現実には多少のロスは発生するでしょうが、その形を目指していく方が、企業にも学生にもいいのだろうと思います。
そういう意味では、いい意味での「コネ入社」というのをやった方がいいのかも。
または転職市場と同じように、新卒採用の現場でもエージェント的な人が学生を吟味して、企業はそのエージェントを信用して採用を行うとか。
そういう形を取った方が、お互いの無駄を省けて生産的な気がします。

学業に力を入れさせるために就職活動の時期を変えるのではなくて、そもそも就活のやり方を変えて行くべきなのでは、と思う今日この頃です。

iBatisで同じSQLを流用する際の問題

iBatisが変な動きをした。※正確には、TERASOLUNA
一つのリクエストの中で、同様のSQLを二回発行する必要があったので、二度使った。

SelectDAO seDao1 = new SelectDAO();
seDAO1.setXxxCd("aaa");

SelectResult [] result = query.executeForObjectArray("select1",seDAO1,SelectResult.class);

SelectDAO seDao2 = new SelectDAO();
seDAO2.setXxxCd("aaa");

SelectResult [] result2 = query.executeForObjectArray("select1",seDAO2,.class);

一回目は数件取得され、二回目は通常は一件取得されるようになっている。
一回目の動作は正しいのだけど、二回目がどうしても取得件数が多い。
中身をよく見てみたら、どうも一回目の時の取得結果が残ってしまっているらしい。
二回目で取得した件数が一回目の件数を下回っていると、後ろのほうが上書かれずに残る？

ちょっと想定外の動きすぎて困った。
とりあえず、一回目と二回目では微妙にSQLは異なるので、別のSQLとすることで問題は解消。
でも、なんか釈然としない。

どこまで教えるか、いつまで教えるか

今年2年目になる後輩がいます。
自分が育成担当なのでいろいろ教えながら働いているのですが、さていつまでどこまで教え続ければいいかなと悩んでいます。

ある程度年次が経っている後輩なり同輩に教えるなら、「ここはこうでこれこれこういう理由でああなってるからよろしく」とかポイントを押さえて一通り教えます。
自分が躓いたポイントとかはなるべく予め教えてあげて、同じことで悩まないように。

ただ、いつも先人がいる仕事をやれるわけではありません。
むしろ、誰もやったことのない仕事をやることがSEの仕事の醍醐味であり真骨頂だと思っているので、初めてやることを一人でやり抜くことも重要な能力です。
そのためには、誰にも教えてもらわずに悩む力、悩んで悩み抜いて自分なりの答えを見つけ出す力が必要だと思います。

でも、それって新人とか2年目くらいだとまだまだ力不足な子も多い。
そうすると、悩ませることも育成の一環と思ったりもするのですが、さてそれをいつまで続けるか。
悩ませるにしても悩ませすぎて禿げられても困るのでどこまでは教えるのか。
この辺の塩梅が難しいです。

自分は割りと悩むの好きなので、この辺が苦手な人の気持ちが分からない。
けど、分からないからって教えられないわけにもいかないので悩みます。

というところで、育成って育成担当の育成にも繋がるのだなぁということを感じている今日この頃。

MS Project と Redmineの連携

MS Project と Redmine を連携させてみた

はじめに

プロジェクトの管理をしなければならなくなった。
これまでは一開発者だったんだけど、プロジェクトの同時進行が増えてきたために、ついにそのお役が回ってきてしまった感じ。
まぁいい機会なので頑張ってみようと思う。

で、Redmineは高機能だけど、プロジェクト管理には痒いところに手が届かない感がある。
プラグインもいろいろあるけど、なかなかうまく動いてくれなかったり、自動計算とかはあんまりやってくれないし。
ということで、MS Projectと連携させてみることにした。

前提

MS ProjectでWBSを起こし、タスクとリソースを管理する。
Redmineは作業の状況を入力してもらうだけで、開始日・終了日などは変更させない。

方法

まずMS ProjectでWBSを作った。
バージョンを工程とし、詳細設計、製造／単体試験に分けて、さらに機能毎などタスクに落としこむ。
一通りタスクが出来上がったらExcelに貼っつけてRedmineにインポートする。
CSVとかでやってもいいけど、今回はこの便利ツールを使った。

Redmineチケット★一括★の詳細情報 : Vector ソフトを探す！

で、登録されたチケットのIDをMS Project側にも書いておく。
（そういう意味でも上記ツールが楽）

MS Project側はマクロを設定し、REST API経由でチケットの情報を取得してくるように設定。
取得した情報は適宜MS Project側に貼り付けていく。
自分が取得しているのはとりあえず作業時間とトラッカーとステータスくらい。
まだ他にも必要になるかも。

運用

運用イメージはこんな感じ。

1. MS Project側の情報をマクロで更新。
2. 必要に応じてリソースの再割当てや開始日の調整を実施。
3. Excelに貼り付けてツールで更新を反映。

こうすると、作業管理はRedmineでやりつつプロジェクトの状況を可視化したいときはMS Projectから素敵レポートを出力することができる。
とはいえ、MS Projectの使い方自体を勉強中なのでこれでうまくいくのかは未知数。

情報取込のマクロはこんな感じ。
拾い物を切り貼りしたやっつけです

Const API = "http://server/redmine/"
Const Key = "key=aaaaabbbbbccccc1234567890123457890"


' ###################################################################
' #
' # Redmineから情報を取得する｡
' #
' # チケット番号が入力されたタスクを、Redmineの情報で更新する
' # チケット番号が入力されていないタスクは無視される
' #
' ###################################################################
Sub ImportRedmineData()

    Dim prj As Project
    Set prj = ThisProject
    Dim tsk As Task
    Dim ticket As Object
    
    ' すべてのタスクを対象に動かす
    For Each tsk In prj.Tasks
    
    ' チケット番号が入力されている場合
    If tsk.Text1 <> "" Then
    
        Set ticket = GetXmlData(API + "issues/" + tsk.Text1 + ".xml?" + Key)
        
        '説明
        tsk.Text6 = ticket.getElementsByTagName("description").Item(0).text
        
        'トラッカー
        tsk.Text2 = ticket.getElementsByTagName("tracker").Item(0).getAttribute("name")
        
        'ステータス
        tsk.Text4 = ticket.getElementsByTagName("status").Item(0).getAttribute("name")
        
        'トラッカー
        tsk.ActualWork = ticket.getElementsByTagName("spent_hours").Item(0).text
        
        If ticket.getElementsByTagName("parent").Length > 0 Then
        
            tsk.Text5 = ticket.getElementsByTagName("parent").Item(0).getAttribute("id")
        
        End If
        
    End If

    Next

End Sub

平和国家を名乗るとして

平和国家を名乗るとして、隣人が暴力を受けているときに、それを傍観、あるいは静止の言葉だけを投げかけるのは平和的だろうか。
そうとも言えるだろうし、そうでないとも言えるだろう。

隣家が暴漢に襲われていた時、隣人が赤の他人なら、警察は呼べども助けはしないだろう。
でもそれが親類や恋人なら、助けに行くのは普通だろう。

密接な関係にある国とは、そんな親類や恋人に該当するような国だろうか。
そこの意識が違うから、余計に意見が別れるのかな。

ただ、他の国から見た時に、「君の国が襲われても助けないけど、僕が襲われてたら助けてよ」なんて言われて助けてくれるだろうか。
戦争を避けたい気持ちと、仕掛けられたら守らなきゃいけないというところの、バランスが難しい。
攻める権利だけは持たない、というところが落ち着きどころのような気はするのだけど。