CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
これらの数値は、数多くの開発チームを分析しクラスタリングした上で、ハイパフォーマーの特徴として抽出されたものです。ここでの重要な問いとして、「Four Keysといった数値を高めたら、自分たちが目指す強い開発組織の状態になるのか?」というと答えは、NOです。 特に開発生産性の可視化は、管理や監視のために測定するのはアンチパターンで自分たちのケイパビリティー向上のために使わなければ、逆効果になるケースもあります。よくあるケースとしては、開発生産性の指標をハックして無理やり数値をよく見せる行為です。自分たちのために計測していれば極端にハックする意味がないことは明白ですが、開発生産性を存在価値のために数値を提供すると、ある事象が起きやすいので気をつけたいところです。 こういった事象を「グッドハートの法則」と言います。または「キャンベルの法則」という類似の法則もあります。どちらの法則も、組織や制度
進化を続ける生成AIの最前線、ChatGPT。既に多くの業界で注目される中、まだこの革命的な技術を手にしていないあなたへ。本連載では、具体的なコードを交えながら、ChatGPT APIの可能性とその活用法を徹底解説します。今回は、チャットBot以外の様々な利用目的で組み込むノウハウについて紹介します。 はじめに 前々回、前回の記事ではChatGPTの最もオーソドックスな使い方として、ユーザーとの会話を主軸とするチャットBotの開発に焦点を当てて解説してきました。しかしながら、ChatGPTの活用方法について未だイメージを掴めていない方々の中には、ChatGPTの活用方法で迷っているというよりも、チャットというインターフェースを取り入れるイメージが沸かないという方も少なくないのではないでしょうか。もしもこのケースに当てはまる場合は、「ChatGPTは会話をするもの」という先入観を捨て、システ
「保険業界のアップデート」を目指して2017年に設立したhokanは、保険代理店向けシステムを開発している。2021年に同社へジョインしCREチームを率いてきた小倉隆宏氏が若手エンジニアに向けて、同氏が若手時代に経験してきたこと、学んだことを若手エンジニアに向けてつまびらかに語る。 不安と焦りのなか、資格取得に迷走した20代 若手に向けて、自身の経験を語ってくれるのは株式会社hokan 開発責任者 小倉隆宏氏。2021年2月に入社、CRE(顧客信頼性エンジニアリング)を立ち上げ、30社ほどの顧客企業の導入支援に従事してきた。2023年5月より開発責任者を担当している。小倉氏にとってhokanは4社目。1社目に13年、2社目に6年勤めたため「社会人としての人格を形成したのは最初の2社」と話す。 小倉氏のこれまでのキャリア 小倉氏が就職したのは2000年。バブル崩壊後の不景気の影響で「就職氷河
前回は「開発生産性」という言葉の広さから、きちんと組織のレイヤーを構造化しながら用語を分けてオーバーラップする部分を繋げていきましょうという話を紹介しました。第2回となる今回は、開発チームに焦点を当てていきます。ソフトウェア開発の現場では、Four Keysを中心とした「開発生産性のメトリクスはどうあるべきか」 や「認知負荷を下げるエコシステムはどう設計するべきか」といった議論が頻繁に行われています。こうしたソフトウェアアーキテクチャから生まれる開発生産性に関する議論はとても重要であり効果が高いものです。本記事ではそうした議論とは少し離れ、「エンジニアの継続的なフロー状態が生む開発生産性への重要度と、組織が開発チームに対する不安の定量化によるフロー状態の軽視がなぜ起こるのか」という観点で解説します。 以前の記事 【第1回】「開発生産性」はエンジニア"だけ"のモノではなくなった?──開発組織
本書は2018年に発売された『ハッキング・ラボのつくりかた』を全面刷新し、1,200ページの厚さで読者にハッキング体験をもたらす1冊です。 ハッキングの実験室として安全な仮想環境を構築し、サーバーへの攻撃を体験。サーバー侵入の様々な手口や管理者権限を奪う方法などを学ぶことで、ハッキングの技術、WindowsやLinuxへの攻撃手法に加え、セキュリティやネットワークの知識も身につきます。 コンピューターを扱う人なら誰でも一度は「ハッキングをしてみたい」「ハッカーになってみたい」と思ったことがあるのではないでしょうか。実際にはできなくても、仮想環境ならやりたい放題でハッキングができますので、ぜひこの機会に試してみてください。 目次 第1部 基礎編 第1章 ハッキング・ラボでできること 1-1 ハッキング・ラボとは 1-2 本書を読むにあたって 1-3 前作『ハッキング・ラボのつくりかた』との違
本調査は6月に、GitLabのソーシャルメディアチャンネルおよびメーリングリストを通じて行われ、世界中のさまざまな業種・規模の企業に所属する開発・IT運用・セキュリティ部門の従業員およびリーダー1001人から有効回答を得ている。 調査結果によると、回答者の90%が「ソフトウェア開発にAIを活用中または活用予定である」と回答した。また、83%が「他社に後れを取らないように自社のソフトウェア開発プロセスへのAI実装が不可欠」と回答したのに対し、79%が「個人情報や知的財産にアクセスするAIツールに懸念」を示した。加えて40%が、「AIはすでにセキュリティ面で大きなメリットをもたらしている」と答えた一方、そのうちセキュリティ担当者の40%は「AIを活用したコード生成によってワークロードが増大すること」を懸念として挙げた。 AI導入の課題に関する項目では、95%の技術系上級幹部が「AIツールの選定
はじめに Microsoftの提供するVisual Studio Code(VSCode)は、2015年の最初のリリースから、今では開発用エディタの定番の座を占めるまでになりました。これには、無償で使えることも大きいですが、何よりエディタとしての使いやすさ、そしてさまざまな拡張機能によっていくらでも使い勝手を向上させたり、利用の領域を拡げられたりすることも大きいでしょう。本連載では、このVSCodeにフォーカスし、基本的な使い方から拡張機能の活用、そして本格的な開発現場での利用を想定した高度な機能までを紹介していくことで、読者がVSCodeマスターになるお手伝いをします。 対象読者 テキストエディタメインで開発してきた方 Visual Studioより軽い環境が欲しいと考えている方 Visual Sudio Codeをもっと使いこなしたい方 必要な環境 本記事の内容は、以下の環境で動作を確
今回の改良で、ユーザーの問いに対するGPT-3.5 Turboの回答を、ユーザーが望むものに近づけることができる。例えば、企業内で独自のノウハウを蓄積している業務について、GPT-3.5 Turboがより正確な回答を出力できるようにしたり、回答文のトーンをより丁寧なものにするなどの調整が可能だ。 微調整するには、ユーザーが訓練データを用意してアップロードし、GPT-3.5 Turboに訓練させる必要がある。大規模言語モデルの訓練データについては、プライバシーやセキュリティの問題を指摘する声が挙がっているが、OpenAIは今回の機能でユーザーが投入する訓練データはユーザーのものであり、OpenAIがほかの大規模言語モデルの訓練で使用することはないとしている。 微調整の訓練には、1000トークン当たり0.008米ドルの費用がかかる。そして微調整済みのGPT-3.5 Turboの利用料金は、入力
パーソルホールディングスは、全国の15~69歳の、本業または副業で働いている男女を対象に実施した、ITエンジニアのはたらく実態に関する調査の結果を、調査レポートとして8月14日に公開した。同調査は、3月10日~17日の期間に行われ、調査レポートには職種分類が「IT/通信系エンジニア」である3834名に絞り込んだ結果を掲載している。 調査結果によれば、ITエンジニアの出社頻度は週5日出社が41.3%を占める一方、「ほぼ出社しない/ほぼリモートワーク」がそれに続いており、リモートか週5出社かの二極化がみられた。 ITエンジニアの理想とするはたらき方としては、「テレワークができる」(41.3%)がもっとも多く、以下「ワーク・ライフ・バランス」「安定した収入」が続いている。 評価制度に対して求めることとしては、「評価項目がわかりやすく周知されている」「公平性がある・えこひいきがない」「成果主義」が
米Stack Overflowは、すでに発表している生成AIとStack Overflowのパブリックプラットフォーム、Stack Overflow for Teamsの統合や、コミュニティからの質問と回答を直接提供するIDE統合などを実行する、「OverflowAI」を7月27日(現地時間)に発表した。 同社は、ユーザーが生成AIによる会話形式の検索を使用することで、質問に対してより信頼性が高く、より正確な解決策を得られるようにすることを目標としており、OverflowAIによって同社の提供するQ&Aサービス「Stack Overflow」における5800万件超の質問と回答から、よりパーソナライズされた結果を得られるよう、ナレッジベースをクエリする機能を通じて生成AIによる回答の提供を目指していく。 あわせて、Stack Overflow for Teamsの検索機能も強化し、ユーザーは
OpenLM Researchは、米Meta AIが開発した大規模言語モデル「LLaMA(Large Language Model Meta AI)」のライセンスに基づく、オープンソースの大規模言語モデルOpenLLaMAのパブリックプレビューとなる「OpenLLaMA 7B」の、3000億トークンでトレーニングされたチェックポイントを、5月3日(現地時間)にリリースした。 今回リリースされた300Bチェックポイントは、既存の実装と広く互換性を持たせることを目的に、BOSトークンの影響を受けにくくしている。 トレーニングは、1.2兆を超えるトークンを含むLLaMAトレーニングデータセットを再現した、TogetherによるRedPajamaデータセットによって行われており、モデルアーキテクチャ、コンテキスト長、トレーニングステップ、学習率スケジュール、オプティマイザなど、元のLLaMAペーパ
対象読者 Gitをより深く理解したい方 Gitの自作に興味がある方 Gitの内部構造を学ぶ意義 Gitの使い方を知っている人でも、それぞれのサブコマンドが実際どういった挙動をしているか、ましてや内部構造がどうなっているかを学んだことがある人は少ないかもしれません。というのも、Gitが内部を知らなくとも十分使える優秀なツールになっているからだと思います。 しかし、Gitの内部実装を知ることで、コマンドの挙動を正確に理解できるだけでなく、Gitを使っていて何らかの問題が起きたときにも、自分で対処できるようになります。そうしたGitの地力を鍛えるために、内部構造の把握は重要な要素になってきます。 また、今回の内容を学べば、Gitの大枠を実装することもできてしまうので、興味がある方はぜひ挑戦してみてください。 Gitについての誤解 それでは、まずGitについて多くの人が誤解しているであろう点を挙げ
リモートワークが一般的になり、一方でさまざまな課題が生じてきています。特にコミュニケーションの課題などは多くの人に関係するため大きな関心を集め、急速にさまざまなソリューションが出てきています。一方で開発業務に目を向けると、少しずつ進みつつあるものの、デファクトと言えるほどのものもなく、情報もあまり共有されていないように思います。そこで、筆者がいろいろと試行錯誤をしながら行った施策について紹介したいと思います。 はじめに 今の開発現場ではDockerなどを使った仮想化コンテナを使うことが一般的になっています。そのため、ソースリポジトリ(Gitなど)と仮想化コンテナを使えば、各開発者が開発環境を構築し、業務を進められます。つまり、オフィスのPCを自宅に持ち帰るか、もしくは自宅のPC上で開発環境を構築してしまえばそれで問題は解決するのです。 しかし、どちらの方法もセキュリティや情報管理の観点から
IT業界のプロジェクトを成功に導くためのノウハウを網羅的に解説した書籍『プロジェクトマネジメントの基本が全部わかる本』(翔泳社)。著者でパラダイスウェアの代表取締役である橋本将功さんは、プロジェクトマネージャーが直面する課題として大きく3つ、「現場で使える知識体系がない」「無茶ぶりされる」「スキルの属人化」を挙げています。これらの課題を解決するために何が必要なのでしょうか。本書から、プロジェクトマネージャーが持つべきスキルセットと、プロジェクトの成功と失敗をどう定義すればよいのかを紹介します。 本記事は『プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで』の「序章 プロジェクトマネジメントのスキルの全体像」と「第1章 プロジェクトとはなにか─基本的な知識と考え方をおさえよう」から一部を抜粋したものです。掲載
昨今、開発者の中で人気が増しているプログラミング言語「Rust」。気になっている開発者は多いものの、業務での採用はまだこれからと考えている人も多いだろう。そんな中、ゆめみではRustに力を入れ、自社内外の案件でRustの活用を進めている。なぜ、ゆめみではRustの習熟を推奨するのか。その理由とともに、Rustの特徴、実際に使って見た感想、さらにはRustの今後の展望などについて、ゆめみでRustの推進に関わっているチャレンジCTO(最高技術責任者)の池口直希氏、エンジニア兼チャレンジ取締役のスミス 祐一郎 ルーク氏、サーバサイドエンジニアの舩戸隆氏に話を聞いた。 ゆめみでRust活用を牽引するエンジニア 2006年にグレイドン・ホアレ氏という個人プロジェクトとして開発されたプログラミング言語「Rust」。2009年にMozillaが開発に参入してプロジェクト化。その後、仕様変更を繰り返し、
いよいよ今回が最終回です。これまではKubernetesのしくみや、使い方などを説明してきました。最終回では「いざKubernetesを本番で運用してみよう!」ということで、「障害」を主題とした内容となっています。Kubernetesの特徴の一つは障害に強いことで、例えば自動復旧などさまざまな仕組みが用意されています。それらの仕組みを知ったうえで、それでも起こり得る障害に備えるためにアプリケーション開発者はどのような準備をすればよいか具体的に説明したいと思います。 Kubernetesと障害調査 どんなに手を尽くしても本番で運用をしていれば障害はつきものです。ここでは障害が起きることを前提として、障害調査のための準備や障害調査の仕方について説明します。 障害調査のための準備 これまで物理/仮想マシンでアプリケーションを立ち上げて運用した経験のある方は、コンテナを利用した障害調査がこれまでと
仕様に沿ったプログラミングができるようになったエンジニアが設計に取り組むために、その全体像と具体的な手順を解説した技術書が『はじめての設計をやり抜くための本 第2版』(翔泳社)です。本書では大きく外部設計と内部設計、さらにアーキテクチャについて取り上げ、システムをゼロから作り上げるためのノウハウを解説。今回は「第2章 設計の目的」から、そもそもエンジニアは何を設計するのかを説明したパートを紹介します。 設計ができるようになるには、設計とは何かを知る必要があります。世の中には、設計に関する書籍がたくさん出回っています。最近では、オブジェクト指向設計に関するものが多いようです。書店に行くと、「オブジェクト指向」「UML」「ユースケース」といった文字が目に留まります。他にも、「アーキテクチャ」「デザインパターン」「フレームワーク」などもよく見かけるでしょう。これから設計を学ぶ皆さんは、学ぶことが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く