Conversation

Notices

1. ( ᐛ) まりなっピ (sasanquaneuf@qiitadon.com)'s status on Friday, 26-Oct-2018 09:45:38 JST ( ᐛ) まりなっピ

   調査って、全貌を(なるべく体系的に)理解する方法と、部分的に使えるかどうかを調べる方法とある。
   前者の知識があった方が多分深く検討できるんだけど、それだと一つ一つに時間がかかり過ぎたりするので、「求めている要件にマッチするか」に絞って見た方が効率的だと思う。
   直接、要件に合致する言い回しとは限らないので、そこは言い換えたりして検索するんだろうけど、それができない時にある意味で一番早いのは、営業を呼んで相談する事なんだよなー
   私自身は自分で仕様を調べる事の方が多いけど、例えば非技術者の同世代の社長がどうやって調査するかというと、とりあえず有識者、多くの場合はその商品を使っている会社の営業を呼んで説明を聞く。
   OSSの場合は、コミュニティで聞くか、他に使っている人がいたらその人を捕まえるか、ドキュメント読むか、かなあ。
   よっぽど慣れてないと、いきなりコードを読むのは難しいと思う。

   • まんじゅ（́ん｀）@駄メンター (manzyun@qiitadon.com)'s status on Friday, 26-Oct-2018 09:48:45 JST まんじゅ（́ん｀）@駄メンター

     in reply to

     @sasanquaneuf なにとなく話題にしていただけてるようなので。

     そこでOSSのコミュニティに聞こうとすると、リーダーから、
     「聞かなくていいだろボケ。ソースコード読めアホども」
     と指摘が入るので、毎日失望の沼で泳いでいます。

   • ( ᐛ) まりなっピ (sasanquaneuf@qiitadon.com)'s status on Friday, 26-Oct-2018 09:55:20 JST ( ᐛ) まりなっピ

     in reply to

     • まんじゅ（́ん｀）@駄メンター

     @manzyun たいへんですね。でも最悪個人アカウントで質問すればいいような。
     具体的な課題の粒度がわからないので何ともですが、本当に細かい挙動とかは聞いても意味ないですけど、そもそもタスク列挙してあるのかなーとかは気になりました。

   • まんじゅ（́ん｀）@駄メンター (manzyun@qiitadon.com)'s status on Friday, 26-Oct-2018 09:56:29 JST まんじゅ（́ん｀）@駄メンター

     in reply to

     @sasanquaneuf 列挙されてないです。一応リーダーからの、
     「こういう機能が欲しい」
     に対して、できるかひたすら調査している具合です。

   • ( ᐛ) まりなっピ (sasanquaneuf@qiitadon.com)'s status on Friday, 26-Oct-2018 10:00:25 JST ( ᐛ) まりなっピ

     in reply to

     • まんじゅ（́ん｀）@駄メンター

     @manzyun こういう機能が欲しい、はさらに落とし込めないレベルですかね？
     手元では一覧化した方がよいかもです。
     しばらく仕事でぬけます。

   • まんじゅ（́ん｀）@駄メンター (manzyun@qiitadon.com)'s status on Friday, 26-Oct-2018 10:30:12 JST まんじゅ（́ん｀）@駄メンター

     in reply to

     @sasanquaneuf お忙しい中お付き合いいただきありがとうございます。

     こういう機能が欲しいを更に落とし込んでチケット化しているのですが、結局リーダーの評価がチケットの消化具合。それと自分の理想の仕様を満たしているか、満たしていないなら再調査させる（絶対に自分の要求を満たす方法があると確信を抱いている様子）という具合で。

     依頼人なので当然かも知れませんが、その下で働いている僕らは、正直もどかしいという現状ですね。

   • ( ᐛ) まりなっピ (sasanquaneuf@qiitadon.com)'s status on Friday, 26-Oct-2018 13:37:23 JST ( ᐛ) まりなっピ

     in reply to

     • まんじゅ（́ん｀）@駄メンター

     @manzyun なるほど、大変ですね。
     理想の仕様については、一度タスクに着手して提出してから、あらためて話をしてから分かる感じですかね？
     チケットを作る時点で、理想の要素を列挙して、1.単純に対応できるかどうかと、2.仮にソースを改変するとすればどうなるかA、3.仮にソースを改変するとすればどうなるかB、みたいな感じですかね。
     その時に、2や3はまずアイデアを書いておいて、それから実装を調べるとかかなと思いました。

   • ( ᐛ) まりなっピ (sasanquaneuf@qiitadon.com)'s status on Friday, 26-Oct-2018 13:44:20 JST ( ᐛ) まりなっピ

     in reply to

     • まんじゅ（́ん｀）@駄メンター

     @manzyun 超極論でいうと、何でも論理的に矛盾してなければ改変すれば作れてしまいますが、一方、その工数がどれぐらいかとか、元の仕組みから外れてリスクが出てくるかとか、その辺を示さないといけないですね。
     全体像があまり掴めない・掴みにくい仕事なのかなという気がするので、お互い目的をはっきりさせるのと、"現場担当"としての懸念がどの辺にあるかを、論理的に整理して指摘できるとよいですね。
     ある程度能力のあるプログラマで、偏りがある場合、プログラムを追加で書けば何でもできると思っていて、実際それは正しいとは思うんですが、とはいえ普通の使い方と外れるリスクや、改修でバグが入るリスクもあるので、その辺についてお互い拒否感から入らずに話ができると良いですね。(異次元の理想空間)