コンテンツにスキップ

Deverlopers Summit 2021 Summer [C-9] 感想

#devsumi #DDD

✒️ 概要

🎉 感想

品質特性の説明について

引用：

促進の意味するところ：
「放っておいても促され与え続けていくこと。たとえば交通の便が良いと街が発展したり、水はけが悪いと作物の育ちが悪くなるなど。」

  • 技術的負債の解消をビジネスサイドに伝えるときにどうしてもプラスのイメージはあまりなく、「マイナスをゼロにするだけ」の作業として捉えられてしまい、受け入れにくくなりがちだけど、上記の表現はすばらしいと感じた。受け入れやすくなり、参考になる。
  • たしかに品質の良いソフトウェアをつくるというのは、ビジネスの良い土壌をつくるようなもの。
  • 自社開発のビジネスサイドとの調整もそうだが、受託開発においても、顧客のお金でリファクタリングしなければならないケースがあるため、説得力がないといけない。ちゃんとつくられていれば、みんなが幸せになり、ちゃんとつくられていないと、みんなが不幸になるという確信はあったのだが、交渉や説得でなんとかしなければいけないケースがあり、語彙力もないのでそういう調整力はずっと課題感があった。こうやってオンラインのイベントでスタディできるのは非常に良い機会を貰えている気がする。

エンジニアに必要なスキルについて

引用：

「技術には興味があって楽しいよ。会社の議場の細かいことはよくわからないけれど、仕様書さえあれば、そのとおりに実装してみせます」
... このような考えだと、システムの活力が減衰し、事業継続が困難な状況に陥るかもしれません。

  • この部分かなり同意。
  • 昔うけたオブジェクト指向の教育で、「変更されやすい箇所(ホットスポット)と確定的で変更されにくい箇所(フローズン)にわけることが重要」といわれたのを覚えていて、その切り分けをおこなうには、本来実現したいことの背景を突き詰めて理解する必要があるという感覚がずっとあった。その考えで設計して、うまくいったときが楽しかったし、開発においてこれができる／やるべきことだという感覚がった。
  • 目的を理解しているかいないかが、設計だけでなく実装するコードのレベルまで波及してくるので、できるだけ理解しようとして取り組むことが大事。いつも顧客とはできるかぎり密に話をするようにしていて、そういうソフトウェア開発での重要ポイントを理解して開発できるという自信は自分でもっていたが、言語化できておらずわかりやすいスキルとかの形にならないので、もやもやがずっと溜まっていた感があった。
  • エンジニアの評価として、スキル「〜の技術を知っている／使える」があるということのほうがわかりやすく、ソフトウェア人材の市場ではスキルがある人が価値が高まりやすい傾向があって、これももやもやする原因だった。
  • このブログもそうだが、もうすこし自分なりのソフトウェア開発に対する考え方を(下手なりに)言語化してアウトプットしたい。

名前の付け方の重要性について

  • 名前のつけかたも、目的や役割を読んだひとに理解させる方法としてかなり重要と考えていた。たしかにこれはいろいろなひとが言っている。
  • ただし、自分はぼんやりと「センス」と思っていた。今回の「目的駆動名前設計」はガイドラインとして非常に役に立ちそうと感じた。書籍出たらぜひ買いたい。
最終更新日: July 31, 2021