2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
リンクをコピー
記事をブックマーク
榎本悠介氏:最速でループを回すためには、もう簡単な話なんですが、フルスタックになりましょう。先ほど、画面仕様を作る、バックエンド設計する、実装する、みたいなポイントがいくつかあったんですけど、それらを全部カバーできるようになれば自分1人でループを回せるので、それが一番速いんですよね。
フロントとかバックエンドとか、もちろん得意領域はあっていいんですが、それらをまたいで一気通貫にできるようになろうぜというのが、基本的な考え方になります。
慣れてくると、脳内でループが回せます。脳内ですぐ「やっぱりこっちだったわ」というのができるようになると、めちゃくちゃ開発は早くなるし、いいものができるサイクルが回ってきます。
フロントエンドエンジニア、バックエンドエンジニア、プロダクトマネージャー、デザイナーみたいな感じでこれが全部分業されていると、お互いの専門性が発揮できていいっちゃいいんですけれども、やはりどうしてもコストがかかります。
前提を揃えたり、前提を共有するために、画面仕様を起こしてみましたとか、資料作成したりとか、インターフェイス仕様書作ってみましたみたいなコミュニケーションコストがかかったり。
それをもとに実際に実装してみて、みんなで確認して、「なんか違うね」ってなって、「じゃあ、ここから戻ろう」みたいになるコストとか、最終的に、「これはいいね」って合意形成したりだとか、そういうコストがかかっちゃうので。
これを1人とか、オーバーラップするかたちで2人とかで完結すると、めちゃくちゃループが速く回るので、いいプロダクトが作れるようになると思っています。
なので、第1にドメイン知識が絶対あります。必要です。ドメイン知識をベースに、もちろんコードレビューとかはあるかもしれませんが、この機能は自分が主役だと、自分が絶対責任を持って作りきるんだという、あくまで自分が主役で、みんなで背中を預け合って開発しましょうみたいなチームが結果的に一番いいプロダクトを作るチームになるかなと思っています。
なので、とにかく覚悟が大事ですね。「この機能は俺が主役で、なにかあったら俺の責任だ」くらいに思うのが、いいプロダクトを作れるチームかなと思います。
あとは、デザインもそうですし、いろいろな技能があると、さらに高速に回すことができます。要は、全部できるといいねという、ちょっとマッチョな結論になっちゃうんですけど、そういうチームでありたいなと思っています。
あとは、大事な考え方になるんですけど、仕様ですね。プロダクトの仕様は、とにかくシンプルにしましょう。複雑になった時点で、もうなにか罠にはまっていますね。ユーザーに伝わらないし使われないし、よくわからない。作るのも大変だし、作るのが大変ということは、負債も大きくなるし、品質も低くなるのでだいたいバグも出まくるんですよね。
複雑な仕様って、たぶん誰も得していない。なにかが間違ってそうなっちゃっているという嗅覚を持ちましょう。それを工夫して、どうシンプルに落とし込むかが腕の見せどころだと思っています。
なので、エンジニアってそこがすごくいいところかなと思っています。エンジニアだと見積もりができるじゃないですか。概算で問題ないので、これがやばいかやばくないかみたいなところが肌感でわかるのがすごくいいなと思っています。
あとは、「短期では、なんとかなるけど長期だとやばくなるな、これ」みたいな嗅覚もあると思います。既存のシステム仕様もわかっているので、「ここをつぎはぎするとやばいぞ」みたいなのもわかる。
プラス、先ほどのドメイン知識と、どれだけユーザーにメリットがあるか、という両面を掛け合わせると、シンプルなコスパのいい落としどころがわかるので、そこを目指していけると長期的に使われるプロダクトになっていくかなと思います。
「ここまでは許していいけど、ここまではあかん」みたいなポイント、落としどころをさっと作れるような人になると、いいプロダクトになっていくかなと思います。
あとは、ユーザーに言われたとおりに作らないのもすごく大事です。
ヒアリングで、「こういう機能欲しい、こういう機能欲しい」と言われるんですけど、それをそのまま額面どおり受け取るんじゃなくて、「こういう要望が来るということは、そもそも想定していない使い方をしているぞ」とか、「そもそも、もともとの業務をこう変えるべきなんじゃないか?」とか、逆に提案をしたり「僕らのそもそも考える、あるべきのフローって何だっけ?」みたいなところに立ち返って、言われたまま作るんじゃなくて、あるべきをより抽象化して作るのがいいかなと思います。
Howは僕らが考える仕事なので、あくまでWhyを突き詰めて考えるというかたちです。お客さまが言っている。その上でなるべく個別機能じゃなくて、ラベル機能とかタグ機能とか、抽象化していける分には抽象化して作る、みたいなのをすると、複数の要望が一気に打ち取れてキメラにならないプロダクトになるかなと思います。
(次回へつづく)
関連タグ:
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ