How to make a smiling face ～笑顔の作り方～

twitterユーザです。それもヘビィと言ってもいいですかね。

わたしと同い年のミュージシャン広瀬香美さんと、勝間和代さんのやり取りから一夜にして「ヒウィッヒヒー」という不思議な言葉が流行しました。まあ、これはルールとはいえないのですが。

twitterでのルールといえば、「ＲＴ」とか「ＯＴ」などの記号を入れて、他人のつぶやきを再度送るとか、「＃」で始まる単語を付けてハッシュタグを入れるなど。

このような使い方は、twitterを作った人は想定していなかったのではないでしょうか。ただ単にユーザのつぶやきを時系列で、それも１４０文字という絶妙な文字数制限で表示させるだけのサービス。

それが、ユーザ自身が使いながら自分なりの工夫をしていき、それが他のユーザに「nice!」と思われれば使い方が広がっていく。そうやってどんどん使い方が広がっていくと、最終的にはデファクトスタンダードとしてルール化されていく。

こういうことって、ＩＴ特有の現象ではないと思いますが、ユーザ主導でルールが決まってそれがそのまま固定化できるというのは、ＩＴ独自のことじゃないでしょうか。

例えば炊飯器。
いままではご飯を炊く機能しかなかったのですが、「炊飯器ケーキ」というものが流行したら、最近では「ケーキ」機能のついた炊飯器も売られるようになりました。
これはユーザのニーズに応えてメーカが開発した結果ですが、メーカが「機能」として認めない限り「用途以外の使い方」として、安全性の保証などは受けられない可能性があります。つまり、ユーザが使いたい方法はユーザだけでは標準化できないわけです。

ＩＴは、とくにwebはオリジナルツールの使い方に合わせたサービスを、別のページやツールで使うことが可能な技術です。オリジナルではなく派生のサービスがきちんとルール化されれば、ユーザはそのルールに従うことで安定したサービスの提供を受けられます。

前述した「別のページやツール」とは、オリジナルに対して最初は１ユーザであったでしょう。「こうすればもっと便利に使えるのに」というアイデアが、それを新しいサービスとして派生できる。それもオリジナルとは別の人が。

twitterはユーザが新しい仕組みやルールを自然と作り出しながら、オリジナルの機能はほとんど変わらない。
でも、ユーザが使い方を広げたことで、企業ユーザを獲得してビジネスを広げるというところにまで至りました。

ＩＴは、ユーザの意見を開発者が反映させるというだけでなく、ユーザ自身が使い方の決定を牽引していくものなんですね。それもユーザはルール化なんて意識もせずに。

改めて強く感じる今日この頃です。

• 
• 
• ツイート

弊社では、ペアプロだけでなく「全ての仕事をペアですること！」というのが、ある種「掟」のようになっています。就業規則に入っているわけではないのですが、社内wikiには信条として「ペアワーク」を強く奨励しています。

どういうことかというと、プログラミングに限らず、提案書の作成やプレゼンテーション資料、あまり作るケースはないのですが設計書なども基本的にペアで行います。
わたしも先日、セル生産を考慮した人員配置計画を作成するのに、社長とペアで作りました。

このように、ペアワークを徹底するとこの仕事の仕方が習慣となります。そうすると社員の中に心の変化が出てきます。

ペアで仕事しないと怖い。という気持ち。

これは、常に誰かの同意を得ながら仕事を進めるので、この仕事の責任が自分ひとりに被ることがない、というのが潜在的に生まれるというか、もうちょっとポジティブに言えば、誰かが同意してくれるから常に安心してその仕事に取り組めるということなのだと思います。

ペアプロの効果に「常にレビューしながら進めているようなものなので、品質が維持できる」という側面があります。これも正しいと思います。この根底には、人の不安や安心といった「感情」を上手く使った仕組みがある、ともいえるのではないでしょうか。

そして、この感情は欧米人よりも日本人のほうが強いと思うのです。個人主義に根ざして自分の意見を強く言える欧米人に比べ、日本人は周囲の意見をうまく聞きながらまとめていくことで物事を決めるケースが多い。多数決が好き、などなど。そういう性質が活かせる仕事の仕方が、ペアプロでありペアワークなのではないかと思います。

ペアワークを経験したことがない人は、作業は個人で分担したほうが効率よく仕事が終わると考えるようです。わたしも最初はそんな気がしていました。
しかし、ペアワークは自分がどこかで思考が行き詰まり手が止まってしまっても、ペアがいるので「どうしたの？」と突っ込まれれば「実はね」と状況を説明して、仕事を進めるしかないのです。つまり、頭も手も全く休める暇なく仕事をするのがペアワークなので、時間的な効率は格段によく、また止まることなく仕事をすると激しく疲れるので、残業なんかする元気がなくなります。これで週４０時間はかなり近づくことでしょう。

ということで、ペアプロだけでなくペアワークはお勧めの仕事の仕方です。ぜひ一度お試しを。

• 
• 
• ツイート

昨日は、とあるチームの回顧（弊社ではふりかえりをそう呼びます）でした。このチームが定期的に回顧をするようになったのは、まだ２回目なのですが、前回の回顧で気づいた「回顧のグレードを上げる」方法を再現してみました。
それにより、この方法はかなり効果があることを実感しました。

回顧の方法はＫＰＴを利用した、ごく普通の回顧です。チームから１名がファシリテーターになり、KeepからProblemそしてTryを出していく。自分たちで考えたＴｒｙを出すまでは、よく聞く方法と全く一緒です。
ひととおり終わって、ここでオブザーバー参加している人の意見を聞くのです。「終わってから」というのもポイントなので、覚えておいてください。

回顧で確認することは、自分たちが仕事をしながら得てきた知識や気づきの整理と共有が目的です。それらは「自分たちの実績」として受け入れて、次のイテレーションで改善しながらまた実績を積み、自分たちのスキルとして定着させることは重要です。

しかし、次のイテレーションで出さなければならないクオリティもあります。例えば、今回のイテレーションで重大な不具合を出してしまったら、次には出さないようにしなければ、顧客からの信頼を失う可能性があります。

組織というのは、それなりに歴史を重ねていれば、何らかの失敗をしていてそれを克服したという経験が、どこかにあるものです。それらをデータベース化して「ナレッジマネジメント」として利用していこうという考え方は昔からあるのですが、それに成功したということを、少なくともわたし自身は聞いたことがありません。

それはなぜか？わたしが思うに、失敗経験というのは「ストーリー」で語られて初めて他者が「なるほど」と思えることで、情報として最適化されたデータとしての経験は、生身の人間には伝わりにくいものだから、ではないかと思うのです。

でも、組織にはたくさんの成功体験も失敗体験も、人の中に蓄積されています。これを活用しなければ、組織としての成長は期待できません。回顧を利用して、チームの単位で成長を促進することはできるでしょうが、それに「組織の知」が加われば、チームの成長は加速すると思います。

以下にそのイメージを貼ってみました。


それぞれのイテレーションで、自分たちの学びを積み上げていって、それを実践することで定着させる。しかし、そこに経験者の知識を付加することで、それを実践する期間も含めれば、より高い「実践知」をチームは得ることができます。

そこで大事なことは「実践」です。経験者の話をただの話として聞いてしまって、そこを試してみるという実践をしなければ、チームは何も自分たちのスキルとすることはできません。
また、オブザーバーの言葉を真摯に受け止めるだけの信頼も必要でしょう。自分たちのやり方だけが全てで、他のことはノイズに等しいと思うようなことがあったら、それは知識の大切な経験を埋もれさせてしまうだけです。本当に価値のある知識かどうか、その人の声で聞くことが大切だと思います。

「オブザーバーの意見は最後に聞く」と最初に書きました。これは、チームで出したＴｒｙは、オブザーバーも褒める言葉をかけるためです。チームがどれだけ苦労して、自分たちで考えて出した答えや挑戦の意思であるかを、十分理解した上で、自分たちのビジネスを成功させるには、そのＴｒｙを実践するだけでは遅いのだと、納得してもらうことが必要だからです。

「伝える」とは、相手の経験や実践を理解した上で自分の考えを述べる。そういうことなんじゃないでしょうか。

• 
• 
• ツイート

自分のブログ史上、最長のタイトルになった気がする。
どういうタイトルにしようかと思ったのですが、そのままでいいやと思って長くしたまんまにしました。

以下に書くことは、これからどこかでしゃべろうと思っていることのネタにしたいものですが、論点が完全ではないかもしれません。自分でも整理しきれていないところもあるので、できれば多くの方からのフィードバックをいただいて洗練したいと思いブログに書きました。

弊社ではアジャイルを「ビジネスモデル」だと捉えています。
どういうことかというと、顧客のビジネス上も問題点を解決するために弊社はＩＴを提供するのですが、まだリリースされたばかりの段階では、まだ顧客にとっての価値はゼロだと思っています。しかし、顧客がビジネスの中で弊社が作ったＩＴを利用することで、ビジネスそのものの価値が増大していくことがＩＴの本質的な価値だと考えるのです。

もう少しわかりやすく説明すると、こういうことです。

ある人が通信販売を始めようとしています。当初は雑誌に商品を掲載し、申し込みは葉書か電話で受け付けます。このようなビジネスモデルで得られる利益が1000万円だとしましょう。
この「通信販売」というものを、ＩＴによって実現したら、ビジネスそのものはどう変わるでしょうか。
商品はweb上で紹介され、検索エンジンからも見つけられるようになり、申し込みもwebでできるようになれば、欲しいと思った瞬間、つい「ぽちっ」としてしまう環境ができる。
そうなったら、同じ「通信販売」というビジネスなのに、ＩＴを利用することでマーケットやユーザが拡大し、2000万円とか3000万円になってしまう可能性があるわけです。

このように、ＩＴが「あるビジネスに価値を付加できる」場面では、常に利用可能なＩＴをリリースすることで、いつも「新鮮なビジネス」がマーケットの要求に遅れることなく、価値を生み続けることができるわけです。だから、アジャイルで実践することでより早くビジネスの価値を提供できる、というわけです。

それに対して、製造業におけるＩＴの位置づけはかなり異なります。
わたしも育ったドメインである組込みなどでは、ＩＴの技術は「製品の一部」になります。つまり製品の原材料のようなものでしょうか。
これを簿記でいうところの「製造原価」で考えると、よくわかります。

ある製品を作るために、原材料はＡとＢとＣがあります。
Ａは100円、Ｂは100円、Ｃは200円だとします。合計して400円の原価で、これに利益を100円加えると、この製品の価格は500円になります。

しかし、ライバル企業の競合製品が450円で販売されていたら、それよりも安く売ることが必要になります。最初に削られるのはおそらく「利益」かもしれません。単価あたりの利益が少なくても、今までより多く売れば利益は確保できるかもしれませんから。
しかし、これにも限界があります。利益０で製品を作り続けるわけにはいきません。そうなると次に考えられるのは「コストダウン」です。原材料であるＡ、Ｂ、Ｃいずれかのうち、どこかの原価を下げなければ市場競争には勝てない。このような原理が働いたとき、部品であるソフトウェアもコストダウンの対象になりやすいのです。

つまり、どちらのケースでもＩＴが投資額もしくは原価として100円だったとしても、前者は200円、300円の価値に膨れる可能性がありますが、後者は100円以上の価値になる可能性がほとんどないのです。

だからといって、製品に含まれるＩＴの価値が低い、と言っているわけではありません。その場合はリリースの段階でその価値が決定するので、リリース以降は別のものとして新しいライフサイクルにのせていく必要があると思うのです。

価値を重ねてシステムを育てていく、という考え方のほうがアジャイルの本質には近いと思います。だから、ＩＴを投資としてみることのできる金融や流通などのビジネスラインでの適用のほうが、アジャイルの価値を理解しやすいのだと思います。

• 
• 
• ツイート

何年も前から参加したいと思っていたセミナーに、ようやく参加してきました。
「マインドマップ(R)基礎講座」

今回、このセミナーに参加した理由は、アイデアを整理するような場面で使うことが習慣になったマインドマップの、もっと違う側面での効果というか、マインドマップの本質的な部分を知りたい、と思ったことです。
いろいろとマインドマップは使っていますが、たまに「これはマインドマップにはできないな」と思うような場面がありました。でも、それってツールの限界なんだろうか？という疑問があったのです。モノなんて使う人の考え方ひとつで変わるというのが持論だったので、もっと何か違うことがあるんじゃないだろうかと思った次第です。

そして、偶然にもこの受講直前に、講師である伊藤賢さんがiMaindMapによるマインドマップ本を出版されていました。

パソコンで広がる思考の翼 iMindMapではじめるマインドマップ(CD-ROM付)/マインドマップ公認インストラクター 伊藤 賢

￥1,764

Amazon.co.jp

これまた贅沢なことに、今回のセミナーではこの本も教材としてご提供いただきました。買わなくてよかったー。

実はこの本、セミナーの内容にかなり近いものになっています。近いどころか、セミナー＋αな本です。
だからマインドマップの知識であれば、この本を読むのとセミナー受講はあまり変わらないかもしれません。しかしやっぱりセミナーでは「体感」という部分があるので、一段階掘り下げた理解を得たいひとは、ぜひセミナーに参加されることをお勧めします。

セミナーの内容は本で知っていただくとして、このセミナーを通してわたしが得た気づきを書いておきます。

《「マインド」とは、脳が働いたことの「アウトプット」》
一般的な理解として「マインド」という言葉は「精神世界」に近い存在として認識されているのではないでしょうか。何に近いかというと「やる気」とか「モチベーション」とか。
それらが必要なことである、ということはもう十分認識されていますが、そこを形成するものが「性格」などの「コントロールしにくい精神部分の問題」として捉えられているケースは、少なくないと思います。
しかし、マインドマップが語っている「マインド」とは、「考える」などの「脳の行動」がもたらした「結果」であり、科学的なアプローチで説明できることの結果なのです。


《マインドマップは「思考の筆算」》
これはセミナーの冒頭で伊藤さんが言っていたことです。マインドマップとは何か？という質問に対して端的に答える場合は、この言葉を使うのだそうです。
どういうことかというと「１２３４×５６７８＝」という計算を、暗算だけでやるのは、普通のひとではほぼ無理です。（暗算をきちんと習った人は別ですよ）
普通の人がこの計算をする場合は、縦書きにしたうえで繰り上がりの数字をメモしたり、桁毎の計算結果を書いていって、最後に合計するという「過程の記録」をしながら計算するから、結果を出せるということ。
マインドマップとは、自分の脳内にある情報をメモしながら全体を引き出す、ということをするためのツールなのです。

だから、アイデア整理のためのツールとして使うときは「スピード」を重視してブレインストーミングのように使うこともあると思いますが、それだけではなく、自分の脳内の様々な情報を繋ぐためには「ゆっくり考える」ということも必要だということを学びました。そのためにすることは、センターイメージをじっくりと描き、伸ばす枝も丁寧に描くこと。ゆっくりと考えることで、脳は動くためのウォーミングアップをするのだそうです。いろいろな箇所に分散している記憶のスイッチを、少しずつ入れていくことで効率的に脳を動かすことが可能となるそうです。


《TEFCAS 学びのライフサイクル》
プロセス改善を主業務にしていたわたしには、ライフサイクルという言葉は馴染み深いものです。ここでＴＥＦＣＡＳという新しいサイクルのモデルを聞きました。
ＰＤＣＡと同じで、それぞれのアルファベットはある単語の頭文字です。特にそこまでは説明しないので、ぜひ調べてみてください。（意地悪？）
このサイクルのいいところは、ＰＤＣＡと違って厳格な計画を要求していないところ。最初にやるべきは「成功へのイメージ固め」ではあるのですが、学びにはある程度の失敗が考慮されるわけですから、絶対的な成功のための計画は必要ないのです。その辺の「緩さ」が、学習に本来必要なゆとりを与えているように思います。
この理解は本来の目的とは違うかもしれないのですが、わたしにはそうやってＴＥＦＣＡＳを捉えるほうが、効果の高い学習のプロセスを考えることができるように思います。



ということで、いろいろと書いてみましたが、本当はこういうことを文章だけではなくマインドマップで描いたものを公開するほうがいいんですよねー。はい、やります。そのうち。（っていつよ！！）

• 
• 
• ツイート

フィードバックが遅くなってすいません。
わたしも参加が恒例となっているオブジェクト倶楽部のイベントに、今年も行ってきました。

イベントの詳細はこちら。
オブジェクト倶楽部２００９夏イベント

といくことで、細かい部分の説明は省いて、ざっくりと所感を書いてみたいと思います。

平鍋さんの基調講演は『アジャイル開発方法論の現状、課題、未来』ということで、アメリカでの調査やKanbanの盛り上がりなど、アジャイルの現状を話されました。何度か拝聴したことのある内容でもあり、自分でもAgile2008に参加して肌で感じた世界の事情だったので、目新しい感じはありませんでしたが、春のAgileJapan2009の実績も整理されており、世界の日本の事情がある程度対比して語れるようになってきたな、という感慨はありました。

しかーし。ここでひとつ（文句？）言っておこう。

日本のアジャイル適用事例ですが、弊社が入ってませんから！
弊社の事例はＰＭカンファレンス２００８で、社長がしゃべってますから！
それから、弊社は売り上げの８０％以上は、アジャイル適用プロジェクトからのものですから！

かなりの自慢話ではございますが、弊社はアジャイルの適用事例だけじゃなく、自前のアジャイルプロセスを持っています。これは、アジャイルでいうところの「エクストリーム・プログラミング」とか「Scrum」と並ぶ位置づけで「A-BIP」というものを考えているという意味で、アジャイルを適用しているソフトウェア企業でも先駆的であると自負しております。

ということで、その辺をそろそろ言及しておく必要がありそうなので、近いうちにどこかで話します。
「この10年、アッズーリが沈黙してきた理由をそろそろ話しておこう。」（仮題）

午後は「オブラブ若人の集い」を拝聴しました。
Ｕ－３０のオブラブ中の人が、30分程度のプレゼンテーションを怒涛の如く続けていくという、なんとも「オレ様」的なセッション！！
そう考えると顎が落ちそうですけど、よく考えれば１社提供のイベントなわけですから、こういうのもアリだなーと思いました。特にわたしは今の仕事に「人材育成」があるので、自社のイベントで若手の成長できる場を作るというのは、会社としても大切な事業かもしれないと思いました。
そして、その内容は見事にそれら全ての懸念も期待も反映したものでした！

ぶっちゃけ、gdgd感もたっぷりだけど、何としてでも自分の思いを伝えたい！という情熱はどんなセッションよりも強いのではないかと思いました。セッションが始まってすぐ、この感覚はどこかで味わったことがある、という思いに駆られました。それは昨年のAgile2008です。アジャイルのイベントとしては世界最高ではありますが、あの場でもプレゼンの質は様々です。しかし、どのセッションも熱い思いを感じることができます。そのような点で若人の集いは、開発者のイベントとして大切なソウルとパッションを見せてくれました。ありがとう。

今、わたしは会社で「人材育成」を仕事のひとつにしています。技術者にとって何よりも大切なことは「自ら学ぶ」ということだと思っています。若人の集いでは、それをありありと見せ付けられました。「どうやったら、こんなふうに人が育つのだろう？」畏敬の念とともに、軽く（？）ジェラシーも感じました。あぁ、どーしよう。

最後に、まとめ的な感想。
第1回のイベントに参加してから、しばらくご無沙汰して後に２００６年以降、大体のイベントに参加させていただいていますが、少しずつ自分がイベントに参加する上での思いいれが変わっていることに気づきました。特に今回は強く。
自分が開発者であったときに得られる気づきと、ＩＴを基調に経営をしている会社の運営に携わるという立場での気づきでは、同じ話を聞いても全く違います。

例えば「若人の集い」を、自分が開発者であったときには「自分もあれぐらい勉強するようにがんばろう！」と思うはずですが、今は「どうすればああやって自分から学ぼうとする技術者を育てられるか？」というところに気持ちが向きます。

イベントそのものに、一所懸命工夫を凝らして、参加者に楽しんでもらおうとするスタッフの姿勢はいつも感心しますし、実際楽しませてもらっていることに大変感謝しています。
でも、イベントってもしかしてマンネリでもいいのかもしれない、と今回は思いました。それは、マンネリということは「ここにくれば大丈夫」のような安心感であり、決してネガティブなものではないから。そして、そこに参加する人たちは常に外で変化を続けていて、たとえマンネリな場所であっても、各々が新たな気づきを得て帰って行ってると思うのです。特に今回のわたしはそう思いました。

また、いつも半分ぐらいの参加者が初参加ということイベントには、ある一定のクオリティは期待されているのではないかと思います。それを変わらず提供することは、業界に対する使命なのかもしれません。それを果たすためには見えないところでの努力は必要ですしね。

そうそう。そこで気づいたこともありました。数年来イベントに参加させていただくと、スタッフのみなさんともずいぶん顔見知りになりました。そうすると、運営しているメンバーのポジショニングが微妙にシフトしていることに気づきます。以前はちょっと頼りなかった彼が、今はすっかりたくましくなってスタッフとして立派な立ち振る舞いをしている、とか。特に事務局の永田さんの、安定感のあるディレクターっぷりはとても素敵でした。すっかりオブラブの顔になってましたね。

だから、イベント自体はマンネリでもいい。そこに集まってくる人はその時なりの受け止め方をしているのだから。
長く続くこと。それがイベントにとって重要な役割なんだと思います。

今後とも、多くの人に静かな刺激を与えてくれる、よいイベントとして続いていっていただけることを願っております。

• 
• 
• ツイート

前職でプロセス改善の仕事をしていたとき、お世話になったコンサルタントさんと３年ぶりぐらいにお会いして、いろいろとお話をする機会がありました。ＣＭＭに関してはわたしの師匠的存在です。

ここ数年、主に名古屋の車関係の企業でコンサルティング活動をされていたそうで、ドイツの車メーカーからの監査に対応することも多かったとのことで、現地のソフトウェア関連エンジニアと話すこともあり、彼らのプロセスに対する思いいれに感心されたそうです。

例えば、車関係のアセスメントモデルはAutomotiveSPICEが有名ですが、それらのモデルを用いたプロセス改善の実施を会社から指示されると、現場はとても喜ぶのだそうです。周囲のエンジニアは、羨ましがるとか。

なぜかというと、アセスメントを前提としていても、プロセスそのものは自分たちで構築するものであり、またそれを会社の指示で実施するということは、長期に渡って会社で使われるプロセスを自分が作れるということであり、それだけの技術力があるという証であるので「自分たちのプロセスを作れることを、会社から許された」ということにとても誇りを感じるからだと。

つまり、ドイツでは開発の現場においてプロセスというものがとても重要視されており、それに則した開発を行うということは、自分たちの技術力を更に強固にしてくれるものだという考えが根付いているようなのです。

日本では、一般的にプロセスが重要と考える風土がないように思います。プロセスを構築するということが、技術の一部であるという認識は、薄いのではないでしょうか。

ものごとを「体系化」することが得意な欧米の人々には、自分でプロセスを構築するということに高いスキルが必要なことを熟知しているのでしょう。日本人はそこが不得手なのか、体系化に価値を感じない文化なのかはわかりませんが、体系化のスキルに興味のある方は少ないようですね。

最近では勝間和代さんが「フレームワーク力」を提唱されるようになったりしてきて、知識の体系化に興味を持たれるようになってきたようなので、このあたりは今後変わってくるかもしれません。

それから、これはドイツのメーカーに限ったことではないようなのですが、自動車の生産プロセスはかなりアジャイルに近いもののようです。

自動車を構成する、ある程度の機能単位は「部品」と呼ばれています。これは「ネジ」とか「スプリング」などが部品と呼ばれているものとは異なります。どのようなものかというと、エアバック機能とかクラクション機能など。
これらの部品を開発するチームは、生産される車種に関係なくこの部品を担当します。もう何年もその部品の開発、製作に携わるそうです。そして、これらの部品は新しい車種に対して改良が加えられると、それを１つの「要求仕様」として受け取り、その要求が完了した段階で「完結」します。もし、次に何か変更要求が来たとしてもそれは「新しい要求」であり、仕様変更ではありません。

それは契約上でも明確で、もし部品の開発を担当しているのが下請企業である場合には、新しい契約が結ばれるので瑕疵責任として無償対応するなどの必要もないのです。

つまり、部品の開発は常に続いているのですが、１つのリクエストを完結させていることで、常に機能するものであり続けるということでもあります。
これはアジャイルの価値と合致しています。

わたしはいつも思うのですが、「仕様変更」という言葉は実に不思議なもので、この言葉である要求を提示されると、以前にやった仕事がムダになってしまったように感じ、モチベーションも下がります。しかし、これが「新しい要求」として提示されると、そのようなことはあまり感じません。

様々な文化的背景もあるのでしょうが、労働時間の短さではが世界有数のドイツでのお話です。それが実現できる背景は、このようなところにあるのではないでしょうか。（勝手な憶測ですけど。）

• 
• 
• ツイート

ちょっとしたところのMLにあった、大先輩のお言葉が真っ当であり、背が伸びる思いになったので書いておきます。

・技術としてみたときの「良いプロセス」とはどのように考えればよいのか
・ソフトウェアの現場実践としてよいプロセスを志向するにはどのようなアプローチがよいのか
・現実の市場の中でプロセスの良し悪しはどのように評価され淘汰されていくか

などの問題を冷静に見つめる研究的な活動もやはり必要ではないかといいう気がしてきました。

擦り寄るばかりの普及活動ではなく、研究すべきは直接現場の役に立つこと。
そういうことなんだと思った。

• 
• 
• ツイート