Reactを使ってプロダクト開発している開発者だけでなく、マネージャにも読んでほしい「Fluent React」 - ROUTE06 Tech Blog
チームでReactを使って開発していると、コードレビューをする際に、「この書き方はしない方がいいが、それを説明するには800文字くらい必要。図も描きたい。でもそれらを準備する時間はない。」ということが度々ありました。 また、フレームワークやライブラリの技術選定をする際、マネージャに「どうして技術選定が必要なのか」を説明する必要がありました。ROUTE06のマネージャはエンジニアリングへの造詣が深い方が多いので、対立構造になることはありませんが、説明するためには1000文字くらい必要で、やはり図も描きたい。時間はない。と同じ気持ちになることがありました。 参考情報として紹介できる情報がないか探してみると、「とりあえずこうすればOK」というベストプラクティスについては検索エンジンやSNSですぐに見つかります。ただ、どうしてその方法がベストプラクティスなのか、仕組みや原理を説明している情報は少な
思いやりから始めたリーダーシップ、その先へ - ROUTE06 Tech Blog
北欧神話の世界で、村を作りながら新大陸を開拓する『NORTHGARD』というストラテジーゲーム*1を遊んだ時に、とても印象的な体験をしました。村人が増えて食料やお金も整って、いざ遠征するぞと準備を始めた時に、村人の士気が急に下がり始めたのです。食料やお金を用意したり、手当たり次第に介入しても士気は下げ止まらず、隣の村からの侵略を受けて占領されてしまいました。 何回かやり直してわかったことは、村がある程度大きくなった時には、家や酒場のような憩いの場がとても重要になるということでした。そして、憩いの場は、士気が下がり始めてから作り始めても効果はなく、村は崩壊します。とはいえ、最初に憩いの場を作ってしまうと限られた食料やお金がなくなり村は力を失います。 この例はいろいろと単純化していますが、遠征を「大胆さ」や「挑戦」、憩いの場を「思いやり」や「信頼」と置き換えることでチームでのソフトウェア開発に
不確実性を保ちながらソフトウェア開発を進める呪文「てみて」 - ROUTE06 Tech Blog
私はソフトウェア開発を10年以上仕事として続けています。いつからか、どうすれば不確実性を減らして早く、要求通りのソフトウェアを開発できるかを考え始めていました。特に今年の4月に、フロントエンドチームのテックリードになってからは、フロントエンドチームが対峙する不確実性が少なくなるように考え、行動することに時間を使っています。 テックリードになってから6ヶ月経ち、反省することはたくさんありますが、プロジェクトのスケジュールに大きな遅延がなく、現時点で達成すべき水準の品質を満たしているので、ある程度の成果は出せていると自己評価しています。一方で、不確実性を下げるために考えたり行動することに少し飽きているというか、もうちょっとワクワクした気持ちで開発できないか悩んでいました。 そんな時に、庵野秀明監督が不確実性を保ったまま商業アニメーションを制作することに挑戦し、成し遂げた作品が『シン・エヴァンゲ
リモート開発を助ける「思いやりのある文章」の書き方 - ROUTE06 Tech Blog
新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが
チーム開発における技術選定の進め方 - ROUTE06 Tech Blog
プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私
GitHubの通知を制するものは仕事を制す - ROUTE06 Tech Blog
ROUTE06 Software Engineerの@yoshida-m-3です。 GitHubからの通知が溢れ返る😂 GitHubはIssue、Pull Request、Projects、Actions、Discussionなど様々な機能があるため、通知の件数も増えていきます。 大量の通知をコントロールして効率良くチェックできるようにしましょう！ 不要な通知は受け取らないようにする🚫 そもそも本当に全て通知を受け取る必要はあるでしょうか？ クリック1つで情報へアクセス出来るので見てしまいますが、人一人が扱える情報量にも限度があります。 勇気を持ってWatched repositoriesから不要なRepositoryのWatchを外して通知自体を減らしてしまいましょう。 また、用件がある場合はMentionされるのでWatchして居ないRepositoryでも通知は届きます。 通知を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
