上流工程や品質にフォーカスした上流工程・品質勉強会を7月25日に開催します！
TDC : 上流工程・品質勉強会を7月25日に開催します！
テーマは「要件定義」です。
家の用事があたので、初めから行けなかったが何とか１５：３０からのパネルディスカッションには間に合った。正直パネルディスカッションの前の羽生さんの講演を聴きたかったのだが・・・
今回は社員の何人かに声をかけたけどねぇ、残念な結果になってしまったよ、ある程度は予想していたけど上流工程にうるさい上司あたりは来るかなと浅い期待は持っていたんだけどね。この件については今回も来ていたウチの会社のお客様でもあるＭ氏と話していて、こういった勉強会ってのは問題意識がある人が来るようなもんだからねってことで納得。
自分は別に問題意識があるわけではなくて、単に面白そうってだけってのもあるけど、はるばる来仙してくださったいつもＷｅｂで見ているパネラーの方々のなんだろう、「気持ち」をもらえればこれからの仕事もちょっとは面白くなるかなぁって気持ちの方がつよいんだけどねってのは秘密さ。よーするにミーハーなのかな。
パネラー紹介
パネルディスカッションのメンバーはホームページにも書いていたけど一応ここでも紹介。
- パネリスト:
- モデレーター：
- 杉山隆志氏（株式会社フライトシステムコンサルティング取締役）
へぇ〜、仕事でよく知る今井さんと漢字が一文字だけ違う人もいるんだ、実は今井政信さんのお父さんかな、と・・・と今まですごい勝手な勘違いをしていたけど、今井さんって名前の漢字は勝信さんだったんあぁ、（今井さん今まで間違って覚えていてすみません）
羽生さんってこんな方だったんだぁ、Ｗｅｂで見る文章のイメージでは、線の細いおっさんって勝手なイメージ持っていたけど・・・（実はこれ以上失礼なイメージを持っていたけどココでは怖くて書けません）なんかすごいオーラが・・・
みんななんか顔見知りのような感じで進んじゃうけど、正直こういった講演会は初めからいないと話の経緯なんかが分からなくてちょっと何でみんな笑っているか分からない部分があった。悲すい。
Ｑ１：なぜ、こんなお題の勉強会が必要か？
羽生
以前は勉強会というものには出たことがない。昔にくらべて、プロジェクトに余裕が無いためではないか？昔はコンピュータは、数人で１台、コンパイルに数時間なんてのが普通で時間の流れがゆっくりだったなので仕様の決定っていうのもゆっくりだった。大変だけど、時間の流れはゆっくりだった分、その中で勉強する機会があった。でも今はテクノロジーの進歩で時間が早くなっているので、世代間で勉強をさせる時間が無くなりつつある。なので問題意識を持った人たちがあつまる仕組みができたのではないか？
新井
品質が保てないのは上流が悪いという意識が「上流工程に肝」となり、お客様自身の品質への目も厳しくなっている。なのでみんなの関心がここ（上流）に向いてきた
松村
勉強会は実装技術などのほうがやりやすいが・・・先の２人が言ったように、実装技術は進歩しているなかで、俗人的なところが多い上流に対する問題意識が出てきたのではないか？
杉山
ここで杉山さんから、説明
プロジェクトの失敗の原因
成功率 ２６．７％プロジェクトの遅れの原因
要件定義が計画より長引いた
企画作業が長びいた品質がわるいのは
要件定義が不十分
システムの企画が不十分稼動システム物満足度
計画通り使っているが不満足使われない、システム
４９％が実は使われていない
⇒要件定義が大事って言っているわりには、勉強会がないとか、誰も失敗したあとに反省がないとか次に生かせていない。うーん「ざんねん！」
※この辺からちょっと話が変わってきて、Ｑ１に限らない質問も出てきた。で、今井さんに話が振られる。
今井
仕事として経験する機会がへったのは間違いが無いと思う。でも実は勉強会ってのは会社内では結構ある。ある程度の規模の会社には標準工程とかがあるので研修があるはず。ただそういった研修の内容が会社の知材（知的財産）的なものなので、門外不出だった、でもオープンソースなどと同じように勉強会として社外でも出るようになってきたのではないか？
※ 吉澤さんには異なる質問。あれ？質問はなんだっけ？？
吉澤
昨日＠ＩＴの講演会があり、その中で「コスト削減と品質向上」について、＠ＩＴの人がコストと品質は相反するものなのでどうすればという質問があったが、「コスト削減するには品質向上」という話があった。これは品質のＡＢＣをやれば最終的にコスト削減になるということ。
ａ:あたりまえのことを
ｂ:ばかにせずに(ぼやぼやせずに)
ｃ:ちゃんとやる
杉山
今井さんの話題は結構ありますね。新井さんお客さんの要求度合いがきびしくなっているというのは実感がある。そういった意味でも上流は大事なんじゃないでしょうか？
Ｑ２ご自分の経験談をどうぞ（成功談、失敗談）
新井
お客様とスクラムを組んでやるパターンは成功する。これは、お客さんもコミットしてくるし、お客様も責任もってやてくれるということで成功度が高い。でもお客様は本当のことを言わない部分もあって、「ＡさんはＢさんとＣさんがいると本当のことを言わないとか・・・」でもみんな同じ思いでやるのが大事。
松村
うまくいくパターンていうのは、お客様に近いところ（立場が近いと思われる）で作業をするというもの。はじめから一緒にやっていると「失敗しても成功のうち」という考えででやってくれのでうまくいく。でも途中から入ると、使う人から遠いものを作っている感覚を実感する、そういうときは失敗する。
今井
今回のテーマのプロセスとは関係なく、どっちかというと契約とか、ステークホルダーが多すぎるとかチームをうまく作れなかったとか、そっちが失敗する確立が多いと思う。５億とか大型案件で成功するプロジェクトはすくないんではないかと思う。
誰がステークホルダとか分からずにやっていると、コミットしてくれるお客様がいないんで集合的な意識がコミットする物となるため誰にコミットしていいかわからなくなる。そのためプロセスを勉強してもどうしようもない
逆に１千万とかいった小さいものは、コミュニケーションロスがないため失敗する例は珍しいと思う。でも近すぎるのも駄目、社内では誰も言うことを聞かない、なまじ自分の会社なだけに・・・
営業とか年齢とか自分の立場になって言ってくるために。
羽生
今井さんのはなし。他の会社のプロジェクトの外部コンサルに入る場合はうまくいく。でも社内でやると失敗する。何でかというと、外部の人はお客様であってもこちらの意見に素直にやってくれるのでうまくいく。でも身内の場合は身内なだけにできない理由を言ったりして・・・そういうときはお客様もなあなあになっているのでそのうち火が吹いて・・・となり、あの時言っておけばとなる。
決めたプロセスを遂行しなくなる時点で駄目になる。かえって未経験者チームの方が成功率がたかい。みんなわかんないんだから。経験があるとアドリブ、我流が入って変にお客様に空手形を切ってしまう。そしてフィードバックもちゃんとしないので余計に・・・
「ちゃんとやろうよ」を徹底しないと駄目
ここで自分の心の声
あーわかる。お客様の中に入ると緊張してそこに仕組みに慣れようとして頑張るんだけど身内だけでやっていると理由を言いやすい分だけ、理由を言ってそこで終わってしまう。
杉山
ここで杉山さんより質問。
お客さまに近いところで仕事をしている場合とそうでない場合、において設計以降の要件変更の多発の差があるのでしょうか？
羽生
大前提としては要件定義ですべて決められるはずがないルール、変更はあるもんだとしてやっている。でも変更をハンドリングできるかどうか？（変更を予測できる状態を作れるかということ）
松村
お客様は動くものを見せられないと分からない、近いところで仕事をすると日々見せることができるので毎日確認できる。最近ではウォーターフォールとアジャイルの区別がつかない。これらは区切りをどうするかと言う問題が違うだけ。フィードバックと改善を繰り返しているウォーターフォールもあるでしょと。
・・・多分ここで話題が変更
今井
そもそも仕様変更するリスクの高いプロジェクトは会社がうけないので経験があまりない。ただ、難しいのはチームビルディングだと思う。たいていの仕事ってのはプロジェクト制を敷いていると思うけどメンバーは固定ではないので経験が生かせない。結構いい雰囲気って思ったプロジェクトも終わると解散してしまう。同じ会社の社員だったらそのうちまためぐってくるかもしれないけど、協力会社さんなんかだとそのチャンスすら無かったりする。経験、知恵が引き継いでいく土壌がない
杉山
ここで杉山さんから吉澤さんに「組み込みでの品質を高めるための知恵は」という質問
吉澤
品質にはいろいろあるがコンパイラ、ＯＳ、デバッガとか狭義の品質を高めることとかやってきたけど、教育も含めて、内部の技術者の技術力を上げるってのが一番だと思う。
・
・
・
この辺の話、パネラーの経歴に込み入っているので、ちょっとわからない。
ただ、お客様の中にはさっきの「本当の事を言わない」って言うのがあったけど、「言いたいことを伝えられない」ってこともあるので何度か通ううちに、分かる場合もある
羽生
・
・
・
この辺の話、パネラーの経歴に込み入っているので、ちょっとわからない。
特定ユーザ向けの要件定義は、現場の課長などのキーマンが合意すればよいけど、不特定多数向けの場合は実は多数のステークホルダーと合意しなくてはならないわけではない。不特定多数のユーザ（エンドユーザ（ソフト買う人））の合意って取れないよね。なので、誰がＯＫを言ったらいいのか？最後はエンジニアマター、上司マターなり、「お前が決める人」となる。
杉山
要件を聞くではなく、要件を作るって立場で考えるのが大事、その方法として先ほどのチーミングであったりする。聞いたものをそのままやらないといけないようなプロジェクト（チーム）だと駄目。チーミングに問題がある。お客様と一緒に要件を積み重ねて、プロジェクトに必要な要件をつくるようなチーミングだといいのではないか？
自分の心の声
杉山さんの話については、それがＳＩのサービスじゃないのかと思う。基本、お客様の要件をまとめるって行為だけがクローズアップされる傾向が強いけど、お客様の要件をまとめるって言うのは、単に言った事をリストアップして見積内にできることだけを提案するのではなくて、そこに「お客様が求めるシステム、お客様が気づかない部分、業務の提案」があるのではないかな。それはお客様の意見がシステムに反するのであれば、システム自体を守るって行為も含めてシステムを提案するってのがＳＩの仕事なんじゃないかなと。なんか言葉が足りないなぁ。でもそれに加えて、これからはチーミングを含めて提案できるって事が大事になってくるのかなぁ。
羽生
お客様より聞いた要件から、お客を説得して「なるほど」って思ってもらったときがＯＫだと思う。受注する側がお客様と対等な立場で物を言う関係性が大事（お客様の要件は作るシステムにとってどうなのか提案する）
自分の心の声
あ、これこれ。こういうこと。
羽生（続き）
・
・
・
あと、ちょっと省略。
Ｑ４：エンジニアに求めること
杉山
上流工程をエンジニアに求めるときにやってほしいスキルはなんでしょうか？
羽生
得意ですっていう分野では８時間でやる作業を３０分でできるようになってから言え！って言う気持ち。そうすれば、残った作業時間で上流工程なり何なりのスキルアップの勉強ができる。得意ですっていう分野を８時間まるまる使っているようでは・・・片手間でやれるようになるほど秀でる。まず、自分の得意なことを研鑽。
自分の心の声
多分、得意に感じる分野では、８時間丸々使っても疲れないのでやった気になるってことだろうなぁ、好きだからいつまでもやるしね。でも羽生さんの言いたいことはわかるなぁ。この業界の仕事って、直感と力作業ってものがあって、とある工程では想定時間のうち直感で資料を作って後の時間はこっそりと色々好きなことを調べたり・・・（こんなブログ会社の人は見ていないだろうから書いたけど・・・）
新井
さっきの「なるほどと思わせる要件を作る」について、お客さんより知っていないとできないので、システム意外にもお客さんの業務とか、最近の業務設計とか、知っていないとなるほどって言うようなものはできない。そのほかにも読む力。お客さんが何を考えているか、利害関係などをある程度察知する力なんてのも必要、でもこれは経験がすごく重要だけど。
松村
上流を経験する場が無いひとは無理にでも経験する場を自分で設ける努力をするのが大事。上司に頼み込むとかそういった方法でも。
今井
技術力は基本スペック。その上で折衝能力。最近はファシリテーション大事。読み書き大事。人に読んでもらえる文章を書くのが必要。
ここで、杉山さんより「ＳＥの書く文章ってなんで難しいんでしょ」って言う質問
羽生
人間に興味を持つ。（お客様はなにをもとめているか、上流工程をやっているひとには、この人はこのタイミングで、質問するけど、なんでとか）好き、嫌いじゃなくて興味を持つことが大事。言語、フレームワーク、メソドロジなどだけでなく、人間に興味を持つ事大事
今井
伝えるつもりの無い文章はつらいんで、今のような（羽生さんの言葉のような）意識は必要
自分の心の声
どっちかっていうと、ＳＥの文章が難しいっていうのは、伝えるというよりは「自分（会社）に責任は無いよ」って言いたい文章ってことでないかな？要件を記載するって言う行為のほかに、言った言わないを出さないようにみたいな、責任は無いよ！見たいな文章。
吉澤
他の人が言っちゃったので・・・「よみかきそろばん」と言おうと思っていたけど、あとは、先入観を捨てるって言うこと。
総括
杉山
「物を作れます」って言うだけの会社って言うのは値崩れをおこしている。これは物をつくれるだけではやっていけない世界が近いと言うことではないか。先ほどの羽生さんの例で言うと、「技術が得意」だけじゃなくて圧倒的に得意ではないと駄目ということ。
自分の心の声
そうだよね、技術や製造だけ見れば「早い」「安い」「すごい」のインド人にはかなわない。付加価値、特に他への優位性（ココでの優位性とは圧倒する力と言うこと）が必要。
杉山（続き）
人間に興味を持つのが大事。ココに来ている人たちは多分、コンピュータが好きで入った業界だけどその次に必要なものが大事。人間に興味を持つと言うこと。
質問
杉山
ここまでやって質問等ありませんか〜
武田（武田ソフト）
「技術があって当然」って言っていたが、でも実態は違うよね。聞き捨てならん！
羽生
商売やっていくって言うのは、お客が期待しているものがあって、我々はソフトウエアという一般人がよくわからんんものを扱っている。なのでコンピュータに夢を見ちゃう。自分は技術力はあるかっていると、足りない。でもあってあたりまえって言わざるをえない。プロとして、仕事をひきうけたからにには、技術はあってあたりまえ。こういうものはできるけどこういうものはできませんと言う場合、「こういうものはできる」について、売り物を分かってもらう
技術を軽視しているわけではない。プロなんで、気概として当然もっているべきであると思うし、達すべきであると。これにキャリアは関係ない、他の人からみれば、あってあたりまえ。
Ｑ７：最後にひとこと
吉澤
東京の方では結構やっているが、・・・
・
・
・
ちょっとまとめ切れなかった。
今井
・
・
・
まとめ切れない。
松村
会社が長いとその会社のやりかたに毒される。こういったコミュニティは大事。
新井
・
・
・
まとめ切れない。
羽生
次は、今回会場のみなさんの一人がここにあがってもらったらよい。良いもの持っていてもアウトプット出せてなんぼと思う。自分のなかで当たり前っことは他人にとってのヒント。
ココで自分の心の声
反応がないブログ書いていてもシャーナイってことか。壇上にあがれば直反応がかえってくるしね。多分、立場が人を作るってことかな？
終わりに
とりあえず、パネルディスカッション部分を、時系列に書いてみました。途中自分の意見も書いてありますが、無視してください。まとめ切れていない部分については、一応、パネルディスカッション部分は録音していたので、反応があったらまとめて見たいと思います。今回も色々と面白い気持ちをいただきました。どうやったら自分または、会社で回りにいる人に生かせるかなと思う。
今回も懇親会の参加はできませんでした。次こそは・・・とあすなろ君のわたし。
