お知らせ

最近、私のシステムを手伝わせていただいているサイトで オンライン会議システムを導入することになりました。 通信部にはskywayを導入しますが、中々良いシステムです。 今まではzoom apiを使用していたのですが、制限のこともあるため P2Pで通信が行える方式に変更します。 Web開発においては、最近は既存の方々がメインになっておりますが 私自身の開発したアプリの多言語化や、営業の業務管理システムなど色々な仕事があり 楽しくもあり、大変でもありと言う感じです。

最近ではWeb開発においてはSPAで進めることが多いです。 シングルページアプリケーションといい、ページの切り替え処理が消えることになります。 従来はMPA(マルチページアプリケーション)はページが切り替わるごとに全ての情報を読み込まないとなりませんが SPAでは一部必要な情報の更新だけで済みます。 また、データ変更がない箇所においては読み込みの待ち時間は一切消えます。 私の担当しているウィリーズイングリッシュさんも、この方式に切り替えました。 こちらのメリットとしては ・サーバーの負荷を減らせる ・ユーザーの読み込み負荷を減らせる ・スマホのアプリ化を容易に行える ・vue.jsなどで開発することで動きのあるサイトを制作できる などがあります。 ただ、SEO的にどうなのだろうという懸念はあります。 そのため現行はSEOに関係ない箇所に導入している形です。 事実、ウィリーズさんもこれらのメリットを受けることができました。 皆様方もMPA⇨SPAへのシフトを検討されては如何程でしょうか？ 検討する

売上もだいぶ上がってきたため、個人事業主としても税理士さんを入れることにしました。 全国展開している税理士法人さんで、グループの長の方がYouTubeもやられている方です。 担当の方も若く、Webにも明るい方なので助かります。

開発の事務所を豊洲に移転しました。 今後はこちらでシステム開発をしていきます。 こういった移転は心機一転が出来て良いですね。 ただ、引越属になってしまっているので、 今回は長くここに事務所を構えたいと考えています。

昨年は実は特殊な年でした。 二十年前後前に東京に来て以来、開発者として個人事業主で活動してきましたが、どうしても営業が必要でした。 しかし、昨年は殆ど営業をしてきませんでした。 その理由としては、既存のクライアント様によるところが全てと言っても良いと言えます。 私の開発したシステムで、かつクライアント様のアイデアが当たり（こちらの要因が大きいのが正直なところです） そのシステムのバージョンアップや保守料などで十分な収益を得られていました。 この試みは収入は落ちると思っていたのですが、昨年の会計を確認したところ、全く落ちていませんでした。それどころか、反対に上がっていました。 安定した収益で、かつ収入アップとなる。言う事がない2021年でした。 皆様、ありがとうございました！ 今まで案件を受けてきて、上手くいくサイトと、そうではないサイトで何が違うか。 以前に完成形を目指さないということを書きましたが、それ以外にも耳を傾けて頂けるか否かだと思っております。 これは私のアドバイスが有用だと言いたいわけではありません。 私の言うことはシステム寄りだったり、IT業界の先端がこうだよという助言に過ぎません。 お聞頂きたいところもありますが、正しいとは限りません。 （100％正しいことを言えるという方がいたら、それは只の過信だと考えています） それでは誰の意見を聞くべきかという話になりますが、これはサイトを利用するユーザーの意見です。 上の耳を傾けないという問題は、サイトを利用するユーザーにも同様のことをしてしまうと考えています。 これは、上で書いた完成形を目指さないと共通しているところもあるのですが、サイトはオープンしたら完成では無いのではないでしょうか？ サイトを利用するユーザーからのフィードバックを受け、それで改善していき完成形を目指すものだと考えております。 サイトオープンをゴールにしているプロジェクトは大抵が上手く行っていません。 何せ、プロジェクトに関わっている数人の意見に過ぎないのですから。 ユーザーからのフィードバックを受け、思案し、システムを改善していく。 これが開発の理想形だと考えています。

Web開発において、よく、サイトを軽くしてほしいという話が出てきます。 HTMLやCSS等のシステムが絡んでいないWebサイトでの重さの原因は９割が画像です。 対応ブラウザを視野に入れながら、webpを入れたり、画像圧縮のツールを使うと良いでしょう。 ただ、システムが絡むものの場合は別です。 この場合、9割がデータベースのSQLの書き方と、テーブル構造です。 データベースとは、データを蓄積しておき、そこに保存し、取得できるソフトウェアです。 端的に言ってしまえば、Webシステムとはこのデータベースに保存したり、取得したりする事がメインとなります。 データベースの重さの原因で最初に目につくのがindexの貼り方でしょう。 indexとはなにか？ 要はデータの目次をつけるものに近いと思って頂ければと思います。 ただ、気をつけるべきは、indexを無闇に貼れば良いとは限らないと所です。 他にも細かいもので、検索順序を変えたり、取得情報を変えたり、キャッシュさせたり、データベースのコンフィグを変更し、チューニングしたり DBサーバーを複数個持ったりと様々な手法があるでしょう。 ただ、何件か重さの改善をしましたが、一番の解消法は正規化を減らすことです。 正規かとはなにか？ 要はデータ情報をグループ化してしまうことです。 果物で言えば、みかんの情報の「カテゴリ」に柑橘系と入れるのは良い構造ではありません。 この場合、他にレモンを作り柑橘系と入れてしまっては、後々情報を変更する際に面倒なことになります。 他に「カテゴリ」の情報を作り、そこに柑橘系を入れておき、「果物情報」と「カテゴリ情報」を紐付けたほうが 後々変更の際に便利なものになります。 なら、何故、その良い技術である正規化を減らすことが良いか？ 少し専門的に言えば、joinやサブクエリを減らせるかです。 もちろん、一番理想的なことは、正規化をしても高速なデータ構造を作るのが理想的です。 ただ、連結するデータがあまりにも増えてしまった場合は(良くないですが。。。)、上記の正規化を止めることも選択肢の一つです。 また、他にも集計を表示時にしているシステムを見かけます。 表示のたびに集計をしていてはシステムも遅くなります。 ここは、登録の際にバックグラウンドで、またはリアルタイム性は損なわれますが 深夜などにまとめて処理をするのも手の一つです。

クラウドワークのマッチングサイトでは「ランサーズ」、「クラウドワークス」が有名ですが よく、開発の失敗事例を聞きます。 紹介などで私に依頼が来る方でもここで失敗した方が多いようです。 誤解がないように、予め書かせていただきますが、これらのサービスはとても素晴らしいものです。 これらのマッチングサイトには大きな矛盾点があるのです。 自営の駆け出しの頃や、たまに、これらのサービスを使う人達は関係がないのですが 矛盾を生んでいるのが頻繁に応募する方たちです。 通常であれば、数件案件をもらえれば、お客様が定着するか、サービスがヒットし それらの方々の対応で新規受注を受けることは必要がなくなるはずなのです。 要するにそのプロジェクトが頓挫してしまったか、システム面などでサービス展開がうまくいかなかった方々が 頻繁に応募するわけですね。 実績が多い人＝素晴らしい人材 という構図では無いということです。 実績が多い人＝何かしらの問題があり、顧客が定着しない人 になるのです。 マッチングシステムを介して再発注されているのではないか？と疑問が出ると思いますが そのメリットは双方に無いため考えづらいです。 クラウドワーク系のマッチングシステムのメリットは システム運営会社がお金を預かるため、受注、発注の両方の方がお金が保証されることです。 お互いが信頼関係が築けていれば、必要がないものになり、かつ、システム手数料というデメリットのみが発生します。 何よりも、一度、システム開発者に依頼した発注の方でも、別の案件をまた募集をかけていたりするように思えます。 前回の依頼した方に依頼すればよいため、ここにも疑問が残ります。 万が一、発注で使う場合は、応募ではなく、直接メッセージを送ることをオススメいたします。

FXのデモでトレーニングできるアプリをクライアント様にご要望をいただき 公開しました。

クライアント様のご要望でFXデモにAdjustを導入しました。 ユーザー様の動向を確認し、ご要望に応えるためになります。 ハイブリッドでの開発のため、導入に少しのコツが必要でした。

最近は、私は制作するのは既存のお客様のみになりつつありますが 新規のクライアント様で開発を依頼されることもたまにあります。 その際に多くあるのが、海外の方に発注して完成しなかったというものです。 もちろん、海外の方の開発スキルも低いものではありません。 ただ、どうしても障壁があるのです。 1.言葉の壁 一番お聞きするのがこれです。 これは避けようのないものです。 「お願いしたものと違うものが出来上がった」 これは言語が通じないので当然のことでしょう。 よく、日本の翻訳の方が間にいるから大丈夫と言われることがありますが これは、正直リスクが高まるだけです。 クライアント様→日本の方→実際作業する外国の方 人が多く入るため、実際作業する方の指示がより曲がって伝わってしまいます。 実際に開発する方が日本語が出来ればまだ良いのですが これでも、日本語を完璧に理解できるわけではないため、意図は曲がってしまいます。 2.考えの違い 海外に発注するにおいて、当初の仕様は絶対です。 これは当然といえば当然なのかもしれませんが、当初の仕様になかったことは 作業してくれないことが多いようです。 私も含め、日本のエンジニアの方はこの辺りは融通を利かせて対応することが多いです。 もちろん、仕様書の作成は前提ですが、書類を作成しても 実際触ってみて「あれ？　違うな」という事は起きえることだと考えています。 この辺りもトラブルの原因になっているようです。 また、海外の方は責任感で動くことは少ないです。 あくまで「お金」で動きます。 報酬が近日払われるものを優先するのです。 また、システム的な物が違ったりします。 それはやっておくべきだろうという箇所が、やっていないことが多いようです。 また、それを対応してくれないことが多いと聞きます。 （例：保存後のアラートメッセージやお問合せなどのフォーム入力時の確認画面） この辺り、理解、納得の上での発注であれば、海外発注も良いとは思うのですが 中々、難しいように思えます。