blogの話じゃなくて、ITシステムにおける開発プロジェクトの話です。
最近とっても多いんですよ、炎上するプロジェクト。その理由の最大は「その期間で開発できないスケジュールを立てている」なんですね、いずれも。炎上するのは当然なんです。
巨大プロジェクトを細分化して、下請けに実際の開発を委託するやり方にそもそも間違いがあります。縦に切るならいいんですが、多くはその理解がなく、作業工程の階層で切って、孫受け、ひ孫受けに渡してしまう。
その工程とは、末端では「実装と単体テストのみ」であり、システムの全容もわからず、その仕様の整合性も自分たちでは検証ができず、利用者の声も伝わらず、中間業者にの言うようにその要望に応えるわけです。
現場も、それを仲介しているプロパーの方も、スケジュールどおりに進捗が進んでいるかどうか、それをどう上の会社に報告するかが最大の関心事で、開発プロダクトの品質やお客様にとって使いやすいシステムかどうかは考えていません。
お客様にとって最大の目的は、低コストでよりよい製品にしたいというものですが、開発者のところでは、かけ離れたものになってしまって、単に、手当てもない長時間残業で、作業を消化するだけの仕事に埋没しているわけです。
いえ、せめて能動的に仕事したいですよね。そんな局面であっても。
・ITpro 【IT Service Forum 2007】プログラミング軽視が使えないシステムを生む----積水化学の寺嶋氏がベンダーに苦言
『「システム開発でどんな技術や開発手法を使うかはアーキテクトが決める。経験上、良いアーキテクトが設計すると、開発と運用のコストを段違いに削減できる。良いアーキテクトとは、業務とプログラミングをよく知っている技術者だ」と寺嶋グループ長は話す。だが、今は「プログラミングを知らないSEが“売らんかな”でツールやパッケージの導入を目的に設計し、オフショア開発などで業務の分からないプログラマが実装している」（同）
この状況を改善する策として寺嶋グループ長は「内作型開発モデル」を提唱する。「完全な設計はあり得ないという前提のもと、要件定義から実装まで、全員がSEでありプログラマである技術者集団が担当する」方法だ。また文書だけに依存せず最終的にはソースを読むようにするという。 』
うーん、ちゃんとわかって下さってる方もいらっしゃるんですね。少し、希望が持てました。
しかしホント、こういう方と仕事したいでっす。
Please stop the government! Our dugong are crying !! And we are crying!!!
US government and Japanese government has a plan of the construction of the HUGE MILITURY BASE at Okinawa now. Please stop them! That plan will destroy not only the living environment of dugong, but also OUR LIVING ENVIRONMENT in Okinawa.
Will you kill us, and our dugong? Please appeal to the public and your government to stop that plan. Please help us!!!!
Save the Dugong, Stop the Airbase
2007年11月28日
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/69898784
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。
この記事へのトラックバック
http://blog.seesaa.jp/tb/69898784
※ブログオーナーが承認したトラックバックのみ表示されます。
※言及リンクのないトラックバックは受信されません。
この記事へのトラックバック
まるで俺の今の現場を見られているかのようなそのご指摘(笑。
しかし我々のような目立った実績の無い中小企業が仕事を得るためにはやはり向こうの言い値で請けるしかないんですよね･･･。
で、請ける仕事はやっぱり実装＆単体テスト･･･。
今のIT●CHUなんて酷いですよ。
『セキュリティ上、機能仕様を公開できない』
とまで言い出しますから。
意味わからん。
そうなのよねー、個人情報保護法あたりから、情報セキュリティの対策が歪曲して、専門家の立場から見たら、本末転倒なことされているのを実に沢山拝見しています。
『セキュリティ上、機能仕様を公開できない』って、それじゃ、開発できないですよねlol
これは、セキュリティの意味をまったく誤解されている代表的な例です。通常は、情報漏えいに対する誓約書を交換した上で、必要な情報の提供を受けて開発に入ります。
しかし、信用してないから情報公開しないってことなら、どうしてそんな相手に開発の仕事を任せられるのかも不思議だったり〜lol
同じITコンサルタントを生業とする者として興味深いエントリでしたのでコメントさせて頂きます。
『セキュリティ上、機能仕様を公開できない』のは企業側としては当然の言い分かと思われますし、
必ずしもその全てを知らなければ開発できないという訳ではないと思います。
（全ての情報を知っていた方がよりスムースに開発が進むという事は否定しませんが）
もし、末端のプログラマにまで機密部分を明かさなければその開発が出来ないと言うのであれば、
それは企業側の責任でもなく、ましてや末端の開発側の責任でもなく、それこそが我々の仕事である
ITコンサルタントの腕の見せ所なのではないでしょうか？
これは信用しているしていないの問題では無く、その形態での開発では支障が出るやり方を提唱した
ITコンサルタントの力不足、見込みの甘さ故の失態かと思われます。
だからこそのITコンサルタントなのですし、それこそ何の為の専門家なのかと問いたいですね。
>しかし、信用してないから情報公開しないってことなら、
>どうしてそんな相手に開発の仕事を任せられるのかも不思議だったり〜lol
これはご冗談ですよね？とてもITコンサルタントのお言葉とは思えません。
そこの橋渡しを熟慮し総合的に統括し提唱するのがITコンサルタントの仕事じゃありませんか。
機密情報部分は公開せずに下請けに開発をさせたい。
信用している、していないに関わらず機密情報部分は公開しない。
その条件下で請け負う所に仕事を回す。
仕事というのは得てしてそういうものです。
その条件では開発できない、支障が出るというのであれば、受ける側が断れば良いだけの事。
受けた後で『セキュリティ上、機能仕様を公開できない』って、それじゃ、開発できない！
それでは仕事として支障が出るし効率が悪いし意味が無いしITコンサルタントは役立たずです。
そうならない様にスタート部分からゴールまでを見据えて計画するのが仕事なんですから。
お互いに頑張りましょう。
仰る事その通りで同感です。問題なのは「個人情報保護法対策」であって、「機密情報」を具体的に定義し、提供すべきものとしないものを明確に切り分けること、顧客にご理解いただくこと、開発者のリテラシー教育の二点が大切です。
上記では「機能仕様が開発者にも知らせられない程の機密にあたるのかというと、一般には否でしょう。それが必要なシステムであるのなら、本来外部に発注できない筈だ」という私の指摘に過ぎません。
>しかし、信用してないから情報公開しないってことなら、
>どうしてそんな相手に開発の仕事を任せられるのかも不思議だったり〜lol
って、この点については、もしそうだった場合の想像の話で、断定しているわけではないですので、その点読み取っていただけたら幸いですlol
書籍ですが、こちらもご参考まで。
http://coin.nikkeibp.co.jp/coin/nc/books/prm/
この業界厳しいと思いますが、お互いがんばりましょう。
個人情報保護と開発上の機密情報とは全くの別物ですからクライアント側が明確に切り分けない、
理解していないというケースはごく稀です。私も今まで100社以上の企業と仕事をして来ましたが、
クライアント側が理解していないなら、当然の事ながら初期のコンサルティング段階で指摘しますし、
それらを明確に切り分けた上で取り掛かる事が我々の仕事ですから当たり前の事ともいえますね。
>「機能仕様が開発者にも知らせられない程の機密にあたるのかというと、一般には否でしょう。
>それが必要なシステムであるのなら、本来外部に発注できない筈だ」
残念ながら私は全く逆の見解です。
機能仕様を開発者にも知らせる事が出来ないのは、それ相応の機密内容を含んでいるからに他ならず、
にも関わらず外部に発注しているのは、それでも開発できるという見込みがあっての事なのだろう。
と。
機密というものは事の大小、内容に関わらず「これが機密」と言われればそれが機密なのです。
どんなに些細な事、他者から見れば他愛の無い事でも、社外秘と言われればそれは絶対だと言えます。
クライアントからそう言われればその範疇で工程を管理するしか無いのです。
もしくは初期段階で前述の通りに「本当に必要で守るべき機密なのか」を再考して切り分けて頂く。
「必要なシステムであるのなら、本来外部に発注できない筈だ」という短絡的な発想は危ういです。
>しかし、信用してないから情報公開しないってことなら、
>どうしてそんな相手に開発の仕事を任せられるのかも不思議だったり〜lol
想像でもそういった考え方が出てくるのが不思議だったのです。SEやプログラマの発想ならともかく
独立してITコンサルタントを名乗っている方の言葉とは思えなかったものですから。
参考として貼って頂いたURLの書籍の件ですが、どういう意味でしょうか？
同業者の私に対して紹介する書籍としては少々失礼だとは思えませんでしたか？
これを読んで勉強してください。という意味にも受け取れてしまいますよ。
個人情報保護と開発上の機密情報とは全くの別物ですけれど、セキュリティとも別のものですよね。しかし、一般には対策が似通ったものになるので、同時に語られます。ですので、その点について指摘は私のほうからは差し上げませんでしたがいやはや。
どうも、ご意見を伺いますと、実際の開発をご存じないように感じますが、いかがでしょうか。
実際の開発現場では、企業の機密情報の提供を受けることを、極力避けます。それを持てばリスクが高まるからです。しかし、その提供を受けなければ、設計だけでなく、テストも満足にできないケースが多いので、やむなく受け入れているのです。
「機密保持契約を相互に結んで、情報の提供を受ける」これが一般なのですが...
失礼ですが、語り口、投稿頻度などから行動様式がどうも荒らしのように感じられます。
コンサルタントなのでしたら、siteもお持ちなのだと思います。是非名乗られてください。
なるほど確かにそうですね、特に深く突っ込んだつもりでは無かったのですが気分を害されたのなら
お詫びいたします。言葉が足りず、且つ少々キツイ言い方だったかもしれません。
【「機密保持契約を相互に結んで、情報の提供を受ける」これが一般】とは至極当たり前の事で、
実際にはそういった契約を結ぶ事が多いのは事実です。
しかし、まるご。さんの言うように実際には必ずしもそうなっていないのが現状と言えます。
Jitohさん自身「専門家の立場から見たら、本末転倒なことされているのを実に沢山拝見しています。」
と言っているではないですか。
私はその狭間を埋めるのがITコンサルタントの手腕ではないのかと申し上げているだけの事です。
>失礼ですが、語り口、投稿頻度などから行動様式がどうも荒らしのように感じられます。
本当に失礼な方ですね。意味が分かりません。
機密保持契約を結ばずに開発を受託するケースは、私の経験では皆無です。開発にならないので、結局は機密情報といわれるものでも提供を受けることになるのが実情です。
それと、ITコンサルの仕事は、多岐にわたりますが、開発の途中に介入するというのもあります。ですが、計画立案の段階で助言を行うのみで、監査に立ち会うぐらいなのが、一般だと思います。もちろんお客様のニーズ次第ですが、仁さんのおっしゃるようなコンサルの立場で開発に直接の発言権があるというケースは私は見たことがありません。
一番の悩みは、コンサルの推奨する方式をなかなか開発現場で採用いただけないことなので、それができているとすると、それはすばらしいことだと思います。
しかし、失礼にあたったなら申し訳ありませんが、自分が誰であるかも名乗らず、中傷をされるのは如何な物かと感じます。
これまでの貴殿の書き込みは、典型的な荒らしのパターンにマッチしておりますので、是非お願いしたいのですが、貴殿のsiteを教えてください。
自らを名乗って、貴殿の言動の信憑性を証明して頂けることを期待しています。
具体的な経緯をお伝えさせてください。
過去にこちらや複数のblogにおいて荒らしを行為を行った方がいて、その方はいずれでも書込み禁止処分になっております。
その荒らしの発言スタイルと独特の特徴が、今回の貴殿のご発言と酷似しており、またアクセス元も一致しているのです。
更に数日様子を見させて頂きますが、もしお身元をご提示頂けない場合、荒らしの悪質な成りすましと判断して、発言を削除をさせていただきますのでご承知おきください。
正直、その言われている言葉の意味がよく分かりませんのでなんと答えれば良いのかも分からないのです。
書き込み内容から中傷と受け取られる、真意が伝わらない事があったのでしたら申し訳ありませんでした。
私としてはそのようなつもりはまったくありませんでしたので、不快に思われたのなら謝ります。
>これまでの貴殿の書き込みは、典型的な荒らしのパターンにマッチ云々
どのような点が荒らしのパターンにマッチしてJitohさんの琴線に触れてしまったのでしょうか？
【アクセス元も一致】と言われても、身に覚えの無い事であらぬ疑いを掛けられては良い気がしません。
私はITコンサルトの可能性と将来性、出来ませんと決め付けない柔軟性、一般的ではない特殊なケース、
そういった内容をコメントしただけで、荒らし行為をした覚えも中傷したつもりも無かったのです。
大上段から【身元をご提示頂けない場合、荒らしの悪質な成りすましと判断】と言われましても、
いやはや困ってしまいます。
>機密保持契約を結ばずに開発を受託するケースは、私の経験では皆無です。
>開発にならないので、結局は機密情報といわれるものでも提供を受けることになるのが実情です。
ですからそれは【私の経験では】という前提ですから、それを持ち出すことは不適当かと思います。
>実際の開発現場では、企業の機密情報の提供を受けることを、極力避けます。
>それを持てばリスクが高まるからです。
>しかし、その提供を受けなければ、設計だけでなく、テストも満足にできないケースが多いので、
>やむなく受け入れているのです。
リスクは負いたくない、しかし設計・テストは満足のいくものにしたいので情報は欲しい。
天秤に掛けた結果、どちらを選択したかという話。実際は選択の余地は無い事の方が多いですが。
下請け側の事情はまるご。さんが言っている様なケースも多いでしょうし、私も否定はしていません。
しかし我々の立場はJitohさんの言うように【機密保持契約を相互に結んで、情報の提供を受ける】、
それならば我々の手腕で工程の歪みを改善しようとするのも仕事の一つなのではないかと言うこと。
ただそれだけの事です。Jitohさんの仕事ぶりを否定したわけでも低く評価したわけでもありません。
私は個人ですが独立した会社として【会社対会社】の形で契約を結んで仕事をしておりますので、
site＝会社のHPになります。
私個人のことならともかく会社の名をこういった場に出すことには抵抗があります。
>コンサルタントなのでしたら、siteもお持ちなのだと思います。是非名乗られてください。
個人独立起業したコンサルタントなのでしたら、自社siteもお持ちなのだと思います。
当然の事ながらこのようなレンタルサービスのブログなどではなく自社でサーバーを立て管理し、
ドメインを取得した【対会社】と対等な立場で契約するに恥ずかしくないHPなのだと思います。
その場しのぎの契約社員扱いでフリーターの片手間にやっているITコンサルトならお門違いです。
荒らしだと思うのであればご自由に。
しかし、結果的にこういう事を私に言わせたのは他ならぬJitohさんだと言う事もお忘れなく。
失礼極まりないです。