ログイン
詳細
やの

最近結構コード書いてたけど、やめた。今週はたぶんもう書かない。 書きたいけど、それ以上の価値のある動きをします。

前へ次へ
やのゴリトーク
トーク情報
  • やの
    やの

    「銀の弾丸などない」
    ってのはなかなか真理だとおもう。

    良くも悪くも、本質的なタスクをこなす速度は一定以上の技術力のエンジニアなら大して変わらない。

    重要なのは、銀の弾丸はなくともいろんな種類の弾丸は世の中に散らばってるということと、それの使い方をきちんと知ること。
    もちろん使い方を知る過程で原理も一定知らなきゃ行けないし、どこまで知るべきかも真剣に冷静に考えなきゃいけない。
    原理は奥深いので知的欲求に身を任せすぎてはいけない。

    本当に優秀だなと思うエンジニアの人たちはこの辺りがすごくうまい。
    結果それが速度や精度につながる。

    ちなみに、優秀なプランナーは銀の弾丸を生み出す。

  • やの
    やの

    Unityは、扱いやすい大砲の弾、ってかんじ。
    中ボスくらいまでなら比較的楽に倒せる。

  • やの
    やの

    UX主導ブラッシュアップしたい。
    その機能でユーザをどういう気持ちにさせたいのか。
    それを言語化して、評価基準にする。
    いくらかっこ良くても美しくても、UXがずれてればNG。

    グラフィックはアートに走りがちだし、プランニングはグラフィックに任せがちなので、UXってのは組織構造的に抜け落ちやすい(属人的になりやすい)視点だけど、大切。

  • やの
    やの

    賛否両論だろうけど、難しいことをやればいいってもんではないよなー
    簡単だけど効果があるのが一番。
    逆に言うと、難しい技術を使ったら自己陶酔に浸りがちだけど、そういう時こそ冷静にプロジェクトへのメリットを考えないといけない。

    自身はリソース。
    技術は手段。

    ただゴールから逆算すると、たいてい難しい技術は避けられなかったりするんだけどね…

  • やの
    やの
    関根
    今日みたいな日を増やしてきたいね。もっと深掘りしたかったw こっからは工数対効果を重視したいとこだけど、中長期的目線で、かけなればいけない所は必要十分でかけていこう!

    ですね、増やしていきましょう!

  • やの
    やの

    ブラウザ時代に車輪の再利用ができてたのは、車輪どころか車ごと再利用してたからというだけの話。

    車輪が貰えても、普通はそもそもその車輪が合うように設計してなきゃ使えない。(発煙筒レベルの部品なら使える)

    とはいえ同じ仕組みのものを作るわけじゃないなら、車ごと再利用するわけにもいかない(エンジン化するメリット小さい)。

    これが、ネイティブで車輪の再開発が止まらない理由。

  • やの
    やの

    じゃあ、どうすべきか。

    まずは、モジュール単位でインタフェースを決めること。これでどんな車輪が来てもとりあえずはまるようにする。

    モジュールをまたぐ時にはインタフェースが実装されてる基底クラスかabstractなクラスの参照を持って依存させる。これで車輪が作動することを保証する。

    あとは他モジュールの依存性を外部から注入する。車輪を外す時に余分なパーツが付いてこないようにする。

    これをどれだけできるか。

  • やの
    やの

    億モン会議終了〜
    ここ1年で一番良い会議だった。

    内容的にも時間的にもかなりタフな3日間だったけど、誰も辛さを見せないしむしろ放っといたらずっと話してそうな勢い。
    「これから死ぬほど大変だな」って笑って言いあえる結論が出た。

    これは良いモノできちゃうなー

  • やの
    やの

    車輪の再開発が止まらない一つの大きな理由は、何をどこまで再利用するのかを意識できてないから。
    自転車の車輪を自動車用に再利用するくらいなら結局、新しく作ったほうが早い。

    例えばアクションRPGの設計を再利用するのなら、「アクションRPGとは?」をきっちり定義しないとうまくいかない。
    また、その定義の場合は今後アクションRPGを作らない場合は基本的には再利用できない。

    大事なのは、これから先に作っていくであろうプロダクトたちを予測して、最大公約数的に再利用するパーツを決めていくこと。
    これだけは自分のアタマで考えないといけない。

    再開発は機会損失。作るものが多様化してきてるからこそ、徹底して考えよう。