TypeScriptが仕事で使えるレベルになるためには、単に基本的な文法や構文を理解するだけでなく、実際のプロジェクトやチーム開発でどのように活用するか、スケーラビリティや保守性を考慮しながらコードを書く能力が求められます。この記事では、TypeScriptを実務で使うために必要な基本から、少し踏み込んだ中級レベルの知識を、コード例を交えながら丁寧に解説します。 TypeScriptとは TypeScriptは、JavaScriptのスーパーセットで、JavaScriptに静的な型を追加した言語です。静的型付けとは、変数や関数にあらかじめ「このデータはこの型でなければならない」というルールを設定することです。このルールに基づいて、開発者が予想しない動作やバグを防ぐ手助けをしてくれます。 JavaScript自体は非常に柔軟で、型に縛られない自由な書き方ができますが、それが逆に大きなバグを生
チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手
Dain 古今東西のスゴ本（すごい本）を探しまくり、読みまくる書評ブログ「わたしが知らないスゴ本は、きっとあなたが読んでいる」の中の人。自分のアンテナだけを頼りにした閉鎖的な読書から、本を介して人とつながるスタイルへの変化と発見を、ブログに書き続けて10年以上。書評家の傍ら、エンジニア・PMとしても活動している。 わたしが知らないスゴ本は、きっとあなたが読んでいる keyboard_arrow_down はじめに keyboard_arrow_down 独学のキモは「いかに継続するか」 keyboard_arrow_down 「顧客が本当に必要だったもの」をいつ知るか？ keyboard_arrow_down チームに笑顔を keyboard_arrow_down 質の高い課題を見極める keyboard_arrow_down 技術を哲学する keyboard_arrow_down おわり
はじめに 新社会人の皆さんもそうでない皆さんもこんにちは。 この記事を読む方々は将来に漠然とした不安を抱えている方かと思いますが、いかがでしょうか？わたしは抱えています。 このエントリーでは、そんな不安を払拭するための生存戦略を考えます。 考察に利用するデータは政府が公開している信用できるデータを利用していますが、わたしの個人的考察については必ずしも正しいとは限りませんがそのつもりで読んでいただければと思います。 まずは情報収集 戦略を考えるには現在の状況についての情報をできるだけ多く集める必要があります。情報が足りていない状況で何かを判断するのは大変危険です。例えば最近は見かけない広告で 『フルリモート週３日出社副業で８０万円収入』 といったものがありましたが、情報がなければ、それがどのような性質のものかを判断することもできないかと思います。 最近ではWebでググったり、ChatGPTに
はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章
「開発生産性」がホットな話題となっています。Four KeysやSPACEといったスタンダードと言える指標もできあがりつつあり、エンジニアリングの成果が直接ビジネスの成功に結びついている例も少なくありません。しかし、開発生産性の評価を行う際にはエンジニア側の視点だけでなくビジネス側の要求と、期待をもとに逆算することが不可欠になっていますが、エンジニア側の視点に閉じてしまう例がしばしば見受けられます。本連載では、開発生産性を起点にビジネスとエンジニアリングの課題に切り込み、ビジネス側からの逆算の意義や可視化の方法、エンジニアと事業側が抱く開発生産性に対する異なる視点とそのギャップの埋め方に焦点を当てていきます。 はじめに 本連載は、ソフトウェア開発における「開発生産性」にスポットを当てていきます。タイトルにもある通り開発生産性の多角的視点をテーマにしています。単なる生産性を上げる方法ではなく
Developers CAREER Boost 2023 登壇資料
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを市場投入したい。彼らに空き時間という無駄を作らせてしまうわけにはいかない。 しかし、そのような努力が、必ずしも良い結果につながるとは限りません。むしろ、開発者の稼働率を高めすぎたことが、リードタイムに悪影響を与えているかもしれないのです。そして言うまでもなく、アイデアの市場投入が延びれば延びるほど、ユーザーにとってもビジ
久しぶりに転職をした。 理由は「上司がクソ・年収も上がらない」という至極単純なもの。 自分は人手不足と言われているエンジニア業界でも、人が居ないと嘆かれている言語のエンジニアである。 正直に言って、今までは求人に乗っかればそれなりに内定を取れたので、そんな感じでいくだろうとタカをくくっていた。 ところが、今回の転職はめちゃくちゃ難航した。 受けたカジュアル面談は20社近く。 約半数の選考に進み、スキルチェックで落とされたのが3社、面接で落ちたのが2社、内定獲得したが辞退したところが3社。 打率3割は高いと思うかもしれないが、経験者なら誰でもOKのSESなので自慢にならないんだ。すまんな。 最終的には良さげなところを見つけ転職は幕を閉じたが、かけた期間はおよそ6ヶ月。 それをぼちぼち忙しい業務の合間と土日に行っていたので、もう身も心もすっかり摩耗した。 ようやく落ち着いて新しい環境にも慣れた
最近テックリードのロールを手放し、働き方がEMに近づいた。折に触れてEMになりたいと言ってきたが、だからと言って最初からうまくできるわけもなく、ここ1ヶ月くらいは悶々としながら過ごしている。特に今回困ったのは、自分の現在地がぼんやりしていて漠然と据わりが悪い感触に苛まれている点だ。もう少し課題や方向性を精緻にして、自信を持って前進できる環境をつくりたい。その一環としてマイスキルマップを作ってみたので紹介する。 マイスキルマップへ至る思考 自分が大事にしている心構えのひとつに「練習していないことはできない」というのがある。十を知るには十を聞き、繰り返し実践することでしか一人前にはなれないという、ごくごく当たり前のことだ。この心構えでひとつひとつ丁寧にやっていくのが、ここ5、6年の自分の強みだと思っている。 しかしこの心構えを維持するのは簡単ではない。何かができるようになると、自分の能力のイメ
GPT-4時代のエンジニアの生存戦略 ※ この記事の内容の一部はこちらのイベントでお話したことと重複します。 はじめに 2023年3月1日にOpenAI社よりChatGPTのAPIが公開されました。 さらに14日にはGPT-4が登場し、その翌々日にはMicrosoft 365 CopilotでGPT-4をOffice製品に搭載することが発表されるなど、AI領域で大きな変化が起きています。 変化の速度の速さと変化量の大きさにより、私自身も追いつくのが精一杯な状態です。 個人的には、iPhoneの登場時以上の衝撃を受けています。 人類の歴史上、過去3回AIブームがありました。Generative AIが4回目のブームになります。 そして、特に日本においては顕著なのですが、AIへの過度な期待とそれへの失望の繰り返しがここ数十年にわたって繰り返されてきました。 直近だと数年前のDeep Learn
昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな
先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を
ソフトウェア開発で、より早くより多く価値を届けたいと考えた時、エンジニアの増員は有力な選択肢です。もちろん、人月の神話などで語られるように、人を増やしただけ線形に生産力が向上するというシンプルな世界ではありません。それでも多くの現場でエンジニアの増員が行われます。自分のチームでも、とりあえずエンジニアを増員すれば、いくつかの問題が解決してくれるような気もします。雑談ベースでメンターなどにこういう話を出してみるわけですが、改めて「なぜエンジニアを増員したいのか」と問われると、これが意外と広がりのある議論であることがわかってきました。本記事では、エンジニアを増員するロジックについて、自分が思考を広げられた範囲で書いてみます。 作り切りの場合は明快 まずエンジニア増員のロジックを素朴に立てられるのは作り切りの場合です。ある程度の規模のものを丸々作り切らないといけないケースです。締め切りがあること
ソフトウェア開発に関わる人々の新たなきっかけを生み出す場となることを目指す「Qiita Conference」。ここで「働きやすく、成長し続けられるエンジニア組織を目指して 」をテーマに株式会社カオナビの松下氏が登壇。ここからは、CTOに就任して行った取り組みと、CTO室の設立について話します。前回はこちらから。 CTOに就任して行った3つの組織的な取り組み 松下雅和氏：ここからはCTOとして組織全体の話をしようと思います。当時「ニューノーマル時代のカオナビへ」ということで、オフィスの移転を行っています。カオナビでは、働き方を選択するのは企業ではなく、社員がするべきだと考えています。 出社は義務ではなく、自由に出社しても自宅でもいい。出社するなら居心地のいい環境を提供するのが企業の義務だと考えているので、すごくいい環境のオフィスを提供してもらった記憶があります。 働き方では、ハイブリッド勤
同社は2017年から新卒エンジニア向けの研修資料を公開しており、外部からのフィードバックを基に毎年内容を変更している。例えば21年版ではAWSの入門研修資料を公開。22年版はNext.jsの資料を新たに追加した。過去に公開した資料は今後も閲覧可能という。 関連記事 リクルート、新人エンジニア向け社内研修資料を公開 AWS入門やマネジメント手法など20講座以上 リクルートが、新人エンジニア向けの社内研修資料を無償公開した。Webブラウザの仕組みやAWS入門、トヨタ生産方式など20講座以上の資料を公開している。 「動画で助かる」「IT基礎知識が一通り学べる」──各社が公開した新人エンジニア向けの研修資料が話題に 人気資料まとめ IT企業が社内の新人エンジニアに向けた研修資料を無償公開して話題になっている。学べる内容はIT業界の文化からゲームエンジン「Unity」を使ったゲーム開発までさまざまだ
エンジニアとして今の自分を形成した本5冊 エンジニアとして働くにあたって自分が大きく影響を受けた本を考えてみた。もちろん他にもあるが、今回は以下の5冊に絞って紹介する。 Clean Coder（クリーンコーダー） Team Geek Clean Architecture（クリーンアーキテクチャ） テスト駆動開発 LeanとDevOpsの科学 この記事の対象者としては、独学でプログラムを書き始めた人やエンジニアスクールを卒業したばかりの方というよりは、実務経験を1~3年くらい積んでいるけど次に何を学べば良いかわからず、自分でイマイチ伸び悩んでいると感じている人を主に想定している（かつての自分がそうだった）。 特にチーム開発、オブジェクト指向言語でのコーディング、テストコードを書いた経験がある人が読んで、本に書いてあることを実践すると自分の成長を実感するだろう。 「Clean Coder」、「
はじめに こんにちは、freee 競技プログラミング部副部長の辻です。普段は認証認可周りの開発をしています。 好きなアルゴリズムは Rabin-Karp Algorithm、好きなデータ構造は Union-Find、好きな定理は Spectral 定理です。 先日 freee 初の社内プログラミングコンテストを開催しました! 今回は、開催までの苦難やコンテスト当日の様子をご紹介したいと思います。 最後に重大告知もあるのでぜひ見てください！ 社内プログラミングコンテスト開催するぞ！ 日経さんの社内プログラミングコンテスト(社内プロコン)の記事を読み、リモート下になって減っていたチーム外の人との交流のために社内プロコンを開催するのは良さそう、ついでに部員募集という意味でもいい宣伝になりそうという思いから社内プロコンを開催することになりました。 また部員から「社内プロコンを開催するなら free
こんにちは。Forkwell の赤川です。 2022年5月、あなたは上位何％？ITエンジニアの年収分布まとめ【データベース完全公開】を公開したところ、ITmedia でも一部が取り上げられ、累計4,000RT以上の反響がありました。特に「エンジニアは自社内で”昇給を頑張る”よりも転職したほうが昇給できるバグがある」という一言に注目が集まりました。そこで今回は「このバグの正体」を掘り下げます。 この記事では、所属する企業タイプによって給与がどの程度変化するのかを報告し、さらに読者の手元で年収シミュレーションが可能なグラフを公開します。また、前回の記事では説明しきれなかった「どのようなアプローチが給与アップに効くのか？」という疑問に取り組みます。これについて結論を先にお伝えすると、自身の役割を変化させるよりも、給与払いの良い企業群に属することが有効、という身も蓋もない話をしています。 データは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
