<code>git add -p</code>コマンドが便利なので共有します。 <code>git add</code>に<code>-p</code>のオプションをつけることで、このように対話形式でどんな変更が行われたか表示され、変更箇所ごとに「変更をステージングするか」を設定できます。 実装時に一時的にコメントアウト箇所した箇所を見つけられたりなど便利なので、ターミナル派の方は是非使ってみてください。

git addの-pオプションが便利

自分は最近、担当する案件が全て人月の準委任契約になりました。 準委任契約は請負契約に比べて、スケジュールや仕事の進め方における自由度が高いとされています。 しかし、自由度が高いほどその管理が難しくなることを忘れてはいけません。 単に1ヶ月間で決められた稼働時間をこなすことを目標にするだけでは、うまくいかない場合が多いです。 一般的にスケジュールが長いほど、タスクの粒度が大きいほど、マネジメントの難易度が上がります。 そのため、自分は与えられた1ヶ月のスケジュールを4つに分割して考えるようにしています。 単純に考えると、1週間ごとに全体の1/4のタスクや稼働時間をこなしていない場合、作業が遅れているということを意味します。 期間を分割する前は1ヶ月という長期間の計画や進捗管理という難しいマネジメントスキルが必要でした。 しかし分割することで、1週間という短い期間内でいくつかのタスクをこなすだけでよくなります。 自由度が高い環境でこそ、自ら制約を設けることでマネジメントの難易度を下げることができます。 そして、その手段の1つがマイルストーンです。

準委任契約におけるマイルストーンの重要性

サービスにおいてユーザーからエラーの問い合わせが発生した場合、まずはURLを送ってもらうことがあります。 URLを確認することで、ユーザーがどのような操作をしていたかを特定しやすくなり、エラー解決の助けになります。 例えば、データの作成や更新を行うフォームの場合、UIは同じでもロジックが異なることがあります。 ReactなどのUIライブラリを使うことで簡単にコンポーネントの切り替えができるため、これらを一つのページとして実装することができます。 しかし、データの作成と更新が同一ページとなるため、仮にエラーが発生しユーザーからURLが送られてきたとしても、データの作成にともなうエラーなのか、データの更新にともなうエラーなのかがわかりません。 データの作成を<code>/create-data</code>、データの更新を<code>/update-data/:dataId</code>などとしページを分割することで、エラー箇所や原因の特定がしやすくなります。 URLの決定に関しては実装者が裁量を持っているケースもあるので、サービスにおけるURLの重要性を理解しておきましょう。

サービスにおけるURLの重要性

普段Webサイトの実装をする際にデザインが本当に素敵だなと感じる時があります。 最初にデザインデータを見た時には気づかなかった細やかな配慮が所々に散りばめられていることにコーディング中に気づいたりもします。 こういったデザイナーさんのプロダクトに対するこだわりや情熱を感じることができるのは、とても刺激になります。 また、実装側としても「完成度にこだわらなければならない」責任感と「実装側からよりジャンプアップさせたい」という気持ち生まれます。 日常の業務から刺激をもらえるのはとても嬉しいです！

実装者から見たデザイン

FLATに入社して1年半が経つ。 先日、FLATに入社してから半年経ったタイミングで書いた日報を発見したため、 このタイミングで公開しようと思う。 <h2 id="h1dcd2aa599">FLATに入社して半年が経った</h2>FLATに入社して半年が経った。 私はFLATが３社目だが、Web制作会社や少数精鋭の環境で働くことはFLATが初めてである。 本日の日報では、この半年間FLATで働いていて感じたことを書いてみようと思う。 <h3 id="h2a6e04ae83">1.誰もが主体的である</h3>FLATは代表1人、ディレクター１人、エンジニア３人と少数精鋭の組織である。 また、組織自体が若く、制作フローやルールはあるがまだ固まっていない部分も多い。 だからこそ柔軟な部分が多い。それは私がFLATに入社して「いいな」と感じたポイントでもある。 業務を進行する上で自分たちで考えたり、その都度ルールを作っていくことが多々あるのだが、 だからこそ、誰もが受け身にならず「働きやすい環境、よりよい制作フローを自分たちで作っていく」という意識が組織全体で根付いているのだと思う。 また、「こうしたい」という声の上げやすさも、主体的に働くうえで重要だと感じる。 FLATでは「こうしたい」という声をあげやすい。 そして、1人の「こうしたい」と思ったことに対して、全員が耳を傾けてくれるし、誰もが否定をしない。 そうした環境が心地よいと感じるし、だからこそ「主体的に組織を作り上げていく」という意識に向かいやすいのだと思う。 <h3 id="ha758cb3de7">2.技術向上意欲の高さ</h3>FLATのエンジニアは技術向上の意欲が高いと感じる。 毎朝の1分間スピーチでは技術関連の話題が多いのだが、共有した技術はすぐに業務で活用しようとしてくれる。 技術の移り変わりが激しいこの業界では、技術の共有だけでなく、 共有された技術に対するポジティブさはかなり重要なのではないかと思う。 共有して終わりではなく、ではどう活用していくか、どう社内ルールに組み込むかなど。 こうした技術に対する前向きな考え方は、私も良い影響を受けている。 また、興味の範囲がスタッフそれぞれで異なるのもFLATの良さだと思う。 そして歴も関係なく、みんながお互いの持つ個や得意分野に対して興味や理解を持ってくれていると感じる。 <h3 id="h39a9d87018">3.一人にならない環境</h3>サトウさんがよく「ひとりにはさせないので」とおっしゃっているが、 「ひとりにならない環境作り」が徹底されている印象がある。 毎朝の進捗会ではお互いの業務の作業進行を報告し合い、 詰まってる業務がないか・相談事がないかを確認をする時間が設けられている。 これにより悩みを抱える時間が少なかったり、ひとりぼっちになり道が逸れてしまうことも少ない。 助け合いの意識が根付いており、「悩んでいることないですか」「大丈夫ですか」という声かけもみんな自然にできている。 新人スタッフの私にとって、この「ひとりにならない環境」「何かあったときに助け合える人がいる環境」はとても心強く、有難い環境である。 <h2 id="hc6285e42c5">FLATに入社して1年半を迎えて</h2>以上が半年経過したタイミングで感じたことである。 現在、FLATに入社して1年半が経った。 今のFLATは柔軟さはそのまま、社内制度や制作フローは確立され会社全体が大きく成長している。 社員数も増え、会社の移転も行なった。だが、当時感じていたFLATの良さは今も変わらない。 今後も私自身がFLATの一員として、エンジニアが成長し続けられる環境作りに貢献していけたら良いと思う。

FLATに入社して半年が経った

マネジメント

業務改善

仕事の気づき

テクノロジー

更新情報

先日の出社日、朝会前にほうじ茶を淹れるとき、サトウさんが「（ほうじ茶の）色がよく見えるから透明のグラスがいいね」と言っていた。 「お茶の色を見る」ために透明なグラスにお茶を入れるという発想が私にはなかったので、私にとって新しい発見だった。 ちょっとした朝の出来事だけど、例えばリモートだったらこうした発見はできなかったと思うし、透明なグラスに入れられたお茶に対して「綺麗な色だな」と思うこともなかったと思う。 出社日というのは、スタッフ同士のコミュニケーションがとりやすく、業務上スムーズに進行できるのはもちろん、誰かと空間を共有することで、こうした意図しないコミュニケーションの発生や、ふとしたときに聞こえるスタッフ同士の会話から自分では気づけないことに気づかせてくれる、そういうチャンスがある日なのだと思う。 また、そうして得られる刺激や発見が、新しい可能性へと繋がるのだと思う。 （また、意図しないコミュニケーションがあるからこそ、いい具合に集中モードと緩和モードを切り替えることができるのだと思う。） 本日はリモートで、意図しないコミュニケーションもスタッフ同士の会話も聞こえない日だからこそ、先日のことを思い返して出社日の楽しみ方に気づけた日だった。

出社日＝空間を共有するということ

俯瞰的に見る、第三者目線を持つ。これを常に行いたい。 批判的思考＝クリティカルシンキング判断を出した後に、そのまま突っ切るのでなく 主観から切り離して、他の誰かだったら、例えばクライアントの立場から見たらどうか。 例えばエンジニアの立場からみたらどうか。といったように、立場をシフトしてその判断を見るとどうかという思考フェーズを設けたい。そうすると判断の内容が変わる可能性がある！またクリティカルシンキングを使うことで、見えなかった、もしくは考えつかなかった、 考えの余白に気づいて新たな提案が生まれる可能性も秘めている。 自分の考えもそうであるし、誰か他者からの考えのシェアがあった時にも 自分の主観＋色んな立場の目線で物事やアイデアを見る目を養えば、 日々がクリエイティングになりそうだと思う。最近は論理的思考や批判的思考などを研究していますが、 いままでの自分に足りなかった部分なので、 ロジカルに本質的に、物事を捉えていきたい。

第三者目線

<h2 id="h8a175a9b0e">前提</h2>コードレビューの修正が一つにまとまった「レビュー対応」という名のコミットを見たことがある方は多いのではないでしょうか。 また、機能追加（feat）なのか、修正（fix）なのかでコミットの粒度が変わってしまう人もよく見かけます。 これは特にレビュワー経験の少ない初級エンジニアにありがちで、レビュワーに不親切なコミットの条件を理解できていないことが原因だと思います。 <h2 id="ha997db750b">どのように解決するか</h2>上記の例では、どの差分がどの修正に対応するものなのかわかりづらいという問題がありますが、一度レビュワーを経験することで、アンチパターンから避けるべき行動を学習することができます。 FLATでは入社後初期からコードレビューを経験してもらうために、相互レビューという制度を設けています。 ポジションやスキルに限らず、プロジェクトメンバー同士で相互にコードレビューをしてもらうことで、チーム全体でコミットやプルリクの粒度に配慮する習慣が身に付いています。 コミットの粒度はレビュー効率に大きな影響を与えます。レビュワーの経験が少ない方はぜひ積極的に手を挙げてみると良いでしょう。

レビュワーに不親切なコミットの条件を理解する

複数の要件を一つのタスクにまとめてしまうことは危険です。 例えば、実装仕様に対するいくつかの疑問点を解消するべく、一つの確認タスクを起票し、まとめて質問したとしましょう。 即座に回答できる質問もあれば、以下の理由から即座に回答できないこともあります。<ul><li>実装仕様の一部がまだ決まっていない</li><li>回答するために調査が必要</li><li>回答者ではなく他の誰かが回答する必要がある</li></ul> この場合、処理中（回答待ち）と完了（回答済み）のステータスが一つのタスク内で混在し、特にステータス管理に関して問題が生じます。<ul><li>一部の回答待ちでタスクを完了にできず、第三者がタスクの進捗状況を把握しにくい</li><li>タスクのスレッド欄が複雑になり、あとから情報を参照しにくい</li></ul> 上記の例では、要件ごとに個別のタスクを起票することが望ましいです。あるいは要件同士に関連性がある場合、サブタスク機能を活用すると良いでしょう。 またタスクを受け取る立場においても、まずはタスクの粒度が適切かどうかを判断する習慣を身につけておきましょう。 必要に応じて積極的にサブタスクに分割することで、ステータス管理の難易度が下がり、コミュニケーションもスムーズになるはずです。

カテゴリー

人気記事

git addの-pオプションが便利

準委任契約におけるマイルストーンの重要性

サービスにおけるURLの重要性

実装者から見たデザイン

FLATに入社して半年が経った

フロントエンド専門制作会社FLATスタッフの業務日報です。エンジニアが気になること、仕事の気づきを共有します。

出社日＝空間を共有するということ

準委任契約におけるマイルストーンの重要性

サービスにおけるURLの重要性

実装者から見たデザイン

git addの-pオプションが便利

第三者目線

FLATに入社して半年が経った

レビュワーに不親切なコミットの条件を理解する

改めて1タスク1要件の重要性

git addの-pオプションが便利

準委任契約におけるマイルストーンの重要性

サービスにおけるURLの重要性

実装者から見たデザイン

FLATに入社して半年が経った