Ahfです。いつもありがとうございます。
私は参考になる話題が多いので、なるほどと思いながら読ませてもらっているクチです。

個人的に思うに、エンジニアライフを購読しなおかつアクティブに発言される方で
・「業務分析に興味がある」割合
というのが結構低いのではないかと思います。ただ、需要がないか？と言われるとまた別と思いまして、ネックになっているのが「アクティブに発言する」方の中での割合、なのではないかと。

コメント等で声を出してくれる人は、読んでくれる方の中の本当に極々一部だと思っています。
ですのでまずはビガーさんの思う話題を貫いてみるのもいいのではないでしょうか。

一読者としては、業務分析な話題を続けていってもらえると嬉しいですねぇ、というのもありますけどね。

業務分析については心配せずとも結構興味がある人がいると思います。
私は高橋さんのコラムに一度しかコメントしていませんが、無コメントで毎回読んでいます。
高橋さん所にコメントをつけないわけは、理論が完結していて言う隙がないからです。
一方生島さん所は、コメントしやすい空気なのでよくコメントしています。
そんな私と同じような人もいると思います。
ですから、コメントが少なくとも業務分析に興味がある人はいると思います。
とはいえ、技術者の人が多そうなので、本当に業務分析に対する需要は低いかも・・・
なので私なりに少し考えてみました。
業務分析といえば、技術と現実の関係を着目点としてコラムを書けば楽しいと思います。
どの技術がどのように現実へ反映されるのか。
それが分かれば、エンドユーザから遠いプログラマだってもっと業務分析が気になると思います。
私はそこが楽しくて仕事していますので、結構これいけると思います。

ビガーさん、

　お久しぶりです。高橋です。
取り上げてもらってありがとうございます。

　本当に皆さんが業務分析に興味が無いのかな？と思って考えていました。結果、テクノロジを追いかけている真っ最中の方は、そちらが優先なのかなと。一方、ある程度経験を積んだ方は興味があるでしょうが、私のコラムがまるでセミナーのような一方通行型なので、コメントするというより、読んで参考にしてもらえるのではないか・・・ということである程度納得していました。

　そう考えていたところへインドリさんの的確な指摘があり、あ、やっぱりと思いました。自分で読んでみても、コメントを入れるのはハードルが高いですね。

　ビガーさんから意見をもらったり、コラムで取り上げてもらって、インドリさんの意見もあったりで、こういった双方向がコラム形式の基本だと思います。参考になりました。ありがとうございました。

ビガーさん、ども。

自分のところにも書きましたが、私の経験上、そこそこの規模（億以上かな？）で上流でOOAで揃うことはないです。
最上流はCOBOLerが多く、大概POAかDOAで考えています。
そもそも、億の規模ならユーザ側にもSEが居て、ほぼPOAかDOAですし。
ユーザと宗教戦争しても仕方ない。

それは矯正はできないと思いますが、大筋は外れてないし、外れる可能性は荒かいじめ分かるので、一緒に居たらプロジェクトの軌道修正は可能です。

SQLは分かってなかったら、大筋を外してくれるので軌道修正しようがないので、「頼むからそこだけは何とかして頂戴」と言ってるわけで……。

すんません。

荒かいじめ
→
あらかじめ

>自分のところにも書きましたが、私の経験上、そこそこの規模（億以上かな？）で上流でOOAで揃うことはないです。

そこがこの業界のおかしな所ですね。
技術力が下がれば下がるほど価格が高いなんて洒落になりません。
そんな業界を変えるためにも、ビガーさんには顧客満足度について語ってもらわねば！

はじめまして、ビガーさん。にゃん太郎と申します。

　私は今は上流で仕事してますが、作業としては詳細設計からコーディング、デバッグの作業がやっぱり一番楽しいと思うわけで、それがメインだった頃なんかは業務分析など上流の仕事にはほとんど興味無かったです。

　プログラム的な技術って特に今なんかは個人のパソコンで簡単な環境を作って試して勉強できたりしますが、上流の仕事ってそういうものではなくどちらかと言えば抽象的な部分が多いので勉強しようと思うとややハードルが高いと思います。個人的には仕事で必要がない限りなかなか難しいかと考えてます。もっと楽しく分かりやすく誰か教えてくれないかなぁとホントに常々思います。

　いつも思うのはこの業界、好きな人は常にいろいろ勉強していて「よく知ってるなぁ」とか「よく考えてるなぁ」と思いますが大半（特に上流の人）の人は仕事として選んでるだけで自分の守備範囲以外は興味が無いように思います。ここでアクティブに発言する人は前者でしょうが、大勢を考えると圧倒的に後者の人が多いと思います。余談ですが、私は高校時代プログラミングの授業が苦手で将来絶対にプログラマにはならないと思ってましたが結局、プログラマになってました。前者の方が望ましいとは思いますが、現状を考えるとどちらが良いとは言い切れないのがこの業界のジレンマでしょうか（でないと回って行かない）

　私の場合は業務分析は非常に重要ですので考えてやってますが、これが仕事でなければ興味があったか、というと必ずしもあったとは思えないのが本音でしょうかねぇ。正直、こういう人が多いと思います（あくまでも個人的な考えですが）

　ですから高橋さんやビガーさん、生島さんなどのコラムは読むと目からウロコです。もっともどの人のコラムもいろいろなテーマで書かれているので楽しく読ませてもらってますが。

自分から進んで一般化された情報を毎度毎度見るってことにもいかないのが普通ですから、記事の価値は非常に高いと思いますよ。

業務分析手法をいかにして有象無象どもに周知徹底させるか！？
なんて内容ですと、コメントも大変な事になると思います。

こんにちは。コラムニストのヨギです。

これはビガーさんや高橋さん個人への苦言でないことを、先に書いておきますね。

業務分析や最適なシステム設計方法論はとても重要です。わかります。

一方、僕はいわゆる「客先常駐」の期間が長く、１０年以上に渡り、いろいろな企業を見てきました。

で、それらの企業で行われている業務分析を見ると、はっきり言ってめちゃくちゃなのです。
めちゃくちゃと言ってもいろいろなバリエーションがありますが、簡単に言うと「大ざっぱで抽象的で、現場にそぐわない」のです。

ヘタすると、プログラミングも設計もしたこともない人がそれをやってる。（最近はその傾向が強い）
やるのは勝手ですが、極論すると、それは泥にまみれて野球の試合をしたことのない人が、野球のルールブック片手に監督やるようなものです。

駆け出しの会社ならともかく、一部上場企業でも似たり寄ったりです。
いや、異論を唱えられない分、大企業の方が悪質というか、手が付けられない。

そんな業務分析されても、具体的にどう開発を進めればいいかわからない。
（これは私ではなく、すーごく仕事のできる人がそう言うのですよ）

それで打合せの場を設けると、業務分析等の上流工程担当者は
「ああ、それは概念（抽象）レベルの話だから....」とか、
「いや、そこから先はキミタチの仕事でしょ」かなんか必ず言いだし、そして大抵、上流工程担当者の方が立場が上なので、実りのない打合せで終わります。

しかし納期は迫るので、仕方なく現場は動き出し、やがてデスマーチが始まります。
現場が死ぬ思いで開発をしているのに、そんな修羅場を作り出した元の上流工程関係者は、
我関せずの涼しい顔。

そんな現場をたくさん、いや、そういう現場しか、まず見たことがありません。
エンジニアライフを購読している方も、似たり寄ったりなのかなと推測します。

そうなってくると、業務分析（他に要求分析などいろいろありますが）という作業自体を、
斜に構えて見てしまうのです。
「どうせ、いいかげんな、大ざっぱなモノが下りてくるんだろ」みたいな。

理屈はわかる。
でもそれを現場で展開する時間も、受け入れてくれる上層部もいない。
それならアナタ、うちの会社（或いは顧客）に来て、頭の固い部長や事業部長を説得してくれませんか、そっちが先です。

という気持ちになるんです。
でももちろん、そんなこと現実にはムリですよね。

なので、業務分析と言っても「（多くの人にとっては）自分とは関係ない遠い話」と読め、
レスが少ない、ということなのかなと推測します。

※私のコラムもレス付かないときは全く付かないので、人のことどうこう言えませんが。ははは。

追記です。(^^)

インドリさんの、
>どの技術がどのように現実へ反映されるのか。

突き詰めるとこれかもです。
言ってることはわかるにはわかる。で、現実的にどう反映させるわけですか？
というところですね。

皆様たくさんのコメントありがとうございます。
読むのと書くのでは雲泥の差ですね。皆さんのご意見が聞けて迷いが晴れました。

>Ahfさん
ありがとうございます。
今後も自分の信ずることをお伝えしていきたいと思います。

>インドリさん
>業務分析といえば、技術と現実の関係を着目点としてコラムを書けば楽しいと思います。
ありがとうございます。
私も実体験に基づく現実論でお話していきたいと考えています。
が、経験が浅い分、抽象化がうまくできておらず偏りがちな傾向がありますが、
そのあたりのスキを見せるぐらいが議論できてちょうどよいでしょうかね。

>高橋さん
ありがとうございます。
勝手にリンクしているのにご挨拶が遅れ申し訳ありません。
今後ともリンクさせていただけると伝えたいことが伝えやすいと感じているので
よろしくお願いします。

>生島さん
ありがとうございます。
生島さんの現実論はいつも参考になります。
私も地方で開発をしていたころは、POA的発想の人しか相手にできていなかったので
地方での現実はわかっている「つもり」です。
ただ、都心では結構OOAの割合も高いですが、そもそもOOPとOOAのリンクが重要であると
理解して仕事をされている割合は低いと感じます。
その辺りは、コラムで取り上げていきたいと思います。

ちょっと仕事の時間が近づいてきたのでにゃん太郎さん、oumiさん、ヨギさんには
今夜コメントへの回答をさせていただきます。

お忙しいでしょうし、
「コメントしなくちゃ」というスタンスを取ると大変なので、
（少なくとも私の分は）コメントなしでもけっこうですよー。(^^)/

>にゃん太郎
ありがとうございます。
確かに自分の仕事の範囲を越えたモノはそうですね。
私の中で再認識しましたが、やっぱり業務とシステムの境界(壁みたいなもの)を「エンジニア」の視点でなくせるような情報を発信していきたいと思います。

>oumiさん
ありがとうございます。
>>業務分析手法をいかにして有象無象どもに周知徹底させるか！？
やっぱりレスをいただくにはある程度過激な内容が必要ですかね。勉強になります。
ただ、炎上させて注目されるのが目的ではないのでイロイロ考えながら情報を発信していきたいと思います。ありがとうございます。

>ヨギさん
ありがとうございます。
要件と実装の間には壁が存在し、それが利害関係者を不幸にする一要因になっていると思います。それを解消するには要件定義→設計→実装をどのように関連付けられるかが重要なテーマで、私のコラムではそれをお伝えすることに注力していきたいと考えていますが、やっぱりある程度エンジニアサイドも要件ってどうやって定義されてくるんだろう？と興味くらいないと不毛な情報発信になってしまうと考え、みなさんのご意見を聞きたかった次第です。
現実には、研究機関や金融のデリバティブなどの案件では、実装(試したい要件はざっくりある)→設計→要件みたいなまったく逆の流れも現実には存在しますが、これを通常の業務システム開発に取り入れられるとユーザがやりたいことをポイント毎に可視化できるし、エンジニアサイドも安心する(自分のやっていることは正しいと確信できる)ので最良と思います。
ただ、ホイホイと引き受けていてはデスマーチになるので高橋さんのコラムにあるような抽象化等々を行うことでユーザより先を見通す力や進め方が肝になると思います。

このご時世にチンタラ業務分析だけやっていたらその間にそもそもの要求が変わってしまう可能性が高い。(実際変わったと感じるのはどこまで抽象化できているかで変わってきますけど)
いかに俊敏に変更に強いモノを作れるか、これがエンジニアの使命ではないかと。
その基礎として高橋さんのコラムはすばらしいと思います。
私のコラムはもう一歩現場に踏み込んだ内容にしていきたいと考えています。

皆さん、ありがとうございます。