システム工房よろず屋

遅ればせながらドロップシッピングとやらに手をつけてみました。
といってもまだ登録して、デフォルトのＨＰを公開しただけですが…

今はまだデフォルト状態ですが今後は少しずつ変更してみたいと思います。

良かったら時々見にきてみてくださいね。

http://www.sk-yorozuya.jp/shop/

最近、めちゃくちゃ忙しい…

ブログに色々書きたいのですが、なかなか時間が取れないです。

１日、２日の徹夜は当たり前状態なので体を壊さない程度にペースダウンしないと…

システム開発者の皆さん。

徹夜作業ってやっぱりかなりありますか？

雑記です･･･（＾＾；

ここ最近、週末になると異様にアクセス数が多いのはなぜ？？？

フィデリさんが何かテストでもしてるのかな…

常時このくらいアクセス数があるといいんだけどな…

せっかくだから何か書いてって…

システム工房よろず屋です。

システムの開発を依頼する時に数社から見積依頼を取ると思いますが価格の
バラつきが多く悩むことがしばしばあるのではないでしょうか？

その差については大きいときには倍以上の開きがある(価格)という話も聞いたり
します。

開発業者からの提案内容(対応範囲)、類似実績の経験、スキル等、その背景には
色々な要因が隠れていると思いますが、実はそもそもの単価設定(人月単価)にも
大きな差があるようですね。

単純にSE、PGといったざっくりとした括りで単価を見た場合、私の知るところでも
倍以上の開きがある場合があります。

たくさんの背景があるため、価格の妥当性を見極めるのはお客様にとっては非常に
難しい課題ではないかと思います。

高いから良い、安いから怪しいと言う事もなく、また、高いから諦めて安いから
入れるのでもなく、やはり、一社ずつ詳しく話し(提案内容)を聞き、よく吟味する
ことが大事になってくると思います。

前述のような背景があるので、色々な事情が考えられる為、文章ではっきりと答えを
出すのは困難なのですが、一つ大事なことはお客様自身が「これは簡単、これは難しい」
と判断しない(先入観を持たない)事が重要ではないかと思います。

見た目や、言葉で一口に言うと簡単に聞こえますが、処理上の観点から考えると
意外に処理が大きいこともありますし、反対に難しいと思っていたが意外に簡単に
できる場合もあります。

この先入観を外し、自分達が第3者のつもりで数社の提案を聞いてみると、妥当性が
見えてくると思います。

単価設定については、システム開発だけに限らず、どの業界にも地域差があると
思うのである程度はやむをえないと思います。

通常であれば打ち合わせ、メンテナンス等で地域差を懸念したりすると思いますが、
システム開発の場合、メンテナンスや不具合発生時の保守等において地域差を
埋める方法はいろいろと考えられます。

提案内容の他、万が一の場合の保守体制を問い合わせてみると地域が離れていても
安心して任せられる場合があるのでぜひ問い合わせてみてはいかがでしょうか。

システム工房よろず屋です。

少し日が開いてしまいましたが、先日書いた「プロジェクトの管理」について
続きを書きたいと思います。

３）担当者のスケジュール(各フェーズの期日)、成果物を明確にする
　「作業が終わった？　よしよし」ではまずいですよね…
　何らかの形で何かに記述しなければ終わったとはいえません。
　特に若いエンジニアは書類を書く習慣が薄い傾向があるので、自分が欲しい
　書類を打診してあげます。
　お互い面倒ですが習慣になってしまえば良いだけの事ですし。

　ちなみに私のところではWordやExcel、PowerPoint等ではなく、基本はテキスト
　ファイルです。

　凝ったものである必要は必ずしもあるわけではないので、テキストで残し、
　図や絵が必要な場合のみExcelを使っています。
　更にエディタに簡単なマクロを作成してあって、簡単なテンプレート化を
　図っています。

　Excelも凝った資料を作るのではなく、シンプルなものにして、補足が必要な
　部分を吹き出しで補足する程度。

　自分達だけが見るものであればこれで十分です。
　但し、後で見て「ここってどういう意味？」とだけならないようにすれば
　良いのです。

４）レビューや打ち合わせもスケジュールに含める
　調査や資料作成が終わると、レビューを実施していると思います。
　ですが、このレビューや、レビュー結果を反映するための時間をスケジュールに
　含めておくことも重要です。

　レビューを経て戻り工数が発生すると、その分遅延が発生してしまいます。
　担当者は必要以上に焦ってしまい、しなくて良いミスをしてしまうかも知れない
　ですし、レビュー結果がおざなりになり、結果として意味のない時間を過ごした
　事にもなりかねません。

　それならいっその事、レビューと結果を整理する時間をしっかり取っておいた
　方がはるかに無難でしょう。

　また、レビューまで一気に進めてしまうのではなく、ミニレビューを途中に
　挟むのもかなり有効です。
　これを行う事によって、方向性がずれるのを極力防ぐことが可能です。
　進捗会議の中で簡単に確認でも良いですし、帰宅前に「調子はどうだ？」と
　確認するだけでも十分な効果がでてきます。

　ミニレビューには実はもう一つ、効果があります。

　上のように簡単に確認するだけでも、私達もある程度状況がわかりますので、
　レビュー時間の短縮にも繋がります。

　自分の負担を下げることにもなりますのでぜひ試してみてください。

５）費用の管理を行う
　プロジェクトが予定通り進んでいるかを判断するのは、スケジュールだけでは
　ありません。
　例えば、ある作業に3日かかって、予定通り終了していたとします。
　しかし、担当者は1日8時間×3日=24時間で終わっているとは限りません。
　実は毎晩2,3時間等の残業を行いながら間に合わせていたかも知れません。
　日程上、いくら予定通りであっても、実作業の工数がオーバーしていれば、
　そのプロジェクトは赤字になります。

　日程の他、実作業工数＝費用も定期的に確認し、各担当者にあった作業を
　割り当てているか、特定の担当者に異様に負荷をかけていないかなどを確認
　する必要があるでしょう。

システム工房よろず屋です。

今日はプロジェクト管理について書きたいと思います。

開発のプロジェクトってなかなか予定通りに進まない(進んでいない)と
思いませんか？

多くの場合、何らかの問題が発生し一部の作業が予定より時間がかかって
しまう、しかもその問題が中盤以降に発生したりする。
結果、再度検討のしなおしが入り日程が遅れてしまう。

こんなところではないでしょうか？

なくしたい現実ですが、なくすのはなかなかに難しいところではないかと
思います。

プロジェクト管理を行う際、ベテランの方たちは実践されているかと思い
ますが、主に下記のような点が盛り込まれていない場合、このような問題
が発生することが多いのではないでしょうか？

　１）作業を細かくフェーズ分けする
　２）リスク回避の為の作業(時間)もスケジュールに含める
　３）担当者のスケジュール(各フェーズの期日)、成果物を明確にする
　４）レビューや打ち合わせもスケジュールに含める
　５）費用の管理を行う

この５点を管理すれば、なくすまではいかないまでも大幅に軽減できる
のではないかと思います。

この内、今日は２つについて書きます。

１）作業を細かくフェーズ分けする
　　先日、「細かく細分化された管理が行われていそうだが、実際には
　　数個の大まかな工程にしか分けられていないことが多い。」と触れ
　　たが、単純に思いつく工程というのは大項目であることが多い。
　　それらの項目の中に実は更に細かいフェーズが隠れているはず。
　　最初の段階で、いかに細かい項目まで細分化できるかが鍵となる。

　　基本的な工程はどの開発もほぼ同じなので一度雛形を作成すれば
　　多くの場合に流用でき、規模・難易度に合わせて工数を当てはめる
　　だけです。　一度この部分に時間をかけしっかりと洗い出してみて
　　ください。

２）リスク回避の為の作業(時間)もスケジュールに含める
　　プロジェクト管理の最大の目的は、起こりそうな問題をできるだけ
　　回避することだと思います。
　　未解決の部分があっては正確なスケジュールは立てられません。
　　開発者は得てして得意なところから着手しがちです。
　　未解決部分を真っ先に解決できるような線表を引きましょう。

　　これはＳＥだけに限ったことではありません。

　　私はまず、自分がヒアリングしてきた内容を全員に伝えます。
　　そしてその後、数日の時間を与えるようにしました。

　　数日間の中の作業は以下です。
　　　・自分の役割の中で、今回の案件に対し不明な点を洗い出す
　　　・洗い出した点について報告させる
　　　・調査し、結果を報告させる
　　その結果を見てスケジュールを立てる。

　　もちろん、私の考えるスケジュールもありますから、それも最初に
　　伝えておき、皆からの結果を見て再度練り直します。

　　抱える課題は人それぞれです。
　　ある人は既知の問題でも、ある人は悩んでいるかも知れない。
　　レベル、スキルは一人一人違うのでまず各個が抱えている不安部分を
　　洗い出し、トレースできるところ、調べなければならないところを
　　明確にするところからはじめます。

その他についてはまた後日この場でお話できればと思います。

システム工房よろず屋です。

システム開発を行っているというと、パソコンやツール・システムをフル
活用しているように感じる人もいるかも知れないが、決してそんな事はあ
りません。

見た目的には複数のパソコンを使ったり、モニタを複数繋いで何やらカタ
カタやっているのでそう見えるかも知れませんが、意外とアナログで管理
もずさんだったりする事があります。

その一つが仕様書。

まず、プロジェクト管理について

細かく細分化された管理が行われていそうだが、実際には数個の大まかな
工程にしか分けられていないことが多い。
開発会社のリソース不足ということで案件を受ける事がありますが、その
際に頂く資料からもそれが伺えるので、事実そういうところが多いのでは
ないかと感じている。

ざっくりしたプロジェクト管理では全ての工程がざっくりしたものになり
がちです。
スケジュールもざっくり、仕様書もざっくりと…

次にスケジュール管理

ざっくりとしたままプロジェクトが進むため、スケジュール管理もざっく
りとしがちです。

トラブルは大きくなった時点、なりはじめた時点でやっと気が付く、重要
な調査が最後に回っているなどから開発日程が遅れる事にも繋がってしま
います。

次に各仕様書類

本来で言えばコーディング(プログラミング)前に作成されるべきものなの
ですが、コーディングが終わった後、ソースコードを見て作られている事
が結構多い。
「ウチの仕様書は正確で細かいです」　…当たり前です！という話ｗ

最後にテスト仕様書

デバッグレベルの仕様書が多い、正常系(動いて当たり前)の仕様書が多い
気がします。
コーディング担当者が作成することが多いので、作ったとおりに動くこと
を確認する資料になりがちです。
作ったとおりに動くのは当たり前なので、デバッグレベルの仕様書になって
しまうのです。

正常な異常系、予期しない異常系も踏まえてこそのテスト仕様書ではない
だろうか。

書類自体の管理というより、作成自体(中身の管理=精査?)がずさんなことが
多い仕様書。

仕様書は内部に留まり、お客様に提示されないことが多いのですが、納期が
他社に比べ、異様に早い・価格が異様に安い場合などはこれらの作業が簡素
化されていることにより、完成だけが早いだけなのかも知れませんね。
(必ずしもということではありません)

自分達は違う！と思いながらも書いていて「胸が痛い」内容でした…

システム工房よろず屋です。

システム開発に必要な技術…　というと、どうしても各言語に関する
コーディング技法、リファレンス、サンプルが真っ先に浮かんでしまう。

現に参考になるサイトを探すとこれらのサイトはものすごく多い。
確かに私達も参考にさせて頂き、助かっています。

しかし、これらはシステム開発に必要な技術というより、コーディング、
プログラミングに必要な技術ではないだろうか？
(狭い意味での技術にとどまっている)

システム開発に必要な技術はそれだけではありません。
他の業種にも当てはまると思いますが、
　1)実現する為のコーディングではなく、信頼性や柔軟性を高める手法(技法)
　2)仕様書の重要性、見やすい・分かりやすい仕様書の書き方
　3)要求を的確に分析する手法
　4)開発効率を上げるための手法
　5)テストの手法(漏れ、問題点の発掘)
などではないだろうか？

これらの参考になるサイトというと極端に数が少なくなる。
本当に重要な部分は公開されない、文章としてまとめるのは難しい、
ブログやHPにまとめるには限界があるなど色々な理由があるのでは
ないかと思います。

私はプロのライターさんではありませんので、偉そうなことを言っても
私自分も上手にまとめることはできないでしょう。

ですが、自分の中で抱いている思い、実践している(させている)ことは
ありますので、下手ながらも今後少しずつこの場で書いていければと
思います。

システム工房よろず屋です。

システムの導入を検討されている方、果たして導入する事により効果が出ると
思いますか？
システムを導入された方、今後導入されたシステムにおいて効果が出ると
思いますか？

開発業者の観点から正直にいうと…

「そこそこ効果は出ます」

という回答になります。

まず、よほど使い勝手の悪いシステムでなければ少なからず作業効率は
上昇傾向になります。

次に現在手作業で行っている作業をルール化し、システム化(自動化)
する(されている)事により、更にワンステップに効率をアップすることも
可能です。

しかし、現実には効果を実感できなかった方も大勢いらっしゃることかと
思います。

ぶっちゃけた話をすると、かかった金額に比例する効果が出ていないと
いうことです。

では、なぜそのような感覚、結果をもたらしてしまうのでしょうか？

私はIT技術の進歩の度合いと、お客様の認識の弱さがあるのではないかと
思います。

IT技術の進歩は真に日進月歩です。
発注した業者が最新、最適な技術を有している事が必須となってきます。
また、遺憾ながら国内での新技術の誕生は非常に少なく、新技術の大半は
海外(英語圏)ということも理由の一つかも知れません。

日本人は外国語に抵抗を感じがちである事実は否めません。
言語のギャップから積極的な取り込みが遅れてしまうというのが直接の
原因でしょう。(日本語化されてから利用することが多い)

次にお客様の認識の弱さです。

最近、特に最新技術に目敏いお客様が増えている気がします。
技術の指定が多いこともしばしばあります。
しかし、最新技術だけが本当に良いのでしょうか？
頂くご要望を満たすには何も最新技術だけに捉われる必要はありません。
ぜひ、システム会社の技術提案にも耳を傾けてください。

また、頼りすぎも厳禁かと思います。
開発会社は開発のプロであってもお客様の業界、社内に関するプロでは
ありません。
(極端な話、システムは仕様さえ決まれば業界やお客様社内の事は一切
　知らずも構築できてしまいます)

お客様の業界、社内に関しては「お客様がプロ」なのです。

プロとプロのコラボにより初めて効果的なシステムが完成するのでは
ないでしょうか？

要望を伝えたから、あとは開発会社任せではなく、ぜひ一緒にシステムを
導入するという認識で御社の困っている内容やシステムの状況をさらけ
出してみてください。

きっと更に効果的なシステムの導入に繋がることと思います。

------------------------------------------------------------------

システム工房よろず屋は、効果的なシステムを導入させて頂くために
お客様と共に作るシステムを重視しています。
また、お客様社内の状況を把握し、改善するための情シスサポートも
承っております。

お悩みの点、ご相談等ございましたら遠慮なくお問合せください。

　→お問い合わせ：sales.f@sk-yorozuya.jp

システム工房よろず屋です。

私達の本業はソフトウェア・システム開発ですが、案件を受注する上で
コンサル的立場から参画させて頂くことも非常に多いのが現状です。

また、SOHOの方達には個人でコンサルをなされている方もいらっしゃる
かとおもいます。

ここではSOHOの立場でのコンサルタント業務について思うことを書いて
いきたいと思います。

まず最初は会社勤務のコンサルタントとSOHOコンサルタントの違いに
ついて書いてみたいと思います。

■違いとして思いつく事
　1)学習の場
　　会社勤務のコンサルタントは、先輩や上司コンサルタントの仕事を
　　学びながら(盗みながら？)、経験を積んでいくことが出来るかと思
　　います。
　　対してSOHOコンサルタントの場合、名乗ったその日からコンサルタ
　　ントです。
　　　→会社勤務の場合はスキルを身につける環境が少なからずありま
　　　　すが、SOHOの場合は一定のスキルがないと仕事に結びつきませ
　　　　ん。

　　私も偉そうに人の事はいえませんが、世の中には自称コンサルタン
　　トが大勢いるのではないでしょうか？
　　(もちろん非常に高いスキルを持つコンサルタントも大勢いるかとは
　　　思いますが、そのスキル差は計り知れないでしょうね…)

　2)営業の場
　　会社勤務の場合、営業マンがいて仕事を見つけてきてくれますが、
　　SOHOの場合、自らが営業しなければならず、その営業もなかなかに
　　難しいのではないかと思います。
　　　→自ら「コンサルさせてください」と営業することは考えにくい
　　　　(実質ない？)と思われるからです。

　　「仕事を下さい」的な営業をせずに依頼が入ってくる仕組みを確立
　　するのは容易ではないでしょう。

　3)価格帯
　　コンサルというと価格が高いイメージがありますが、一定のステー
　　タスを得ている企業の話だと思います。
　　　→SOHOの場合、大半は比較にならないほどの低価格になっている
　　　　のではないでしょうか？

SOHOコンサルタントとしてはこの"差"をいかにして埋めていくかがネック
かな？と感じています。