NDS35に参加しました。

第35回NDS（長岡開発者勉強会）に参加しました。

第35回勉強会(2013/01/18) & 新潟開発者新年会(NDS) - 長岡 IT開発者 勉強会(NDS)

今回のテーマは、「設計（≒デザイン）の話をしよう」。 ゲストスピーカー3本とLTの構成になっております。

所感（というかメモ）

所感を書こうと思ったけど、うまくまとめきれないので、 備忘録的なメモ書きが中心です。

設計（≒デザイン）の話をしよう (@masaru_b_cl)

まずは、高野さん (@masaru_b_cl) の発表から。 スライドはこちら。 ブログにも解説がありました。

高野さんの経験から設計（≒デザイン）について「当たり前」の話をしゃべるとのこと。

設計（≒デザイン）とは「ソリューション」である ソリューション（問題解決） 「何を」「どのように」「どうやって」 「どのように」は「どのようにするために」といった目的に近い感じかな。

設計の進め方

1. 目的の明確化
2. ゴールの設定
3. 対応手段の決定

目的の明確化については、「何が問題か」という、 問題解決の前に問題発見を見極める必要があるということ。

ライト、ついてますかあたりを もう一度読み直してみよう。 このあたりが「何が問題か」のアプローチのヒントになるはず。 そして、原因や前提条件等も明確化する必要がある。

問題を明確化した後はゴールの設定。そして、対応手順の決定。

このあたりを短いスパンで回していくのが良さそう。 発表でも「小さく繰り返すことで洗練される」とあったので、 KPT、PDCA等でふりかえりしながらやっていく。

設計の重要ポイント

1. 一貫性
2. トレードオフ
3. アフォーダンス
4. スキルである

「設計はスキルだ」は、結構重要かな。 また、アフォーダンスについては、 この世の原理、原則みたいなものに反しないようにすることかな？ これに反することが特長となりうる利点なのか、やっぱり欠点なのかは、肝なのかもしれません。

一貫性については、Joel on Software第五章をもう一度読み直してみよう。

設計する上での課題

1. どこから設計する？
2. どこまで設計する？
3. ゴールの設定はどうやる？
4. 意識の外の問題はどうする？
5. 完全には防げないよね？

この辺りは「設計はスキルである」ということから、 繰り返しながら少しずつ身に付ける必要がありそう。 今回の発表内で挙がった内容や、各種書籍で挙げられているパターンやツールを使いながら、 時間がかかってでもやらなければならないと感じました。

あまりにもおかしな設計にならないためにも、 短いスパンでふりかえりが必要なのかな。

以下、メモ

• 設計の一貫性とは？
  • 一貫性から標準化が生まれる
  • 『標準化を守ってるから一貫性があるのではなく、一貫性を保つための指針が標準化なんだよ！』
  • 「一貫性」「バランス」って便利な言葉だ
• 「守破離」
  • 物事の本質を理解していなければ、「守破離」はできない。
  • においとかも「なぜにおうのか」を言語化できなければ、
• yagn
  • 守るとどこまでやればいいのかわからなくなる
  • ゴールの線引きが難しい
    • 問題を改めて考えてみるのがよいかも
    • 優先度をつけてみる

最後の質疑応答で「魂」の話になったりして、面白かった。

ソフトウェア開発のInput→Architecture→Structure

つぎに、尾上さん (@ugaya40) の発表。 MVVMの人ですね。

パターンなんだけど、パターンにはまらないなどのお話

以下、メモ

以下、発表で心に残ったものをメモ。

• ソフトウェア開発の理想
  • Input -> Structure
• ソフトウェア開発の現実
  • Input -> 複雑さに対する各種対処（Architecture）-> Structure

「Architecture が Structure を定義する！」ってなるほどと思った。

• Architectureとは、 すべての複雑さに対する対処のこと。工学的には「関心事の分離」。
• アプリケーションはそもそもドメイン（問題領域）に対するソリューションである。
• Architecture Pattern
  • アーキテクチャ記述の一種
    • GoFのあれとかはStructure Pattern
  • GUI Architecture Pattern など
• 例：MVC
  • MVC系
    • MVC系の何がViewpointで何がViewなのか
    • Viewpoint: Presentation Domain Separation
      • プレゼン部分とそれ以外の部分にわけるだけの視点
    • View:
      • 各プラットフォームで異なるMVC
      • PDSの視点を適用した結果がMVCの各プラットフォームで異なる図になる
• Architecture記述はStructure記述ではない
  • アーキテクチャ設計=関心事の分離のための記述だから、 Viewpoint（視点）ありきでView（アーキテクチャ記述のview）がある。
• SIerのWebシステムとかは「Transaction Script」。
• C/Sやスマホアプリ等のリッチクライアントとかは状態管理しなきゃいけないので、 Transaction Scriptでは破綻する。
• いろんなアプローチがある。

まとめ

• アーキテクチャは複雑さへの対処
  • アプローチは関心事の分離。
• アーキテクチャの表現のされ方
  • アーキテクチャを単一のViewで記述できない
  • アーキテクチャは複数のViewpointとViewで構成されるアーキテクチャ記述で表現される

マーティンファウラーの「Presentation Domain Separation」は 後日読んでみようかな。

発表内容は、自分の知る「アーキテクチャ」の概念が実は誤りだったかもしれないので、 聞いてて混乱してきた部分が多い。 いろいろ調べて理解しないと、やばいなこりゃ。

組織設計の基礎理論と実践

最後に、Matsuki**さん (@liliput) の発表。

発表について、ブログでまとめられております。 長岡で話したこと / 話さなかったこと #NDS35 - エルの楽園

以下、メモ

「組織設計」って言葉は、個人的にはあまり耳慣れない言葉でした。 組織を設計するということは、プロジェクトマネジメントのようなものなのかなと思った。

プロジェクトマネジメントについては、今後いろいろとやらなければならない立場なので、 お勉強中だったりする。 小規模プロジェクトからやらさせていただいているけど、 なかなか大変ですね。

組織設計も、他の設計と同様に、 「何を」「どのように」「どうやって」をしていくことであって プロジェクトマネジメントも同じかなと。

以下、気になった言葉のメモ

• 時間を区切って考える
  • 時間軸から考える組織運営
    • 目標はいつまでに達成？
    • その期間、どのように組織は変化する？
    • 目標が達成されたとき、その組織はどうなる？
  • ある一定の期間で、いろいろと変化するはず
• 時間経過による構成員の流動
  • 組織への流入 - 構成員をどう選ぶ？
  • 組織の運営 - 構成員の品質をどう保つ？
  • 組織からの流出 - 構成員が去った後どうする？
• 戦略？戦術？
  • 戦略：目的とリソース配分方針の設定
  • 戦術：上記条件を達成するための手段
• 戦略と戦術との本当の関係
  • 現状のリソースと持っている戦術
  • 単純な階層構造ではなく、スパイラルでフラクタルな関係にある。
  • 戦略はテンポラリでプライベートなものであり、当事者以外の誰にも作れません。
  • 戦術はユニバーサルで、条件さえ合うならば、他の局面でも応用可能
• リーンでアジャイルなスタイルを組織にも…
  • PDCAでまわす
  • 最初からすべてを詰め込まない
  • すべての人を巻き込む
• 状況変化への対応と問題解決のために
• 根拠とは
  • 誰でも参照できる
  • 誰が見てもそう判断できる
• 内面化
  • クレイトン・クリステンセン「イノベーションのジレンマ」
• 偉い人が「ルール」を作るだけでは誰もついてこない。
• 1ヶ月から3ヶ月で人間の価値観は変わる。
• 組織の中で気づかないうちに何がおこっているのか？
• いかなるシステムがそれを再生産し続けているのか？
• 調査をしやすくする下地を作るために有効なあの手この手
  1. 数会話
     • 具体的な思考の癖がつく
     • 客観的に行う習慣ができる
     • 時間や労力、予算、進捗といった主観的な状況記述にコンセンサスがとれる
  2. Job Descriptionを書いてみる
     • 「職務記述書」と呼ばれたりする。
     • たとえ実際の人事プロセスに反映されないとしても、
     • 「自分たちの業務は何なのか」「どういう人材を望ましいと考えているのか」の コンセンサスをとってみる。
     • 技能的側面 + 情意的側面 = 能力
       • (competency) + (personality) = (Ability)
  3. Evidence Based Scheduling
     • Joel Spolsky氏提唱
     • 各タスクにかかる時間を測定し、それらのデータから統計的に作業時間を見積もる。
     • 「Joel on Software」
  4. 「射撃しつつ前進」
     • とりあえずやれることをやるだけやってみる！
       • 「試験的に」／「この部分だけ」／「ちょっとの間」
       • 改善策を最初から完璧に実行しない
       • 正負に関わらず、どんなフィードバックがあるかを冷静に観察する
• 何が起こっているのかを把握する。
• これらの方法だけでは、問題を解決しません。
• 何が起こっているのかを知る手がかりの一部を教えてくれるし、 原因追求を可能にする「土壌」を作ってくれる。

メインセッション感想

今回はすごい回でした。 自分の理解している事、理解不足の事、 初めて聞く言葉も結構多かったですけど、 いろいろ感じるところがありました。

「何を」「どのように」したいのかを考える前提があって アプリケーションだったりプログラムだったり組織だったり、 いろいろな場面で「設計」が役に立つこと。 改めて思い知らされました。

あとは、Joel on Software読むべし。

LT

今新潟で勢いのある「ウォーターセル」勢から、 いろいろとLTがありました。

「PHP駆逐！」だったり、「iPadすげー」だったり、 面白いセッションでした。

懇親会

所用があったので、懇親会は欠席となりました。 NDS（Niigata Developer’s Shinnenkai: 新潟開発者新年会）も行われたのに、 参加できなかったのが心残り。