de:code 2016 「拝啓『変わらない開発現場』を嘆く皆様へ」を担当して


実に2年ぶりのエントリになりますが;、今日はこちらの話題を。

少し前の話になりますが、5 月下旬に弊社イベント de:code 2016 で、ちょっと変わったセッション「拝啓『変わらない開発現場』を嘆く皆様へ ~エンプラ系 SI 開発現場の「今」を変えていくために~」を担当させていただきました。内容は、エンプラ系 SIer のプロパー(PL, PjM, SE)の方々向けに、設計やテスト手法の改善テクニックの要点などを通して、開発現場を改善していくための考え方を解説する、というもの。未来をお届けするイベントなのに最新技術を一切説明しないという異色のセッションにもかかわらず、参加者満足度(NSAT)ランキングで全 125 セッション中 2 位という結果になったことに大変感謝する一方で、私自身、いかに日本のエンプラ系 SI の闇が深いのか、を改めて実感することになりました。

セッションの内容については近いうちにテキスト化してこの blog にも掲載したいと思っているのですが、できればぜひ 1 時間ほど皆様のお時間をいただき、録画ビデオを見ていただければと思います。ダウンロード可能なので、通勤中にスマホなどで見ることも可能です。(はてブでは 100 人以上の方からブクマいただきました。ありがとうございます。m(_ _)m

そして、この内容がよいと思われた方は、ぜひ周りの方にこのビデオをそのまま紹介ください。特に SIer のプロパー(SE, PL, PjM)の皆様、そしてさらにその上司であるマネージャの方々に

もちろん、現場の皆様ご自身がこうした訴えかけをロジカルかつ根気強く上申していくことが最も重要ですが、その一方で、「当事者が言っても意見を聞いてくれない」という話もよく聞きます。そういう場合には、外部の第三者の声をうまく使って伝えていくことも必要なのだと思います。ぜひ、そうした目的のためにこちらのビデオや資料をうまく活用していただければと思います。社内勉強会やコミュニティなどでもぜひご活用ください。


……というわけで、ここから先は私個人の「つぶやき」です。(できればビデオを見た後に読んでください。)

今回、参加した方々の約半数からコメントをいただきました(← かなり高いコメント率です)。「自社のことかのように感じた」「心に刺さる内容だった」「de:code らしくはないが、このセッションの内容は本当に役立つ内容だった」といった内容のコメントが多く、とても有難く思うと共に、本当に皆様が現場で苦しまれているのだということを改めて実感しました。

そうしたコメントの一方で、「既に実践していることだらけ、レベルが低いのでは?」「新しい考え方などは得られなかった」といった厳しいフィードバックも(少数ではありますが)いただきました。忌憚のないご意見をいただき、こちらも本当にありがとうございました。m(_ _)m

今回、もう少し突っ込んだ話ができなかったことを本当に申し訳なく思うのですが(ごめんなさい;)、こうしたご指摘に関しては、私も全くもって「その通り」だと思いますし、またそれ以外にも、内容自体が受け入れがたい、という方もきっといると思います。このセッションの評価は、おそらく非常に高評価か低評価か、どちらかに極端に振れるだろうと思っており、セッションの内容についても内心、「こんなシンプルな内容で本当によいのか?(もっとその先の話をすべきじゃないのか?)」とものすごく悩んでいたのも実際のところです。そして出てきたスコアやコメントを見て「ああ、やっぱりそうなのか;」と、改めて日本のエンプラ系 SI の難しさを実感した一方で、「そんなの当たり前じゃん」と言える開発現場も確かに日本にある、と思えたことも、自分的には大きな救いでした。

願わくばこのセッションの内容に対して、日本のみんなで「そんなのレベル低すぎる」と自信を持って言える時代が来ることを。目指す先は「根拠のある作業」「根拠のある SI」。そこに向かって、日本の現場の開発者と SIer の皆様のみんなで知恵を出し合い、議論を深め、日々少しずつでも改善を続けて進んでいければと思っています。超えるべき障壁、解決すべき課題、そしてその解決方法も現場ごとにいろいろ違いがあると思いますが、みんなで頑張りましょう!

……というわけで、まるで更新してないこちらの blog ですが、今後もよろしくお願いします。m(_ _)m(← おい;)

# よかったら、動画を見た皆様の忌憚のないご意見もお聞かせください。ものすごく参考になりますので。

※ 続編も書きました。よかったらこちらもどうぞ。
続・拝啓『変わらない開発現場』を嘆く皆様へ ~ ウォータフォール & アジャイル編~

Comments (2)

  1. 武田 誠 says:

    セッション動画、非常に面白く拝見させていただきました。
    まるで日々の愚痴を盗聴されているかのような。。。(^^ゞ

    ただ1点私と考え方が違っていたのがテストの工程と実施者の話です。

    開発とテストの分離から、
    今はまた同一人物のほうが効率が良くなったという趣旨でしょうか。

    私が思うに、開発者によるテストは当然行われるものとして、
    ユーザー寄りの目線でのテストの必要性がうたわれていたのが
    開発とテストの分離の話だと思っています。
    そしてその分離は不可欠だとも思っています。

    そのあたりいかがでしょうか?

    1. nakama says:

      武田さん、コメントありがとうございます。
      日々の愚痴……^^ いえいえ、前向きな改善を目指す心の叫びです、きっと!^^

      さてテストの話ですが、語りが甘くて誤解を招いてしまったようで、申し訳ありません。

      ・効率性を高めることだけを追及すると、Dev も Test も同じ人 (DevOps ロールの人)が一気通貫でやってしまった方がよい。
      ・しかし同時にきちんとしたテストをするためには、この DevOps ロールの人は、「Dev」「Test」の両方の目線を持てなければならない。

      つまり、DevOps ロールの人には、

      ・ある日は「開発者目線」でモノをチェックする。
      ・しかし別の日には「ユーザー目線」で同じモノをチェックする。

      ということが求められます。(というか、もともとはそれができないからロールが細分化されたのですが、いやいやみんな今はスキル上がったから一人でもちゃんとできるでしょ! と言っているわけです。)

      DevOps では、実装/テストだけではなく、仕様策定者/設計者/実装者/テスターといった細分化されていたロールを、同じ一人の人が担当する、ということが求められる(ことが多い)のですが、これは要するに「なんでもできるスーパーマン」が求められているようなものでもあります。そして実際、例えばマイクロソフトの社内では現在、そういうことが行われています。

      しかしその一方で、日本の実際の開発現場を振り返ってみると、「いやそこまで成熟したエンジニアばっかりじゃないよ!」という方が多いと思います。武田さんの悩みもまさにそこにあるのではないかと思いますし、そういった状況下で Dev/Test ロールを合体させると、多分破たんするでしょう。なので、そういうケースでは Dev/Test ロールの合体はやめた方がよいです。

      ただ一点、意識しておいていただきたいのは、各領域の専門性を追及するあまりロールが細分化されすぎると、オーバヘッドが大きくなり、作業効率は悪くなる、という点です。複数のロールを兼務できるようなスキルの高いエンジニアがそろっている現場ほど、当然ですが作業効率は高くなります。そういったところを目指して、ぜひ現場エンジニアの方々を育成していただければと思います。

Skip to main content