Fight the Future

Java言語とJVM、そしてJavaエコシステム全般にまつわること

IT勉強会での初プレゼンなどお助けします!

勉強会でスピーカーをやりたいけど、プレゼンが初めて、苦手という方に無償でコーチできます。スライドのレビューや録画したリハへのアドバイスなどなど。Twitter@jyukutyoまでメンションでもDMでもお気軽にご連絡ください。

私はIT講師の経験があり、プレゼンはデブサミやJJUG CCCなど200人規模の経験が豊富で最大800人の前でプレゼンしました。海外ではDevoxxUSで。デブサミ2017では公募スピーカー1位、デブサミ関西2012アワードで5位となりました。

要求開発フォーラム西日本 2009に行ってきた

10月27日 要求開発フォーラム西日本 2009(大阪府)


要求開発する目的はシステム開発をちゃんとやるため。

エンジニアリング(ex.きちんとオブジェクト指向で構築するなど)をちゃんとやっても

お客さんにそれを認めてもらえず苦戦した。

エンジニアリングはメンテナンスの段階で初めて価値がわかるものだから。


システム開発においては

  • 業務管理者
  • システム開発者
  • 業務担当者

の3者間にそれぞれ壁がある。

それを突き崩すためにみんなで一緒にコタツに入って話を進めていく「コタツモデル」。


現在のシステム開発では、見える化を進めても結局 as is を見える化しているだけ。

そしてシステム要求というのは業務要求から導出されるものであるにもかかわらず

業務要求は隠されている(発注や2次受けの業界構造)。

システム要求はハードでしかないということ。

ドキュメントなど紙だけではダメで、プロトタイプや画面フローなどでシミュレーションし早期のフィードバックを得ることが大切である。

(このあたりはもちろんアジャイルの考え方と一致する)

つまり、to beを早く見せること。


ビジネスオペレーションはユーザー企業が作成できない領域であり、

ITエンジニアが進出すべき領域である。


そして、ドキュメントは保守や再構築の段階でほとんど利用されないことを認識し、

「本当に必要な」ドキュメントだけを作成すべきである。


要求開発はトップダウンのように見えて実はボトムアップであり、トップはそれを承認するだけ。

現状エンジニアはわからないことを何とか形にすることが苦手であり、

論理的に説明できないものを形にすることができるようになるべきである。

論理を追求しすぎると虚像になる。

象牙の塔ってことですね。)

懇親会

カオスでしたww

てつ。さんが飛ばし過ぎですwwww