IT

WEBサービスのさらなる利便性向上を目的に、数か月前にシステム性能強化と耐障害性強化を実施しました。 この対応により、HP閲覧の快適性とサービス継続性が飛躍的に向上しました。 その結果、弊社お客様お教室HP全体的に体験レッスン申し込みペースが2倍以上に増加しました。 ここまで効果が出たことに私も驚きました。   背景 おかげさまでピアニスト・ピアノ教室ホームページ公開が増え続けております。 また、最近ではBECHSTEIN Japan公式サイトリニューアルはじめ、ピアノメーカー関連企業様や音大付属音楽教室様など、組織・団体サイトも手掛けるようにもなりました。 これに伴い、弊社管理HPへの総アクセス数が飛躍的に増加しております。 そして、システム障害時のダウンタイムの影響度も大きくなりました。 この新たなニーズや今後のさらなるアクセス増加を見据え、システム設計方針レベルから根本的に見直しました。 いままでは、データ消失リスクの最小限を方針としたシステム構成としておりました。 新たな方針は高性能かつ堅牢なシステム構成です。データ消失リスクはさらに低減します。 具体的なアクションは下記のとおりです。   高性能サーバへ入れ替え 従来サーバよりもCPU,メモリ,ストレージのすべてに渡り高性能なサーバに入れ替えました。 新サーバはWEBサーバ専用として稼働さています。 これにより他サービスの処理負荷影響を受けなくなりました。   システムパフォーマンスチューニング WEBサーバとして、高速に動作するようにハードウェア&ソフトウェアの両面でシステムパフォーマンスチューニングを行いました。 WEBサーバは瞬発力が重要です。 瞬発力とは、WEBブラウザがWEBサーバへアクセスにおける、要求から応答までの処理時間です。 要求から応答までの処理時間が短ければ、閲覧者は即座にコンテンツを閲覧できます。 HP閲覧の快適性向上だけでなくSEO対策にもつながります。(応答速度が早いWEBサイトは検索上位へ評価されます。) チューニングの結果、応答時間は従来システム比1/10以下となりました。 性能は応答時間と逆数の関係となるため、性能向上比は10倍以上となります。...

東京行政書士会様で情報セキュリティセミナーで講師を務めました テーマは「あなたのパソコン、スマホも何者かにのっとられているかも?」 ~クラッカーの巧みな攻撃とその対策・初心者にも分かるセキュリティ~ 機密情報を取り扱う行政書士業務。 IT活用は業務効率を上げる効果的な手段である反面、不意に情報漏洩してしまうと信頼を損ねてしまいます。 今回は情報セキュリティについて、どなたでもご理解頂くために超基礎的な内容を中心にお伝えいたしました。 参加された全員が真剣にお聞きくださいました。 ちなみに今年度開催された東京行政書士会様主催セミナーの中で、参加人数が最も多かったそうです。 実務と間接的な内容にも関わらず、情報セキュリティへの関心がとても高いということですね。 東京行政書士会員限定となりますが、セミナーの模様を動画でご覧頂けます。...

弊社お客様である音楽家様(演奏家・指導者)が安心して音楽活動に専念頂くことを目的に、音楽家に特化したセキュリティ対策を強化しました。 詳細は申し上げられませんが、上場企業でも情報セキュリティ重要度が非常に高いシステムでしか採用されない技術をさらに応用しています。 ご活躍されている音楽家を数多くサポートしている弊社しか実現できない模倣困難性の高い技術です。 ご興味がございましたら個別にお問い合わせください。 セキュリティ対策強化の背景は、音楽家様への迷惑行為増加です。 執拗なアウトバウンド営業やストーカー・・・ 音楽家HP公開は良いことが多い裏でリスクも伴います。 今回導入した技術により、健全なお客様を増やし、不健全な迷惑行為排除の両立が実現しました。 いままでも、これからも、FineAlliesは他社が真似できない高度な技術力を駆使して音楽家をお守りいたします!!...

[caption id="attachment_5022" align="alignright" width="150"] THE部活![/caption] 「月刊ショパン」を発行している株式会社ハンナ様の季刊誌、「THE部活!WEB」開発を無事に終え、公開に至りました!! ハンナ様より開発事例掲載許可を頂いたのでご紹介したいと思います。 「THE部活!WEB」は部活目線で学校を探すというユニークなシステムです。 今回の開発は、アジャイル型開発モデルを採用しました。 アジャイル型開発モデルってなに? システム開発プロジェクト手法のひとつです。 アジャイル(agile)は素早い等の意味で・・・ などといった詳しい説明は専門家に任せておき、大きく意訳して音楽家の方々でも分かりやすく説明したいと思います。 アジャイル型開発モデルは「お客様と一緒に技術的理解を深めながら開発する」といったやりかたです。 日本において、巨大なシステム開発はウォーターフォールモデルという手法が採用されることが多いです。 設計→開発→試験→公開 といった工程を経て、システム公開するやり方です。 これが水(Water)が上流から下流へ流れ落ち(Fall)、再び上流に戻らないことを前提とするやり方から、WtaterFall(水が落ちる=滝)モデルといわれています。 ウォーターフォールモデルはビルなどの建物建築と重ねるとイメージしやすいです。 設計図を書いて、お客様に説明・承認を経たら、基礎を掘って骨組み組んで、内外装を作っていく・・・ 作り上げたらお客様が竣工検査 問題無ければ引き渡して竣工完了!! 巨大なシステム開発もやり方は一緒です。 ただ、ひとつだけ大きく異なることがございます。 それは、作り上げる対象が物理的か論理的かの違いです。 ウォーターフォールモデルの問題点 諸説ありますが、私がいままで経験してきて感じている大きな問題点は「設計書を技術的に読み抜く力が受発注者双方に求められる」という点です。 依頼を受けたシステム開発者(請負者)は、どのような機能を開発するかを設計書に明記します。 それを依頼主(発注者)が設計書をチェックします。 設計書を悪くいえば、「絵に描いた餅」です。 ウォーターフォールモデルで巨大なシステム開発となると、設計書は数千、数万ページ以上におよびます。 超々々々々~~~~ざっくり説明すると、 プロジェクト計画書(どのような期日になにを完了させるかの計画) 外部設計書(見た目の設計) 内部設計書(機能を実現するための技術的設計) 試験計画書(仕様通りに動作しているかを確認するか?の計画) など、膨大な書類の山が築き上がります。 システム開発者はレシピ(設計書)に基づき、料理(プログラミング)することで、食べられる餅にします。 そして依頼主はどのような餅を作るかをレシピ(設計書)で確認します。 でも、それは作ってみないと実際に味わうことはできません。 システム開発でよくある話は、絵に描いた餅(設計)段階で、受発注者双方で合意した内容を、食べられる餅(開発完了)段階で「味が違う!!」となることです。 建物建設の場合、開発対象は物理的です。 見た目でどのようなものができあがるか?という過程を目で確認することが可能です。 一方で、システム開発の場合は論理的です。 開発過程をどんなに詳細にお伝えしても、食べられる餅(開発を終える)になるまでわかりません。 作った後に、「思ってたのと味が違う!!」という話、よくあることです。 受発注側双方に不幸なことですね。 アジャイル開発モデル 絵に描いた餅を、早い段階で試食しながら食べられる餅に作り上げていく開発モデルといえます。 重厚長大な設計書を書き上げて「絵に描いた餅」の作り方を定義するのではなく、試作品を作り、実際に触れて確かめてもらうことを優先した開発モデルです。 受発注側双方で触って確かめながら開発を進めるため、完成形(=絵に描いた餅)をイメージしやすくなります。 これだけ聞くとメリットばかりなやり方ですよね!! しかし、日本ではこのやり方がなかなか定着しません。 その理由は最後に言及したいと思います。 株式会社ハンナ様 [caption id="attachment_5027" align="alignright" width="180"] ハンナ編集部とのミーティング[/caption] 「月刊ショパン」でおなじみの歴史ある出版社様です。 月刊ショパンは私がピアノを習っていた頃からの愛読書でした。 プログラム開発を伴うシステム開発は初めてでした。 当然ながら編集部にITに精通された方はいらっしゃいません。 この状態でいかにしてプロジェクトを成功させるか? そこでアジャイル開発モデルの登場です。 THE部活!WEBシステム開発は、試作品を2度作り、実際に動作を確かめて頂きながら開発を進め、最終形を完成させました。 試作品開発を通じて、編集部の方に技術的理解を深めて頂きました。 THE部活!WEBシステムの肝は部活検索機能です。 開発過程で編集部からいろいろなご要望が挙がりました。 これについて、技術的にどのように実現するかを提案するだけはなく、実際に動作をお見せして、双方で確認しながら開発を進めていきました。 公開時点で、編集部の方が技術理解を深めることが実現し、データベース構造を議論できるレベルに達しました。 もし、ウォーターフォールモデルで進めてたとしたら、なかなかそうはいきません。 アジャイル開発モデルを採用して大成功でした! アジャイル開発モデルはウォーターフォールモデルよりも優れているのか? 私はそうは思いません。 各開発プロジェクト単位で最適な方法を選ぶべきだと思います。 アジャイル開発モデルのメリットは柔軟性の高さです。実際に確認しながら作り進めるため、開発過程で細かな軌道修正が可能です。 でもこの柔軟性の高さがデメリットともなりえます。 開発と確認を同時並行するため、開発当初の要件以外の機能を求められることがあります。 機能が増えるとプログラム開発量が増えて、コストに影響します。 日本の商慣習では一度合意した予算を超過するやり方は好まれません。 また、意思決定者が複雑に絡み合うような巨大システム開発プロジェクトとなると、採用することが難しくなりがちです。(そもそも意思決定が複雑であることそのものが問題の本質ですが、本題から外れてくるのでここでは言及しません。) これに対して、開発目的に立ち戻って判断していくことが大事です。 ハンナ編集部様とも開発目的に沿って建設的に議論を重ね、開発を進めました。 いずれの方法でも、双方の協力関係を築くことが大事ってことですね!! ...

先日のセミナーのプレゼン資料作成時に興味深いデータが取れましたのでご紹介しようと思います。 弊社が制作するお教室ホームページ(以下HP)はすべてスマートフォン・タブレット対応です。 これがどれくらいの効果があるのか?について実際に調査してみました。 調査方法 調査対象期間 2016年4月度の30日間 調査対象HP 弊社が制作した全お教室HP <理由> お教室により、初回訪問件数やレッスン申込件数にバラツキがあります。 全お教室分を総和することにより、母数を増やしバラツキを平均化しました。 調査ポイント 初回訪問時のデバイス(パソコン、スマートフォン・タブレット等)の利用率 体験レッスンお申込み時のデバイスの利用率 この2つの利用率の差がどれくらいあるか?を調査ポイントとしました。 こうすることでお教室HPとしてのコンテンツの良し悪しによる影響を排除します。 PCで訪問して、体験レッスンお申込みすればお申込み時のデバイスもPC スマートフォン・タブレットで訪問して体験レッスンお申込みすればお申込み時のデバイスもスマートフォン・タブレット といった具合です。 まったく効果がなければ、初回訪問時のデバイスの利用率と体験レッスンお申込み時のデバイスの利用率は一致することになります。 ちょっと荒っぽい手法ですが、傾向把握としては充分な調査方法だと思います。 調査結果 初回訪問時のデバイスの利用率 51%でした。 体験レッスンお申込み時のデバイスの利用率 74%でした。 初回訪問時と体験レッスンお申込み時のデバイスの利用率比 1.45倍でした。 考察 スマートフォン・タブレットの利用率がPCを超えた 半数以上がスマートフォン・タブレットでお教室HPにアクセスされる時代となりました。 スマートフォン・タブレットに非対応のままでは半数以上の閲覧者の利便性を損なう状態ってことですね。 スマートフォン・タブレット対応としているだけでレッスン申込み率が1.45倍増加する これは、他のお教室HPがPCしか対応していないことを意味しているといえると思います。 もちろん音楽教室にとって最も重要なことは、指導者の指導力です。 しかし現実は、指導力とは本質的に関係の無い、「お教室HPの利便性」という差で生徒集めが大きく影響しているということもいえると思います。 今後、スマートフォン・タブレット利用率と他のお教室HPの動向次第でこの倍率は変化することになるでしょう。 いずれにしてもスマートフォン・タブレットは必須ってことですね!!...

いまままでセミナーでレクチャーさせて頂いた内容を1部ですが公開することにいたしました。 半年前から全国行脚してセミナー活動を行ってきましたが、残念ながら、日程や地域的にご都合が悪く、お越し頂くことができなかった先生も多くいらっしゃいました。 そこで、先日のセミナー内容を公開し、お越しいただけなかった方々にも情報を発信しようという結論に至りました。 ピアノ指導者様がお教室webサイト制作にあたり、参考情報の一助となれば幸いです。 https://www.fineallies.co.jp/how-to-make-of-mswebsite まずは第1回を掲載しておきました。 今後、順次情報を公開していこうと思います。 楽しみにしていてくださいませ♪...

弊社のwebサイトのURLは、
https://www.fineallies.co.jp
です。

このブログを読まれているということは、このURLにアクセスしているのでお分かりですね(^_^;)

https_001このhttpsのsは、secure(安全、信頼できる)という意味です。
つまり、システムの正当性を証明し、通信を暗号化して情報漏洩を防いでいるのです。
このブログのタイトルに書いたseo(検索エンジン対策)のsは技術的由来はありませんが、実は検索エンジン対策にもなります。