もしSIerのエンジニアがドラッガーの「マネジメント」を読んだら


流行は去ったけどドラッガーの「マネジメント」からSIer事業を考える

もう流行ってないけどドラッガーの「マネジメント」からSIer事業を考える

続きです。

SIer事業というのは「顧客のイノベーションを実現するというのを手助けする」ことであるということであれば、私たちにできることが明確になりそうです。

それはイノベーションを実現するためにITを活用するとともに顧客のリスクをできるだけ軽減すること。

そのために必要なことは・・・

  1. 実現するための技術を提供すること。
  2. 柔軟に機能の変更・追加・削除ができること。
  3. 柔軟にプロジェクトの拡大・縮小・撤退ができること。

1は当然の話しでやはりイノベーションを実現するための技術はきちんと追い求めていくべきですよね。

2についてはより大きくビジネスが関わってくる部分だと思いました。

新しいことをやろうと思えばビジネス上機能の変更・追加・削除は当然のようにでてくることだと思います。
最近ではアジャイルがこれに対応するものとして主流になりつつありますが、プロセスだけでは根本的に解決するとは思えません。
なぜなら、一つの変更で変更箇所をあちこち探したり、修正漏れがあったりすれば結局かかる時間の膨大さは変わらないからです。
TDDでテストをきちんと書いていてもそれは変わらないと思います。

もっと早くもっと少ない手順で機能を変更・追加・削除できることが大事ではないでしょうか?

それを可能にするのが「顧客のビジネスを理解してそれをソースコードのレベルまで落とすこと。」
もっと早くもっと少ない手順にするには究極には「変更箇所」を一箇所・ひとつのクラスにすること。
機能の変更・追加・削除の理由は「ビジネス上の理由」が必ず存在します。
とすればビジネスに沿ったクラスを作成していかなければならない。クラスだけでなく、メソッドやフィールドレベルまで適用することが大事。
そのための設計手法の代表がDDDであるのだと思います。

しかし、イノベーションの実現には「スピード」が求められる。今日の社会の状況は明日もそうなっているとは限りません。

ということでRDRAICONIXで要求からコードまで一貫して設計する。

で、スピードが求められるところで一発でそういう設計をするのは難しい。。。ということで「リファクタリング」を行いながら設計を改善し続ける。ということでしょうか?

3についてはそれこそアジャイルなプロセスがそれを実現できる手段ではないかと思います。

実は私は半年前に転職し、「有限会社 システム設計」にお世話になってます。
システム設計では正にこれをやっています。
私もシステム設計の社員です!と胸を張って言いたいところですが、まだ技術が付いていけず悪戦苦闘の毎日を送っております。

現在は社内の勉強会で「リファクタリング」の不吉な臭い(P75~P88)からパターンを覚えるというところをやっています。もちろんRDRA/IConix/DDDなども主要なテーマとして理解を日々深めています。

最初に示した1~3について、もちろんそれを実現する手段というのは各企業によって異なることでしょう。それどころか事業の定義すら各企業で異なるはずで、この3回で示してきた「顧客のイノベーションの実現のための手助け」というのは私自身が書籍を読んだ上での感想でしかありません。

しかし、リファクタリングが翻訳された当初(・・・はまだ私はエンジニアではなかったのですが)、さらには半年前DDD本が翻訳された当初のIT勉強会界隈のあのブームは今はどこにいったのかが気になるところです。
各企業で細かい事業は異なるがやはり必要とされて歓迎されたのだろうものが今あまり見られない・・・各企業で浸透したのか、または忘れ去られたのか、あまり必要でなかったのか。。。リファクタリングを勉強したりマネジメントを読んだりしながら思ってしまいました。

また、エンジニアがビジネスを理解すべしという曖昧な疑問には(今私自身実現できているかどうかが別として・・・)明確な答えを出すことができました。
顧客にとってはイノベーションを実現するためにリスクを取っている。それを支援する我々はどうしても同じ立場でリスクをとることはできない。
しかし、それでも顧客のビジネスを最大限理解し、適切な技術を選択し、ビジネスをソースコードレベルまで落とし+アジャイルなプロセスを適用することで最終的に顧客のリスクを最大限軽減することができ成果をあげることができるのだと思います。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です