読者です 読者をやめる 読者になる 読者になる

好きなことを好きなぶんだけ

podcast もやっています http://lean-agile.fm/

JUGG CCC 2013 Spring

当日殴り書きメモ

14:15~ Java Small-Object Programming

はじめに

  • 9つのルール、DDDなどを総称してSmall-Objectとしている

S-OPって?

  • 小さくつくろう
    • テストしやすさ、可読性
    • Javaの冗長さ
    • FWの定番化
    • DDD、9つのルールなどの出現
  • S-OPの実現

APの現状

  • FWは安定している(SpringMC、MyBatisなど)
  • BLが理解しづらく変更容易性がない。テストしにくい。(1000行、意味不明なクラス名)
  • ビジネスの変更への対応 → BLの変更
  • システムは変わり続ける

Javaの抱える問題

  • オブジェクト指向的でないPGが容易にできてしまう。(C言語チック)
  • 冗長な構文(アクセサ、toString、equals、close、trycatch)
  • よくある問題:検証処理がちらばる。

S-OPの具体例

  • プリミティブ型、Stringはすべてラップする。
    • String code; って誰が桁数知ってるの?
    • Codeクラス。(フィールドクラス)
    • Validationもドメインクラスにはかかず、フィールドクラスにかく。
  • フィールドクラスを利用しないデメリット
    • たとえばStringとした場合、修正箇所を探すこともできない。(shohinCode, shohinCd)
    • バリデーション処理が重複。全部直さなきゃいけない。
    • 仕様書がないと、商品コードの仕様がわからない。
  • フィールドクラスを利用するメリット
    • 利用方法と仕様がひとめでわかる
    • 検索が楽
    • 修正は常に一箇所
    • 仕様書がなくても保守が楽。
  • 不必要なアクセサは記述しない。
    • 不必要なSetterでは? 不変だったりしない?在庫は減らしたり、増やすものじゃない?
    • 不必要なGetterでは?
  • FWを利用する。
  • 例外やログなど、本質的でない処理はSpringなどのFWに。
    • close, trycatch, log

9つのルールとDDD

  • 設計と実装をみなおす9つのルール
    • エクササイズ
  • DDD
    • ドメイン層 → フィールドクラス
    • フィールドクラス → ValueObject
    • Employeeクラス → Entity
  • DDDやらないといけない?
  • S-OPはトランザクションに不向き?
    • 所謂、入れポン出しポンのBLがないAPに最適
    • 少ないフィールドクラスで実現できる。

自動生成への道

  • DDDのモデルからフィールドクラスを自動生成。
  • ExcelやテキストベースUMLから。
  • SpringWebFlow。

3つの世界:エンタープライズ、ソーシャル/ゲーム、スタートアップ

デブサミ2013 1日目

10:00〜 (14-B–1) 3つの世界:エンタープライズ、ソーシャル/ゲーム、スタートアップ

玉川憲氏(司会)/三谷慶一郎氏/伊藤直也氏/孫泰蔵

IT業界は2つの世界に分かれたのか?

エンタープライズ、ソーシャル系で全然文化がちがうように見える。

  • エンタープライズ
    • 資本力、業務系、IT=インフォメーションテクノロジー
  • ソーシャル/ゲーム
    • 新技術の採用を厭わない。IT=インターネットテクノロジー。
  • ワーク・シフト(書籍)
    • 今までの常識を見直さなければならない。
    • 変化に目を閉ざすな。
    • 過去の成功にとらわれない。
    • 働き方を予測する。
    • 未来について後回しにしない。
  • 自分の属する世界から距離をとって見る。

三谷さんより(エンタープライズ

自己紹介

エンタープライズのいままでとこれから

  • いままで
    • 省力化、自動化中心
    • バックオフィス業務中心
    • 信頼性、安全性、高品質を重視
    • 成功要因は、要求仕様収束と大規模PJの安定的推進
    • 領域としては今後も存在
    • グローバル化
      • グローバル企業への対応
      • グローバルリソースのマネジメント
  • 民間投資の伸び
    • 日本はほとんどない。1995年から横ばい
    • 米国は5倍
  • IT投資と効果(生産性の向上)
    • 米国:80年台は効果があまりなかった。00年台で相対的に大幅に伸びた。
    • 日本:80年台は効果がとても上がった。00年台で相対的に下がってしまった。
    • 日本に80年台に効果があがったのは、現場レベルの高さ。(省力化、自動化が効果的)
    • 2000年台は、企業を変革する方向に変化している。
      • 日本ではそもそもこの「付加価値向上」に方向が向いていない。
  • これから。
    • バックエンド×自動化 → フロント×付加価値創出
  • CIOミッションの変化
    • 「ITを活用して新たなビジネスを創出する」
  • IT人材ケイパビリティ
    • システム設計、開発 → PM → ITマネジメント → 業務改革 → マーケティング
      • これらは積み上げである。
  • これから。
    • ITでしかできないことをやらなければならない。
    • フロント業務中心
    • 迅速性を重視。Quick & Dirt
    • ユーザとともに構想する「デザイン型人材」
      • 言語化されていない課題の発見
      • 解決に向けた集合知の活用
      • 評価を繰り返すことによる成熟化
    • 新しいパラダイムへシフトしていくために、スタートアップ、ソーシャル/ゲームと協調していく必要がある
  • アメリカができて日本ができなかった理由
    • 文化、組織。ダメなら潰す、トップダウンの文化がアメリカにある。

伊藤さんより(ソーシャル)

自己紹介

  • niftyはてなGREE
  • サーバ/インフラを支える技術 (書籍)
  • 大規模サービス技術入門 (書籍)

WEBサービスの世界

  • 2つのB2C
    • 既存のビジネスをITで提供
      • EC、交通予約とか
    • ITそのもので価値提供を行う。
      • 検索、SNS、コミュニティ、ゲーム
  • これまで
  • PostPC
    • PCインターネットは終わった。
      • 儲かったのはGoogleだけ。飲み込んだのは広告ビジネスの資本のみ。
    • WEBの理想が相対化された。
  • 開発トレンド
  • 現状の課題
    • モバイルプラットフォームの寡占、アプリストアの飽和
    • 国内市場の相対的縮小・飽和
    • WEBの大衆化
  • 地域別利用者
  • Consumerization
  • 成功例
  • あるべき姿
    • 建前のないベストプラクティス
      • WEb開発が生み出した最良のものを使う。
    • モバイルインターネットの波には抗えない。
    • WEBはインターネットになった。(ホッテントリ

孫さん(スタートアップ)

自己紹介

  • Yahoo 創設者との出会い
  • 元・学生起業家
  • パズドラ

スタートアップ

  • 年間投融資総額
    • 2006年の半額。アメリカの20分の1
  • 悲観的になる必要はまったくない。
    • 統計に表れないものがある。ちゃんと盛り上がってる。
  • 誰でもスタートアップできる時代に
  • EXIT戦略は、M&Aが主流に
    • いまやIPOは殆ど無い。
    • マネタイズの話はナンセンス。
      • 客を集められるだけで、買収される。
  • ベンチャーのカジュアル化・大衆化
    • スタートアップムーブメント
  • シリコンバレー
    • 300万人人口
    • 17,000社/年 - 12,000社/年 = 5,000社/年
    • ベンチャー生態系がある。
      • 起業家育成、融資プログラム、起業支援、投資家育成、産学連携、再起業支援、ネットワーキング
  • 目標
    • 2030年までに東アジアの世界一ベンチャー生態系をつくる。
  • 能力のあるプログラマー、エンジニアはスタートアップに引っ張りだこ。
  • バンドを組むようにスタートアップすればいいのでは。
    • 役割が集まったら、スタートアップ。
    • うまく行かなかったら解散

パネルディスカッション

ウルトラエコシステムでどんな影響が?

グローバル化で働き方はどう変わるの?

  • スタートアップにおけるグローバル化(孫さん)
    • 最初からグローバル視野
    • 先に英語で開発することを推奨している。
    • グローバルは強制ではなく、チャンスだ。
    • 日本語で作ってしまうと、日本文化の暗黙の了解で作ってしまう。
  • エンタープライズにおけるグローバル化(三谷さん)
    • 国内に閉じた開発は無理がある。目と目の会話はない。ネットワーク越し。
    • グローバルに攻めるエンタープライズ開発も。
  • ギークはどうする?(伊藤さん)
    • github では当たり前。英語で作れば英語でpullrequestがくる。
  • インド人の英語は独特だが、欧米人が理解しないと仕事にならない。逆転現象。
    • そういうものを日本でも起こす。

参加者質問:三谷さんからデザイン能力の話があったが、ドメインを理解し俯瞰できるウルトラマンがいればスタートアップするのでは?エンタープライズに必要?

  • 三谷さん
    • お客様に入り込み、顧客の見えないニーズ/課題を見つける。一緒に考える。というのをデザインと表現。
    • 問題発見、問題発掘の能力が重要。
  • 伊藤さん
    • 役割分担が重要。
    • オバマの件も、CIエンジニアがキーマンになった。
      • 別にその人はオバマに興味がなかったはず。

参加者質問:ソーシャルへの人材流出がある。エンタープライズでの開発者へのフォーカスの手段は?

  • 三谷さん
  • 伊藤さん
    • SIerからの転職のモチベーションは、8割が「自分の作ったものに対するフィードバックがほしい」。
    • まっとうなフィードバック。使われている実感。が必要。

まとめ

  • 働き方を予測しながら、幸福と豊かにする働き方を。
  • 所属する世界における本質を見るには?
    • 違うフィールドを見る。自分のフィールドを距離をおいてみる。
  • 三谷さん
    • Open, Speciality, Professionalism
    • 自らのスペシャリティを確立が必要。
    • どこのために何をやるのか。をいまいちど。
  • 伊藤さん
  • 孫さん

たのしい自分戦略 -セカイとカイシャと自分の仕事を考える-

http://devlove.doorkeeper.jp/events/2503 参加時の殴り書きメモ

まず

  • 自分戦略を踏まえて「会社」を考える。
  • アジェンダ
    • 会社とはなにか
    • 会社と自分との関係を考える
    • スタートアップと目標設定
  • 会社はツール
    • 使われるものじゃなくて使うもの
  • 使いたい会社とかかわる
    • なければ使う。作らせる。

前振り

  • 自分戦略をやりたくない。。。
  • ソフトウェア技術者の戦略
  • 客観的でもなければ、実力勝負でもない。
  • 個別ケース以上は話しづらい
  • 起業
    • 全力でリスクを取れるか、リスクを下げられる事情がある場合にはいいけど
  • 成功した人はバイアスがかかる。
  • 失敗した人は語りたがらない
  • 現実から全力で目をそむける
    • (現実がみえなくなるくらい)マクロの視点で

会社とはなにか

法人とは

  • 民法(一般的な話) + 会社法(会社固有の話)
  • 民法での規定
    • 権利を有し、義務を負う
  • 法人 = 人間みたいな人の集まり
  • 自然人 = 普通の人
  • 任意団体
    • 銀行口座がもてない
    • 団体として会場が借りられない
    • 何かあったら個人に責任が降ってくる
  • 法人
    • 営利法人、非営利法人、法人以外
    • ポイント;営利
    • 営利団体は、構成員に利益を還元できる。→非営利はできない。
  • 営利団体
    • 合議制だと、意思決定がやりづらく、冒険がしづらい

会社の問題点

会社と自分との関係

会社とどう向き合うのか

  • 目的があったほうがはやい
    • お金が欲しい、は実現方法が難しい。結論が出づらい。
  • 何かやりたいという動機
    • ひとりではできない、
    • 会社はツール
    • 会社なら平日の昼間からできる。
    • うまくいったら利益
    • 組織を大きくしやすい
    • 個人では扱いづらいこともできる
  • 問題
    • 「やりたいこと」は都合よくみつからない。
  • 体験談
    • はじめるまで1年
    • 利益がでるまで3年と数百万
    • 簡単ではない。
  • やりたいことの実現方法
    • 社内の事業
    • 他社と組む
    • 個人でやる
    • 非営利団体でやる。
    • 自分の会社
      • 時間を投入できる、しばらく赤字でもOK、関係者にも安心感、本気度は伝わる。
  • 「あったらいいな」から始める
    • あったらいいなを考える。
    • 実現方法を考える
    • 実行する。

スタートアップと目標設定

  • 大きい言葉(「世界を変える」)
    • 開発現場とのギャップ
    • ついうっかりつかってしまう
    • 本当に変わるの?
  • なんで大きい言葉を使うのか?
    • 会社は遠くの目標がほしい。
    • 会社は何をやってもいい。
      • 何をしていいかわからなくなる。
    • 適用しないと死ぬ
      • 迷走と区別がつかない
    • 変わらない目標は、遠くの目標になってしまう。
      • 多少ブレても誤差の範囲
      • 無限遠点の目標
  • でもすべてがそうではない。
    • 「Social Change」
    • ケント・ベック XP入門
      • 「ソフトウェアは新たな社会構造を創る機会がある」
    • オブジェクト指向PGのためのパターン言語
      • 25年前
      • ずっとブレない
    • 本気で変えようとしつづける。

ダイアログ

すすめ方

  • 新しい事業に思いを馳せる
  • 共有
  • 付箋に書いて貼る
  • 全員で話す

共有

  • Sunにはピープルマネージャーという役職がある。
    • 部下を売りこむ。
    • タレントとしてどうするか。
    • コミュニケーション担当マネージャーもいた。
    • エンジニアはコミュ力なくていい。

まとめ

  • 会社に負のイメージがないか?
  • でも会社ってよくできてる。
  • 「会社」ができること。可能性。
  • 会社はツール

Selenium 2 (WebDriver) でinput項目に半角カナを入力する

Selenium 2 (WebDriver) で input 項目に日本語を入力する方法ですが、そもそも前回のエントリの前提が間違っていました・・・WebElement#sendKey()で日本語送れますね・・・。
ただ、半角カナ(笑)が正しく入力できません。(たまたま事情があって半角カタカナでテストしてた。)

ちなみに、前回のエントリで無理やりな方法で実現しようとしていました。ただ、その後何度も試しているとどうにも挙動が安定しない・・・。

特に Selenium Grid(リモートノードにテストを配信してSeleniumテストを実行できる)を使って別ノードでテストを実行していると、WebDriver#get() で JavaScript スキームを送信したあと、テストが止まってしまうという現象が起きました。(HTTPステータスコードの関係かな・・・。)

前回の記事に追記した「クリップボードを経由する方法」は、よくよく調べてみると java.awt.Toolkit#getSystemClipboard() を使う方法だったので、ローカルテストであればOKでしたが、リモートでテストする Selenium Grid ではもちろんうまくいきませんでした。

・・・と困っていると、前回のエントリのコメント覧にずばり解決方法を書いて下さった方がいました。ありがとうございます。以下で解決です。(半角カナもOK。)

// input項目に日本語を入力
WebElement element = driver.findElement(By.id("foo"));
JavascriptExecutor js = (JavascriptExecutor)driver;
js.executeScript("arguments[0].value=arguments[1]", element, "テキスト入力");


しかしこの JavascriptExecutor#executeScript() メソッドの可能性は無限大ですね。これさえあればなんでもできそう。
ちなみに JavaDoc はここです。


と、ここまで書いたことろで、@ITSelenium WebDriver の記事の後編(Selenium WebDriverのブラウザ自動テストを実践する)が出ていることに気が付きました。
サンプルコードで WebElement#sendKeys() の引数に日本語渡してますね。そりゃそうだ。

Enterprise User eXperience Design - ユーザー中心設計の実践 -

http://devlove.doorkeeper.jp/events/1931 の当日書きなぐりメモ

ユーザ中心設計(UCD)による、ユーザーインターフェース開発のススメ(前編)

市場の動向、顧客の状況

ユーザビリティとユーザエクスペリエンス

ユーザビリティ・エンジニアリング・プロセス

  • とは?
  • UDXとは
    • 使いやすく魅力的なシステムや商品をデザインする
  • UCDとは ISO9241–210
  • The Elements of UX
    • 表面、骨格、構造、要件、戦略
  • プロセス
    • 現状調査→現状分析→ペルソナ作成→要件抽出→プロトタイピング→評価→(満足するまで循環)

デザインセンターの設立

  • プロダクトオーナーと開発側に
  • 2007年に設立。2011年に正式組織化。
  • きっかけ。自動車会社のデザイン部門。UnifiedDesign。
  • 疑問
    • 評価軸がないのでは?
    • 美的センスがいるのでは
    • ユーザ前提によって異なるのでは?
  • 米国の例
  • 日本でも

最も大きな課題

  • ソフトウェア開発プロセスにどのようにユーザビリティ・エンジニアリング・プロセスをとりいれる?
    • ウォーターフォールにどうやってUCDとはを組み込む?
    • コストはどうやって見積もる?
    • どこを探しても答えが見つからない。
  • 要件定義後に、UI設計、UIガイドライン
    • プロトタイピングがない。だめ。
  • 要件定義工程にて実施。プロトタイピングもやる。(準委任契約でやる。)
    • 現在は一部開発でやっている。

ユーザ中心設計(UCD)による、ユーザーインターフェース開発のススメ(後編)

UXとは

  • 機能がある Utility → 使いやすい Usability → 嬉しい・楽しい User Experience
  • UXの例 → iPhone、Piano Stairs、World’s Deepest Bin
  • ビジネス上の目的が裏にある。
  • UXのハニカム構造

適用事例

Selenium 2 (WebDriver) でinput項目に日本語を入力する

<後日追記>
解決しました。
Selenium 2 (WebDriver) でinput項目に半角カナを入力する

以下元記事
--------
テスト自動化を本気でやらねばと思って、Selenium 2 (Selenium WebDriver) の検証をはじめてみました。

@ITの記事(iPhone/Android含むブラウザ自動テストの最終兵器Selenium WebDriverとは)を参考にインストールして、「ブラウザ勝手に起動したすげー」「画面勝手に操作してくれるすげー!」「スクリーンショット自動でとれるすげー!!」って無邪気に感動していたのですが、一瞬で壁にぶち当たりました。


テスト対象Webページのinput項目(テキストボックス)にどうやって日本語入力すればいいの??


WebDriver.sendKeys() はメソッド名のとおり、キーシーケンスを送るだけなので日本語は送れません。
つまりこれ↓はダメ。

driver.findElement(By.id("foo")).sendKey("テキスト入力");



ググってみてもなぜか同じ悩みを持つ人が見つからなかったので、ええい、ということで「Webdriver.get() メソッドjavascriptスキームを渡して、JavaScriptを無理やり送る(いわゆるブックマークレット)」という無茶な方法を思い立って、試してみました。
つまりこう。

driver.get("javascript:(function(){document.getElementById('foo').value='テキスト入力'})();");
// jQueryが入ってるページならこれ↓でも。
driver.get("javascript:(function(){$('#foo').val('テキスト入力')})();");



思いの外ちゃんといける。

こんな感じで↓メソッド化して、、、

protected void inputTextById(WebDriver driver, String id, String inputText) {
    driver.get("javascript:(function(){$('input[type=text]#" + selector + "').val('"+ inputText + "')})();");
}


よしおk!
ってほんとにいいのかな??この方法、これはこれで色々応用できそうなのでいいですが、日本語入力については、もっとちゃんとしたやり方があるような気が・・・。うーむ。


<30分後追記>
と思って改めて調べてたら、クリップボードを経由する方法があるみたい。明日試してみよう。

SIエンジニアの自分戦略 -急がば回れ、選ぶなら近道

http://devlove.doorkeeper.jp/events/1733 の参加時かきなぐりメモ

業務系SEの今後について 〜消費税増税年金問題が与える影響

自己紹介

  • 外資M&A
  • 流通系上場企業の役員
  • ITベンダーの役員
  • キャリアの共通点

現在の社会状況 マクロ

  • 年寄りが増える
    • 清算価値が現象
  • 社会的コストの増大
    • 社会インフラの維持コストの問題
      • 公共事業で景気維持というスタイルの後遺症
      • ランニングコストを考えていない
    • 全体パイの縮小均衡
      • 人口減、売上の減少、コスト削減の圧力

現在の社会状況 個人

  • 年金問題
  • 消費税の増額
  • 実質所得は減少する

産業別人口

  • 日本人のIT技術者は多い
  • でも給料は安い

IT業界

  • PGの生産性は、10倍以上の開きがある。
  • であれば、できるやつの給料をあげろ
  • 本当に?
  • 他の業界ではあっても三倍。
  • なぜ差がない?
    • そんなにずれたら商売にならない。
  • なぜ差が出る?
  • そもそもばらつきがひどくないか?
    • 参入障壁がない。
    • 受託が、人数で数合わせをしているモデル(できなくても無理やり)

そこで経営層は普通どう考える?

  • できるやつの給料を上げる前に、できない奴の給料を下げる。
  • でも実態は、、、「できない奴の給料を上げないついでに、できるやつの給料も適用に据え置く」
    • 他人が給料あがったことのマイナスは、自分の給料が上がったことでは補えない
  • つまり、「人が多く、給料がやすい」+「能力のばらつきがひどい」→据え置き

ITのありかた

  • SI自体が成り立たないという現実
    • 人力で大規模SIに頼る現実
  • かつ、一人あたりの賃金が上がる要素はゼロに近い
  • ノーチラスは、人を増やさない。なぜなら給料を上げられないから

SIの現実

  • SI屋
    • 単純な売上増を安易なSIで稼ごうとする。
  • ユーザ層
    • ITリソースを外部から調達すれば良い
    • ITは本業ではない、と公言するユーザ様に顕著
  • この需要と供給で成立してきた。
    • 「市場としてのビジョン」は皆無。
    • 市場を維持しようというモチベーションが薄い
    • IT 業界特有
    • 結果として成立しているだけ
    • 「なくなるときに簡単になくなる」

業務系SEの現実

  • 認識すべき背景
    • マーケットとして厳しい
    • 企業環境として給与は上がりづらい
    • 年金・消費税の問題
  • 「どうすべきか?」
    • マーケットがどう変化するか
    • 変化するマーケットにどう自分自身をビッドするか
    • 賭けるチップは手元にある?

マーケットがどう変化するか

  • SIビジネスは縮小する
    • ゼロにはならない
  • 中規模・小規模SIの増加
  • SI自体の数の現象

変化するマーケットにどうビッドするのか

  • 少ない人員で回せる仕組みが必要になる
    • 100人月→70人月
    • 50→20
  • ある程度マルチでできることが必要になる
    • 能力のある人間が1.5役
    • 単一能力ではなく、複数の領域でのノウハウ
      • レビューをまわして、
  • 業務屋のニッチな仕事はむしろ増える
    • 物流システムは、倒産しやすい
    • 業務知識の豊富な人材が必要

手持ちのチップは十分か

  • 手持ちの武器は何が必要か
    • カードは多ければ多いほどいい
    • 最強–1のカードを目指す
  • スーパースターになる必要はない

エンジニアとしてのキャリアパス

  • 単一の道で最強をめざす
    • おすすめしない
    • 日本で最強はない
  • 複数の道で最強–1をめざす
    • おすすめする
    • 90点を100にするではなく、30を90に。
    • 50では妥協しないが、100はめざさない
  • それ以外は
    • 転職する

経験値として

  • 歴史は繰り返している
  • 車輪の作り直し
    • 作るべきかどうか、と再考する。(「作れる」は重要)
  • 流行に飲まれるな
    • 一回退いた上で、自分なりに咀嚼して「目的をもって」取り組む

何もしないとどうなるか

  • まずは実質所得が下がる
  • SIビジネスは縮小する
  • モチベーションとか、生きがいたおか、そういった精神的な充足のまえに生きるのがつらい

いままでと何が違うのか?

  • 座っていても大丈夫という時代は本当になくなる
  • SNS等のつながりで情報の流れが早い
    • 選択肢の幅
    • 競争の激化
  • 企業の壁が薄くなる
  • 勉強するモチベーションと、自分の脳力をどう評価するのか、ということが非常に重要になる

何をカードにするか

  • 設計
    • 普通の設計
      • 要素技術に依存しない
    • 例外処理を拾えること
      • やりすぎても、やらなくても死ぬ。程度を抑える。
    • 設計時点でパフォーまんすボトルネック
  • アーキ
    • すべての基本はI/O
      • 架空物理改装をちゃんと理解
      • 限界を理解
      • パフォーマンスはアーキで決まる
    • 障害設計から考える
    • 「何が何をするのか」がわかるようにしておく
  • アプリ
    • 基本はPM
      • WF、WBS、課題管理
    • 要素技術の共通点
    • 書き過ぎないこと
      • 書かない技術
      • 少ない人数でどうするか
      • 手をどう離すか
  • インフラ
    • とにかく情報収集
      • ただし枝葉はいい
    • ネットワークの基礎技術は抑えること
    • ハード
  • 運用(継続開発)
    • 設計が命
      • 運用設計は絶対一度は経験すること
      • 今まで見えなかったものが見える
    • CIのマスター
    • コスト意識
  • 基礎技術
    • 「計算」についての基本知識
      • 計算量
      • 確率統計
      • 計算とはなにか
    • 「品質」についての基本知識
      • 品質は作りこむもの
      • 手法は様々だが、完璧なものはない
      • 予見可能性が高いもの」 = 「品質が高い」
        • どうなるかわからないもの
    • 論文は読めるようになっておくこと
      • 巨人の肩に乗るべき
  • 業務系ノウハウ
    • 「考える」
      • なぜこういう仕組みになっている?
      • 書籍を読む。基礎知識を積む
    • 「聞く」
      • なぜなのか?
      • いやがられるけどめげない
    • 「応用する」
      • 大事なのは個々の仕様ではない
      • 「考え方」を学ぶこと
        • 考え方には文化がある
        • 感覚。センス。
        • 顧客の印象もよい
      • 「考え方」を常識にとらわれず転用する。

Q&A

  • 少数精鋭部隊がどうやって受けられるのか?
    • 受けないほうがいい
    • 大規模のSI自体を見直す
    • 受注側が発注拒否している
  • 大手SIerにいたままそうやって?
    • 中でちゃんと提案する。
    • ケンカ別れは簡単
    • こうしてったほうがいいですよ。
    • 部の意見はこうだ、で経営層にかけあう
  • エンドユーザ側にたってイノベーションを起こせないか?
    • それはある。
    • その人のモチベーションを維持するのが難しい
    • コストもまっさきに切られる。
    • R&D部隊
    • 実際のユーザ企業にはいると、ギャップはあるよ。
    • ヤル気のある取締役
  • USのユーザ企業は流動性が高い。すぐに首切れる。日本ではどうする?
    • 別の業務をやらせる。
    • PMを必ずやっているのはIT業界ぐらいだ。
  • シュリンクするSIの受け皿は?
    • コアな人間を引きぬく
  • 質の悪い人材をどうやって引き上げる
    • 論理的にものが書ける人間をとる
    • 二年間しっかりトレーニング
    • できないなら取るな
  • お金がないけどやる、のはどうすればいい
    • やるな。SIの悪いところ
    • やるなら投資だから、回収計画を上に立てさせる。