koeだめ 過去アーカイブ[〜2013-12-14]

最新情報は https://www.pixiv.net/fanbox/creator/3780274 にて

潜入!NTTデータとの決闘シリーズ第二幕

NTTデータの中の人では無い、ピラミッドの下の方に属する1開発者ではありますが、このNTTデータとの決闘シリーズ第二幕に潜り込み*1聴講させていただきました。

昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。

http://d.hatena.ne.jp/higayasuo/20080828/1219901392

戦闘服、アロハシャツとばかり思ってましたごめんなさい(><)
今回はブログなどで言及してねとのお話だったので、言及しておきます*2。ピラミッドボトムの1開発者観点の所感なので、私見バリバリはご容赦ください。

品質についてのディスカッション

  • SIerに開発を丸投げするのは失敗の元
  • SIer側が任せてくれと丸ごと抱え込む事も多い。
  • みんなでエンドユーザ(マーケット)が満足いくものを作る

上記のような話がありましたが、これら実行するには、古来から続く巨大な滝の開発体制ではしんどい気がします。マーケット、顧客、ITが同じゴールを目指すのが必要となってきますが、その為には上流下流、元請け下請けでズバっと切り分けて疎結合な開発体制では、一つのゴールを目指すことは不可能でしょう。
良い意味で密結合なチームで、ひとつのゴールを目指すには、

データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考え

http://d.hatena.ne.jp/higayasuo/20080612/1213241779

この考えを捨てて、元請けでマネジメントする人は、下請けの開発者をもっと信頼してほしいです。そして、そのためにはそんな立場にいるわたしの様な開発者はもっと信頼される要素を持つ必要があります。
つまり、”BPさん”として十把一絡に扱われるのではなく、例えば”こしばさん”と名指しで開発メンバーとして「一本釣り」されるような材料を持つ必要があります。

わたしとしては、昼の仕事に加え、夜の(個人としての)活動についてをアピールして「一本釣り」されるようにないたいなと考えてます。興味があればまずはお声掛けいただき、お話合いの機会を持たせていただければ幸いです。

「スピードがないと勝てない」

パネラーの某ユーザ企業の方が言われていた言葉です。「勝ち負け」という点では、開発する側は負けないことに目が行きがちではないでしょうか。例えば、テストを精緻に行うのもヘビーウェイトな方法論やフレームワークを作るのも、発想としては「いかに失敗しないで完成までこぎつけるか」という考えがベースになっているのではと思います。
顧客が勝つことを求めている以上、開発する側も「負けない」ではなく「勝つ」事を志向しなければなりません。そこで、アジャイル開発者*3としては、失敗しないように言われたものを粛々と作るのではなく、スピードと勝つことを要求される現場にいる場合は、より短期間で必要なものを作れるやり方をガシガシ提案し実践していく必要があります。

設計書は進捗阻害要因&重いテストは無駄

プログラミングファーストに関する話で、設計書はその設計の背景や意図、Whatな部分があればそれでよい。今はフレームワークや技術の発達で、どうやってるかはソース読めるとのこと。テストも、バグは偏在するものであり、バグが起きやすい/実際に起きた部分を手厚く行えば必要な第一品質は確保できるとのことでした。
つまり、プログラミングファーストでは、

  1. 使わなれない仕様書は作らない
  2. 打鍵でまかなえるところはテストに時間をかけない

これらの事を行って、工数削減を図るというお話だったのですが、これらは問題なく実践できるでしょう。でしょうというか、経験があるのでその効果を理解してるし大賛成です。

どこで経験したかというと、期間が足りなくってアップアップになったプロジェクトでこれらが行われました。

  • 仕様書はカットオーバー後に自動生成で取り繕うことにして、開発中は作らない。
  • テストは照会系などDB登録が掛からない部分は開発者が画面を叩いてチェックし、問題が起きるといけない更新・登録系は入力データと格納データとをきっちり突き合わせてきっちり確認する

ということを行い、何とかカットオーバーには間に合い、業務が止まってしまうレベルの障害は発生しなかったという結果になりました。
今回の話をきくと、プログラミングファーストでは、上記のやり方をプロジェクトに火が付いてない当初段階から行い、ペア作業や自動テストなどの手立てで品質を保つフォローを行うので、プログラミングファーストは当然効果的であろうことは強く感じられました。

現実として、不要な仕様書作らない&テストは重点部分に集中なんて、火がついた現場ではいつでもどこでもやってきたと思います。なので多くの開発者はすでに経験したことであり、その点ではプログラミングファーストを受け入れることは簡単でしょう。プログラミングファーストに不安がある人は、開発者をイマイチ信頼できていないマネージャ側ではないかと思います。上でも書いた様に、わたしの様な開発者がもっと信頼される要素を持てば、今日明日にでも踏み切ることができるでしょう。

SIerのビジネスのあり方

日本のSI業界の多重下請け構造をなくすためには、新しいビジネスモデルが必要なのです。

http://d.hatena.ne.jp/higayasuo/20080828/1219901392

1開発者がそんな構造を無くすには何ができるだろうと考えたのですが、元請けに頼らない活動を進めることで、ピラミッド構造への依存度を下げられるのではないでしょうか。
具体的な手段として、オープンソースや勉強会など、自分の働いている会社の壁を超えて広く動いていく事を、ただいま実践中です。

今回の話をきいて今後自分がやりたいと思ったこと

下請け開発者会議

”BPさん”とか”協力さん”とか言われがちな立場の開発者で語り合う場とかいいなあ。自社自慢とかもやりたい。
例え立場が下請けであっても、いらん下請け根性捨ててしまえばええねん。

XPとかプログラミングファーストとか、アジャイル開発

現状でもかなりアジャイルにできてると思うけど、より明示的にアジャイル開発している! と主張したい。そして、その良さとメリットを周りに広めたい。

*1:もちろんちゃんと申し込みました

*2:前回も参加したけど直接言及しなかった

*3:少なくともアジャイル開発者たる心構えとスキルを持とうとしている