求められているのは“製品”ではなく“解決策”｜CTO(技術最高責任者)の“7つのマイルール”とは？
こんにちは、株式会社CyberOwl(以下、サイバーアウル)広報の平田です。
今回のnoteでは、活躍しているサイバーアウル社員の活躍のウラにある7つのマイルールをご紹介します！
仕事やプライベートも含めて、その人自身が大切にしているこだわりや価値観、意識していること、何気なくやってしまうこと、などを7つのマイルールとして教えてもらいます。
第3弾は、2023年3月末に行われた全社総会で、ベストプレイヤー賞(エンジニア・デザイナー部門)を受賞したPhone Zaw Phyo(フォン ゾウピョ)です。ぜひご覧ください！
1. The best process is no process, the best code is no code
(最高のプロセスにプロセスはなく、最高のコードにコードはない)
例えば、ある依頼者がウェブサイトの記事ページにコメントや返信の機能を追加開発するよう依頼したとします。
有能なエンジニアであれば、その依頼どおりに正確に作り上げるかもしれません。しかし、本当に優秀なエンジニアは、一旦立ち止まって「この機能は本当に必要なのだろうか？」とより深く考えるでしょう。
さらには、その機能を追加する際にどのような複雑な作業や開発費がいくらかかるかを進んで明らかにし、依頼者へほかの方法を提案することも…。
私の経験では、このような効率的なアプローチによって、多くの依頼者が当初の依頼を見直して、より生産性の高い方法を選択しています。
2. Don’t repeat yourself (DRY) (同じことを繰り返さない)
Don’t repeat yourself (DRY)とは、ソフトウェアの構成や構築手法の原則の一つです。
例えばあなたがブロガーだったとします。新しいコンテンツを次々と生み出さなくてはいけない難しい仕事に直面しているとき、冗長性を防ぐ秘密兵器として「DRY」の原則が役に立ちます。
この場合、記事ごとに“車輪”を作り直すのではなく、基となるテンプレート、再利用可能なリサーチの貯蔵庫を発展させることで、新しいコンテンツを生み出す作業を“自動化”させることができるのです。
この「DRY」の原則に基づいた戦略によって、プロセスが合理化されるだけでなく創造力までも解放され、ブログが常にユニークで魅力的なコンテンツで満たされることを保証します。
3. No job is boring (退屈な仕事はない)
たくさんのデータを集めてレポートを作る仕事を考えてみてください。なんだか退屈そうですよね。でも、そんな仕事も見方を変えてみるとどうでしょう。例えばパズルを解くように取り組んでみたら？
見方を変えることで、退屈だと感じていた部分を代わりにおこなってくれるような自動化されたプログラムを作ることができるかもしれません。それによってこの退屈な仕事が「問題解決のための楽しいプロジェクト」に変わります。タスクは新しいチャレンジとなり、仕事のスピードも速くなります。
つまり、創造性と好奇心を持って取り組めば、どんな仕事も退屈にはならないということです。
4. Ideas come in a hot shower (よいアイデアはシャワーを浴びているときに生まれる)
熱いシャワーを浴びている時や、ジョギングをしている時、突然アイデアが浮かんでくるなんて経験ありませんか？集中力を使う仕事から解放され、脳がリラックスしているときこそ、頭を悩ませている問題の解決策を発見することができるのです。
私はいつもアイデアを引き出すために、時間をかけるのではなく、仕事を完全に中断するようにしています。それが新しいアイデアを引き出すのに役立つと思っています。コンピュータが再起動するとスムーズに動くのと同じように、私たちの脳も休息や充電、空想にふけるような時間を与えられると、新鮮で革新的なアイデアを生み出すことができます。
5. Cut the middleman (間に入る人をつくらない)
複数の人を介して伝えられる情報は、ときに大きく歪んでしまうことがあります。
ソフトウェア開発においても、開発者と担当者との直接のやり取りでないと、プロジェクトの重要な要件などが十分に伝わらなかったり、省略されてしまったり、ときにはクライアントの要望どおりの製品にならない可能性が生じることも。また、このような間接的なコミュニケーションは、開発プロセスを遅らせる原因にもなり得ます。
しかし、“直接のやり取り”という簡単な仕掛けによって数か月かかるようなプロジェクトも効率よく捗るでしょう。
6. Most work is done by reducing specifications (大抵の仕事は“削減”によって捗る)
プロジェクトに取りかかる際、機能や要件を追加するよりも、不要なものを見極めて削減した方が効率的な場合が多くあります。プロジェクトに必要なものを絞り込むことで、混乱をなくし、作業量を減らし、生産性を向上させることができるのです。
このアプローチは、合理的なプロセス、集中力のあるチーム、そして最終的には、よりよい結果をもたらすことにつながります。
“削減すること”は依頼されたタスクをすべて実行することと同じかそれ以上に重要です。そのために交渉することを恐れてはいけません。
7. Solutions, not products (求められているのは製品ではなく解決策である)
開発依頼をいただく時、依頼者が本当に求めているのは“製品”でなく“解決策”なのですが、依頼者自身がそれに気づいていないことが多くあります。そのため依頼者から送られてくる仕様書には、製品のアイデアや詳細はあるのに、その目的が明確でないことも。
依頼者が本当に完璧な仕様書を用意してくることはありません。しかし仕様書の情報が不完全な場合でも、依頼者がなにを解決したいのか、その目的を理解することで、自分自身の設計判断でそのギャップを埋めることが可能になります。
そのため、私は開発依頼をいただいた時にはまず、その裏にある開発の目的と動機を理解するよう努めています。
この記事が気に入ったらサポートをしてみませんか？