IT，ソフトウェア開発方法論，ビジネスに関する雑談

Satohru @Satohru

@zacky1972 Blogに今の心境をメモってみましたので、お暇な時に読んでみてください。

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru 読みました．ソフトウェアの専門家がマイノリティである僕の状況と近いものがあるかもしれません．意外と多くの組織がそういう状況なのかもしれないですね．自分自身の説明不足に原因を求めるところはハッとさせられました．

T.Fujikura - うふふのふ @tfujikura

@zacky1972 @Satohru 説明することの難しさは最近ひしひしと私も感じています。分かるように説明しないと説明ではない。言いたいことだけ言っていたんだなと気がついて来たところです。

Satohru @Satohru

@zacky1972 @tfujikura 説明責任を強く求められる一方で、ITはますます素人にわかりづらいものになる（SaaSとか仮想化とか…）。毎日苦労の連続です(^^;)。しかし、わかって欲しければ、語り続けるしかない。すべての人にとって共通のテーマではないでしょうか…

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru @tfujikura もはや IT はパラダイム(ものの見方)なのかもしれないですね．構造化プログラミングに対する OOP と一緒で発想の転換を強いるところに類似性を感じます．だからといって，説明する側があきらめてしまってはいけないのですが．

T.Fujikura - うふふのふ @tfujikura

@zacky1972 @Satohru 共有できる問題を発見できると話が進みますね。手法より目的から入る方が良いのかなと最近思っています。

Satohru @Satohru

@zacky1972 発想の転換、という意味では、ITの技術に対する理解を共有するのではなく、ITが享受する価値を共有することに説明のスタンスをシフトしています。そんなの当たり前じゃないか、といわれそうですが、その当たり前のことに気づくのに、私は一定の時間を要しました。

Susumu Yamazaki (ZACKY) @zacky1972

@tfujikura @Satohru それは同意見．プロダクトラインの考え方が示唆するのは，経営層にも技術者層にもわかる言葉で，問題を共有することの重要性です．じきにそういう考え方が台頭するのではないかなと思っています．(というかはやらせたい)

Satohru @Satohru

@tfujikura @zacky1972 同感ですね。目的、または価値。

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru それも同意です．いろんな方から目的や価値に重きを置くことを教えられ，学生さんにもいつもそれを言っています．当たり前のようですが，実はとても難しい．

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru @tfujikura 最近注目しているのが，その名も Value-Based Software Engineering．要は利害関係者の価値観を明らかにして Win-Win 目指しましょうという話です．技術的には突っ込みどころが多いですが，思想としては好き．

Satohru @Satohru

@zacky1972 @tfujikura それと、アジャイル。アジャイルな思想をビジネスに採り入れたい。そうすれば、いわゆるアジャイル開発はもっと普及するはず。企業の目標管理制度のあり方などにも影響を与えるはずです。これも我が社でトライしたいテーマです。

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru @tfujikura でも VBSE は，さっきの政治のつぶやきにも通じるのですが，みんなにいい顔をするあまり，イノベーションは生まれないかもしれないという弱点があることに最近気づきました．一歩間違うと衆愚になるというワナ．

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru @tfujikura アジャイルも思想として大好きですね〜 やっていると生きている実感が得られるようなので．プロダクトライン，VBSE のビジネス指向とアジャイルを結びつけて一旗揚げられないかといつも思っています．

Satohru @Satohru

@zacky1972 @tfujikura 確かに。イノベーションにはとんがった部分が必要ですからね。会議室では良いアイデアは生まれない、という奴でしょうか…

Satohru @Satohru

@zacky1972 一旗、いいですね～(^^)。私もいつもそんなことを考えてます！

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru @tfujikura 会議も，ファシリテーションとか使うと豊かな発想の場になりうるんですけどね．

Satohru @Satohru

@zacky1972 一昔前、会議が混沌とした時、私はメモを取っていてハッとしたことがあります。皆正しいことを言っているのに、順番の違いや見方の違いで争っている。私がメモを基に整理したら、皆納得。ファシリテーションの重要性を実感した瞬間でした。

T.Fujikura - うふふのふ @tfujikura

@Satohru @zacky1972 アジャイルってテストに依存してますよね。テストまたは実験できない分野では難しいかなと思います。そう言えば先日飲み会で、人類学はフィールドワークだテストはできないと言う話を聞いた覚えがあります

Susumu Yamazaki (ZACKY) @zacky1972

@tfujikura @Satohru そういう場合はテストの代替技術を使うといいと思います．たとえばシミュレーションとか．最近は文系でもシミュレーションすることがあるようです．

T.Fujikura - うふふのふ @tfujikura

@zacky1972 @Satohru そうそう、シミュレーションやモデル検査や仕様実行等ですよね

Satohru @Satohru

@tfujikura @zacky1972 アジャイルのビジネスへの適用としては、計画立て方やインクリメンタルなビジネスの進め方などがあると思います。

Satohru @Satohru

@tfujikura @zacky1972 テストはベンチマークに置き換えてはどうでしょう。これによってシミュレーションなどと相対的に評価できます。

Susumu Yamazaki (ZACKY) @zacky1972

@Satohru 実際に経営戦略論でもアジャイル的な方法論があります．どうも80年代から90年代にかけて各分野で同時多発的に考え出された概念のようです．

Satohru @Satohru

@zacky1972 経営戦略のアジャイル的な方法論。何か具体的な名称や提唱者の名前などありますか？　詳しく知りたいです。