00:05
はい、皆さんこんにちは。株式会社ゆめみのキースこと桑原です。 本日もやっていきます。Web 業界のなんでも雑談室です。
この番組では、皆さんに何かプラスになる情報提供を目指してお届けしていきたいと思います。 第55回ですね。第55回は久しぶりにレター回答になります。
今回のレターはこちらですね。 技術選定ってどうやってやるの?決め方は?というレターをいただきました。
はい、レターを送っていただきましてありがとうございます。 よくある開発現場での技術選定、技術といってもその利用するツールとかフレームワーク、ライブラリーの決め方についてのご質問ですね。
こちらですけども、基本的には一緒に開発するメンバーのスキルセットっていうのが、やっぱり土台にあると思っていて、
その中、メンバーとの相談とか競技の上で最終的に決定をしていくものではないかなと思っています。
こちらというのはどの現場とかどのチームでもやっぱり同じではないかなと思っております。
はい、なので今回はですね、その点技術選定をする上で考慮することについてちょっとお話ししていけたらいいんじゃないかなと思っています。
最終的にはみんなで相談して、またの冗長決策ある現場もあるのかもしれないですけど、
最終的にはですね、やることはやると決めて、営業の面も多少なくはないので、そうやって決めていくのではないかなと思っておりますが、
そうやって考慮する点ですが、一つ目としてはやっぱりまず枯れているものを選択することが圧倒的に多いなというふうには思いますね。
もちろんやっぱり使うもののバグが多かったりとかGitHubのイシューが大量にあるというものはやっぱりちょっと落とし穴が多いなというふうに感じますし、
エッジケースと言いながらエッジの数が大量にあると、それもフレームワークとかツールって使えないんじゃないかというふうに判断しなきゃいけないときがあると思いますので、
やっぱり枯れているもののほうがいいなというのは思いますね。
もしくは枯れているというかGitHubのスターが多いというものはやっぱりそれだけで信頼度が高いということを世界が認めていることになりますので、
そういうのを選んでもいいのかなと思いますね。
あとは身の回りとかインターネットで調べたら結構利用実績が多いなというツールとかも全然信頼度が高いなというふうに思いますね。
あとはですね、これも結構いい選択肢の考慮すべきものとして、ドキュメントとかQAみたいなのとか、
使ってみたよというブログの数が多いというのはすごくありがたいなと思っていて、
そういうのは自分たちがこけたり困ったときに調べるとそういうのがドキュメントとして公開されているものが多いというのは解決へのアプローチがたくさんあるということですので、
しかもそういうのがインターネットにいっぱいあるというのは心強いですよね、実際開発上でというのがあるので、
そういうものを選ぶというのも結構いいのではないかなと思いますね。
もしくはですね、逆の視点として新しいものとか今ホットなものっていうのを選択するのもありだと思ってますね。
03:00
というのもですね、最近リリースされたとか話題になっているっていうのはそれだけ過去の何かという問題があって、
その問題を今の新しく出たものと解決しているはずですので、という意味で選択するのはありかもしれないですね。
今までにないアプローチっていうのがここで生まれているということになりますので、
まだそれだけ話題になるっていう時点でそこに有用性があるはずですので、
そういうのを注目するのもありだと思っています。
また新しいものを選択するエリットとしては、やっぱり自分たち、開発メンバーのスキルアップもそうですし、
会社全体としての知見が溜まっていくっていうのもありますし、
全員と関わったメンバーのスキルの底上げっていうのがやっぱり大きいですよね。
特に住宅みたいな会社さんだとやっぱりメンバーとかメンバーのスキルそのものが資源になりますし、
技術力の象徴になりますので、そこを底上げできるのは本当にメリットだと思いますので、
そういう視点を持って新しいのを選ぶっていうのも勇気を持ってやるのは大事かもしれないですね。
またやっぱり新しいものとか掘ったものって、独学で勉強されている方もたくさんいらっしゃるんですけど、
やっぱり独学って結構限界があって、
なので実践投入して初めて得た経験っていうのが本物のスキルになるようになっていると思っています。
規模感とかもやっぱり個人だとたかが知れることが多くて、
よっぽどのことない限り個人開発でこんな大規模なことをやれるのはなかなかないですからね。
そういう視点があるかなと思いました。
あとはですね、プロジェクトの要件に沿うっていうのももちろん大事なことですよね。
そこは外せないと思います。
例えばですけど、一緒にお仕事するクライアントさんにも技術メンバーがいて、
その技術メンバーと連携しなきゃいけないとなったときに、
その技術メンバーと連携しやすいものとか、
すでにその先方の技術者の方々が使っている技術があったりして、
それに乗っかる、先ほどそういうことを指定されることもよくあると思うんですよね。
その場合はそれに乗っからざるを得ないのでしょうがないんですけど、
それに合ったライブラリーとかを自分たちで選んでいって提案していくという形になると思いますね。
あとはプロジェクトの要件としても、
クライアントさんが作ろうとしている既にあるサービスというののユーザー数がすごく多い場合もやっぱりあると思っています。
そのユーザー数に耐えられるものなのかどうかというのは結構大事なんじゃないかなと思います。
往々にしてユーザー数に耐えられるかどうかというのは、
非機能要件のインフラだったりする話には大体なるんですけど、
一方で開発するフレームワークとか言語もそうですけど、
少なからず多少の影響はやっぱりありますので、
そこは加味して考えていくのがいいのではないかと思っていますね。
パフォーマンスがまずしっかり出るものというのはやっぱり大事だと思います。
なのでベンチマークもしっかりとっているのも大事かもしれないです。
そのベンチマークをいっぱいとっているサイトとかライブラリとかを公開されている方も全世界たくさんいらっしゃるので、
そういうサイトを見てベンチマークを確認するのも大事だと思いますね。
あとは保守性を考えている選定していくのは結構大事で話題かなと思いますね。
06:04
利用するライブラリとかフレームワークそのもののアップデートがどれだけなされていますかというのも結構大事で、
最終コミットを見ると2,3年前とか言われると、
ちょっともうこれメンテナンスされていないんじゃないかというところで、
その時そのフレームワーク依存の起因で何か起きたときに、
自分たちで全部手を動かしていかなきゃいけない。
それは結構大変ですよねというのもあるので、
そういうところを見るのも大事かもしれない。
ちゃんとこのツールって保守されていますかというのを考えるのはいいと思いますね。
そういうことをしないとセキュリティ問題起きたときに、
ちゃんとパッチ対応してくれるんですかというのがすごい課題になってきて、
バグだけであればいいんですけど、
セキュリティパッチを結局自分たちでやると本当に大変になりますので、
その場合そのツールとかは捨てる可能性が出てくるので、
それは結構シビアな話かなと思いますね。
捨てるという話でいくと、
ある意味でこのライブラリとかフレームワークを捨てやすいというのも一つ選択肢にあるかもしれないです。
何かあったときに乗せ替えようと。
乗り替えやすいものというのは結構大事かもしれないですね。
あんまりないと思いますし、
そういう状況になるのはこのまましかないんですけど、
最悪のケースとしてそういうことを視野に入れるのは悪いことではないかなと思っています。
あと最後は、
そのツールとかフレームワークを使って開発速度が下がらないことが結構重要かなと思います。
もちろん上がるんだったらそれに越したことはないですけど、
やっていくと何だかんだ落とし穴があったり、
結構みんなで議論したりするときがあると思っていて、
なので早々に上がるということを望むのは結構難しいので、
やっぱり今のメンバーのパフォーマンスとか開発速度というのがしっかり発揮されて、
そもそも落ちることがないというのが結構重要な視点かなと思いますね。
その要件とかもクライアントさんの次第では、
要因が結構出てきたりとか、
仕様変更があったりとか、
やっぱりここの仕様を講じてほしいって、
要望って結構出てくるのは往々にしてあり得る話なので、
そういうものにもしっかり対応できたりするとかいうところですね。
変更に強い、それはツールというか設計になる話かもしれないですけど、
一方でその設計をすぐに反映できるツールっていうのはやっぱり使いやすいし、
そこで開発速度が下がらないんだよねっていうのはあると思います。
やっぱりそういうところですかね。
結構やっぱり触ってみたり使い始めると落とし穴だらけっていうのはやっぱりよく聞く話ですし、
コアの部分で、あとエッジケースとかですごく面倒くさい、
機電の垂れ化するような行動を書いてしまうことってやっぱりあるので、
なるべくそういうことを避けるに越したことはございませんからね。
やっぱり開発速度ってそのまま、
僕ら開発会社としては売り上げにすごく直結するものですので、
速度が下がらないようにできるんだったらもうそれに越したことはないので、
そこはやっぱり加味していくのがいいのかなと思います。
具体的に言うと難しくてですね、
それもやっぱりケースバイケースで現場の話になるので、
なかなか難しいんですけど、
いろんなことを想定、考えることを想定して、
技術をみんなで相談して決めていくのがいいのかなというふうに思いました。
09:01
というわけで今回はこんなところで、
収録以上となります。
また何か聞きたいことが、話してほしいことがありましたらいつでもレターをお待ちしております。
今日の話が少しの参考になれば幸いですね。
以上となります。バイバイ。
