お知らせ

近々、事務所を引っ越します。 このサイトでは既に新事務所の住所にしております。 個人事務所は下記の住所となります。最寄り駅は「茅場町」になります   東京都中央区日本橋蛎殻町1-8-2 3F   法人の方は汐留の方に移る予定です。   今後とも宜しくお願い致します。  

2023年はいつの間にか終わってしまいました。 記事を書くことが少なくなってしまっておりました。 手が回らないほど、忙しいというわけではないのですが、やりたいことが多いのも事実で時間が足りておりません。 以前の記事でお伝えしましたが、今年は多くのお客様に恵まれ、安定した一年を送ることが出来ました。 いつものお客様の顔ぶれで安心して作業できる反面で、反面で厳しさに身を置くことを恐れてしまっている自分がいます。 2024年は新しいことに挑戦したいと考えております。 自分が思い描いたアプリを作ること、デジタル以外の何かしらの作品を生み出すこと。 お客様の開発の仕事を回しながら、色々と挑戦していく一年にしたく思います。

遅れましたが、新年明けましておめでとうございます。 今年もよろしくお願いいたします。 今年の目標は、第一にお客様のwebサイト(ホームページ)を開発完了し、次々にオープンし 盛り上げていくことです。 これに対し、広告の技術も習得したいと考えています。 第二の目標は自分の長年の夢を進めていくことです。 これは長年停滞してしまっているところがあります。 第三の目標は英語を学ぶことです。 ある程度の読み書きはできますが、海外のドキュメントを読む際には苦労しているところもあるのと 日本だけではなく、グローバルに自らの技術を役立てたいところがあります。

Makoto Tejimaでは、12/30まで営業自体は行っております。 正月は勝手ながら、1/4まで休みとさせて頂きます。 休日期間中も何かある際はご連絡頂ければ、ご返答させていただきます。 Web開発自体は緊急を除き、対応は出来かねるかもしれませんため 予めご了承のほど、お願い申し上げます。

私は若い頃に小説家に憧れた時がありました。 当時もあったのですが出版形式に「自費出版」という物があります。 これは名前の通りに、出版にかかる費用を作者自体が負担する物です。 ちなみに私は自費出版はした事がありません。 私はこの形式を否定する気も、ネットにあるような詐欺だとか言う気もありません。 事実、「山田悠介」さんの「リアル鬼ごっこ」は自費出版から大ヒットしています。 ヒットしないのは、作者側の責任であり、出版社さん側の責任は無いと考えています。 ただ、ある程度の作品の質の担保がされているかは疑問があります。 この前、自費出版らしきものを買ったのですが、「各々（おのおの）」を「めいめい」とひらがなで書いている作品がありました。 正直、文章自体も微妙で１Pで読む気が失せてしまいました。 個人的な思いですが、これはユーザーに不利益を与え、小説離れに繋がるのでは無いかと感じてしまいます。 自費出版は本来は世に出ない名作がスポットを当てられるメリットもありますが、 低い水準だと、作者と購入したユーザーに不幸を招きかねません。 ある程度、作品の質は必要ではないかと思います。 あくまで個人的にはですが、ある程度のwebの知識があるのであればkindleが良い気がします。 出来れば、最初の頃は、かなりの低価格または無料が良いと思います。 既に電子書籍も一般的になりつつあります。無理に紙で出す必要はないでしょう。 Web開発が出来る方は自分のWebサイト（ホームページ）や人気の小説投稿サイトで公開されてはどうでしょうか？ 漫画家の方になりますが、「one」さんはそれでヒットされた方で、良い作品がヒットする土台が出来つつあります。 紙に拘るのであれば、上記方法でフィードバックをもらい、ある程度の技量がついたら、自費出版を考えられても良い気がします。 フィードバックを受けないと、独りよがりの作品になるのは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やサブクエリを減らせるかです。 もちろん、一番理想的なことは、正規化をしても高速なデータ構造を作るのが理想的です。 ただ、連結するデータがあまりにも増えてしまった場合は(良くないですが。。。)、上記の正規化を止めることも選択肢の一つです。 また、他にも集計を表示時にしているシステムを見かけます。 表示のたびに集計をしていてはシステムも遅くなります。 ここは、登録の際にバックグラウンドで、またはリアルタイム性は損なわれますが 深夜などにまとめて処理をするのも手の一つです。