ESM アジャイル事業部 開発者ブログ

永和システムマネジメント アジャイル事業部の開発者ブログです。

After "Hello, World!"、何書いてますか?

こんにちは。@junk0612 です。

この記事は、ESM Advent Calender 2021 の4日目の記事です。

前置き

12月、師走になりました。界隈ではアドベントカレンダーが盛り上がり、世間では様々な場所でイルミネーションが行われ、友人と「もう12月かよ、今年あれもこれもできんかったわ〜」と無駄話する、そんな季節です。

来年の話をすると鬼が笑うと言いますが、来年の言語はすでにお決まりですか? 僕は Rust 面白そうとか TypeScript ちゃんと触っておきたいとかアセンブリなんていいんじゃないのとかいろいろ考えてしまってなかなか決まりません。年明けまでに決めておかないと……

本題

前置きがだいぶ長くなりました。

新しい言語を学んでいて、アプリやゲームを作るほどまだ手に馴染んでいないけど、Hello, World! じゃないもうちょっと難しいプログラムを書きたくなったとき、皆さんは何を書きますか?

僕は再帰下降パーサが好きなので、「四則演算の式を再帰下降で構文解析するパーサ」をよく書きます。Ruby で書いたコードの Gist です。 https://gist.github.com/junk0612/b79d080a5c4a6c34efc85dc56b63b29e

この問題の気に入っているところは、ゴールを自分である程度調整できるところです。四則演算でゴールして作りたいアプリの作業に移ってもいいですし、改良できるところはいろいろあるので、気分が乗ったらそれに手を付けても構いません。

実はこの話題、たまたま Twitter でみかけて (どこだったか失念しましたが……)、JSON のパーサを書いているとか、言語特性を考えてその都度書くものを変えているとか話していて、みんな意外と違っていて面白いなと思ったのでした。

どんな物を書いているか、Twitter などで反応をもらえると嬉しいです (さらに書いたものを GitHub にまとめてこちらからご応募いただけると泣いて喜びます)。

ソフトウェア受託会社の営業がお客様へ最初に質問すること(あるいは、永和システムマネジメントアジャイル事業部にお仕事を依頼されたいときにご一読いただきたいこと)

この記事は「ESM Advent Calendar 2021」の2日目の記事です。

adventar.org

こんにちは、平田です。アジャイル事業部の Ruby x Agile グループにお仕事の依頼をいただいた時には、ほとんどすべての場合に、私が最初に話を聞かせていただいています。

同業他社の方から「トークスクリプトまとめてるんですか?」と聞かれたこともあるのですが、お客様によって状況も異なることもあり、あまりきちんとまとめてはいません。ものづくりをやっていくにあたり気になる点を都度確認しているのですが、でもよく聞くものは似通っているなと思い、少しまとめてみました。

開発しているサービスについての質問

  • 対象のサービス名
  • サービスのビジネスモデル
  • 現在のお客様の状況(BtoBの場合大口顧客の状況や、BtoCの場合ユーザー数の伸び等)

開発対象の技術的な状況

  • 現在のフェーズ(ローンチ前なのか、ローンチからどれだけ経過しているのか)
  • 規模(どのくらいの期間、何人で開発してきたのか。bin/rails statsの結果を聞くこともあります)
  • 使用している技術スタック(新規開発の場合には技術選択の制約)
  • 困っていることがあればその状況

開発しているチームがいる場合、その状況

  • 現在の体制
  • リリース間隔を含めた開発プロセス

今回依頼したい内容

  • どのような課題を解決したいのか
  • 技術的な課題はなにか
  • チームビルディングや開発プロセスの課題はなにか

(主に初めての方の場合)一緒にやれるかの文化の確認

  • どのようなルートで弊社を知ったのか
  • 他に声をかけている会社様について

お取引に関する確認

  • 費用感
  • 希望開始時期
  • 最遅開始時期(いつまでお待ちいただけるか)
  • リリース等のマイルストーン

新規のサービスや社内システムの開発の場合、もう少し対象領域に踏み込んだ質問をさせていただきますし、エンジニアが同席して詳細な技術的な課題をお聞きすることもありますので、最低限のものですが、このようなことをお聞きします。

もし、ソフトウェア開発の外部委託(一部でも全部でも)を検討されている場合には、このようなことを確認されるということを心に留めていただき、下記のリンクよりお問い合わせください!

agile.esm.co.jp

また、永和システムマネジメントアジャイル事業部では、様々なお客様の課題解決のお手伝いをしたいと考えているエンジニアの方を募集しています。ご興味のある方は以下のリンクより事業部の紹介をご覧いただき、カジュアル面談のご連絡をください!

agile.esm.co.jp

Turing Completeで学ぶデジタル回路設計

f:id:htkymtks:20211123005417p:plain:w500

こんにちは。永和システムマネジメントの内角低め担当、はたけやまです。

今回は、11月前半の私の可処分時間の全てを注ぎ込んだパズルゲーム「Turing Complete」を紹介します。

Turing Completeとは?

store.steampowered.com

宇宙人にさらわれた主人公が、宇宙人から出題されるパズルを解きながらデジタル回路を作成していく論理パズルゲームです。 Steamで早期アクセス版として配信されており、お値段は2050円。対応プラットフォームWindows、macOS、SteamOS + Linuxです。

Turing Complete は「デジタル回路設計パート」と「プログラミングパート」の二つのパートを行き来しながらゲームが進みます。

デジタル回路設計パート 〜 NANDがあればなんでもできる

f:id:htkymtks:20211122190054p:plain
https://en.wikipedia.org/wiki/NAND_gate より
f:id:htkymtks:20211122190216p:plain
NAND真理値表

NAND回路をご存知ですか?AND回路の出力をNOTで反転させた上記のような回路です。NAND回路があればAND回路やOR回路ひいてはCPUまで、あらゆる論理回路を構成できることが知られています。

f:id:htkymtks:20211122203941p:plain

ゲーム開始時点ではプレイヤーはNAND回路しか使えませんが、NAND回路を組み合わせて「NOT回路」→「AND回路」→「OR回路」→「半加算機」とステップアップしていき、最終的にはチューリング完全なCPUの組み立てを目指します。

f:id:htkymtks:20211121182156p:plain:w300
OR回路
f:id:htkymtks:20211121181929p:plain:w300
CPU

プログラミングパート

CPUを組み立てたあとは、組み立てたCPUを使ってプログラミングパズルを解いていきます。飛来する小惑星の円周を計測したり、金庫のパスコードをブルートフォースアタックでクラッキングしたり、ハノイの塔を解いたりと多彩なステージが待ち受けています。スタックや関数呼び出しを自分で実装するステージなどもあったりして「これが...論理パズル...???」みたいな気持ちになったりして面白かったです。また、アセンブラばかり書いていると「あー、アセンブラだりー、Rubyつかいてー」と普段使っている高級言語のありがたさが身に染みたりしました。

f:id:htkymtks:20211122003746p:plain:w300
小惑星の円周を測れ!

f:id:htkymtks:20211122003940p:plain:w300
ハノイの塔

CPUはピタゴラスイッチ

回路を設計していく中で、シンプルなルールに則って規則ただしくデータが流れていく様はピタゴラ装置のようだなあと感じることが何度もありました。 情報化社会がこんなピタゴラスイッチみたいなものに支えられてるのかと思うと、狐につままれたような気分になります。

こんな人におすすめ

Turing Completeはこんな人におすすめです。

とはいえ、ちょっと微妙なところもあります。

  • 早期アクセス版なので結構バグが残っている
  • 多少の予備知識がないとクリアは難しいかも

現状のTuring Completeは早期アクセス版、未だ開発途中なためバグが結構残っています。例をあげると、複数の部品を動かしたあとにUNDOすると高確率でクラッシュしたり、バグでステージがクリアできなくなったり(すぐに修正されましたが)ということがありました。俺がバグ出ししてやるぜ!という強い気持ちでプレイするのがおすすめです。

また、開発途中のためか説明が足りないところが結構あります。デジタル回路設計について何も知らない状態で挑むとちょっと大変かもしれません。(実績を見ると最終ステージまで到達したユーザーは全体の5%ほどのようです)

それでも挑みたい!という方は以下の書籍が参考になると思います。

まとめ

以上Turing Completeのご紹介でした。低レイヤ好きの皆様はぜひチューリング完全なCPUの自作を目指してみてください!

おまけ 〜 NAND回路はどうやって作るの?

「NAND回路があればどんな論理回路も作れる」と言うけど、そのNAND回路はどうやって作るのか気になりませんか?

Turing Completeと同じ回路設計ゲーム「NandGame」の「NAND」と「NAND(CMOS)」のステージにその答えがあるので、気になる方は以下のリンクをたどって是非チャレンジしてみてください!

nandgame.com

Problem が倒せない

こんにちは、悟空体験アクションRPG を楽しんでる nsgc です。

去年の今頃、Continuous KPTA について紹介しましたが、 KPTA をしていて、いつまでも Problem が残り続けることってありませんか?

私の関わったプロジェクトでは、何度もそういう場面に出くわすことがあります。
1, 2イテレーション位ならまだしも、何ヶ月前からあるの? というものがそのままになっていたりするのです。

なぜこういったことになるのでしょうか?

プロジェクトのコンテキストに依存するところも大きいのですが、これまでの経験したことや伝え聞いた内容からどういうケースがあり、そういう場合にチームはどうしたら良いのか、どうしていったのかを今回は挙げてみました。

Action が具体的じゃない

「KPTA の Action には具体的なものを挙げましょう」、という前提から外れてしまっているケースです。

「XXXの勉強をがんばる」とか「本番作業に気をつける」というお気持ち表明や意気込みだと何をしたら良いのか分からず、いつまでも不安は除けません。
「朝会の後 XXXの読書会をする」、「次回のメンテナンスでは本番作業の手順を用意する」というように具体的で行動しやすい Action にすると着手しやすく、 Problem を早く解決できるかもしれません。

解決まで時間がかかる

Action を実行しているけど、問題解決のための行動がほんの少しずつなので Problem の領域に残ったままになる、という場合もあるかもしれません。

この場合、全部解決するまで KPTA ボード上に残しておく必要は必ずしも無く、少しずつでも改善していっているのならそこから取り除き、別の所で進捗を把握しても良いかもしれません。
タスクとして切り出してプロジェクトの計画に組み込んでいるなら、そっちで成果を追うようにしましょう。

問題が強大すぎる

実現できない Try ばかりのため、着手できる Action が出ない場合は、その Problem はチームで解決できる範囲を超えているのかもしれません。
環境での制約によりどうしようもできない、お客様の社内ルールに手を入れる必要がある、といった場合はなかなか難しいことも多いです。

エスカレーションできるなら偉い人にお任せし、チームの問題からはいったん切り離した方が良いかもしれません。

本当は Problem じゃなかった

ここまでも見てきたように様々な理由で Action に着手できないことはありますが、実は Problem がそもそも Problem じゃない、もしくは Problem では無くなっている事はありませんか?
ふりかえりで挙げた当初は不安や課題であると認識していた。しかし、具体的な改善 Action はなされていないが時間が経つことで、学習や慣れなどを経たためか、何も気にならなくなったというケースです。

もし、チームで誰も困っていないのなら思い切って Problem から除くと良いかもしれません。
きっと、問題だと感じたら、また挙がってくるのですから。

解決のためのコストパフォーマンスが悪い

課題や問題の発生頻度が低く、困り具合が小さいのに対して、それに対する解決策のコストが大きい時にも Problem として残り続けるのかもしれません。

手軽な Action を抽出し実行するか、それが出来ないのならいっそチームとしては Problem を容認しても良いかもしれません。
私達には、もっと他に議論するべき問題がたくさんあるのです。

カイゼンサイクルがまわっていない

ビジネスサイドからの要求が多く、そのため目の前のタスクで手いっぱいになっているケースです。
Action に着手する時間がない。最悪な場合、ふりかえりの時間も取れない場合もあります。

一時的である場合はともかく慢性的にそういう状態になっているのなら、プロジェクト自体の立て直しが必要なのかもしれません。

最後に

残り続ける Problem はこうしてみると実に簡単な原因ばかりに見えますが、なかなかそのことに気付かないことが多いです。
ただ、あらかじめ今回あげたケースがあるということを頭の片隅に置いておくと、客観的に分析し対処できるのではないかと思っております。

もし、私と同じように Problem が残り続けてお困りの方は、上のようなケースにあてはまっていないか検討し、Problem をどうしていくかを考えてみましょう。

Rails / OSS パッチ会オンライン 2021年11月のお知らせ

【重要】Rails/OSS パッチ会で運用していた Idobata ルームは近日閉鎖されます。本記事で言及している Discord へ引越しをお願いします。

2021年11月の Rails / OSS パッチ会を 11月25日(木)に Discord でのオンライン開催をします。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS について、upstream にパッチを送る会です。

会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。

Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です👇

discord.gg

パッチ会では、来月リリース予定の Ruby 3.1 に関する話題などあるかもしれません。

これからパッチ会に参加してみようという方もぜひどうぞ。Discord でお会いしましょう。


永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

【ご案内】Rails/OSSパッチ会をDiscordに会場変更しました

【重要】2021年11月中旬に Rails/OSS パッチ会で運用している Idobata の ルームは閉鎖されます。本記事で案内されている Discord へ引越しをお願いします。

Rails/OSS パッチ会の会場を Discord に移動しました。音質次第で当日のオンライン会場も Discord となる予定です。

Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です👇

discord.gg

これからパッチ会に参加してみようという方もぜひどうぞ。これまでやりとりに使っていた Idobata の rails ルームは 11 月中旬に閉鎖される予定です。Idobata を情報チャンネルとしていた方は Discord への引越しをお願いします。

次回の Rails/OSS パッチ会は 11月25日(木) 17:00-19:00 です。Discord でお会いしましょう。


永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

f:id:koic:20211102145713p:plain