少し前に仕事場のローカルに立てている、今や主力でなくなったウェブサーバに久しぶりにアクセスしたら、Wiki が PukiWiki なのに懐かしくなってこれまた久しぶりに公式サイトを見てみた。すると、今年バージョン1.5.4がリリースされており、開発は継続しているのに少し感動した。 かつてはそれこそ雨後の筍のごとく開発されていた Wiki ソフトウェア（エンジン、クローン）だが、Wiki が広義の開発環境の一つに統合されているのもあり、単体のソフトウェアとして今も開発が続いているところはだいぶ少なくなった印象がある。 果たして今も開発が継続しているオープンソースの Wiki ソフトウェアに何があるか、ざっと調べてみた。 具体的には、Wikipedia の Comparison of wiki software に名前があるもので（それくらいの知名度があり）、オープンソース、なおかつ安定最新版

はじめに Google Apps Script（以後、GAS）で開発をするときに困ることがいくつかあります。GASのIDE上で開発を行うため、手に馴染んだエディタを使えなかったり、バージョン管理がしにくかったりします。 このような問題を解決するのがclaspというCLIツールです。今回はそのclaspについて、使い方や使うときの注意点などをまとめたいと思います。 claspとは claspとは、ローカルでGASを開発を可能にするCLIツールです。Command Line Apps Script Projectsの各単語の頭文字をとって名付けられました。 今回はこちらのリポジトリにあるREADMEに従ってclaspを使っていこうと思います。 使い方 使い始める前に

文字はできるだけ可視化、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コーナーのファシリテーターは、グループ開発事業推進部長の篠原さんに務めていただきます。

最近、案件でGraphQLを使ったスキーマ駆動開発を行ったところ体験が非常に良かったため、OpenAPIでもスキーマ駆動開発を試してみました。 普及度でいうとOpenAPI Generatorの方が高そうですが、今回はAspidaエコシステムに乗ってみます。 Aspidaファミリーのopenapi2aspidaでOpenAPI YAMLファイルからTypeScriptの型定義を生成し、フロントエンド・バックエンドでimportして利用するようにします。また、バックエンドフレームワークにExpressを使用しているという前提で、express-openapi-validatorを設定しOpenAPIスキーマを元によしなにバリデーションするようにします。 Aspida選定の理由 OpenAPI GeneratorがJava製なのに対し、AspidaはTypeScript製のため、フロントエンド

はじめに これは"小さなチーム"でDevOpsを実践する際のアイデアのポストです。 DevOpsとは、運用の知識を開発に取り入れるマインドセットであり、またそのためのプロセスやアプローチを指します。ここでの"小さなチーム"というのは開発担当と運用担当とが分かれていないようなチームを指します。 DevOpsというとよく言及されるのは開発担当と運用担当のIntegrationの話だったり、DevOps専任チームの話や、DevOpsツールに言及するものが多いかと思うのですが、今回は開発担当と運用担当とが分かれていないような"小さなチームにおけるDevOps"についての話となります。表面的な事象の裏側にある構造上の特性を考えてみます。 "小さなチームでのDevOps"の場合には、DevとOpsの２つのミッションが１つのチームに集約統合(Consolidation)されています。全員が同じミッション

2022年度リクルート エンジニアコース新人研修の講義資料です

はじめに N予備校品質保証チーム（以下品証チーム）の望月です。 ドワンゴには2022年1月に中途入社しました。 組織が立ち上がってから1年半という品証チームに参画後の半年間で、プロダクト／プロセス品質向上の観点で取り組んだ改善活動をご紹介します。 ※表現に関する補足 この記事では、テストや品質に関連する業務を「QA」と表現しています。 目次 はじめに 目次 参画当初の品証チームの状態 改善活動の前に取り組んだこと STEP1：整理の方針を決める STEP2：課題を洗い出す STEP3：課題をカテゴリごとに分類分けする STEP4：課題改善の取り組み内容と実施効果を整理する STEP5：総合的な判断で課題の優先度を決める STEP6：担当者をアサインし、改善活動を実施する 改善活動の取り組み 1.各クライアントチームへの品証メンバー参画 2.テストデータの整備 3.リグレッションテストのメン

このシリーズについて みなさんこんにちは。さくらインターネットでフロントエンド領域を担当している山田です。この連載では、フロントエンド開発を行っているメンバーが、開発に役立つ情報を半分趣味で不定期掲載していく予定です。 自分からは、近年人気のデザインツールである『Figma』の便利な情報をお伝えしたいと思います。デザイナーの方はもちろん、エンジニアの方にも興味を持っていただける機能がたくさん詰まったFigmaを紹介していきます。 Figmaのご紹介 チーム開発に適したデザインツール Figmaのメインの機能の一つはもちろんデザイン制作です。Figmaを使うことで、これまでのデザインツールでは難しかったWebアプリケーションやモバイルアプリケーションといった、よりダイナミックに画面が変化していくタイプのデザインを表現しやすくなりました。 中でも、複数人で同じデザインファイルを閲覧・編集可能な

PHPカンファレンス沖縄2022の登壇資料です。 発表時間の関係で収まりきらなかった内容を大幅に加筆しています。 以下プロポーザルの内容を転記。 ---- テスト書いてますか？ テストを書く理由と実際のテストコードを紹介する実践編に分け、TDD を3年間実践してきた経験に基づいてお話しします。 テストを書いたことのない方が、テストを書いてみたいと思ってもらえることを目指します。 サンプルコードは PHP + PHPUnit ですが、他言語でも通用する考え方を紹介します。 ■ 概要 ・なぜテストコードを書くのか ・レガシーコードとは、テストのないコード ・テストはコストが安いフィードバックループである ■ 実践編 ・テストケースは日本語で書こう ・いろんな assertion を知ろう ・arrange / act / assertion のテストコード実装パターン ・set up / te

2022/08 スクラムフェス仙台でプレゼンテーションしたスライドです。 https://confengine.com/conferences/scrum-fest-sendai-2022/proposal/17013/5000dai ソフトウェア開発者としてのキャリアやスキルをどのように広げていくかについて悩むことは多いと思います。日々技術は変化していっているのに自分の勉強がおいつかなくて、まわりのすごい人たちに焦り、何もできていない自分にがっかりする。自分はそんな日々を過ごしてきました。 ですが、そこからほんの少しずつでも視点をずらしてジェネラリストという道を選び、ソフトウェア開発に徐々に貢献できるようになり、自信をもてるようになったことも事実です。 ソフトウェア開発者として、アジャイルコーチとしてジェネラリストを選択した理由、ジェネラリストとしてやっていることなど、具体的な経験を交え

現在、本業・副業ともにWEBデザイナーとしてデザイン・コーディングをしているゆるけーです。 本業で携わっているWEBサービスが割と高齢者向けのサービスで、ITリテラシーやUIが今の自分と考え方が異なるよなーと思っているなか、『高齢者のためのユーザインタフェースデザイン』という書籍に出会いました。 高齢者関係なく普通にアクセシビリティの観点でも重要な視点がたくさんあり、とてもいい書籍だったので、ざっくり大事だと思った箇所を抜粋しつつ自分で探した事例等をざっと記事にまとめていきますー。 視覚 高齢者になると視力が低下する傾向があります。ただ、視力の低下＝フォントを大きくするだけではありません。 視力の低下は老眼や光覚の減少などより複雑です。 主な視力の低下の具体例は以下のような点。 老眼：近く・遠くのものの焦点が合わない 周辺視野のぼやけ：画面の端に気づきにくい 中心視野の損失：画面の中央が暗

元任天堂開発者が伝授、3つのモノサシを使ってアイデアの「いい／わるい」を計測する：それは、発想か着想か（1/4 ページ） 相対性理論、印刷、iPhone――世の中を変える発明は、全て優れたアイデアから生まれた。では優れたアイデアとは何なのだろうか。あなたのそのアイデアは、いいアイデアなのか、そうではないアイデアなのか、「アイデアの測り方」と「アイデアの見極め方」を、WiiやSwitchの開発者が伝授する。 いいアイデアとは何でしょう？ これまでは、「シンプルで分かりやすい」「実現可能性が高い」「費用対効果がある」「新規性や意外性がある」などを基準として、アイデアの「いい／わるい」を評価してきたと思います。こういった基準は、製品やサービスのアイデアを判断する際に確かに役に立ちます。 では、新たな領域の開拓を目指すプロジェクトやスタートアップ企業のビジネスなど、まだジャンルも確立されていないよ

はじめに どんなプロジェクトでも、みんなチームに関して何かしら課題を感じているのがあると思います。そんなチームの課題について、私のチームでも、チームの立ち上げから普通の開発チームになるまで、色々な苦労や取り組みがありました。それを表に出せば誰かの役に立つだろうと思うので、記事に起こして公開します。 テックカンパニー的な会社のチームではないですが、大体チームの話はそう変わらないのかなと思うので、参考になれば幸いです。 各章特に依存関係ないので、気になるところだけでも読んでいただければと思います。 私たちはどんなチームだったか? 元々は要望は日本で受け、ビジネス的な要件検討は日本、技術的な検討は海外で行うような体制でした。 その開発拠点を日本に移動して、一から開発チームを立てよう！というのが、私たちチームの開始状況でした。チーム立ち上げの背景はこちらを参照ください。 私が参画したのは、初期メン

Agile Studio プロデューサーの木下です。「アジャイル」という言葉が広く使われるようになり、さまざまなところで耳にするになりました。それに伴い「アジャイル」という言葉の解釈も多岐に亘ってきて...

はじめまして！estie（エスティ）取締役の束原です。 現在私は10名程度のチームで新規事業の立上げに奔走しているのですが、本記事ではその中で発生した問いと学びについて書いてみました。 元は社内向けに書いた記事ですが、現在PdMや事業開発、事業責任者をやっている方や、今後やっていきたい方の参考になれば嬉しいです。 この記事で分かること estieにおいてPdMと事業開発が2つ役割として存在する意味 サービス立上げや大規模な機能開発を行う際に、PdMと事業開発がestieで大切にして欲しいポイント 結論 「どこまでがPdMの仕事で、どこからが事業開発の仕事なのか」という問いに答えはなく、必ずしも仕分けすることはできない 従って、あらゆるチームに適用可能な責任範囲を予め設定する必要はなく、アサインされる人の得意分野によって流動的に設定すれば良い 事業の立上げやグロースには、「リーダーシップ」と

はじめまして。 株式会社Enlytのベトナム側開発拠点、SupremeTech Co.,Ltdの上木です。 SupremeTechの副社長として、Project Management Office（PMO）やResource Management Office（RMO）など、管理面から開発プロジェクトを支援しています。 このEnlytブログでは名無しのインタビュアーとしてこれまでに２件の記事を書きましたが、ご覧いただけましたでしょうか。 【社長インタビュー】スタートアップとポストコロナ〜VUCA時代における不安との付き合い方〜【社長インタビュー】スタートアップがAIのR&Dにかける思い 先日「Why programmers don’t write documentation」という興味深い記事を読みまして、思うところがあり筆を執りました。以前、ディレクターの竹内がEnlytブログでドキュメ

Storybook is a frontend workshop for building UI components and pages in isolation. Thousands of teams use it for UI development, testing, and documentation. It’s open source and free.