残された開発者が欲しかったもの
４月ということで人事異動の時期。
新しい役職や環境で仕事をする人もいるかと思います。
オッサンも例に漏れず現在のチームから離れ、新しい仕事をすることになりました。
いや～、ここのところの人事異動がらみのドタバタでブログ更新をサボってました。
まあ、しばらくは引き継ぎのための現状維持なのですが。。。
まあ、過去何度もあった組織内組替の話なので、チームを離れること自体は特段異例の話ではないです。
問題は、残ったチームの方にありました。
残された開発者が欲しかったもの
自分の記事でも散々書いてきましたが、こういった突発的な異動に備えてドキュメントやシステムに関するノウハウについては、相当気をつけて残すようにしておりました。
人一人いなくなってしまってしまい、チーム活動が止まってしまうことは致命傷だから。
今回のチームでは従来のプロジェクトよりもずっと気をつけており、残されたメンバーは心配などしてないとおもいきや。。。いつもよりもずっと深刻に心配しているんですよね。
今回のチーム異動ですが、マネジメントしているオッサンを中心とした自社員メンバーが異動となり、パートナーさんだけが別の組織に移動となります。
マネジメント層だけがそっくりいなくなる形です。
実際の開発を行っていたメンバーがほぼ全員そっくりチームに残るわけで、一見、基本的な開発能力の低下はそこまでもなさそうに見えます。
もちろん、オッサン自身が抱え込んでいた要件、仕様などのノウハウもありますが、致命的なモノはドキュメントとして残している。
つまり、メンバーが心配しているのは開発力の部分ではないってワケですね。
チームに残してほしいもの
さて、メンバーにヒアリングしてみると。。。どうも、チームの異動の仕方が心配と。
マネジメント層がそっくり入れ替わる、ってことは、新しいマネージャのやり方でチームは動く形となります。
となると、ドキュメントの考え方やソースコードに対する考え方、組織運営に対する思想も変更となります。
要は、
- ドキュメント ・・・ 都度メンテナンス → ドキュメント不要。ソース見りゃいいでしょ。
- テストコード ・・・ seleniumを使って自動でテスト → メンテが面倒。PrintScreenでエビデンスを貼り付けろ。
- リファクタリング ・・・ 気にならなくてもこまめに改善。問題発生前に先手を打つ → 別に直さなくてもよし。困ったときに何とかすれば。
- 進捗管理 ・・・ マイルストンが守られれば細かい進捗はあまり気にしない。ガントチャートでの進捗管理は面倒だし不正確なことも多いので不要。 → excelのガントチャートで進捗度合い書け。定量で進捗率を出せ。毎日報告書を提出しろ。
などなどのような形で、今までの組織運営の考え方がガラリと変わったら。。。みたいなコトが心配ってわけですね。
これって、まあ言ってしまえば「プロジェクト憲章」を次のマネージャへ引き継いで欲しいって意味です。
ちょっとこれは意外でした。
今まではどちらかと言うと、要件や仕様と言ったナレッジをドキュメント化すれば引き継ぎメンバーはそこまで困らないで済むだろう、なんて考えておりました。それで上手くいってましたし。
でも、よくよく考えたら今までチームを離れた時って、長年一緒に仕事をしていたメンバーをリーダに引き上げてから引き継いでいたんですよね。
なので、気づかなかったのだろうな。
つまり、チームを維持するためには要件や仕様を残したドキュメントなどの「歴史」だけでなく、チームの活動の仕方や理念といった「文化」も残さなければならないってわけですね。
これって、Conwayの法則に繋がる話でもありますね。
まとめ
変化からは学びを得ることができますが、今回の組織異動についても改めて面白い発見をもらえたと思ってます。
まあ、せっかく育ててきたチームを手放すのは寂しいやら悔しいやらって気持ちもあるわけですが、そこから得られる学びがあるのであれば決して悪いことではないですね。
ところで、次の仕事がまだ決まらないのは気がかり。。。
個人の意志ではなく、人手不足な場所に回されることがよくあるのでどうなることやら。
もし営業にでもまわされたら、ブログ名を「営業ブログ」にでも変えるべきだろうか。。。
以上
- 作者: Mary and Tom Poppendieck 著、依田光江翻訳、依田智夫監訳
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2010/10/09
- メディア: 単行本（ソフトカバー）
- 購入: 3人 クリック: 99回
- この商品を含むブログ (32件) を見る
DDDの思い出２つ
年度末になると宿題の駆け込み・年末の道路工事と同じく急な案件見積もりや技術調査依頼なんてのが入るもんで、すっかりまいっておりました。
こういうのももうちょい計画的にやってくれたら楽なのに。。。
上記のエントリ見て２つほど思い出したことがあったので。
ドメインを甘く見てはいけない
仕事をやっていると、外部公演や外部研修といった場で他企業でエンジニアやマネージャやっていた講師の話を聞くことがあります。
で、その場で出た話。
講師「まず、プロジェクトを進めるためには、プロジェクトマネジメントやアーキテクチャ、プログラミングと言った開発能力が必要となります。」
当方「それらが必要なことは理解しておりますが、業務知識・ドメイン知識はより重要ではないのですか？」
講師「業務知識はユーザがもてば良いもので、開発者はそこまで重視しなくても大丈夫です」
この話。ずーっとモヤモヤしてたのですよね。
なんだかんだ言って顧客の作りたいもの理解しなければ、顧客に提供しようとしているものをイメージできなければ、たとえどんなに円滑にプロジェクトが進もうと、開発ができても顧客満足度を上げられず失敗になるんじゃないの？って。
この講師の方は、オッサンの会社のライバル会社出身の方で、超大手に分類される方でした。
実はその方の出身の会社って、ここ数年顧客と「求められるシステムを作れない」なんて大騒ぎになってちょくちょく話題になったりしてたんですよね。
※表現はぼかします。
ただまあ、こういう話を思い出すと、海外でDDDが話題となった理由も何となく分かるかなあ。
今思えばやっぱりなって感じなんですけど、ドメインや業務知識といった能力はシステム開発のベースになるんだし、それを無視したら行けないだろって思うんですよ。
以前、DDDの話を最初に聞いた時にそんな感想を持った次第でした。
ドメイン・エキスパートとソフトウェア開発者は一体とするべきか
元記事だと一体化するべき、という意見なんですけど、個人の経験的には分離したほうがよい、って思うんですよね。
最大の理由は、「ドメインモデルの難易度と、ソフトウェア開発の難易度に相関があまり見られない」から。
つまり、複雑で解決困難なドメインモデルがあったとしても、実際のソフトウェアを作成する際には、案外簡単なものとなっていることがよくある話。
逆に、ドメインとしてはカンタンなものでも、実際にソフトウェアをつくろうとした場合に非常に苦労するようなこともある。
※非機能要件がらみの開発物とか。
となれば、優秀なプログラマ・ソフトウェア開発者をドメインモデルのタスクに割り当てて時間を消費することは、ときとしてもったいないことだったりするので、適材適所で上手く役割分担をしたほうが良いって感じたりもするんですよね。
プログラミングのスキルを鍛えるのにパワーが必要になるように、ドメインを理解し定義できるようにするにもパワーがいる話なので、理想的には両方の能力を鍛えることとはいえ、どちらかにならざるのは仕方ない部分もあるんじゃないのかな。
なので、その現実を直視し、
ドメインモデルが、開発者とドメイン知識をもつ人（ユーザ、専門家等）との間の共通言語となるようにする
ってのがDDDの基本的な思想なんだろうなって思うわけです。
DDDの話に触れた際に、チームとして頑張りましょうってことなのかな、なんて考えたことをふと思い出しました。
まとめ
まあ、ざっくりと書いたのですが、結局言いたいこととしてはドメインの重要さを軽視せず、また重く見過ぎず、上手く付き合えるようにしたら良いんじゃないかなと思います。
いつもどおり、バランスが大事ってことですかね。
以上
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
プロジェクト特性とドキュメンティングルール
いいこと書いてあったので一言何か言おうと思っていたのですけど、すっかり忘れていた。。。
ドキュメントって使い方次第では毒にも薬にもなるのですけど、プログラミングほどお作法や考え方がまとまっていないと常々感じております。
コーディングルールならぬドキュメンティングルールって案外重要なのですが、いろんなプロジェクトの様子を聞いたところ、なんとなくの過去踏襲って事例が多く、きちんと定めてないチームも多いんですよね。
プロジェクト特性とドキュメンティングルール
機能仕様書を読みやすくするためのテクニックはどれも納得いくもので、参考にすべき内容と思いますが、一点だけ補足しておきたい項目があります。
【2】仕様書テンプレートは作らない
企業や組織内で、「機能仕様書に書くべき項目を定型テンプレートにまとめておきたい」という誘惑に駆られるかもしれませんが、一般論として筆者はお勧めしません。
開発プロジェクトにはそれぞれに異なる事情があります。機能の規模やシステムのアーキテクチャもそれぞれ異なるでしょう。必然的に仕様書に記載すべき項目の種類や粒度も変わってきます。従って、その都度項目を洗い出すことが設計作業としてむしろ重要です。
（中略）
テンプレートが可能なのは、システムの対象分野や規模を限定できる場合だけだと思います。
常々感じていることで、「プロジェクト特性に開発工程や成果物は準じる」ってのがあります。
プロジェクトが、受託か内製か、バッチかオンラインか、モノリシックアーキテクチャか分散アーキテクチャか、みたいな感じの様々な要因があるかと思いますが、それらの特性は成果物であるプログラムに影響を与えますが、同時にドキュメントにも影響を与えます。
受託や内製の違いはドキュメントの納品の有無の違いにより、記述レベルの注意が必要となります。
バッチかオンラインかの違いは、利用ユーザに対する外部仕様が異なりますので、仕様の考え方が異なります。
モノリシックアーキテクチャと分散アーキテクチャの違いは、システム境界と公開仕様の考え方が違います。
とまあ、つくろうとするものが違えば当然必要となるドキュメントも違うということなんですけど、PMOとかそういった実働部隊じゃない人に限って「会社の標準フォーマットに従ってない」とかミョーな指摘をもらうハメになるんですよね。
なので、プロジェクトが開始されたら、真っ先にドキュメントの標準化（テンプレ化）、ドキュメント規約を定めてしまい、「我々のチームでは今回のプロジェクトに合わせて社の標準フォーマットを参考にドキュメント規約を作成した」って宣言してしまうのが個人的には楽かな、と思います。
外部からの余計な声に惑わされずに済むだけでなく、チームのメンバーもドキュメントを書きやすくなり、「個々の考えを形式知化し、共有する」というドキュメントの目的を達成しやすいので。
プロジェクトをまたいでのテンプレ化は参考程度にしかならないと思いますが、プロジェクトに特化したテンプレ化はお役立ちになると思います。
個人的に感じるプロジェクト特性とドキュメントの関係
以下、個人的に感じたドキュメントとプロジェクト特性の関係。
粒度（右ほど粒度が細かくなる）
- 保守期間（短 ＜ 長）
- 契約形態（内製 ＜ その他企業 ＜ 公共 ＜ 銀行・銀行関連）
- 開発形態（社内 ＜ ニアショア ＜ オフショア ）
量（右ほど作成するドキュメントが増える）
ただの個人的な感想なので、代表的なものだけ。
まとめ
取り留めもなく色々書きましたが、一番肝心なことは、成果物として、どのようなものを作成するかの定義は、プロジェクトを成功させるためには重要なファクトであり、マネージャの腕の見せどころでもあると思うわけです。
以上
バグとプロスペクト理論
直接は関係ないんですけど、これ読んで思い出したので。
バグとプロスペクト理論
長期的に利用されるシステムやソフトウェアって、殆どの場合何らかの改修開発が行われるわけですよね。
で、修正するとバグも発生することがあるわけですが、改修開発の場合「新機能バグ」と「デグレバグ」がおきます。
新機能バグは、改修で新たに追加しようとした機能で発生したバグ。要は、追加機能が目標の機能を達成していない場合のバグ。
デグレバグは、改修してない既存の機能で発生したバグ。まあ、変更してない部分で思わぬトラブルを引き起こしたパターン。
バグはいずれにせよ顧客満足度を下げるものですけど、どちらのほうがユーザの不満を高めるかというとデグレバグの方が高めると思ってます。
理由は上記の図の様なプロスペクト理論がバグにも適応されるから。
プロスペクト理論は「損失回避バイアス」。
同等の利益と損失を比較した場合、損失を回避するようバイアスがかかる、ってやつです。
つまり、新規機能のリリース延期をユーザに宣言するのと、無理矢理リリースした結果既存機能にデグレを生じさせるというのでは、時に後者のほうがユーザの満足度を下げる原因になるってことですね。
そんなこんなもあって、オッサンのとこのシステム開発の現場では、デグレバグはご法度、みたいな品質管理を行っているんですね。
テストの自動化など、ゴニョゴニョと。。。
まとめ
結局のところ、ソフトウェア開発をビジネスにするってことは、顧客満足度を如何に向上させるかという視点で、行動ファイナンス等の考え方が適合されるなって場面があると思ってます。
今回のバグの件もそう。今回はプロスペクト理論を提示しましたけど、他にも品質管理の考え方として適応できそうな物があります。
そんなこんなもあって、新規機能の追加を現行機能保証より優先しちゃったらユーザの怒り爆発だよな、なんて元記事見てたら思うわけです。
まあ、アメリカのベンダと一緒に仕事して、現行保証のところで痛い目を見たことが数度あったので、さもありなんって感じな。。。
ま、デグレには気をつけておきましょ。
以上
プロジェクトマネジメントで大切な一つのこと
ほうほうと思って内容見ていたのですが。。。ちょっとだけ。
プロジェクトマネジメントで大切な一つのこと
まあ、プロジェクトマネジメント語る上で、スケジュール管理や課題管理など、色々管理しなければならないことがあります。
PMBOKでは、以下の様なことを管理しろとあります。
- 総合管理
- スコープ管理
- タイム管理
- コスト管理
- 品質管理
- 人的資源管理
- コミュニケーション管理
- リスク管理
- 調達管理
- ステークホルダ管理
教科書的には上記のような管理が大切なのできちんと行いましょう、というのが答えになるんでしょうけど、それだけだとつまらないので。。。
オッサンが考える、プロジェクトマネジメントで一番大切なことは何か、と聞かれればぶっちゃけ「計画」かな、と答えます。
要は、不確定要素がなくやるべきこと明確で、ステークホルダーの誰もが文句を言わないような状態に持ってきて。で、スケジュールも余裕。予算もきちんと抑えた状態。こんなだれでも勝てるプロジェクト計画立てられるようにすることが重要と。
・・・まあ、プロジェクトの進め方の答えが事前にわかってれば、淡々と仕事進められるわけで当然なんですけど。。。
実は、PMBOKなんかでも「計画」を重点的に記載してたりしてるんですよ。
プロジェクトは変化していくもの。なので、この前提に立って変化に耐えられるような実行→監視→再計画のフィードバック管理も重要なのですけど、それらの変化すらも予想できるような計画立てられれば更にスムーズなプロジェクト運営ができるだろうと思います。
計画段階で落としこみができていれば楽
プロジェクト計画ってわりかしおろそかにされたり、場合によっては読めないからとりあえず開発しようなんて進められたりもします。これもまあ一つの答えであるわけですが。。。
※この場合は、リスクが積み上がった状態でプロジェクトが進められていることとなりますね。
ただ、気をつけなければならないのは、「スケジュール管理」や「課題管理」として実行の場に出てきた問題ってのは、事前の計画段階で潰しこみができていれば半分以下、場合によっては1/10よりも小さな労力で対応できることもしばしばです。
後手後手の対応では、どんどんコスト・労力が積み重なってきてしまい、対応にかけるリソースが不足してきます。エスカレートしていけば、ついにはデスマーチに突入となってしまいます。
コスト管理やリソース管理は重要です。それが成立してなければ、スケジュール管理や情報共有の仕組みも機能しません。
デスマーチ状態に陥った場合、ちょっとやそっとのスケジュール管理や課題管理では焼け石に水状態だったり。デスマーチ状態での課題・問題分析は精度が下がったりすることもあり、更に傷口を広げることもあります。
なので、デスマーチに陥らないよう事前にどうすれば最小の労力、最小のリスクでプロジェクトを達成できるか、計画をたてることが重要ってわけですね。
てなわけで、早め早めに対応するよう、実行段階の管理も重要なのですが、それ以上に計画をマネジメントすることが重要だと思うわけですよ。ついでに言うと、実行段階で出てきた課題や問題の振り返りをきちんと行い、次回のプロジェクトの計画の精度を高めるようにすることが大切だったりも。
まとめ
実は、オッサンも昔は「スケジュール管理」や「課題管理」などの実行プロセスを血眼になって追っかけていたのですが、それでは見えないコストばかり積み重なってきてしまい、残業だなんだと疲労の毎日になってしまったのですね。
それからというもの、計画段階で如何に楽で勝てる計画をたてるか、ということに注力するようにしました。
慣れてくれば、中小規模の案件なら、前述した理想状態のプロジェクト計画を立てられるもので、スケジュール管理や課題管理などであまり苦労することなくプロジェクト進められますよ。
大規模案件ではなおさら。計画段階できちんと先読みができるかどうかで、その後の労力は段違いです。
なので、元増田氏の語るように実行段階のマネジメントも重要なのですけど、もう一步進んで計画をマネジメントすることも気をつけたほうがいいんじゃないかなと。
プロマネに求められる重要な素養として、幅広い情報収集能力と、現状分析や経験から、未来を予測し、早期に問題発見できる能力になるんじゃないのかな、なんて思うわけです。
※情報共有についてなど他にも語りたいことがあったのですが、だるくなったのでこのぐらいで。。。
以上
プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2014/02/15
- メディア: ペーパーバック
- この商品を含むブログを見る
プロマネの価値を発揮できる場所
最近、PMBOKの再勉強していたらすっかりブログの更新を怠ってました。
ちょっと前に読んだ記事ですけど、自分なりの考えを書きたいなって思ってたんですよね。
元記事はプラントの話でソフトウェア開発とは若干違うのですが、感じるところがあったのでちょっとだけ。
プロジェクトは順調で在り続けられるのか
最初から最後まで順調な仕事では、プロジェクト・マネジメントなんて、ほとんど何もすることがないはずなのだ
コレは全く疑うことがないことで、順調な局面はプロマネのすることなど何もないです。言い方を変えれば、順調な局面に抑えることができなければプロマネの忙しさはうなぎのぼりであり、ときとして過労死寸前の生活が当たり前という過酷な状況となることもしばしばです。
システム開発の現場では、何もしなくても最初から最後まで順調で在り続けられるというのはかなり難しいと感じてます。
小規模で要件も明確、誰もが同じコンセンサスで活動可能な案件であれば、最初から最後まで順調というのは難しくない反面、ちょっとでも規模が大きくなると、開発が進むにつれてアヤシイ状況が発生することもしばしばです。
こういう問題が生じるのは、案件規模が大きくなればなるほど、ステークホルダーが増えてきて、それぞれ目する「プロジェクトの目標・あり方」、つまりプロジェクトの姿が異なることにほかならないかと思います。
知的活動としてのシステム開発とプロマネ技術
では、なぜステークホルダーが増えるとプロジェクトの姿の見え方が変わるのか。
これは、システム開発が知識集約的な仕事*1だからにほかならないかと思ってます。
要は、システム開発の現場が顧客の考えた要望、アーキテクトの考えた理解、SEの考えた判断、プログラマの考えた発想といった知的活動に支えられているから。
作業手順書を作れば仕事ができるわけでもなく、また、ITやツールや機械によって自動化される仕事でもなく、人間の考えが必要な仕事だから。
で、それらの知的活動を行う人間を作り上げた経験、学習履歴といった土台が異なるがゆえに、向いている方向がバラバラになってしまうと。
そういったコンセンサスは、関わる人間が少ない小規模開発案件であれば発散しづらい反面、関わる人間が膨大となる大規模開発案件であれば、四方八方に発散してしまうと。
で、それらの人間がきちんと同じ目標に向けて活動できるようにするためには、個々人の考え、思いをきちんと整理し、動機づけを行い、組織としての活動に転換できる技術としてプロジェクトマネジメント技術が必要になるんだろうと思うわけです。
※これだけだと、プロマネ技術中のステークホルダーマネジメントだけですけど。。。
補足：SIが「労働集約」と呼ばれること
ときおり「SI産業は人月商売だから労働集約産業である」なんて言説を時折見かけるのですが。。。
他にも知識産業と呼ばれるコンサルや研究産業だって、準委任契約結べば立派な人月商売になってしまうオチなんですよね。
※「産業」ではなく「収益構造」ということなのかな。であれば理解できるんですけど。。。
元々、知識集約産業が通産省構造審議会で規定された時「知識集約型産業は労働集約型産業である」という言葉で語られてました。
要は、「知識を発揮するのが人間である以上は、労働集約に必ずなる。労働集約と知識集約産業を分けるのは単純労働か知的労働かの差である」と規定されてました。
「知識集約型産業」の言葉の定義に照らし合わせれば、受託開発は「知識労働集約型産業」となり、サービス開発は「知識資本集約型産業」と呼ぶのが正解かな。
まあ、本当にSIの現場が単純労働的な労働集約的ならば、さっさと仕事のやり方マニュアル化して、それこそ誰にでもできるような仕事にして儲かるようにできるんですけどね。
まとめ
誰しもがマニュアルに従って動く労働集約の仕事や、機械が動き続ける資本集約の仕事の中でプロマネ技術が活きることは無いでしょう。
そういった現場で必要となるのは、また別の管理技術。
繰り返しとなってしまいますが、プロジェクトマネジメント技術が価値を発揮できる局面は、「（本来の定義の）知識集約」の仕事の中でこそだと思います。
以上
プロジェクトマネジメント知識体系ガイド（PMBOKガイド）第５版 (A Guide to the Project Management Body of Knowledge)
- 作者: Project Management Institute
- 出版社/メーカー: Project Management Inst
- 発売日: 2014/02/15
- メディア: ペーパーバック
- この商品を含むブログを見る
*1:参照 ： 知識労働集約型産業としての視点から
問題に合わせてアジャイル、ウォーターフォールを工夫することが肝要だよね
上記の記事を読んでいて少し考えるところがあったので。
SOAとウォーターフォール開発
とあるシステムの話です。
社会規模と呼ばれる様な巨大なサイズのシステムであり、そのデカイ図体を支えるためにSOA（Service Oriented Architecture）の考え方をベースとしたシステムで構築されてます。
それぞれのサービスは、サブシステムにより構築されるわけですが、サービス間の整合性や機能重複など、サービスとして効率的に開発するためには、アーキテクチャ設計をきちんと考えることが必要だったりして、トップダウン設計の色が濃い面があったりもします。きちんとしたドメイン設計を行わないと恐ろしいことになります。
で、こういった構造のシステムだったりすると複数の分散した機能を改修したりするわけで、全体整合性を保つ都合上、テストタイミングを揃えて一貫性のあるテストをしなければならない。
つまり、オッサンの経験の範囲ではあるのですが、SOA開発では、ウォーターフォール型開発をきちんと適応しないとうまくいかない場合がしばし発生するんですよね。
もうちょい言うと、ここでいうウォーターフォールも、古きよきガントチャートを使った進捗率片手にガリガリ進めるタイプ、と言うよりか、各サービスは自由に開発しながらも設計、テスト等の要所で同期を取る様なタイプになっていたりもします。
イメージにするとこんな感じ。
上記の開発手法（パラレルウォーターフォール*1）は、単一システム開発で適応するとかなり恐ろしいことになるんですけど、SOAみたいな形態だと綺麗にまとまるのが、システム開発では面白いところですね。
※まあ、業務ドメインを分割している都合上、上記のような開発スタイルを取らざるを得ないのが実情かなとは思いますが。。。
SOAとmicroservice、ウォーターフォールとアジャイル
さて、ここまで書いてふと思い出したのが、数日前見た以下の記事。
類似する技術が流行ってきた起点を考えれば、多分SIerが抱える問題と同じような問題にウェブ業界の世界もぶつかったんだろうな、と思ってます。
さて、ここで元記事の話に戻るのですが。。。
ところで、SOAってSIerでは枯れてきた技術ではあるわけで、発生した問題についてもある程度見えたりもしてます。
前述のような、全体整合性を保つアーキテクチャ設計やテストが必要なため、ウォーターフォールが見直された、みたいな話もそう。
ということは、microservicesはSOAと類似した部分も多いことから、開発の中で抱える問題も似たようなものが今後発生するんじゃないのかな、なんて思うわけです。
つまり、microservicesの現場でも、ウォーターフォールも見直されるのだろうか？microservicesが巨大化したシステム、サービスを効率的に開発するために必要とされた背景で導入されたのであれば、SOAと同じくウォーターフォールが必要な場面が出てくるんじゃないだろうか？あるいは、ウォーターフォールと類似の概念が異なる言葉で語られるようになるのではないか？なんて思うわけです。
今回の記事を見て、ふと上記のような感想を思い出したわけです。
オマケ１：microservicesとSOAの相似性
上記の記事を含めて、microservicesが語られるとき、SOAとは違う、みたいな記載がありますけど。。。
実装例を見るに、10年以上前に構築された事例だとSOAミドルウェアを使わずに、MQとAPI（SOAPやWSDLなど）だけでESB作ってSOA構築するなんて構築例ありますし。メーカ系SIer以外では、自前で作る例が結構あるんじゃあないのかな。
SOAって実装例、開発方法が様々なんですよね。なので、構造や組織論などの枝葉を見ると同じだ、違うって話が出やすいんでしょう。
実際 Microservices にあるmicroservicesアーキテクチャの特徴をみるに、SOA型のシステムのうち、重厚なミドルウェアが売り出される前にSIerオリジナル技術で構築されたSOAが備える特徴と一致しているのですね。アーキテクチャだけでなく、開発スタイルみたいな組織論としても、この手のSIerでは、独立したサービスを独立したチームが開発するみたいな感じの開発スタイルを取っており、一致してたりもするわけで。
SIerでもエンプラシステムが肥大化しすぎた結果、解決方法として分散型のアーキテクチャが必要となった背景より、上記のようなSOAを導入した経緯があります。
問題が似ていれば解決方法も似てくるわけで、SIerかWEB系か起点が違うだけの収斂進化みたいなもんだと思ってます。
オマケ２：SOA後のエンプラ技術の進化
SOAが導入されると、SIerでもより効率的な開発を目指して工夫を追加したりするんですよね。
例えば、従来型の３層アーキテクチャだと開発しづらい場面があるので、プレゼンテーション層、フロントアプリケーション層、データベース層にバックアプリケーション層、データバス層を追加した５層アーキテクチャに変えてみたりとか。
こういった技術についても、そのうち広がっていくか、もしくはSIerは技術情報をあまりオープンしないので、前述のように収斂進化の形で開発されるんじゃないかな、なんて思ってます。
違う方向に進化したら面白いので、引き続き技術動向は追っていきたいな、なんて思ってますね。
まとめ
まあ、だらだらと書きましたが、結局のところ、技術って問題を解決するための手段であり、類似する問題があれば類似した技術が必要になるってのが重要なんじゃないかなと思います。
前記とは視点を変えてみると、SOAにより分割された小ドメインのオンライン中心のサービスは、特定業務ドメインに特化した小さなモノリシックなWEBシステムと見ることもできるわけで、そういったシステム特性があるのであればアジャイルが楽となる場面も多い。
そういった点では、以前の記事*2で紹介したハイブリッドアジャイルみたいな、ウォーターフォールとアジャイルの良いと取りを目指した開発手法などが有効だったりもする場面も多いです。
※オッサンも愛用してます。
というわけで、一番重要なことは何かといえば、問題に合わせてありとあらゆる工夫することが肝要だろうなあと思うわけです。
以上
SOA大全 サービス指向アーキテクチャ導入・設計・構築の指針
- 作者: カール・バンク,ディルク・スラマ,山下眞澄,ディルク・クラフツィック
- 出版社/メーカー: 日経BP社
- 発売日: 2005/11/23
- メディア: 単行本
- 購入: 4人 クリック: 37回
- この商品を含むブログ (22件) を見る
