SOAで利用されるパターン２つ
前回、システム分析アプローチについて記述しましたが、 これにひき続いてSOAの中でもよく使われるパターンが有るなって思ったので追記です。
SOAは元がオブジェクト指向設計（OOA／OOD）であることから、ソフトウェア開発のデザインパターンを適応できそうだな～って前々から思っていたので、ちょっとだけ描いてみます。
その① Facade型
インタフェースに用意された機能が複数のサービスを呼び出し、一連の業務を遂行するパターンです。
例えば、「販売」みたいな機能があった場合、「在庫引当」サービスと「会計計上」サービスを呼び出すみたいな感じ。
一人の事務員が一連の事務手続きを行う姿に似てます。
ユーザからはサービスが隠蔽されますので、サービス内容や利用するサービスの種類が変わったとしてもインタフェースで差異を吸収できる形となります。
反面、インタフェースとサービスとの間のつながりがN:N構造となっており、複雑度が高い関係となっており、保守性がその分低下する恐れがあります。
その② Chain of Responsibility型
インタフェースから呼びだされるサービスは最小限なものの、そこから発生されたデータが複数のサービスに連携され業務処理を行うパターン。
例えば、「売上サービス」から、売上データをバスに送出。バスではそれらを複数のサービスに伝播し、引き続き「会計計上」や「在庫引当」を行うといった形となります。
営業マンが売上伝票を作成し、それを複写、会計担当や在庫担当などに渡して、それぞれの担当者が処理をするような感じです。お役所などの窓口業務をイメージしてもらうとわかりやすいと思います。
GoFデザインパターンのChain of Responsibilityに似た処理構造となってます。
インタフェースとサービスとの関係はシンプルとなっており、保守しやすい形となってます。また、バス側の情報伝達は送信側と受信側で疎な関係となっており、例えば新たなサービスを追加して処理を行う場合でも、他のサービスは影響を気にする必要がありません。
反面、処理は原則非同期となるため、複数のサービスが処理を完了させるまでに時間がかかるおそれがあること、同期が必要となる処理の場合、対応ができないなどの問題があります。
まとめ
もうちょっとパターンを分析できそうな気もしましたが、力尽きたのでこのくらいで。
個人的な感想としてオブジェクト指向プログラミングとオブジェクト指向設計アプローチでは、構造などの部分で相似関係を持てそうだなって気がします。
となると、SOAの設計ではOOPでよく使われる技法を応用できそうだなって思ってます。まあ、システムとプログラミングなんで、クラスとインスタンスみたいな関係は持ちづらいですし、全く適応可能かって言うわけではないのですけど。
※システムは基本全て実態ですしね。。
以上
システム分析アプローチを後輩と話した件
後輩とシステム分析アプローチについて話す機会があったので、ちょっとだけ。
システム分析アプローチ
システム開発を行う中で欠かせないのが、システムをどのように構築するのか分析するためのシステム分析アプローチです。
それぞれのイメージを書くと以下のとおり。
POA（Program Oriented Approach：プログラム指向アプローチ）
業務フローなど、対象となるシステムモデルをベースに、事務手続きなどの「プロセス」をプログラムに落としこんでシステムを構築する技法。
- 小規模のバッチを中心としたシステムではわかりやすく作りやすい強力な設計技法。
- でも、規模が大きくなるとスパゲッティなシステムとなってしまう。。。一個一個のアプリをどんなにきれいなプログラミングしても、システム全体がスパゲッティとなると破綻してしまう。。。アプリケーションの影響範囲を探るのは大変。
- SOAとかでも、サービス内部ではこの手法を利用して設計することもある
DOA（Data Oriented Approach：データ指向アプローチ）
帳票や伝票といった業務で利用する「データ」を中心に、各事務手続きをデータの更新を行う機能とみなしてシステムを設計する技法。
- POAと異なり、データは比較的変更が少ないため、業務改修に強い。特に、オンラインが必要なシステムでは役立つ
- でも、細かい改修には強いが、データ構造を変えるような変更があった場合はやっぱり改修はそれなりに必要。システム改修時の影響調査は、POAよりはるかにやりやすい。
- 中規模でもわりかしシステム構築しやすい
SOA（Service Oriented Architecture：サービス指向アーキテクチャ）
対象となる業務をいくつかの業務機能をベースとした「サービス」を中心に構築し、ユーザからのインタフェースは共通のまま、内部のサービスを複数組み合わせることでシステムを構築する技法。
- サービスの単位で外部とやりとりするアプリケーションインタフェースをもたせ、サービス内部にデータを持たせる。一種のオブジェクト指向設計。設計フォーカスが絞りやすく、影響も極小化しやすいので大規模システムでも構築しやすい。
- 業務単位に分割したサービスを構築するので、外部設計工程から設計を行わなくてはならない。内部設計からでは間に合わない。
- 従来のサブシステム分割と似ている。たまに間違える。単純なサブシステム分割と異なり、情報伝達バスの共通化など、基盤共通化をきちっとやっておかないと効率的な設計はできない。
- 設計、開発、修正と言った個々のシステム単位では構築しやすいけど、システム全体が見通しづらくなり、個別最適化しやすい。人によっては開発効率が落ちるという人も。
適当ですけど、こんな感じ。
まとめ
- システム分析アプローチの選択は、生産性に大きく影響をあたえるので十分注意が必要。小規模なシステムでSOAを使っても生産性は上がらないし、大規模システムでPOAだと保守がままならない
- 大規模システムほど保守性が命となる。複数の業務システムが必要となった段階でSOAを検討したほうが良い。
- SOAが真の意味で価値が生まれてくるのは、スクラッチ開発ではなくパッケージやSaasと組み合わせたとき。てか、スクラッチだとよっぽど規模が大きくなければあまり嬉しくない気も。「パッケージを使って標準的な業務を導入する」という思想で語られることが多いけど、「パッケージを標準パーツとして利用し安価でスピーディなシステム導入を行う」を目指すべき
とりあえず。こんな感じ。
続きを書きました
以上
新人プロジェクトリーダ向け。チームとプロジェクトを動かす１０のポイント
もうすぐ４月ですね。
４月は人事異動の季節ということで、配置換えなど、仕事が変わることもあるかと思います。
オッサンの後輩なんかもこの時期チーム体制の変更などにより新たにプロジェクトリーダなどに抜擢される人もいるのですが、だいたい半年ぐらいは苦労する人も多い。
そんな若手に向けて、オッサンが過去行ってきたアドバイスをちょっとだけまとめてみます。
新人プロジェクトリーダ向け チームとプロジェクトを動かす１０のポイント
１．チームメンバーが仕事ができないと思ってイライラしてはいけない
リーダに抜擢される人は、設計やプログラミングなど仕事ができる人を抜擢するケースがよくあります。で、仕事ができる人がリーダになった場合、自分を基準につい仕事を割り振りがちだったりします。
「オレなら１日でプログラミングが終わるのになんで３日もかかるの？」とか、つい言いがちですけど、グッとこらえてください。
メンバーを基準に仕事をすることの、最初の洗礼みたいなもんです。
２．依頼や説明は丁寧すぎるぐらいがちょうどいい
以前、「詳細設計書も問題だけど、それ以上に成果物定義が問題 - プロマネブログ」でも書きましたけど、概してリーダのやりたいこと、やってほしいことはメンバーにきちんと伝わらないことは多いです。
リーダになりたての頃は、具体的すぎるな、と自分で感じるぐらいきちんと説明するぐらいがちょうどいいと思います。
３．自分でやったほうが早い、は危険
１，２みたいな事態が続くと、つい自分で仕事をやったほうが早いんじゃ、と思っちゃう場面もあるかと思います。
特に、プレイングマネージャーとして現場でも活躍している人を周囲で見たりすると。
でも、最初から無理してプレイングマネージャーとして活躍しようとすると、自分の仕事が想定外に増えたりした場合に、チームリーダーの活動が停止し、チームとしての仕事が停止する危険性があります。
プレイングマネージャーとして活躍するのは、チームを安定して回せるようになってからの方が無難かと。
４．とりあえず半歩先を見る
プロジェクトリーダーで、ある程度仕事が慣れている人ならば次の次の工程ぐらいを読んでプロジェクトを進めたりもしますが、最初はまず今の工程→半分ぐらい進んだら次の工程を見るぐらいの半歩先を見た活動でも問題無いです。
最初そんなに大規模な案件を、いきなり担当することは無いでしょうし、半歩先でもリスクは少ないかと思います。
むしろ、今の工程がきちんと回っているか、しっかりと確認しながら進めたほうがリスクが少ないです。
５．数字にこだわりすぎない
リーダになりたての頃は、つい進捗率などの数字が気になってしまい、細かく数字をチェックしがちなタイプの人もいます。
プロジェクトを進めていれば数字に多少差異が生じることなんて当たり前です。
しかし、リーダとして慣れないと、どのぐらいずれても大丈夫なのかみたいな感覚を持つことができないので、つい数字に頼ってしまいます。
数字合わせのチェックにこだわりすぎて、本質的な「プロジェクトに問題が起きているかどうか」のチェックを忘れないように注意することが必要と思います。
６．上手く上の人を使う
リーダになりたての頃は、ステークホルダーとの調整に苦労します。特に、お客と直属の上司でないお偉方。
お客は、なんだかんだ言って仕事に信頼を求めてたりします。そういった意味で、若手の理論よりベテランの概論が効果的な場面もしばしば。
状況に応じて、先輩も使うこともリーダとしての仕事です。
難しいお客さんを相手にしなきゃいけないなあ、なんて場合は、最初から先輩を体制に組み込んで顧客対応させるぐらいの強かさがあると面白いですよ。
７．熟考と弱気は違う
思慮深いことはいいことですが、とか言って何でもかんでも「前のリーダに聞いてみます」「プロマネに聞いてみます」ではメンバーからの信頼を得ることができません。
あんまりにも自分の判断をしないでいると、いつしかメンバーの方から「直接プロマネに聞いておきますね」なんて言われてしまうことも。。。
最初のうちは相談事が多くても、少しづつでも良いので自分の判断を増やしていかなければなりません。
自分の判断で仕事を進める第一歩目の勇気を持つことからリーダとしての一步が始まると思います。
８．リーダーになっても相談は忘れずに
チームを持つと、ときとして万能感を持ったりする場合があります。相談するのが恥ずかしいと思ったり、プライドを傷つけると感じる場合もあるかもしれません。
でも、リーダになったからといって、何でもかんでも完璧に最初からできるわけではないですし、ベテランになったからといっても一人で解決できることばかりじゃあないです。
むしろ、適切な場面で他人から情報を集めることができる、相談できる力がリーダには必要です。
ひとりよがりにならないよう、注意してください。
９．自分色を出すのはまた来年
リーダになりたての頃は、今までこうすればうまくいくはずだったと思う改善を試してみたくなるかと思います。
でも、最初から新たな試みを導入しても、自分自身上手く扱うことができないですし、よしんば扱えたとしてもメンバーが新しいリーダに追いつくのに精一杯なこともよくあります。
まずは、安定してチームを回せるようになってから。自分色をチームに反映するのはそれからのほうがより効率的に効いてきます。
１０．法律は覚えておこう
チームで活動する場合、全員が自社員だけじゃない場合もしばしばです。請負、派遣、契約社員、トレーニー、社内出向。。。
そのような複雑なメンバー構成で仕事をしていると、良かれと思ってやったことが、実は偽装請負だったとか、派遣法違反だったとかになることがあったりします。
なにか新しいことをやろうとした場合に、それが法律的にOUTではないかある程度は判断できるよう、基本的な法制度は抑えておいた方が良いです。思わぬ落とし穴は、結構空いてます。
※心配なら法務や上長に確認することも。
まとめ
なんだか偉そうなこと書いてますけど、ぶっちゃけほとんど全てオッサンがプロジェクトリーダになりたての頃の失敗談です。
おかげで何度、上司に怒られ、お客に怒られたことか。。。
正直、色々書きましたが、どれもIT業界特有の話ではないかと思います。 どんな業界でも似たようなアドバイスってきっとあるんだろうなって思います。
４月より新たにリーダになる方は、今までのメンバーとしての仕事のやり方とは全く変わった仕事のやり方になることもあるかと思います。
くれぐれもがんばってくださいね。
※しかし、改めて自分で書いていて思うのですが、なんだか「親父の小言」みたいですね。。。まあ、子持ちのオッサンが語っているわけだし、「親父の小言」で間違ってはないですね。
以上
詳細設計書も問題だけど、それ以上に成果物定義が問題
この手の話題が定期的に上がるわけですけど、毎度同じだよねで終わってしまっては人間進歩しないので、何が問題でどうすればよいのか少し考えてみたく。
詳細設計書は「プログラム説明書」として欲しい。
まあ、元記事も多分業務システムの受託の話の模様なのでSIをターゲットに。
往々にしてSI、特にウォーターフォール開発のプロジェクトの中では、設計書などのドキュメントを多数作成いたします。*1
V字モデル的には、設計から開発に至るまでの間
- 要件定義書
- 基本設計書・外部設計書
- 基本設計書・内部設計書
- 詳細設計書
- プログラム
みたいな成果物を作成いたします。
個別の詳細は別のサイトに任せるとして、それぞれ記載する内容を一言で表すと、要件定義書は「スタートとゴール」、外部設計書は「業務とサービスの仕様」、内部設計書は「サービスの構造と機能の分割」となります。
※ただし、オッサンの受け持つプロジェクトに限る。
で、元記事で問題となっている詳細設計では「プログラム構造と仕様」を記載するわけですが、このプログラムの構造がまんまプログラム設計書（紙面コード）になって記載されちゃっているということですね。
オッサンの感覚的には、プログラム構造では、オブジェクトの相互関係や、IN/OUTなどのAPI定義など、プログラム仕様では入出力の動作説明など、「そのプログラムをどう使えばいいか」と言った仕様（と言うか説明書）を書いて欲しいわけですが、設計書という名前に惑わされて実装をそのまんま書いちゃっているんでしょうね。
無駄な成果物を作らないためにもMECEな成果物体系が必要
さて、いろいろな設計書を書くと言いましたが、無駄な成果物を書かないためのお約束として、成果物体系はMECEであるよう定義しなければなりません。
つまり、要件定義で書いたことは外部設計書では書かないし、外部設計書で書いたものは内部設計書では書かない、ということで、成果物間で重複しないように成果物の内容を決めなければなりません。
そういった意味では、プログラムと同一の内容が記載された詳細設計書は、MECEな関係を満たしてない時点で問題です。二重管理となるし。
詳細設計書で紙面コードを書く理由としてよく言われるのが、「ホスト時代はコンパイラが高価で一日僅かな時間しか使えないので、デバックを紙面で行うために作成した」といった過去の環境制約の名残なんて聞いたことがあります。
そういった環境制約があればMECEを崩しても必要かもしれませんが、時代と環境に応じて変えていい部分だと思います。
※ただし、オフショア開発だったりするとまた事情が違うので、一概にいらないと言えないのが難しいところですが。。。
まとめ
まあ、なんだかんだ書きましたけど、やっぱり詳細設計書って必要だから毎度作成しているわけなんですね。
ただ、何も考えずに「今まで作ったことがある内容を参考に、詳細設計書を作れ」なんてなっちゃうから、使えるんだか使えないんだか微妙な設計書が生産されることとなります。
必要な内容を必要最小限だけ作れるようにすれば、こういったごちゃごちゃした不満も解消されるかなあと思います。
※当たり前ですが、大体のプロジェクトはヒト・モノ・カネが限られているわけですし、不要なもんなんか作りたくないわけですし。。。無駄金を使っているのであれば、ある意味景気対策の立役者とも言えるのだろうか。。。
オッサン思うに、こういった成果物定義はプロマネの仕事なんですけど、惰性で決めちゃっているプロジェクトが多いように見受けられます。
プロジェクトの規模や特性、メンバーの力加減、保守体制に応じて成果物を定義することは、プロジェクトの円滑な推進と品質向上、その後の安定した保守のために必要です。必ずプロジェクトの最初には決めておかなければなりません。
というわけで、元記事に戻りますけど、オッサンの感想は詳細設計書の問題というよりか、きちんと何作るべきか定義できてない成果物定義の問題じゃ？との感想。
つまり、プロジェクト運営上の問題が詳細設計書という形で現れているだけじゃないのかなと思います。
というわけで、プロマネ仕事しろ！成果物をきちんと定義しろ！が答えな気がします。
※ただ、設計する人の話を聞くに「うちのプロマネに提言しても成果物体系を見なおしてくれない」なんて嘆きの声を聞いたりするので、ヘタしたらプロマネ替えろってオチになるかもしれませんが。。。
以上
*1:詳細はこちら。ウォーターフォール開発とアジャイルの本質 - プロマネブログ
デスマーチの行進の仕方
前回、みずほ銀行のプロジェクトが炎上しているんじゃないかな、と書きましたので、そこからの派生。
システム開発などプロジェクトに関わり続ける限り、いつ遭遇してもおかしくないのがデスマーチ。
クマに遭遇した時にやり過ごすために死んだフリすることもありますが、デスマーチに出会った時にやり過ごすための主な方法についてちょっとまとめてみます。
基本はQCDの再調整
デスマが発生した場合、いろいろなやり過ごし方がありますが、基本はQ(quality：品質)C(cost：費用)D(delivery：期限)を見直すことが基本です。
現在対処が必要となるプロジェクトの要求がプロジェクトメンバーの処理能力の限界を超えた時、往々にしてデスマが発生します。つまり、プロジェクトメンバーの処理能力の範囲となるよう、QCDを見直すということです。
Qualityを見直すということは、品質面を軽度にし、目標をより作りやすいものとすることです。
Costを見直すということは、プロジェクトの生産力を増加させるため、増員や環境などに投資を行うことです。
Deliveryを見直すということは、目標となる成果物作成期間を後ろ倒しにして、時間を稼ぐことで対処を行うことです。
他にもいろいろな方法がありますが、上記方法を抑えておけば大体の場合には対処可能です。
Qualityの再調整 ( 設計～システムテストで問題に遭遇した時の対策 )
Qualityの再調整を行う場合は、
- 要件
- 仕様
- 作り
のいずれかを見直すこととなります。
要件見直し（要件定義の見直し）
お客と合意した要件の見直しです。当然、当初約束していたことができなくなるのでお客は嫌がります。このレベルの見直しを行おうとする場合は、基本は政治力の勝負です。
とうとうと現在の仕様で進めた場合の破綻の危険性を説明して要件を削減してもらったり、カンタンに作れる代替案を用意しそちらの仕様に変更してもらったりととにかくお客に納得してもらえるよう、ありとあらゆる泥臭い交渉を行います。
オッサンの得意な交渉は後載せ案件化。とりあえずデスマになった時は、最小限度の機能構築にとどめ、不要不急だけどつくろうとしたモノは全て次回の案件にするってかんじですね。時には、暫定的な業務補助のためのフォローシステムを作ったりもします。
仕様の見直し（外部設計の見直し）
お客へ提供するシステムの機能を縮小し、とりあえず業務を維持できるレベルの品質で提供するよう交渉することとなります。
例えば普段は10回ぐらいしか発生しない業務で1000回連続で取引を行うとトラブルが発生する、や日本の国家予算以上の金額で取引をするとトラブルが発生するなど、通常の利用範囲外に対する保証を削ったりします。
要は、普段使いだけ保証して、それ以外は使わないよう制約とします、みたいな感じです。要件定義と異なり、お客側現場の実担当者と交渉しながら落とし所を調整したりします。
作りの見直し（内部設計・詳細設計・プログラミングの見直し）
お客に見えない部分で楽をしようという作戦です。要は「アーキテクチャやコードを汚くしてもよいから動くものを作る」。
保守性や性能などお客から見えない部分が悪化する事となりますので、お客との交渉は行わずに対応することができますが、プロジェクト内部でどこまで許容するか決めなければなりません。
とりあえず、で無秩序に行うと、保守性などが致命的な事になりますので注意が必要です。
とまあ、上記のように品質を対応可能な範囲にまで下げることで対処しようってわけです。個人的な実感として、効果は「要件見直し＞仕様見直し＞作りの見直し」、対応の容易さは「作りの見直し＞仕様見直し＞要件見直し」って感じです。
どの手段を用いるかはお客との関係次第になるかと思いますが、要件見直しはハードルが高く、作りの見直しは生産性が低下しかえって事態が悪化する場合もありますので、仕様見直しが一番やりやすというのが実感です。
作りの見直しは、当初のアーキテクチャに不良など設計の問題がない限りは手を出さない方が無難。さらに問題が発生した場合、二次災害になりかねません。
※お客への交渉力がない場合は、下手に作りを見なおしてドツボにはまる場面があったりするんでしょうね。。。
Costの再調整 ( プロジェクト通期で問題に遭遇した時の対策 )
当初予定していたプロジェクト処理能力では対処しきれなくなったということで、プロジェクト処理能力を向上させれるよう、追加要員や高スキル要員の導入、効率的なツールの購入等で対処する方法です。
デスマの原因次第ですが、プロジェクトで発生した課題の難易度が高いといった理由で詰まっている場合は「少数の有識者・高スキルメンバーの追加」。分割可能なタスクで担当者が不足している場合は「要員の追加」。作業環境がダメダメで仕事にならないって場合は「開発環境の改善」。とまあ、問題に応じてプロジェクトに追加投資を行う形です。
請負で仕事する場合、利益を食って対応するわけです。前述のQualityの再調整とは異なりお客との交渉は不要ですけど、社内のステークホルダーとの交渉が必要な感じですね。
きちんとプロジェクトの問題を分析した結果、生産性に問題があった時にだけしか適応できないです。
単純に要員を追加しても問題が解決しないってのは、ブルックスの法則（人月の神話）のとおりですが、要員を追加しなければどうしようもないって場面もあったりするので、きちんと状況を分析することが必要です。
人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)
- 作者: フレデリック・P,Jr.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
- 出版社/メーカー: アジソンウェスレイパブリッシャーズジャパン
- 発売日: 1996/02
- メディア: 単行本
- 購入: 4人 クリック: 126回
- この商品を含むブログ (47件) を見る
Deliveryの再調整 ( プロジェクト通期で問題に遭遇した時の対策 )
目標とする期限には間に合わなさそうだが、時間があればなんとか解決できそうな場合に期限を延長することで時間稼ぎを行う方法です。
通常、納期には余裕を持たせているわけですが、その余裕期間を超過しても対応が間に合わない場合は期間の調整を行うこととなります。
当然、お客は嫌がります。なので、調整できない、政治力が必要となったりすることもしばしば。
また、単純に期間延長したとしても、他に問題があり解決できてない場合は、結果として期間が間に合わないこともよくある話。
なので、単体でDeliveryの調整だけを行うことはめったにありません。
例えば、QualityやCostの再調整による問題解決のために、時間を稼ぐ目的でDeliveryの調整を行います。
まとめ
それぞれQCDの調整方法をざっくりと上げてみましたが、デスマーチが発生した場合に対処するためには、まずはプロジェクトの運営課題の分析を行った後、QCDのいずれ、もしくは複数の手段を選択する事となります。
なので、きちんとプロジェクトを見ていないと対策を打つことができません。
プロマネはきちんとプロジェクトをウォッチし、問題の兆候を素早く検知することが必要です。
また、お客との交渉力も重要です。ここまで来るとプロマネの政治力の有無がプロジェクトの生死に影響を与えます。
そういった意味では、プロマネはお客との交渉力を鍛え、時にはバーター条件を設計に組み込むだけの柔軟な設計ができる力が必要となりますね。
こういったトラブル対応が得意なプロマネっているんですよね～。
よく火消し屋なんて呼ばれたりするんですけど、こういったプロマネってデスマや障害発生時に重宝します。
※プロマネの種類はあとでまとめようかな。。
とまあいろいろ書きましたが、なにも考えずにデスマーチに突撃するよりも 、対応方法をきちんと知っておくだけでも討死率は減ると思います。きちんと対策を理解して楽しくデス・マーチを行進しましょう！
※ま、デスマにならないようきちんと事前に対応するのが一番ですけどね。
以上
技術以外に設計に影響を与えるもの
論理削除と物理削除
ソフトウェア設計を行う際に、物理削除と論理削除ってのがあります。
物理削除というのは、データを削除したいとコマンドを発行したときに、データを即座に消す設計です。
これに対し、論理削除と言うのは、データを削除したいとコマンドを発行したときに、データを実際には消さずに利用者から見えなくする設計です。windows のゴミ箱をイメージすると分かりやすいかと思います。
この物理削除と論理削除、昔からどっちを設計上で採用するんだ、でもめることが多く、さながらキノコたけのこ論争みたいになったりすることがあります。
オッサンが若手の頃は、「とりあえず論理削除にしておけば後で問題が起きたときに復旧しやすいから安心」なんて教わったりしてました。
でも、最近は「積極的な要件がない限り、物理削除とするべき」という思想になってます。
そんな風に考えるようになったのは、以下の理由があります。
その１ コストベースオプティマイザの登場
最近のオラクルでも当たり前のように採用されるようになったコストベースオプティマイザ。
このオプティマイザ使っている環境だと、論理削除みたいに現在使わないデータが含まれていると、欲しい有効データ検索がうまくいかないことがしばしばありました。
その２ AWSのようなデータの従量課金型クラウドの登場
AWSみたいにデータ量に応じて課金額が変化するクラウドを利用すると、お金をかけてまで使わなくなったデータを残しておく必要はあるのか、という問題が出てきます。
その３ セキュリティの問題
退会等により削除されているべき個人情報が、実は論理削除状態であったため、流出してしまった、なんて事態となったら目をあてられません。こういったセキュリティリスク回避のためにも、極力不要な個人情報を持たせることとなる論理削除が問題となる場面が出てきます。
とまあ、こんな感じの技術的&社会的パラダイムの変化により、オッサンの中では「とりあえずの論理削除」から「必要最小限の論理削除」に設計方針を変えたわけです。
厄介な社会的パラダイム
さて、長くなりましたがここまでが前置き。
本題です。
いろいろプロジェクトの設計方針などを検討するのですが、前述した技術的なパラダイムってわりかしIT技術者がチェックしやすい領域だと思う反面、社会的なパラダイムって如何せん見落としがちだよなあって常々思います。
社会的なパラダイムって法律対応みたいなところで現れることも多く、例えばプロバイダ責任制限法みたいに要件として分かりやすいものもあります。
ただ、明確な要件として与えられるものだけではなく、設計者側が非機能要件として考えなければならない場面も多々あると感じてます。
※例えば、前回記事*1で書いた様な浜銀の事件とか
特にここ近年は個人情報保護法やプロバイダ責任制限法のようにIT関連に強く影響を与える法律も制定されており、ますます社会の変化がIT業界に与える影響が増してると感じます。
こういった社会的なパラダイムの変化は、先の論理削除の件みたいに時折技術的なパラダイム以上の強制力をもって設計思想に影響を与えるんだろうなと思います。
ああ。。。なんて面倒なんだろう。。。
オッサンとしては、これら社会的なパラダイムの変化をうまくキャッチアップをするコツは、「ニュースで見つけたIT関連の事件などを他山の石として、設計の問題点を考えてみる」ってのが一番やり易いかなって思います。
オッサンのブログでたまにIT関連の記事の解説とかしてますが、この他山の石のキャッチアップのためだったりします。
世間は何を問題視してるのか、どう対処すればよかったのかを考えるだけでもスキルの足しになると思いますよ。
まとめ
だらだら書きましたがまとめると
- 設計には技術の進歩以外にも社会的な要請も影響を与えるよね
- ただ、どうしても社会の要請ってキャッチアップしづらいので、ニュース等から他山の石いただくのがよいよね
ってなります。
いやー、結論が当たり障りなくて申し訳ないです。
まあ、ニュースに一言突っ込みを入れるのも案外仕事に役立つんじゃないですかってことで。
以上
プロジェクトリーダはコードの読み書きできれば良いか
そいえば、上記記事のブコメ欄でいただいたコメントの中で考えてみたいなと思うコメントがあったので、記事でまとめてみようかと。
プロジェクトリーダに必要となる技術はコード読み書きできればOK?
どっちにしてもコードが読み書きできない人はソフトウェア開発に関わっちゃいけませんので、その辺何卒よろしくお願いします。
考えてみたいのは上記コメント。異論はないのですけど、プロジェクトリーダ(以下、PL。プロジェクト進行の話が中心なので、広義のプロマネって言うと話がごっちゃになるので)はコードの読み書きできるぐらいでいいのかってのはあります。
知っている限りのPL連中は、往々ソースの読み書きできます。
もともと、プログラミングやったこと無いって人もいると思いますけど、門前小僧習わぬ経を読む、ではないですが、長くコードに触れた生活してると、基本的な読み書きならまあできるって人は案外多いです。
※とは言え、世の中を見渡したとき全くコードをさわれないってPLみたことあるので、全員が全員ではないと思いますけど。
てなわけで、「単にソースを読み書きできる」ってレベルなら大体満たしている場合が多いのが現状。でも、これがかえって落とし穴となるんじゃあないかなって思います。
パラダイムから外れた謎コード生成
オッサンがネットなどの事例含め、ほうぼうで過去見たことがあるアンチパターン。
- 構造化オブジェクト指向言語 クラスや継承といったオブジェクト指向の要素は全くなし。美しく構造化されつつも、オブジェクト指向言語で書く必要あるのだろうかっていう不思議なコード
- ヒント句まみれのSQL oracle旧バージョン時に作成した過去のソースの再利用のためなんだろうけど、ヒント句以外の解決法もあったんじゃないかな。てか、コストベースオプティマイザが無駄になって可哀想。
- テーブルキューイング 昔キューイングソフトが高価だったころの名残らしいのですが、試行錯誤の結果だろうけど、変に複雑になってるような。トラブルのもとにも。。。
他にもありますけど、まあとりあえず３つだけ。
いずれも、言語やミドルウェア等のパラダイムの変化に追い付いてないんだろうなあって感じです。
これらを引き起こすPLは以下のいずれかの問題を抱えていると感じます。
- PLの技術力不足。なまじコードの読み書きができるものだから、とりあえず知ってる知識で動くアプリ作るほうに注力してしまい、考えなしに微妙なアーキテクチャを選択、微妙なソースを量産してしまう。過去に作成したパラダイムシフト前のコードがあると、これを転用しようみたいな意見も出てきてさらに複雑な事情となってしまう。。。
- PLのコミュニケーション能力不足。メンバーが把握していた設計上の問題点を拾い上げられない。ひどい場合は、自分の知識不足を棚にあげてメンバーの提言を拒絶する。
- PLのメンバー調整能力不足。自身、メンバーのスキルに不安があれば、技術支援メンバーなど追加しなければならないのに、それを認識できない、または怠っている。アーキテクト作れる人間が不在だと悲劇が。。。
結局のところ、PL自身の技術力とそれをカバーするマネジメント能力が両方不足しているとき、ダメコード生成に繋がるのかと思います。
この謎コードの存在は、保守性を下げ開発生産性を低下させ、余計な開発コストを生むこととなります。
プロマネは「原価計算を取り戻せ」 - プロマネブログ 
ちなみに、オッサンの事例
参考までに。
オッサン自身、メンバー統率するに当たってリーダが技術面でも会話できなきゃ話にならんって思想なので、マネジメントだけでなく技術力も鍛えるようにしてます。
そんなこともあり、かれこれ小学生時代にLOGOに触れて以降、プログラミングは趣味で、技術研鑽かねて自宅サーバ上にウェブアプリ作って公開したりしてます。
ここ数年はAWS上でサーバ立てたりしてるんですけど、Hadoop とか、自宅サーバではまかないづらい様なものも比較的簡単に動かせるんですよね。
新し物好きとしては、いろいろ遊べて助かるって感じです。
実際に触って、動かして、アプリやサービス創ってみて、といろいろやってはいるんですけど、まあ、仕事に応用できるのが一割もないのが寂しいとこです。。。
※費用は自分の持ち出しだし。。。
そういった意味ではプロマネみたいに直接開発をしなくなった人間は、技術研鑽はよっぽど好きじゃないと続けられないよなって感じます。
※参考までに、作成したサービスの稼働状況。カネがないのでt1.microで月数万UUの処理をさばいてます。極力ディスクアクセスを行わないようにしており、処理のほとんどがオンメモリで完結するようにしてます。
まとめ
毎度のごとくだらだら書きましたが、今回の内容をまとめると以下の通り。
- PL はコードの読み書きができるだけではなく、きちんと使いこなせる位の技術力を持つべき。
- それが出来ないのであれば、チームとしてケアできるようキッチリとマジメントするべき
- AWSなど周囲の環境は整って来てるのだから、プロマネもいろいろ技術に触ってもいいんじゃあないかな
いずれにせよ、チームとして活動する以上、プロジェクト解決のための技術力をどのように確保するか、プロマネは考えるべきだと思います。
個人的には開発の現場に「過去の事例」を絶対視する風潮があると不味いと思います。確かに過去の事例は便利なんですけど、度が過ぎると思考停止となってしまい、新しい技術の拒絶と謎コードを生み出す元凶となりうるんじゃないかなと思います。
※便利なだけにバランスの取り方はいつも悩みます
以上
よくわかるAmazonEC2/S3入門 ―AmazonWebServicesクラウド活用と実践 (Software Design plusシリーズ)
- 作者: 藤崎正範,深海寛信,五十嵐学,馬場俊彰
- 出版社/メーカー: 技術評論社
- 発売日: 2010/06/11
- メディア: 大型本
- 購入: 1人 クリック: 104回
- この商品を含むブログ (6件) を見る
