北欧神話の世界で、村を作りながら新大陸を開拓する『NORTHGARD』というストラテジーゲーム*1を遊んだ時に、とても印象的な体験をしました。村人が増えて食料やお金も整って、いざ遠征するぞと準備を始めた時に、村人の士気が急に下がり始めたのです。食料やお金を用意したり、手当たり次第に介入しても士気は下げ止まらず、隣の村からの侵略を受けて占領されてしまいました。 何回かやり直してわかったことは、村がある程度大きくなった時には、家や酒場のような憩いの場がとても重要になるということでした。そして、憩いの場は、士気が下がり始めてから作り始めても効果はなく、村は崩壊します。とはいえ、最初に憩いの場を作ってしまうと限られた食料やお金がなくなり村は力を失います。 この例はいろいろと単純化していますが、遠征を「大胆さ」や「挑戦」、憩いの場を「思いやり」や「信頼」と置き換えることでチームでのソフトウェア開発に

私はソフトウェア開発を10年以上仕事として続けています。いつからか、どうすれば不確実性を減らして早く、要求通りのソフトウェアを開発できるかを考え始めていました。特に今年の4月に、フロントエンドチームのテックリードになってからは、フロントエンドチームが対峙する不確実性が少なくなるように考え、行動することに時間を使っています。 テックリードになってから6ヶ月経ち、反省することはたくさんありますが、プロジェクトのスケジュールに大きな遅延がなく、現時点で達成すべき水準の品質を満たしているので、ある程度の成果は出せていると自己評価しています。一方で、不確実性を下げるために考えたり行動することに少し飽きているというか、もうちょっとワクワクした気持ちで開発できないか悩んでいました。 そんな時に、庵野秀明監督が不確実性を保ったまま商業アニメーションを制作することに挑戦し、成し遂げた作品が『シン・エヴァンゲ

売上や、プロダクトの機能開発、自身の成長など、目標を掲げて達成に向けて行動することは、仕事をする上で大切な能力の一つです。しかしながら、目標を考えたり、考えた目標が重荷になって心身に悪い影響を与えることは少なくないと思います。 私も、昔、自分の目標を書いて上司に見せるのは、すごく苦手で辛い気持ちになる時間の一つでした。また、掲げた目標をどうしたら達成できるのかを考えられず、手当たり次第にやってみるけどあまり成果が出ないということもよくありました。 目標を立てたけど、毎朝目標のことを思うと辛いのであれば、まずは身近な信頼できる同僚や上司、友人に相談するのがいいと思います。もし、それが難しい時は、これから紹介する「目標を旅のように捉え、道のりや道標を旅のしおりのように綴って行動する」ことで少し気を紛らわしながら一歩踏み出せれば幸いです。 ガイドブック・地図を手に入れる 旅に必要な情報は、Goo

私のプロジェクトでは Architecture Decision Record (以降 ADR と記載) を導入しています。プロジェクトで ADR を使い始めてから 1 年以上が経過したので、実際に使ってみての感想と今現在の捉え方についてここに残します。 ADR とはなにかという説明や具体的な運用方法については検索したら十分に発見できると思うので、ここでは割愛し、私たちのチームでの経験にフォーカスします。 私たちのチームの状況 私たちのチームは、新しいプロジェクトの開始にあわせて 1 年ほど前に結成したチームです。 現在は 4 人くらいのチームですが、開発スピードを上げるためにフロントエンドとサーバーサイドでほぼチームが独立して動いているような時期もありました。 そのときは最大で 10 人以上が同じプロジェクトに関わっているような状態でした。 私たちのチームでの使い方 ADR の導入はチー

新しいプロジェクトに参加してローカル環境を作り始めると、何かとエラーに遭遇します。 また、設計や実装について開発者に相談したり、コードレビューを依頼することもありますね。 開発者が近くにいれば、（それなりに、程よいタイミングを見計らって）話しかけて、エラーの原因を調べてもらったり、設計方法をホワイトボードにスケッチしながら相談できますが、リモート開発ではそうはいきません。 リモート開発で成果を上げるためには、このブログのように何の装飾もインタラクティブ性もない文章で、自分の状況や相談したい事柄を正確に伝える必要があります。 とはいえ私は昔、「文章がわかりにくい」と毎日、毎日上司にフィードバックをもらうくらいには文章を書くのが下手くそでした。今もわかりやすい文章が書けている自信はありません。 それでも、これまでに何度か、議論が好転したり、プロジェクトが前に進むきっかけとなる文章を書けたことが

プロダクト開発に利用する技術の選択は、不確実性を伴う決断であることが多いです。 私はROUTE06で働く前は個人事業主でした。仕事の多くは、新規プロダクトのプロトタイプや初期バージョンの作成でした。デザインを含めてプロダクト開発をするのは私一人だったので、おおよその要件とスケジュール、予算が合意できたら、作り方は任せてもらっていました。 当時、私が技術を選択する方法は「開発速度や品質に非線形の変化を与える可能性があると感じたらまずは使ってみる」でした。アルファ版*1でもとりあえず使ってみて、上手くいったらそのまま本番稼働させているプロダクトもあります。 足りてない機能や不具合に直面することもありますが、パッチを書いたり開発元にプルリクエストを送りながらプロダクトの開発も進めていました。この進め方は、開発者が一人であれば成果を出せますが、チームで大きな成果を出すのは難しいでしょう。 現在、私