開発方針(アジャイル開発手法)

Environment(環境)

• 問題点の把握

  「現在行われている業務に問題点は無いか？」という問いかけから全てが始まります。
  発端はポジティブな場合もありネガティブな場合もあります。ネガティブな場合とは不平・不満・苦情からくる解決策を模索することになった場合などです。 どちらにせよ、ここでまず行われる問題点の把握がシステム開発のスタートとなる為とても重要になります。 システム開発の依頼は「やりたい事」の羅列がメインになりますが、目的なのでこれ自体はとても大切ですがまずはその起因となった問題点の分析の方がより大切な項目となります。 ここに大きく注力し問題点の把握をしっかりと行う事が重要です。

• ---

• 起因業務の分析

  問題点の把握で欠かせないのが起因となる日常業務の分析です。
  提示された問題点の原因個所には必ず業務が伴います。まずこの業務に精通しているかどうかで見えるものが変わってきます。ではその業務にどれだけ精通しているのか、どうすれば精通できるのか。 業務分析は通常ヒヤリングを重ねますが実はこの中でなかなか伝わらない事があります。とても曖昧な言い方になりますがそれは建築業界における文化みたいなものです。 システムを開発する我々はコンピューター業界でのエンジニアでありこの業界では業界のコモンセンスが存在します。 これと同じようなものが建築業界にも存在し、厄介なことにこちらの方がより色が濃く言葉の裏に常に一定の価値観で存在しているのです。 この事が原因で建築業界でいう一般常識が通用せず、時折錯誤が起こる場合があります。この場合双方共に非は無い場合が多いのですがどうしても文化の違いで正確に伝わりません。 弊社は前身が建築事務所であり２０年以上にわたり建築専門のシステム作りを行ってきた経験から建築の文化を理解しているつもりでおります。

• ---

• 対応策の検討

  システム開発の要になる問題点を解決する対応策の検討です。
  問題点の把握、起因業務の分析までが適切に行われてはじめて対応策の検討に移れます。ここからは技術的な側面からの検討になりますので弊社からの提案が主体とはなりますが、お客様とのミーティングを重ね練っていきます。 そしてこの提案の良し悪しがシステムのポテンシャルを大きく左右します。経験がものを言う場面です。今まで関連する同様なシステム開発を手掛けていればその経験が生かされます。 また全く新しい方策も数々のスキルを持っている方が組み合せの数も増えていきます。ここで有効なのが弊社は建築系ソフトウェア開発にずっと特化してきたというノウハウの蓄積です。

Plan(計画)

• 解決策の草案作り

  対応策の検討から大凡の当りを付けた枠組みから実際のシステムの概要設計に入ります。
  提案の段階で具体的な技術的な裏付けは行いますが、最終的なシステム構築の手法は選択肢が多岐に渡る場合が多いので、同類のモジュールから最適なモジュールの再検討を行いシステムの内容を現実的なコーディングが可能なレベルまで具体化していきます。 この場合に複数パターンの草案が作成される場合もあります。こんな時は更にお客様とのミーティングを重ねブラッシュアップしていきます。

• ---

• 問題解決に向けての技術的調査

  Plan(計画)段階の全ては相互的に関連している為並列に行われる事があります。
  草案で出されたシステム内部のモジュールの技術的な調査を行う必要があります。斬新性は無いが過去に使われておりとても安定している枯れた技術は技術調査を行う必要はありませんが、 システムの寿命に問題が有ったり最新技術を取り入れた方がより良いシステムなる事が想定できるような場合は新しいモジュールを使う場合があります。 こんな時は技術的調査や実証検証が必要になります。これらの新技術はシステム開発の依頼を受けてからでは間に合いません。多方面に向けての日々の研究、調査、ノウハウの蓄積が大切な部分です。

• ---

• コストパフォーマンスの検討

  システム全体を視野に入れ開発における全体コストを得られる効果から推定し直します。
  技術の選定や、システム全体の規模、システムで組み込範囲とマンパワーで行う業務の範囲等コスト面からシステム全体を見直す場合が多々あります。労力を惜しまず最良のバランスにたどり着くまで、システムの設計を振り出しに戻ることを恐れずに再検討を重ねていくことが大切です。

• ---

• タイムスケジュール

  コストパフォーマンスの検討と並んでタイムスケジュールも大切な要素です。
  無理のないタイムスケジュールを組むことが理想ではありますが、中々タイトになる事が多いのが現状です。弊社では開発手法にアジャイルを採用している事もあり開発が進むうえでお客様の気付きがあり、システム全体の規模が膨らんで行く場合が多々あります。 こんな時の為にタイムスケジュールに余裕を見ることが大切になります。アジャイル開発手法とは簡単に言いますと「反復 (イテレーション) と呼ばれる短い開発期間単位を採用することでリスクを最小化しようとする開発手法の一つ」という事になります。 弊社での開発のスタイルは、まず出来るだけ早い段階で動作するプロトタイプを作成し、お客様に見てもらいながらミーティングを重ねイメージを共有していくことを主眼に考えています。

Architecture(建築)

• 専門分野の視点

  建築には建築の文化がありシステム開発にはシステム開発のコモンセンスがあります。
  全てにおいて専門分野には専門家同士でしか通じない「暗黙の了解」みたいなものがあります。専門用語も含めてですがこれはもう違う言語同士で会話しているのと同じくらいです。 ある問題に直面した時、打ち合わせで根掘り葉掘り聞けば何とかお互い理解しあえる場合も有りますが、そもそもお互いの常識という部分に入ってしまった事は聞き返したりしません。 つまりお互い全く違う常識で胸にしまいこんでしまうのです。違う言語で会話しているのですから避けようもなく仕方がありません。お互い専門家同士ならば話が通じますのでどちらかが歩み寄る必要があります。 私共は建築言語とシステム屋言語の２カ国語を操るバイリンガルと自負しております。

• ---

• 専門用語の壁

  専用システムとなると必ず専門用語が頻発します。
  専門分野に特化したシステムとなる為必然と言えば必然です。そのたびに専門用語の解説を聞くシステム開発業者がおりますが、よく見受けるのが「専門用語の説明の中にどうしても出てきてしまう新たな専門用語」が出てきて収集が付かなくなる場面です。 こんな場合お客様はもうどうすることも出来ません。「ケラバ」や「破風」「火打ち」など多くのシステム屋では「？」な言葉が弊社ではすんなり会話に溶け込んでおります。こんな環境でのお打ち合わせを想像してみてください。

• ---

• 豊富な建築分野での経験

  弊社では代表を含め設計事務所勤務の経験があるスタッフが在籍しております。
  建築とはその世界に浸かってみないと分からない暗黙の文化みたいなものがあります。コンピューター技術は習えてもこの文化みたいなものはなかなか経験以外での習得は難しいようです。 建築分野に特化したシステム作りを通じてお付き合いしてきたお客様もそのほとんどが建築関連の企業様で、この貴重な経験を過去の業務で培ってきました。専門的な視野でシステム開発のお手伝いが出来るように日々心がけております。