ADHDの当事者自身が運営する『一般社団法人 日本ADHD協会』です。

弊社および弊社社員は運営には関与しておりませんが、
企業支援という形でウェブサイトなどを提供させていただきました。

東京都内での移転となりますが、近頃迷惑な営業やダイレクトメールなどが多いため、
住所・電話番号ともウェブサイト上での公開は控えさせていただきます。

取引先の皆様には個別にご連絡致しますのでご了承ください。

今回は「復縁屋」という一風変わった事業です。
探偵事務所のような形で、依頼者の復縁を支援するとのことです。

弊社および弊社社員は運営には関与しておりませんが、
起業資金の提供などで協力させていただきました。

その最初の工程が「単体テスト」です。多くの場合、単体テストはプログラマ自身が自分で作った機能を一つひとつ検証する作業を指します。自分で書いたプログラムの挙動はよく理解しており、想定と異なる動きをすれば即座にバグだと気づけるので、一見するともっとも効率的なテストのように思えます。

しかしここには大きな落とし穴があります。それは、プログラマが「正しい」と信じている挙動が、必ずしも設計者の意図と一致しているとは限らないことです。設計者は、実際にシステムを利用するユーザーと打ち合わせを重ねて設計書を作成します。設計書はユーザーにも分かる言葉で書かれているため、そのままプログラムに落とし込めるとは限りません。設計書を参考にしてプログラムを作成していく段階で誤解が生じたり、あるいは無意識のうちに都合の良い解釈をしてしまうこともあるでしょう。そうなると、プログラマ自身が「意図したとおり正しく動いている」と感じたとしても、実際は設計書やユーザーの意図とは異なる動作をしている可能性があるのです。つまり、設計者の意図と食い違っていても単体テストは通ってしまうので、これだけでバグを取り除くことはできません。

この食い違いを発見できるのは、次の工程である結合テストです。結合テストでは（多くの場合）設計者自身がテストを行うため、設計意図に沿っていなければ不具合として検知することができます。だからこそ、私は「単体テストを信用するな」と言いたいのです。単体テストをいくら丁寧に実施しても、設計者の意図から外れた部分までは検証できません。結合テストで改めて確認し直す必要があります。

では単体テストは無意味なのかといえば、そうではありません。もし単体テストを全く行わなければ、結合テストに入った途端にシステムエラーが頻発し、テストが進まなくなるでしょう。単体テストは結合テストをスムーズに進めるための「地ならし」だと言えます。プログラム的な単純バグを早い段階で取り除き、次の工程に余計な負担をかけないことが重要なのです。

にもかかわらず、時折「単体テストで細かい確認は済んでいるのだから、結合テストでは大まかな動きだけ見れば良い」と言う人がいます。しかし、それは極めて危険な考え方です。前述の通り、プログラマが「この動きが正しい」と思い込んでいれば単体テストは問題なく通ります。そして結合テストで「細かい確認は不要」と判断されれば、設計意図とのズレが放置され、リリースまで誰も気づかないかもしれません。

単体テストには確かに意味があります。しかしそれを過信してはいけません。単体テストはあくまで結合テストに進むための準備であり、本当の意味で設計意図に合致しているかを確かめられるのは結合テスト以降です。過信せず、役割を正しく理解して取り組む姿勢こそ、システム開発を成功させるうえで重要なのだと思います。

※このコラムは、筆者が個人事業主時代に執筆した文章を推敲しなおして再掲したものです

このとき「設計書どおりに作ったのだから、自分に責任はない」と考えるプログラマもいるかもしれません。確かに、設計書を作成したSEには責任があります。しかし、それだけで済ませてしまっていいのでしょうか。

設計フェーズを終えて実装に入る段階で、プログラマも仕様の理解を共有します。開発を進める中で「これはおかしいのでは？」と感じることがあれば、本来はそこで確認や指摘をすべきです。違和感を見過ごしてしまえば、結果的に「設計どおりだが動かないプログラム」が生まれてしまいます。

もし本当に「設計書をプログラムに翻訳するだけ」でよいのであれば、人間のプログラマは不要です。自動生成ツールで充分でしょう。あえてプログラマが必要とされるのは、機械にはできない「判断」や「気づき」を持ち込めるからです。

もちろん、すべての責任をプログラマが取れということではありません。開発フェーズに次いで行われるテストフェーズでは、プログラマが埋め込んでしまったバグを、SEやテスターが見つけ出してくれます。同じように、プログラマも「設計書通りだから」で思考停止するのではなく、少しでも違和感を覚えたなら、その理由を考え、積極的に指摘すべきです。

SEとプログラマは、一方的に責任を押しつけ合う関係ではなく、互いのミスを補い合う責任を共有しています。「自分の担当範囲だけ守ればいい」という姿勢ではうまくいきません。プログラマもSEも、それぞれの役割をこなしつつも、自分が行った作業がシステム全体に影響することを認識し、メンバーと協力して気づいたことを指摘し合う。その積み重ねこそがプロジェクトを成功に導きます。プログラマに求められているのは、単なる翻訳者ではなく、チームの一員として主体的に関わり、成果に責任を持つ姿勢なのだと思います。

※このコラムは、筆者が個人事業主時代に執筆した文章を推敲しなおして再掲したものです

弊社では、創業以来「一度約束したことは必ず実現する」ことを徹底してきました。もちろん契約前の要件定義段階では、現実的に実行可能かどうかをすり合わせ、お互いに納得できる内容へと調整します。しかし、一度合意した内容については決して曖昧にせず、最後までやり遂げます。状況が厳しくなっても「できませんでした」で済ませるのではなく、どうすれば実現できるのかを考え抜く。その積み重ねこそが、弊社の事業を支える基盤となってきました。

一方で、約束を軽んじる企業も少なくありません。目先の採算や負担を優先して契約を破れば、その場は逃れられても、長期的には信用を失い、事業の持続性を自ら危うくしてしまいます。信頼は一度損なえば取り戻すのに長い時間がかかる。契約不履行は、企業にとって極めてリスクの大きい行為だと言えます。

弊社の場合、特別なことをしてきたわけではありません。契約を結んだ以上、それを履行するのは当然のこと。その当然を一つひとつ積み重ねてきただけです。しかし振り返れば、その積み重ねが信頼関係を築き、結果として現在の良い状況につながっているのだと思います。約束を守る姿勢に派手さはありませんが、企業にとって最も大切な基礎であることを改めて実感しています。

創業期は何をするにも手探りで、予定通りに進むことのほうがむしろ少なかったように思います。少人数で事業を回すため一人で複数の役割を担い、限られた時間の中で優先順位をつけることに追われる日々でした。その中で学んだのは、「完璧を目指すより、まず形にして進めてみる」ことの大切さです。進めながら修正を重ねる方が、机上の計画を練り続けるよりもずっと前に進めると気づきました。

振り返れば、手探りで進めていた小さな選択の積み重ねが、会社の方向性を形づくって行きました。当時は「とりあえず必要だから」と始めた仕組みが、その後の標準になり、思いがけず組織の基盤を支えることもありました。自社フレームワークなど、今では弊社の主力となっているプロダクトも、創業して間もない時期に思い立って制作を開始したものです。

すぐに成果が見えない作業であっても、続けることで後から意味を持つことがある。その実感は、時間をかけて初めて得られるものだったと思います。「大きな飛躍を目指すより地道に継続」というのは派手さのない考え方ですが、実際に身をもって学んできたことです。続けること自体が力になり、結果として次の機会を呼び込む。事業を続けてきた中で得た一番の感覚かもしれません。

これからも世の中の変化は加速し、将来の予測がますます難しくなっていくでしょう。しかし、逆風の中から船出した経験があるからこそ、「不安定な状況こそ新しい挑戦のきっかけになり得る」という感覚は今も変わりません。環境の変化を恐れるのではなく受け入れ、その中で最適解を探していく姿勢を持ち続けたいと思います。

その代表例がリモートワークの普及です。IT企業はもともと「パソコン一つあれば成立する」と言われており（※もちろんそれは大げさな表現なのですが）、他業種に比べてスムーズに移行することができました。弊社においても、会議や打ち合わせの多くがオンラインに切り替わり、出張や対面での商談は最小限に抑えられました。移動時間が減ったことで作業効率が上がるなどのメリットが見える一方、雑談の中から自然に生まれていた情報共有や、チームとしての一体感が希薄になりやすいといった課題も浮き彫りになりました。そのため、単にリモート環境を導入するだけでなく、コミュニケーションの質を維持・向上させる工夫が不可欠だと痛感しています。

加えて、顧客企業のニーズにも大きな変化がありました。コロナ禍を経て「紙からデジタルへ」「対面からオンラインへ」という流れが一気に加速し、業務効率化やシステム導入の相談が増えたのです。これまで先送りにされがちだったIT投資が、事業継続のために不可欠なものとして位置づけられるようになったと言えるでしょう。弊社としても、ウェブシステムや業務自動化ツールの開発を通じて、そうした変化を支える役割を果たしてきました。

一方で、IT企業にとっての負荷も決して小さくはありませんでした。急速に高まった需要に対応するため、短期間でのシステム開発や運用支援を求められるケースが増え、従来以上のスピード感が必要になりました。その結果、「小規模で柔軟な組織だからこそ素早く動ける」という弊社の特性が活きる場面も多くありました。大規模なシステムだけでなく、Excelマクロや小規模ツールといったピンポイントの改善策を提案できることが、お客様に喜ばれる場面も少なくありませんでした。

こうして振り返ると、コロナ禍は社会全体に大きな試練をもたらした一方で、IT業界にとっては「存在意義を改めて問われた時期」であったと感じます。単なる危機対応にとどまらず、働き方の多様化や事業継続のあり方を根本から見直す契機となり、ITが果たす役割の広さと重要性を再確認する機会となりました。

今後も社会の環境は大きく変化し続けるでしょう。その中でIT企業が求められるのは、単にシステムを提供することではなく、顧客や社会の変化に寄り添いながら柔軟に解決策を提示することだと考えています。弊社としても、コロナ禍で得た経験を糧に、「変化に対応できるIT企業」として進化し続けていきたいと思います。

まず、一つ目の強みは高い技術力です。弊社は、ウェブシステム開発を中心に事業を展開する中で、常に高品質な成果物を作ることを目指してきました。その結果として、プロジェクトの失敗が自然と少なくなり、赤字に直結するリスクを最小限に抑えられています。開発案件における失敗は、納期遅延や追加コストといった形で会社の収益に直結します。その点、弊社では技術力の蓄積により失敗が少なく、赤字に転じるリスクを最小限に抑えられたことが、安定した黒字の継続に繋がっています。

また、少人数の会社であることも大きな強みになっています。組織が小さいため、意思決定を迅速に行うことができ、変化する状況に柔軟に対応できます。さらに、固定費を抑えられるため、経営に余裕を持たせながら必要な投資を行うことが可能です。限られた資源を効率的に使いながら事業を運営できる点は、小規模な組織ならではの利点です。

加えて、長期的な信頼関係を築けていることも、弊社の大きな特徴です。小規模な会社だからこそ、お客様一人ひとりに丁寧に向き合い、信頼を築いてきました。その結果、10年以上にわたって継続的にご依頼をいただいているお客様もいらっしゃいます。長期の取引は、単に安定した収益をもたらすだけでなく、私たち自身の成長にも繋がり、経営の基盤を支える力となっています。

こうして振り返ると、小規模な会社であっても、自分たちの強みを磨き、顧客との関係を大切にすることで、持続的に成長できることが分かります。今後もこれまで大切にしてきた姿勢を軸に、工夫を重ねながら着実に前進していきます。

オリジナルジュエリーの制作と販売を行う『株式会社エガリテ』という会社です。

弊社代表の宮野も顧問としてエガリテ社に協力しています。