ＩＴ勉強宴会 理事長 佐野初夫 １．Salesforce 全般（ただしコンポーネントプログラミングを除く） ２．アーキテクチャー設計 ３．運用レビュー、運用業務設計、運用業務 ４．データモデリング（ＤＯＡ）に基づく業務設計 ＜モットー＞ １．おもてなしの心で設計する →使う方の気持ち、プロジェクトリーダの気持ち、決裁者の気持ちをバランスさせます ２．全てはお客様の成功のために活動します ３．運用業務を「プロジェクト」として管理しメンバ指導します →目的と期限を決める事で達成感を持たせます ＜業務システム開発の現状をこう考えています＞ ２０１０．６、２７年勤めたメーカ系ＳＩ会社を自主退社しました。このGoogleAppsなどのクラウドをはじめとした安いサービスがあふれています。無料で使えるプログラムも多くあります。上流設計が終わればプログラムを作らずにシステムが動いてしまうツールも出ています。 それなのに失敗して何千万、場合によっては何億も損害を出すプロジェクトも後を断ちません。失敗プロジェクトを防ぐために様々な取組がなされていますが帯に短く襷に長しの状態だと見ています。アメリカではプロジェクトを出来る限り小さな単位に分割して一歩ずつ結果を見ながら進めよう（アジャイル）としています。日本では逆にNASAなどの巨大プロジェクトのやり方を持ってきて「形式手法（フォーマルメソッド）」というチェックシート形式で後戻りを減らそうとしています。 プロジェクトが失敗する原因はいくつもありますが、根本原因はシステムが完成した姿が誰にも、もちろん作ってる側も作らせている側も誰もわからない事です。いえ、プログラムがどういうものになるかはわかります。そのプログラム（システム）をお客様の実業務に組み込んだ時にどういう姿になるかが重要なのです。 アジャイルは、動くプログラムを早く小出しに確認する方法論です。合理的ですが、最終目標までどれだけの費用と日数が必要かが事前にわからないため、ＳＩｅｒが請負契約にする事が難しいです。お客様の情報システム部門が開発するだけの技術と人数をお持ちなら採用出来ます。フォーマルメソッドは、数千・数万のチェックシートで抜けを防止する方法論です。期間と費用（人数）に相当の余裕がないと採用出来ないでしょう。まだ研究段階ですが、オーバーヘッドが大きいと思われます。 どんなに技術力があるＳＥ（システムエンジニア）でも言われた事だけを完璧に行うだけではお客さんが望んだシステムになる保証はありません。仕様と実装に大きな溝が出来たようなシステムになりがちです。ただ、ＳＩｅｒ側の立場からするといわれた通りに作る事が言い訳になる場面も多いため、誤った仕様だと思いながらも作ってしまいがちになります。 ＷＩＮ－ＬＯＳＥのコミュニケーションで良いシステムが出来るとは思えません。技術者側は、お客様の表面的な言葉でなく本心・本音を探ろうという気配りが必要です。 その解決策の一番近道がセールスフォースの採用だと確信し、2011年から4年弱セールスフォース・ドットコム社でプリセールスをする事で素晴らしさを啓蒙してきました。ところが大阪には実際に作れる技術者が少ないと感じ開発会社に再度転職しました。 ご相談いただければセールスフォース以外でもその仲立ちを致しますし、最適なメンバを見つけてご提案します。まずはご相談下さい。 ＜資格＞
＜職歴＞ 2017年02月～現在 NPO法人IT勉強宴会 2015年09月～現在（株）テラスカイ 大阪事業所 2011年12月 セールスフォース・ドットコム（大阪オフィス） 2009年10月 NECシステムテクノロジー（出向） 2001年04月 NECネクサソリューションズ（5社合併による会社名変更） 1984年04月 日本電気情報サービス入社（所在地：千里中央→本町瓦町→OBP） 1984年03月 関西大学 法学部卒業 佐野 初夫＠大阪 hatsanhat＠gmail.com ※＠は1バイト文字にして下さい |
ONASへようこそ >