印象深い技術経験（５）
こんばんは、ズッキーです。
雨の音を久しぶりに聞いている今宵、今回のテーマ「印象深い技術経験」について書いていきます。
私はソフト屋（ソフトウェア開発）です。基本、自分たちで仕様を決めて、ソフトウェアを作っています。
毎年、バージョンアップするソフトウェアなので、毎年、新しい機能を追加しています。そんな状態が１０年以上続いている製品なので、ソフトウェアの中身（ソースコード）はスパゲッティ状態です。
そういう、ソフトウェア開発生活の中で印象深い技術経験を挙げるとしたら、新人の時の開発経験でしょうか。
１．新しい技術導入への踏切
スパゲッティ状態のソースコードに、新しい機能（ソースコード）を追加する。もちろん、不具合を出してはいけないし、デッドラインは決まっている。新人の私が、上記の課題をどのようにクリアーしたのかを書いていきます。
当時、社内の中堅開発者、または若手開発者は、基本的に既存のソースコードをコピペして機能を追加していました。それが一番早く正確だと思われていたからです。しかし、同じ様な原因で、あちこちで不具合が出ていました。また、１０年以上も経つ製品なので、ソフトウェアを構成しているプログラム技術は、古いものばかりでした。プログラム技術が、古いことは、決して悪いことではありません。既存の技術に新しい技術を取り込んで、もっと良いものを作ろうとする雰囲気がないことが私的には、残念だと感じていました。
また、上記で書いた同じような原因は、すべてメモリ管理ができていないという点でした。だから、私はメモリ管理を自動的に行ってくれる技術を導入することにしました。新人が中堅レベルと同じ精度の機能を実装するには、世界中の開発者が何年もかけて作り上げた技術を利用することがベストだと思ったからです。また、デッドラインも決まっており、既存のソースコードを理解もなくコピペすることは結果的に間に合わないといこともありました。
社内には、この技術を取得している開発者はいなくて、最初は手こずりましたが、最終的には上手く行きました。この背景には、日頃からの技術調査や技術向上があったからもしれません。思いつきだけで、新しい技術を導入するのではなく、仕事以外の時間、例えば、家とか、休日の勉強会などで日常的に技術研究をする習慣が大切だとも感じさせてくれた開発でした。
雨の音を久しぶりに聞いている今宵、今回のテーマ「印象深い技術経験」について書いていきます。
私はソフト屋（ソフトウェア開発）です。基本、自分たちで仕様を決めて、ソフトウェアを作っています。
毎年、バージョンアップするソフトウェアなので、毎年、新しい機能を追加しています。そんな状態が１０年以上続いている製品なので、ソフトウェアの中身（ソースコード）はスパゲッティ状態です。
そういう、ソフトウェア開発生活の中で印象深い技術経験を挙げるとしたら、新人の時の開発経験でしょうか。
１．新しい技術導入への踏切
スパゲッティ状態のソースコードに、新しい機能（ソースコード）を追加する。もちろん、不具合を出してはいけないし、デッドラインは決まっている。新人の私が、上記の課題をどのようにクリアーしたのかを書いていきます。
当時、社内の中堅開発者、または若手開発者は、基本的に既存のソースコードをコピペして機能を追加していました。それが一番早く正確だと思われていたからです。しかし、同じ様な原因で、あちこちで不具合が出ていました。また、１０年以上も経つ製品なので、ソフトウェアを構成しているプログラム技術は、古いものばかりでした。プログラム技術が、古いことは、決して悪いことではありません。既存の技術に新しい技術を取り込んで、もっと良いものを作ろうとする雰囲気がないことが私的には、残念だと感じていました。
また、上記で書いた同じような原因は、すべてメモリ管理ができていないという点でした。だから、私はメモリ管理を自動的に行ってくれる技術を導入することにしました。新人が中堅レベルと同じ精度の機能を実装するには、世界中の開発者が何年もかけて作り上げた技術を利用することがベストだと思ったからです。また、デッドラインも決まっており、既存のソースコードを理解もなくコピペすることは結果的に間に合わないといこともありました。
社内には、この技術を取得している開発者はいなくて、最初は手こずりましたが、最終的には上手く行きました。この背景には、日頃からの技術調査や技術向上があったからもしれません。思いつきだけで、新しい技術を導入するのではなく、仕事以外の時間、例えば、家とか、休日の勉強会などで日常的に技術研究をする習慣が大切だとも感じさせてくれた開発でした。
印象深い技術経験(4)
こんにちは 丼です。
あんまり技術っぽくないことばかり粗っぽく３つ書きます。
その１：
技術者でない人を技術系にする為に事業分野の技術背景の説明を行ったときのこと。自分自身が専門家でも何でもなかったので、参考書片手に資料作りでした。でもおかげで多少は教わる立場に立った説明ができたかもしれません（そうであってほしいです）。教えるほうも教わるほうも専門家でないからにはそんな立派なことはできないだろうと考え、いかにやる気になってもらう（やる気をなくさせない）か、わかった「気」にさせるか、等々に焦点をおき、技術アレルギーやコンプレックスをなくさせることを目標にしました。
ただ、基礎的な段階を過ぎると、教わる側が欲しがる情報と教える側が与える（与えたい）情報とにずれが生じてきました。双方（現場と会社の上のほう）の立場の違いや、お互いにお互いの状況や方針を理解していないことなどが原因にあったんだと思います。同じ物（製品）をある人は金のなる木と思い、別の人は見せ金と考え、また別の人には目の前のやっつけ仕事に過ぎません。そのズレをおさめるには自分の力は及びませんでした。
その２：
お客さんや仕事の相手が外国の方の場合、なかなかこちらの意図が相手に伝わりません。
例えば、外国のお客さんが自分の意見を一言一句変えずに先方に伝えることを要求してきたとき、そのままでは角が立ってしまうから意見を和らげましょうとその外国のお客さんがを説得するのは難しくて困りました。こちらの語学力のなさが一番の原因であるのでしょうが、文化の壁もあるのでしょう。なぜ意見を和らげて表現する必要があるかの説明は大変でした。
その３：
家族が病気の宣告を受けて治療方針を選択する場合、おそらく理想的には、カルテをもらってセカンドオピニオンをとり、いろいろ情報を集めて最も患者にとってQOL（Quality of Life）が高まると考えられる最善の治療法を探して選択すべきなんでしょうが、とてもそんなうまくはいきません。セカンドオピニオンって地方では選択肢がないし、取ったとしても役に立つか不明ですし、そのくせ大変なのは当の患者の家族ですし、へたに「セカンド」という選択肢を相手に提示することで相手に後々いらぬ後悔をさせる可能性もあるでしょうから、果たしてどうすべきなんでしょう？
病気の治療の選択を行うということは、その患者の寿命や人生を左右することです。そんな資格が自分にあったかなとか、もっと選択ができたんじゃないかとか、いつまでも悩みは尽きません。
あんまり技術っぽくないことばかり粗っぽく３つ書きます。
その１：
技術者でない人を技術系にする為に事業分野の技術背景の説明を行ったときのこと。自分自身が専門家でも何でもなかったので、参考書片手に資料作りでした。でもおかげで多少は教わる立場に立った説明ができたかもしれません（そうであってほしいです）。教えるほうも教わるほうも専門家でないからにはそんな立派なことはできないだろうと考え、いかにやる気になってもらう（やる気をなくさせない）か、わかった「気」にさせるか、等々に焦点をおき、技術アレルギーやコンプレックスをなくさせることを目標にしました。
ただ、基礎的な段階を過ぎると、教わる側が欲しがる情報と教える側が与える（与えたい）情報とにずれが生じてきました。双方（現場と会社の上のほう）の立場の違いや、お互いにお互いの状況や方針を理解していないことなどが原因にあったんだと思います。同じ物（製品）をある人は金のなる木と思い、別の人は見せ金と考え、また別の人には目の前のやっつけ仕事に過ぎません。そのズレをおさめるには自分の力は及びませんでした。
その２：
お客さんや仕事の相手が外国の方の場合、なかなかこちらの意図が相手に伝わりません。
例えば、外国のお客さんが自分の意見を一言一句変えずに先方に伝えることを要求してきたとき、そのままでは角が立ってしまうから意見を和らげましょうとその外国のお客さんがを説得するのは難しくて困りました。こちらの語学力のなさが一番の原因であるのでしょうが、文化の壁もあるのでしょう。なぜ意見を和らげて表現する必要があるかの説明は大変でした。
その３：
家族が病気の宣告を受けて治療方針を選択する場合、おそらく理想的には、カルテをもらってセカンドオピニオンをとり、いろいろ情報を集めて最も患者にとってQOL（Quality of Life）が高まると考えられる最善の治療法を探して選択すべきなんでしょうが、とてもそんなうまくはいきません。セカンドオピニオンって地方では選択肢がないし、取ったとしても役に立つか不明ですし、そのくせ大変なのは当の患者の家族ですし、へたに「セカンド」という選択肢を相手に提示することで相手に後々いらぬ後悔をさせる可能性もあるでしょうから、果たしてどうすべきなんでしょう？
病気の治療の選択を行うということは、その患者の寿命や人生を左右することです。そんな資格が自分にあったかなとか、もっと選択ができたんじゃないかとか、いつまでも悩みは尽きません。
印象深い技術経験（３）
こんばんわ。タコスです。
私は学生という立場ですので、大学での研究経験についてに書かせていただきます。
具体的に主観がだいぶ入りますが、自分の研究経験から理想的な研究（室）の指導体制
について主に人間関係的な観点から書こうと思います。ある程度会社組織にも当て
はまる部分があるのではないかと思います。
私の所属していた研究室は学部生、大学院生含めて80人ほどと大所帯でありながら
教授と准教授しかスタッフがいないという環境でした。しかもドクター、ポスドク
もいませんでしたので実質的に修士学生が研究室を動かしていくという体制でした。
私も修士でしたので、指導する後輩も自分一人で少なくとも5～6人はいました。また
研究分野は近いものの各人である程度異なっていました。
このような背景のもと、私は自分の研究に励むのは当然のこと、どうやったら後輩達
の研究をサポートできるかについて日々考えていました。具体的に、①後輩の研究に
対するモチベーションをあげること、②研究成果を出すこと、③自立させること
について簡単に書きたいと思います。
①後輩の研究に対するモチベーションをあげること
まず根本的な部分です。研究室で研究をするというのは教室で座学を受ければよいという
ものではなく、能動的に意欲を持って行動しなければダメです。また授業というものは人
から知識を与えられるものであるので、受動的に何も考えなくてもある程度できてしまう
ものです。したがって研究室に配属された学部生に対して研究に対するモチベーションを
高めてもらわなければなりません。
そのために私が心がけていたことは、コミュニケーションをこまめにとること
です。その目的は、相手に対して自分がその人に興味を持っていることを印象づけ、
研究室に相手の存在がなくてはならないものだと気付かせる点です。これによって研究室
に来る動機付けがなされます。また付け加えて、、困っていることや新しくやりたいこと
など常日頃相手が考えていることを共有することでなるべく研究に対するストレスをなく
すことです。具体的にしつこくない程度に話しかけたり、相手が落ち込んでいそうなとき
は二人で話したり、逆にあえてメールでコミュニケーションをとったりしていました。
なるべく相手の性格を考慮してコミュニケーション手段を変えていました。また、ただ
怠慢で研究をさぼっている相手には、自分が相手の研究分野の論文を読み、こんな結果
もあるのだと興味をもたせていました。
②研究成果をだすこと
研究は何も考えなくても手を動かしていればなにかしらの結果が出ます。しかしいくら
ネガティブデータがでてもその結果に対して考察をしなければ同じことの繰り返し
です。また学部生時代テストの点数がいい人が必ずしも研究において素晴らしい成果
を上げられるとは限りません。その方向性が正しくなければマイナスな結果を蓄積する
だけですし、マイナスの結果が出たときに軌道修正しなければ本筋からずれて行ってし
まいます。研究者にありがちなのが、仮定と違う結果が出たときに、それが逆に研究的
におもしろい結果だと本筋のテーマからずれた方向を突き進んでいってしまうことが
多々あります。研究者は自分の興味を広げて結果を出すものですので、おもしろい結果
がでたらその方向に転換しがちです。それで最終的に論文となる結果がでればよいの
ですが、はっきりいっておもしろいデータなど世の中に無限にあり、だから研究者が
たくさんいるわけです。また当然最初に行っていたテーマもおもしろいものであった
はずなので本筋の研究からずれるべきではないことが多いです。特に学生は卒業論文、
修士論文にしてまとめなければならないはずなのである程度以上道を外れてはいけま
せん。それは今までの研究がそれ以上進めるのが不可能になり、撤退すべきときだけ
です。面白いデータが出ても学生である以上あまり横道にそれるべきではありません。
また教授はたいてい良いデータを追求させたがるものですが、それは他の暇そうな人に
投げてしまいましょう。もちろんこれは主に修士以下のある程度時間が限られた人に対
する話です。したがって結論が遅くなてしまいましたが、指導的立場にいるときに、
相手のテーマの目的を見失わせることなく、客観的かつロジカルに研究を補助して
いくことが大切だと感じました。あと成果が出るかどうかはロジカルに当てはめた
思考過程の要所要所に対してどれだけ考察できるかです。これは具体的すぎるので書き
ません。
③自立させること
これも②と似ていますが、結論から言うと、目的にそくして今までの結果をまとめ、
展望を考えること。当たり前と言っちゃ当たり前ですがやはりこれがみんなあまり
できていません。展望の具体例については省きます。この際指導者が気をつける点は、
結果に対しては目的に対する論点をはずれないようにまとめさせること。また展望に
関してはツール、フレームワーク、データベースなどスキルに属するものは提供して
よいが、アイデアは出さないことです。アイデアを出してしまったらいつまでたって
も考えないままで自立できません。大事なところは紙に書き出すことです。これは意外
にみんなやっていません。常日ごろ紙にかきだしておけばよいのですが、それをやって
いない場合、一度自己ブレインストーミングをやってロジックツリーに書き出し、
ロールプレイングしておくことが大事です。またこのときにアイデアを固定観念化
しないで、常に新しい情報を受け入れ、そこに組み入れることを忘れてはいけません。
これらのことに気をつけて指導してきた結果、自分も学生で指導される立場なのであまり
偉そうなことは言えませんが、後輩は少なくともロジカルには考えられるようになったと
思います。はっきりいってこれができれば、問題になるのは情報収集能力とcreativity
ぐらいのものかと思います。まあ研究の分野ではcreativityが一番大事だと思うので、
この点に長けていない人は研究者には向きません。しかし修士ぐらいまではなんとかなる
かなというのが自論です。
最後に長くなってしまったこととあえて抽象的に書いたことをお詫びいたします。
私は学生という立場ですので、大学での研究経験についてに書かせていただきます。
具体的に主観がだいぶ入りますが、自分の研究経験から理想的な研究（室）の指導体制
について主に人間関係的な観点から書こうと思います。ある程度会社組織にも当て
はまる部分があるのではないかと思います。
私の所属していた研究室は学部生、大学院生含めて80人ほどと大所帯でありながら
教授と准教授しかスタッフがいないという環境でした。しかもドクター、ポスドク
もいませんでしたので実質的に修士学生が研究室を動かしていくという体制でした。
私も修士でしたので、指導する後輩も自分一人で少なくとも5～6人はいました。また
研究分野は近いものの各人である程度異なっていました。
このような背景のもと、私は自分の研究に励むのは当然のこと、どうやったら後輩達
の研究をサポートできるかについて日々考えていました。具体的に、①後輩の研究に
対するモチベーションをあげること、②研究成果を出すこと、③自立させること
について簡単に書きたいと思います。
①後輩の研究に対するモチベーションをあげること
まず根本的な部分です。研究室で研究をするというのは教室で座学を受ければよいという
ものではなく、能動的に意欲を持って行動しなければダメです。また授業というものは人
から知識を与えられるものであるので、受動的に何も考えなくてもある程度できてしまう
ものです。したがって研究室に配属された学部生に対して研究に対するモチベーションを
高めてもらわなければなりません。
そのために私が心がけていたことは、コミュニケーションをこまめにとること
です。その目的は、相手に対して自分がその人に興味を持っていることを印象づけ、
研究室に相手の存在がなくてはならないものだと気付かせる点です。これによって研究室
に来る動機付けがなされます。また付け加えて、、困っていることや新しくやりたいこと
など常日頃相手が考えていることを共有することでなるべく研究に対するストレスをなく
すことです。具体的にしつこくない程度に話しかけたり、相手が落ち込んでいそうなとき
は二人で話したり、逆にあえてメールでコミュニケーションをとったりしていました。
なるべく相手の性格を考慮してコミュニケーション手段を変えていました。また、ただ
怠慢で研究をさぼっている相手には、自分が相手の研究分野の論文を読み、こんな結果
もあるのだと興味をもたせていました。
②研究成果をだすこと
研究は何も考えなくても手を動かしていればなにかしらの結果が出ます。しかしいくら
ネガティブデータがでてもその結果に対して考察をしなければ同じことの繰り返し
です。また学部生時代テストの点数がいい人が必ずしも研究において素晴らしい成果
を上げられるとは限りません。その方向性が正しくなければマイナスな結果を蓄積する
だけですし、マイナスの結果が出たときに軌道修正しなければ本筋からずれて行ってし
まいます。研究者にありがちなのが、仮定と違う結果が出たときに、それが逆に研究的
におもしろい結果だと本筋のテーマからずれた方向を突き進んでいってしまうことが
多々あります。研究者は自分の興味を広げて結果を出すものですので、おもしろい結果
がでたらその方向に転換しがちです。それで最終的に論文となる結果がでればよいの
ですが、はっきりいっておもしろいデータなど世の中に無限にあり、だから研究者が
たくさんいるわけです。また当然最初に行っていたテーマもおもしろいものであった
はずなので本筋の研究からずれるべきではないことが多いです。特に学生は卒業論文、
修士論文にしてまとめなければならないはずなのである程度以上道を外れてはいけま
せん。それは今までの研究がそれ以上進めるのが不可能になり、撤退すべきときだけ
です。面白いデータが出ても学生である以上あまり横道にそれるべきではありません。
また教授はたいてい良いデータを追求させたがるものですが、それは他の暇そうな人に
投げてしまいましょう。もちろんこれは主に修士以下のある程度時間が限られた人に対
する話です。したがって結論が遅くなてしまいましたが、指導的立場にいるときに、
相手のテーマの目的を見失わせることなく、客観的かつロジカルに研究を補助して
いくことが大切だと感じました。あと成果が出るかどうかはロジカルに当てはめた
思考過程の要所要所に対してどれだけ考察できるかです。これは具体的すぎるので書き
ません。
③自立させること
これも②と似ていますが、結論から言うと、目的にそくして今までの結果をまとめ、
展望を考えること。当たり前と言っちゃ当たり前ですがやはりこれがみんなあまり
できていません。展望の具体例については省きます。この際指導者が気をつける点は、
結果に対しては目的に対する論点をはずれないようにまとめさせること。また展望に
関してはツール、フレームワーク、データベースなどスキルに属するものは提供して
よいが、アイデアは出さないことです。アイデアを出してしまったらいつまでたって
も考えないままで自立できません。大事なところは紙に書き出すことです。これは意外
にみんなやっていません。常日ごろ紙にかきだしておけばよいのですが、それをやって
いない場合、一度自己ブレインストーミングをやってロジックツリーに書き出し、
ロールプレイングしておくことが大事です。またこのときにアイデアを固定観念化
しないで、常に新しい情報を受け入れ、そこに組み入れることを忘れてはいけません。
これらのことに気をつけて指導してきた結果、自分も学生で指導される立場なのであまり
偉そうなことは言えませんが、後輩は少なくともロジカルには考えられるようになったと
思います。はっきりいってこれができれば、問題になるのは情報収集能力とcreativity
ぐらいのものかと思います。まあ研究の分野ではcreativityが一番大事だと思うので、
この点に長けていない人は研究者には向きません。しかし修士ぐらいまではなんとかなる
かなというのが自論です。
最後に長くなってしまったこととあえて抽象的に書いたことをお詫びいたします。
印象深い技術経験(2)
こんばんは。でうでうです。
印象深い技術経験ということで、自分にとって良い”経験”となったことをつらつらと書いてみます。
（良い”実績”ではありませんよ）
①工場勤務
自分は、配属先は工場で、１年ほど３交代での生産オペレーター業務を行っておりました。
たった１年でしたが、非常にいい経験でした。
一番直結したのは、工場から開発に異動になった直後の増産対応でした。
有る素材の製造量増加(収率向上)のために工程改良を行うというものです。
「製造設備やラインが解る」という知識的なものはもちろんですが、それ以上に、生産現場とのパイプを持てていることがかなりの強みとなりました。
開発職場ですの生産に関係する仕事も多々ありました。そのため製造に関する情報は常に必要となります。
その際、他の開発の同僚が工場の管理部門から情報を得ているのに対し、自分は生産オペレーターから直接情報を得ることができました。
時間も質もかなり優位性がありました。
自分もそうだったのですが、学生のころは工場勤務に嫌悪感を持っていました。
ですが、工場勤務で生産部門とのパイプを作ることが、開発業務で非常に活用できることを体験しましたので、工場嫌いの学生と話をする時は、よくこの手の話をしています。
②共同出願
ある委託研究で特許を出願することになった時のことです。
委託研究ですので、自分は全く研究作業はしておりません。
書類作成については、ほぼ全てを共同先に任せるとの指示でしたので、ほとんど何もしないつもりでした。
ですが、共同先からの送られてきた文書を見ると、書式や表現など出願書類とは思えない内容。
出願書類を書いたことの無かった自分でもはっきりとわかるものでした。
しかたないので、見よう見まねで文面等を修正。
修正したものは弁理士先生からもそれほど直されていないので、まぁまぁだったのだろうと（勝手に）思っています。
さて、この発明ですが、先行技術調査も任せていたのですが、書面が固まりつつある頃に、先行技術をもう少し補完しようと、少し調べてみました。
すると・・・、かなりそっくりな出願が、あっさりと出てきました。
結局、かなり範囲を絞ったクレームへと、急遽変更して出願するにいたりました。
他人（他社）を信じ過ぎてはいけないという、非常に基本的な失敗の一例でした。
今回は共同先は企業ではなかったので、より配慮が必要でしたね。
③契約
３つ目は簡単に書きます。
３年くらいかけて受託を前提とした共同研究をしていたことです。
TOPで決めるべき契約内容について、あいまいのまま進めておりました。
案の定というか、後半にそのあいまいな部分で揉めて、結局破談となりました。
決めるべきことを最初に決める、という当たり前のことですが、その怖さを実感した経験でした。
印象深い技術経験ということで、自分にとって良い”経験”となったことをつらつらと書いてみます。
（良い”実績”ではありませんよ）
①工場勤務
自分は、配属先は工場で、１年ほど３交代での生産オペレーター業務を行っておりました。
たった１年でしたが、非常にいい経験でした。
一番直結したのは、工場から開発に異動になった直後の増産対応でした。
有る素材の製造量増加(収率向上)のために工程改良を行うというものです。
「製造設備やラインが解る」という知識的なものはもちろんですが、それ以上に、生産現場とのパイプを持てていることがかなりの強みとなりました。
開発職場ですの生産に関係する仕事も多々ありました。そのため製造に関する情報は常に必要となります。
その際、他の開発の同僚が工場の管理部門から情報を得ているのに対し、自分は生産オペレーターから直接情報を得ることができました。
時間も質もかなり優位性がありました。
自分もそうだったのですが、学生のころは工場勤務に嫌悪感を持っていました。
ですが、工場勤務で生産部門とのパイプを作ることが、開発業務で非常に活用できることを体験しましたので、工場嫌いの学生と話をする時は、よくこの手の話をしています。
②共同出願
ある委託研究で特許を出願することになった時のことです。
委託研究ですので、自分は全く研究作業はしておりません。
書類作成については、ほぼ全てを共同先に任せるとの指示でしたので、ほとんど何もしないつもりでした。
ですが、共同先からの送られてきた文書を見ると、書式や表現など出願書類とは思えない内容。
出願書類を書いたことの無かった自分でもはっきりとわかるものでした。
しかたないので、見よう見まねで文面等を修正。
修正したものは弁理士先生からもそれほど直されていないので、まぁまぁだったのだろうと（勝手に）思っています。
さて、この発明ですが、先行技術調査も任せていたのですが、書面が固まりつつある頃に、先行技術をもう少し補完しようと、少し調べてみました。
すると・・・、かなりそっくりな出願が、あっさりと出てきました。
結局、かなり範囲を絞ったクレームへと、急遽変更して出願するにいたりました。
他人（他社）を信じ過ぎてはいけないという、非常に基本的な失敗の一例でした。
今回は共同先は企業ではなかったので、より配慮が必要でしたね。
③契約
３つ目は簡単に書きます。
３年くらいかけて受託を前提とした共同研究をしていたことです。
TOPで決めるべき契約内容について、あいまいのまま進めておりました。
案の定というか、後半にそのあいまいな部分で揉めて、結局破談となりました。
決めるべきことを最初に決める、という当たり前のことですが、その怖さを実感した経験でした。
印象深い技術経験（１）
こんにちは。２回目の書き込み、やましです。
今週・来週のテーマは「印象深い技術経験」。
なのですが、
技術的課題の解決経験は後ろの人にお任せして
技術経験に入る前の課題との向き合い方について
自分の体験談を話してみます。
メーカーで働いてる身としては技術的課題に対して
開発担当者レベルで関わった事もあれば
プロジェクトリーダーとして関わった事もありますが
印象深い（＝苦戦した）案件を思い出してみると
お客様の中にベクトルの異なる２人以上の
担当者がいた事が多いです。
うちの会社は工場用設備を製造販売しているのですが
・工場全体を見る人と自分の担当範囲だけを見る人
・決裁権を持ってる人と実際に装置を使う人
・工場の責任者とその工場の納品先
・生産量を増やしたい人と品質を上げたい人
工場で働く人には１人１人役割があり、
１人１人違うところに問題意識を持っています。
技術というものは何かしらの課題を解決するためにあると
思ってますが、目の前にある無数の中から
どの課題を解決するか（誰の顔を立てるか）を考えて
開発を進めて行かないと良い結果を得られません。
ある課題をどうやって解決するか（How）は
方法Aをやってみた、ダメだったから方法Bをやってみる、
と試行錯誤しながら前に進めばいつか解決しますが
どの課題、誰の課題を解決するか（What）は
あっちへふらふら、こっちへふらふらは許されません。
事前にお客様、少なくとも自分の中では
方向性をしっかり決めてぶれないように進む必要があります。
個別具体的な経験は挙げませんが
最初に方向を決めた案件は大体ハッピーエンド、
登場人物を把握せずに始めた案件はトラブル三昧、
というのが自分の経験上多いです。
経験談というには曖昧な内容になってしまいましたが
明日以降に期待ということで。
それでは！
今週・来週のテーマは「印象深い技術経験」。
なのですが、
技術的課題の解決経験は後ろの人にお任せして
技術経験に入る前の課題との向き合い方について
自分の体験談を話してみます。
メーカーで働いてる身としては技術的課題に対して
開発担当者レベルで関わった事もあれば
プロジェクトリーダーとして関わった事もありますが
印象深い（＝苦戦した）案件を思い出してみると
お客様の中にベクトルの異なる２人以上の
担当者がいた事が多いです。
うちの会社は工場用設備を製造販売しているのですが
・工場全体を見る人と自分の担当範囲だけを見る人
・決裁権を持ってる人と実際に装置を使う人
・工場の責任者とその工場の納品先
・生産量を増やしたい人と品質を上げたい人
工場で働く人には１人１人役割があり、
１人１人違うところに問題意識を持っています。
技術というものは何かしらの課題を解決するためにあると
思ってますが、目の前にある無数の中から
どの課題を解決するか（誰の顔を立てるか）を考えて
開発を進めて行かないと良い結果を得られません。
ある課題をどうやって解決するか（How）は
方法Aをやってみた、ダメだったから方法Bをやってみる、
と試行錯誤しながら前に進めばいつか解決しますが
どの課題、誰の課題を解決するか（What）は
あっちへふらふら、こっちへふらふらは許されません。
事前にお客様、少なくとも自分の中では
方向性をしっかり決めてぶれないように進む必要があります。
個別具体的な経験は挙げませんが
最初に方向を決めた案件は大体ハッピーエンド、
登場人物を把握せずに始めた案件はトラブル三昧、
というのが自分の経験上多いです。
経験談というには曖昧な内容になってしまいましたが
明日以降に期待ということで。
それでは！