プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。3回目は、「Second System Syndrome」について。前回はこちら。 退屈は最大の敵 まつもとゆきひろ氏：次はPerlですね。ここまでですでに4回ぐらいPerlの話題が出てきています。なぜかというと、私はPerlが大好きなんですね。実は、Perlが大好きなんですが、Perlのプログラミングは大好きじゃないんですね。あと、Perlのソースコードも大好きじゃないんですね

プログラミング言語「Ruby」の国内最大のビジネスカンファレンス「RubyWorld Conference」。Rubyの先進的な利用事例や最新の技術動向、開発者教育の状況などの情報を発信することで、「Rubyのエコシステム(生態系)」を知ることができる場として開催します。ここで登壇したのは、Rubyアソシエーション 理事長のまつもとゆきひろ氏。プログラミング言語の過去、歴史から学ぶ教訓について発表しました。全4回。2回目は、「単純さはいつも最高ではない」と「大きいことはいつもいいことではない」について。前回はこちら。 単純さはいつも最高ではない まつもとゆきひろ氏：「最も単純なプログラミング言語は何ですか？」という質問をするとですね……文法的にという意味なんですけども。 初期の言語として、Lisp、FORTH、APLなど、みんな1960年代ぐらいに作られた言語ですが、こういうものが挙げられ

日本CTO協会が主催の「Developer eXperience Day 2023」は、“開発者体験” をテーマに、その知見・経験の共有とそれに関わる方々のコミュニケーションを目的としたカンファレンスです。ここで登壇したのは、株式会社カウシェの柴田芳樹氏。45年の歴史から振り返ったソフトウェア開発とキャリアの変遷について発表しました。全3回。2回目は、米国駐在から帰国した後のキャリア変遷について。前回はこちら。 ゼロックスのパロアルト研究所に転勤後は「PageMill」プロジェクトに従事 柴田芳樹氏：1990年の終わりには、Globalviewの開発はほぼ目途が立って、20人近くいた駐在員も1991年には日本に帰る予定でした。私1人だけゼロックスのパロアルト研究所に転勤してくれと言われたのは、たぶん1990年の終わりか1991年の頭ですね。 私自身は、もう日本に帰るつもりだったのですが、今

技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。「技育祭2023【春】」に登壇したのは、元2ちゃんねる管理人のひろゆき氏。エンジニアを目指す学生からの質問に答えました。全5回。3回目は、地頭とエンジニアリングの関係性について。前回はこちら。 想像もつかないような頭のおかしな仕様をやる人は天才 司会者：これもよくいただく質問ですが、ひろゆきさんが思う、エンジニアでこの人は天才だなって思う人は、例えばどんな方がいますか？ ひろゆき氏（以下、ひろゆき）：ドワンゴっていう会社で一緒にやっていた時に、僕だったら絶対やらない危ないことをやるけど、確かに合理的には正しいなっていう人がいて。 本来であれば、読み込む時にデータを全部テキストファイルから読み込んで、パースして、ってやるんですけど、それをインクルードファイルとして生成して……要は機

映画『Winny』の公開に伴い、記憶から消えかけている20年前の諸々の思い出話をする「Winnyとは何だったのか v2.0b7.1」。ここでAki@めもおきば氏が登壇。続いて、Winnyのバージョンアップ内容について話します。 Winnyの最初のリリースとバージョンアップ ここまでWinnyの全体像の仕組みをお話ししました。後半は、Winnyというソフトウェア開発がどういうふうに進められていたかを、バージョンアップの内容からおさらいをしていこうと思います。 Winnyの開発期間は2002年5月から2003年11月の1年半だけだったのですが、その間に283回もバージョンアップしてるんですね。そういったところを、ダイジェストというかたちでササッといこうと思います。 2002年4月1日に、いわゆる最初の書き込みと開発宣言があります。いわゆる47氏と呼ばれてますが、最初の書き込みでFreenetの

映画『Winny』の公開に伴い、記憶から消えかけている20年前の諸々の思い出話をする「Winnyとは何だったのか v2.0b7.1」。ここでAki@めもおきば氏が登壇。P2Pの基礎知識とWinnyの特徴について話します。 本セッションの構成 Aki@めもおきば氏（以下、Aki@めもおきば）：では「Winnyのネットワークのおもしろさ」ということで話をしたいと思います。ふだん、技術系同人誌を「めもおきば」というサークルで出してるAkiと申します。15分ほどお時間いただきます。よろしくお願いします。 さて、今回の構成ですが、前半でWinnyのネットワークがどういうものだったかをおさらいをしながら、後半ではWinnyがたくさんのバージョンアップを重ねて最終的なかたちに至ったわけですが、そのバージョンアップのダイジェストみたいなものを振り返りながら、Winnyの開発史みたいな感じで振り返っていこう

インターネットやAIを駆使しながら、領域に捉われずにさらなる挑戦を行うDeNAの取り組みを紹介する「DeNA TechCon 2023」。ここで認証認可システムのリノベーションチームの岸直輝氏が登壇。Shift Leftの考え方を基に実践している静的解析や自動テスト、挙動の差分を自動で発見するための取り組みについて紹介します。全2回。前半は、開発において大事にしている「Shift Left」という考え方について。 認証認可システムのリノベーションチームに所属する岸直輝氏 岸直輝氏：それでは「リライトプロジェクトを安全・効率よく進めるための取り組み」というタイトルで発表いたします。よろしくお願いします。 初めに簡単に自己紹介したいと思います。名前は岸といいます。インターネット上では「p1ass」というIDで活動しています。DeNAには2021年に新卒で入社しました。現在は、認証認可システムの

映画『Winny』の公開に伴い、記憶から消えかけている20年前の諸々の思い出話をする「Winnyとは何だったのか v2.0b7.1」。ここでさのし氏が登壇。Winny流行の前後に使用していたソフトやサイトを振り返り、Winnyが残してくれたものについて話します。 さのし氏の自己紹介と、本セッションで話すこと さのし氏（以下、さのし）：では発表します。今日は「Winnyが残してくれたもの」というタイトルでトップバッター（の発表）を務めます。さのしと申します。よろしくお願いします。 今日話すことです。あの頃の話をメインにしていきたいと思っています。Winnyとの出会いと、あとWinnyが僕たちに残してくれたものということで、当時のことを振り返ってみたいなと思います。 登壇者のプロフィールです。あらためまして、本日はお時間いただきありがとうございます。さのしと申します。1989年生まれで、たぶん

大きくなりがちなデシジョンテーブルはどうすればいいか？ 篠原新治氏（以下、篠原）：続きまして、次の質問にいきたいと思います。「畠山さんのパートでやったデシジョンテーブルで表現しようとしたことがあるのですが、どうしても条件が増えてテーブルが大きくなりすぎます。小さなデシジョンテーブルの組み合わせをやってもうまくいきません」という質問に対して多くの方から賛同をいただいています。畠山さん、この質問についてお願いできますか？ 畠山塁氏（以下、畠山）：そうですね。すごくよくわかるなというのが思ったところです。たぶんこの方も非常に苦労されているのかなと思います。私自身も最初は本当に小さなものから練習しました。なのでいきなり大きなものはやはり難しいというのと、大きくなりすぎる場合はデシジョンテーブルの整理が本当に合っているのかというところもあると思います。 ほかには、その大きな中でも一部分をまずは表現し

文字はできるだけ可視化、Must・Neverの考え方でテストの範囲を決める 石原一宏氏（以下、石原）：畠山さんありがとうございます。 見えない仕様を可視化する、できないことを考慮する、図表を活用する。上流工程のひと手間で手戻りリスクは大きく減ることをお話ししていただきました。先ほどもありましたが、範囲が曖昧、条件が複雑、全体像がわからない、書いていることの箇条書きだけを見ても全体像がわからないんですよね。 一方で全体像がわかっても、細かいところが見えない逆パターンがあります。できることしか定義していない、チャットにもありました。Never・MustでNeverしか書いていないことが多いんですよね。「非機能を考慮していない」、そうですね。仕様書にはだいたい機能系の正常系、Mustしか書いていない。非機能のNeverなんて書いていないんですよね。 書いていなければテストをしなくてもいいのかとい

テストすべき領域の30パーセントが仕様書に書いてあればいいほう 石原一宏氏（以下、石原）：というわけで、上流工程が重要で、べき論ではなくて具体的にどうすればいいの？　みたいな話ですね。上流で品質を作り込むという話です。実は下流工程で大量のバグを出すのはあまりうれしいことではありません。もちろん私たちはたくさんバグを出すつもりでテストをするのですが、できれば上流工程でできるだけバグがないようにしたい。 「だったら完璧な仕様書を書けという意味ですか？」ということではありません。完璧な仕様なんて私は30年やっていて見たことがないです。テストをしなければいけない領域を100とすると、みなさんがふだん書いたり読んだりしている仕様書は何パーセントぐらいが書かれていますか？ チャットで思いついた数字を（書いてみてください）。「50は書いている」「70は書いている」。「40」「60」「30」「70」「55

「システム開発に関わるコストを減らしたい」「テストでバグが多すぎるので何とかしたい」「テスト工程まで来てから手戻りが発生し、現場がどんどん疲弊していく」。これらの悩みは開発に関わるPM・SEであれば誰もが直面することです。「PM/SEのための上流工程戦略会議」では、2事例を挙げ、上流工程において“少しの手間”を掛けることで、品質とコストに大きな効果を上げることができるポイントを共有しました。全4回。1回目は、上流工程で曖昧な仕様をつぶすための3つの方法について。 篠原新治氏の自己紹介 司会者：本日の登壇者はこちらの方々です。今回はテスト・アライアンス事業部の事業部長である石原さんと、エンタープライズ品質サービス事業部金融ソリューションサービスグループの副部長である畠山さんの2名にご登壇いただきます。Q＆Aコーナーのファシリテーターは、グループ開発事業推進部長の篠原さんに務めていただきます。

ソフトウェア開発において「悪い結果に陥りやすい、避けるべき典型例」を指す、「アンチパターン」。 プロジェクトマネジメントの世界にも存在するアンチパターンは、プロジェクトの遅延や成果物の品質低下を招く原因となります。今回のセミナーでは、プロジェクトマネジメントの現場でよく見かける「プロジェクトマネジメントのアンチパターン」と、その回避方法を紹介しました。全4回。4回目は、アンチパターンその4「技術課題満載の課題管理表」について。 アンチパターンその4　「技術課題満載の課題管理表」 西郷智史氏：時間もありますので、最後の4つ目にいきたいと思います。 4つ目は、技術課題満載の課題管理表についてです。直面した技術的な課題ばかりが取り上げられた課題管理表。ついついこれも無意識のうちにやってしまいがちになるアンチパターンの1つです。 チェックすべきポイントは、課題の内容を見ても技術者しかわからないもの

アンチパターンその3　「やったこと報告会になりがちな進捗会」 西郷智史氏：3つ目は進捗管理です。今までは計画の話が中心でしたが、実行管理において、みなさんがどのようなことをやってしまっているかという観点で話をしていきたいと思います。 まずは「やったこと報告」進捗会です。これは、その週に起こったことや、やったことを詳細に報告する進捗会のこと。具体的に言うと、毎週月曜日に先週やったことの報告会・進捗会をします。「先週はこれをやりました」「ここまで終わっています」「でもこれは70パーセントぐらいです」などと、先週やったことを報告する会をやっています。 これのどこがチェックポイントかというと、タスク実行の予実にやたらとこだわるところです。「これぐらいの予定だったけれども実際はこれぐらいかかりました」「オンスケジュールです」などと予実にやたらとこだわってしまいます。あとは、なぜ遅れたのかという議論が

アンチパターンその2　「細かすぎるリソース管理」 西郷智史氏：アンチパターンの2つ目は、細かすぎるリソース管理です。先ほど、計画の時にもリソースというキーワードが出ましたが、みなさんはリソースの管理をどのようにしているでしょうか？ よくあるのが、日単位・時間単位でリソースの負荷調整を詳細に行うこと。IT業界でよくやっています。「何にどれぐらいの時間を使ったの？」と後で集計して、この人は設計や会議、管理などにどれぐらいの時間を使っているのか、そういった細かい管理をするケースがあると思います。 （スライドを示して）「Let's Check」の1つ目を見てください。例えば、「Aさんは、Xというプロジェクトに0.5、Yに0.3、それ以外に0.2の割合でアサイン」と、小数点を用いてリソース負荷を管理しているケースはないですか？　マネージャーはよくこのようなことになりがちです。 あとは、すべての負荷が

ソフトウェア開発において「悪い結果に陥りやすい、避けるべき典型例」を指す、「アンチパターン」。 プロジェクトマネジメントの世界にも存在するアンチパターンは、プロジェクトの遅延や成果物の品質低下を招く原因となります。今回のセミナーでは、プロジェクトマネジメントの現場でよく見かける「プロジェクトマネジメントのアンチパターン」と、その回避方法を紹介しました。全4回。1回目は、アンチパターンその1「圧縮スケジュール」について。 よかれと思ってやっていることに苦しめられているケースがある 西郷智史氏：みなさんはじめまして、株式会社ビーイングコンサルティングでコンサルタントをしている西郷と申します。よろしくお願いします。 本編を始める前に、まず弊社の紹介をします。弊社はビーイングコンサルティングといいまして、事業内容は、制約条件の理論に基づいた生産性向上のコンサルティングサービスの提供です。制約条件の

「シリエン戦隊JUN TV」は、現役エンジニアである酒井潤氏がシリコンバレーにおける、働き方やキャリアなどの情報を届けるチャンネルです。今回は、酒井氏が今まで一緒に働いてきた中で出会った天才プログラマー3人について。全2回。後半は、酒井氏がレベルの差を痛感した韓国人天才プログラマーについて。 「正規表現ぐらい覚えてないの？」と言い放った天才 酒井潤氏：3人目は韓国の方で、その方もやはり異常にプログラムができました。 昔、「OpenFlow」というネットワーク関係のルーティングを処理するプロジェクトがあって、その時に私も彼と一緒にPythonを使ってネットワークのルーティング系統の部分のプログラムを書いていました。 ネットワーク関係のプログラムを書く時は、RFCやIEEEとか、プロトコルにしろネットワークのやり方にしろ、世界で決められた標準がドキュメントのかたちになってWebに上がっているん

「シリエン戦隊JUN TV」は、現役エンジニアである酒井潤氏がシリコンバレーにおける、働き方やキャリアなどの情報を届けるチャンネルです。今回は、酒井氏が考えるシリコンバレーで優秀だと思うプロジェクトマネージャーの特徴について。全2回。前半は、自身の経験から語る、優秀な人について。 合理的な判断ができないとアメリカでは生き残っていけない 酒井潤氏：今日は、シリコンバレーのプロジェクトマネージャー（PM）で私がけっこう優秀だなと感じる人についてちょっとお話ししようと思います。今回は私が考える「プロジェクトマネージャーとして優秀な人」なので、私の経験談から話します。 よくネットでは「プロジェクトマネージャーとしての5つの必要な条件」といって、例えば社員のモチベーションを考えられて、リーダー的な発言ができる人がいいとか言われるじゃないですか。そういうことはネットで見てもらえればいいので、私が直感的

品質やテストといった活動が「本質的にアジャイルになって変わらなければならない」といった問題を定義し、その解決手段を提案する「今、全エンジニアに求められる『アジャイル開発での品質視点の変化』」。ここで株式会社デジタルハーツホールディングスの高橋氏が登壇。まずは、ウォーターフォールモデルとアジャイルにおける品質担保の変化について話します。 セッションの概要説明 高橋寿一氏（以下、高橋）：高橋です。今日は講演というよりは、できればディスカッションみたいな感じにしたいと思っています。「アジャイル開発での品質視点の変化」というところを1時間弱お話しします。 ステレオタイプですが、ウォーターフォールからアジャイルへいったと。みんなハッピーなんですよね。書店に行くと、どんな本を読んでも「アジャイルが素晴らしい、ウォーターフォールじゃない」みたいな。やはりものを作る上でも、もののフレキシブルな使い方という

Kernel/VM探検隊は、カーネルやVM、およびその他なんでもIT技術の話題ジャンルについて誰でも何でも発表してワイワイ盛り上がろうという会です。yasukata氏は、バイナリの書き換えで、システムコールをフックする「Zpoline」の仕組みについて紹介しました。 システムコールをフックしたくなった理由 yasukata氏（以下、yasukata）：yasukataといいます。発表を始めます。 今回は、「Zpoline」という、バイナリを書き換えることでシステムコールをフックする仕組みを紹介します。ここではx84-64のCPUで動作するLinuxを想定しています。（スライドを示して）ソースコードはこちらにURLがあるので、よろしければ見てみてください。あとでスライドも公開するので、そちらも併せてご覧ください。 まず、なぜシステムコールをフックしたくなったのかですが、個人的にカーネルに実装