カメログ

_ ソフトウェアアーキテクトが知るべき97のことをそれぞれ3行にまとめてみた

O'REILLYから発売されている「ソフトウェアアーキテクトが知るべき97のこと」の全コラムを、それぞれ3行程度の文章にまとめてみました。これを読めばあなたのアーキテクト力がアップするかもしれません。もっと詳しく内容を読みたくなったら本を買ってみてくださいね。

エントリーの最後にコラムのテーマの統計を載せましたのでこちらも参考まで。

01　システムの要件よりも履歴書の見栄えを優先させてはならない - ニティン・ボーワンカー

• 自分の履歴書にかっこいいことを書きたいから、という理由である技術を使うことを選択してはいけない。顧客のために最善の選択をしよう。

02　本質的な複雑さは単純に、付随的な複雑さは取り除け - ニール・フォード

• Keep It Simple, Stupid. 付随的複雑さをなくし、本質的な複雑さに集中できるようにすること。ベンダーのソリューションは、多機能で使えないことがあるので、それが必要か、現場のニーズにフィットするために工夫すること。

03　最大の問題は、たぶん技術的なことではない - マーク・ラム

• 話し合いを大事にしよう。

04　まずコミュニケーション、そのための明快さととリーダーシップ - マーク・リチャーズ

• チームはリーダーシップを必要としている。あなたがリーダーシップを発揮すれば、コミュニケーションが円滑になり、職場環境が良くなる。

05　パフォーマンスの決め手はアーキテクチャー - ランディ・スタッフォード

• パフォーマンスの決め手は、根本的なロジック、配備環境にある。チューニングには限界があるよ。

06　要求仕様の本当の意味を探れ - アイナー・ランドル

• 顧客のニーズを聞くことを目的とするミーティングを開いて、なぜその機能が必要なのかたずね、本当の要件を調べよう。

07　立ち上がろう！ - ウディ・ダーハン

• 立って話すと、威厳と自身が伝わる。そしてコミュニケーションがうまくいくようになる。

08　すべてのものは、かならずエラーを起こす - マイケル・ナイガード

• 予想外の原因でエラーが起こってしまうことを想定し、救済措置を提供しよう。

09　それは交渉だということに気付け - マイケル・ナイガード

• 3台目、4台目のサーバがいらなくても、要るって言おう。スポンサーはできるだけ節約しようとするから、これくらいから交渉しないと必要なスペックさえ削られてしまう。サーバが余ったらビルドマシンにすればいいしー。

10　定量化を求めよ - キース・ブレイスウェイト

• 非機能要求を数値目標化することが大事。

11　500行の仕様書より1行のコード - アリソン・ランダル

• 仕様が不出来なら実際の制約にあわせて仕様を書き直せ。コーディングに時間を使え。

12　フリーサイズのソリューションを求めるな - ランディ・スタッフォード

• 解決すべき問題より、汎用的で大きな規模のソリューションを作って適用しようとすると、性能問題に陥ったり、非合理な提案をしてしまったりする。ニーズにあった解決法を提案できるようにセンスを磨け。

13　パフォーマンスの検討に早過ぎるということはない - レベッカ・パーソンズ

• パフォーマンス用件に基づいてアーキテクチャの選定、設計を行え。パフォーマンステストは開発の初期から行うこと。どの変更でパフォーマンスが落ちたのかわかるから。

14　アーキテクチャーとはバランスを取ること - ランディ・スタッフォード

• 技術的な問題だけでなく、プロジェクトにかかわる利害関係者のビジネス要件との間でバランスを取ること。

15　犯罪的なコミットエンドランを防ぐには - ニクラス・ニルソン

• テストしないでコミットすることは悪、という文化を育てる。また、テストしやすい環境を整えること。

16　選択肢を1つに絞らないための現実的な方法 - キース・ブレイスウェイト

• 非機能的な要請によって、システムが分割される、データを正規化できない、などの必要が生じうることを頭においておこう。

17　ビジネスサイドに主導権を渡せ - デーブ・ミュアヘッド

• 開発者はビジネス判断ができない(判断に必要な情報を持ってないため)ので、チャート、プロジェクト初期から動作するソフトを提供するなどして、ビジネスサイドに開発状況の情報を与える必要がある。

18　一般性より単純性、再利用よりもまず最初に使えること - ケブリン・ヘニー

• YAGNI大事。汎用性を求めるときは、具体的な問題を解決する視点を忘れないこと。

19　アーキテクトは手を汚さなければならない - ジョン・デービーズ

• アーキテクトはスーパー技術者でビジネスについても理解しているすげー人になるように努力せよ。

20　継続的にインテグレーションを実行せよ - デビッド・バートレット

• 継続的インテグレーション大事。定期ビルドするシステムを作れ。

21　日程による失敗を避けるために - ノーマン・カーノベール

• リリース日を早めるよう要請されたら、まずもともとの日程を維持するよう交渉する。無理なら優先度の低い機能のリリースを後回しにするように交渉する。交渉スキル大事。

22　アーキテクチャーではトレードオフは避けられない - マーク・リチャーズ

• アーキテクチャ選択にはトレードオフがあることを考慮せよ。

23　要塞としてのデータベース - ダン・チャック

• DBにバグがあったら大変なのでちゃんと設計すること。アプリにバグがあっても変なデータが入らないようにすると安心。

24　不確定性が潜むという感覚を磨け - ケブリン・ヘニー

• 設計の判断に困ったら、影響を最小限にする方法を考えよう。どういう分割やカプセル化をすべきだろうか？と。

25　鏡に映る問題は見かけよりも大きい - デーブ・クイック

• リスク管理に組織的に取り組む。
• リスクを伝える方法を探す
• いやなにおいをかぎつける習慣をつける。
• 自分の理解を絶えずチェックする。顧客と定期的にコミュニケーションをとる
• 信頼できる、問題を指摘してくれる人を見つける。
• リスクを避けるために

26　再利用は、アーキテクチャーだけではなく人と教育の問題と心得よ - ジェレミー・メイヤー

• 再利用できるものがあることを知り、その使い方を知り、それを使った方が自分で作るより良いことをチームで共有しよう。

27　アーキテクチャーにI（自我）なし - デーブ・クイック

• 要件、チームに敬意を払え。自分がやってきた仕事、自分の態度を見直して謙虚になれ。

28　地上300mからの目 - エリック・ドーネンバーグ

• ソースコード視覚化ツールを使ってプログラムの大雑把過ぎず、細かすぎない状態を把握しろ。そして構造のバランスをとれ。

29　選ぶ前に試せ - 　エリック・ドーネンバーグ

• 最終的に決断する前に、複数の選択肢をメンバーに試させる。判断材料が増えて十分になった、または決断すべきタイミングが来たタイミングで、どちらを選択するか決める。作業量は増えるが、まずい選択をしたときに失うコストに比べればまし。

30　ビジネスドメインを理解せよ - 　マーク・リチャーズ

• アーキテクトはビジネスを理解せよ。そしたら偉いさんから信頼が得られる。

31　プログラミングは製造ではなく設計だ - アイナー・ランドル

• プログラミングは製造じゃなくて設計だよ。アジャイルの開発管理手法を使うと投資効果を最大限に引き上げるよ。

32　デベロッパーに自己裁量を与えよ - フィリップ・ネルソン

• デベロッパーがプログラミングしにくかったり何度も同じ失敗をしているなら、プログラミングしやすいように設計を変更しよう。デベロッパーの仕事を監視するのではなく、ある程度自分たちで判断させて、困ったときに相談しに来るように環境を築きましょう。

33　時間がすべてを変える - フィリップ・ネルソン

• 真の要件を聞き出すようにしよう。いつも過去の仕事を見てうんざりしてしまうので、シンプルに設計しよう。新しいソリューションを使うときは、それが本当に役立つか自分の尺度で判断して使おう。

34　「ソフトウェア・アーキテクト」のAは小文字だけ。それで満足せよ - バリー・ホーキンス

• ソフトウェアアーキテクトなんて弁護士、医師、建築家の仕事と比べると全然洗練されてない。もっと謙虚になれよ。

35　大きなスコープは敵 - デーブ・クイック

• 本来のニーズを理解する(顧客に質問しよう)
• 分割統治する(複数の小さな仕事の方が簡単)
• 優先順位をつける(重要な仕事から行える)
• 成果をできるだけ早く引き渡す(フィードバックが得られる)
• スコープが大きくなると管理できなくなる。管理できる範囲にスコープをとどめるには、

36　役者ではなく執事になれ - バリー・ホーキンス

• アーキテクトは自分の都合でなく、顧客のニーズにしたがって行動しよう。

37　ソフトウェア・アーキテクチャーが倫理的な意味を持つことを考えよ - マイケル・ナイガード

• 自分が楽をするためにユーザに不便を押し付けるようなプログラムを作ってはならない。ユーザはその機能を使うたびに時間をロスするので、結果的に損失がすごく大きくなる。

38　摩天楼はスケーラブルではない - マイケル・ナイガード

• 小さなコンポーネントに分けて開発、デプロイを行おう。

39　未来はヘテロジニアスとともにある - エドワード・ガーソン

• アーキテクチャの選択は複雑になってきつつある。でもそれは選択肢がないよりいいことなので、ポジティブにがんばろう

40　パフォーマンスがまず大事 - クレイグ・ラッセル

• たとえば1日1回走るバッチ処理に24時間以上かかると使い物にならない。パフォーマンスに気をつけよう。

41　ダイアグラムの空白に注意せよ - マイケル・ナイガード

• ダイアグラムでそっけなく描かれてる箇所には実際には考慮すべき実装上の懸念点が多くあるものだ。そこに注意して。

42　デザインパターンに習熟せよ - マーク・リチャーズ

• アーキテクチャについて簡明かつ効率的にコミュニケーションをとるために、デザインパターンは大事。アンチパターンも便利。

43　状況が何よりも大切 - エドワード・ガーソン

• 状況によって必要なものは変わってくる。その状況にフィットしたソリューションを選ぶべき。

44　ドワーフ、エルフ、ウィザード、キングの4種類の人々 - エバン・コフスキー

• アーキテクトはリーダーとしていろんな種類のメンバーが、互いを学びつつ仕事を進めていけるように、目標を設定すること。いろんな種類の人間がいることは大事。1種類の人間しかいないと、対応できない障害に直面すると立ち往生してしまう。

45　建物のアーキテクト（建築家）から学ぼう - キース・ブレイスウェイト

• 建築家の言葉はソフトウェアアーキテクトに通じるところがあるので、参考にしよう。

46　繰り返しと戦え - ニクラス・ニルソン

• プログラムから重複を取り除くようにがんばろう。

47　現実の世界にようこそ - グレガー・ホープ

• プログラムの動作モデルは昔よりシンプルでなくなってきているけど、びびるな。並列実行可能な設計、エラー処理などでしのげ。

48　支配せず、観察せよ - グレガー・ホープ

• コードの可視化ツールを使って、関節、モデル抽出、整合性チェックを行おう。

49　アーキテクトは2つの顔を持つ - デビッド・バートレット

• 今の要件をこなしつつ、組織が成長し、技術が進歩する将来に向かって維持、拡大できるシステムを作ること。

50　アーキテクトは境界とインターフェイスに注意を注げ - アイナー・ランドル

• コンテキストマップを描いて、分割統治しよう。

51　デベロッパーに力を - ティモシー・ハイ

• デベロッパーの仕事をしやすい環境を作って、優れたデベロッパーチームを構成しよう。やることは、ツールがいきわたるようにすること、反復処理の自動化を行ってデベロッパーの負担を減らす、デベロッパーの教育、デベロッパーの採用、開発環境の準備など。デベロッパーを本質的でない仕事から守りましょう。

52　理由を書き留めよ - ティモシー・ハイ

• 労力を必要とせず、コストに見合う効果を期待できるドキュメントがある。それは、決定した理由を書きとめたドキュメントだ。それには決定内容、理由、却下した代替案と却下理由を書いておくこと。また、検索可能にしておくこと。これにより、決定には理由が必要になる。また、決定に影響を与えた条件が変わったときに決定を見直すための資料になる。ほかにも説明するときなどに便利。

53　暗黙の仮定、特に自分自身のものを疑え - ティモシー・ハイ

• 仮定を見えるようにする。それは歴史的な理由、個人的な見解、デベロッパーの口コミ、FUD、廊下で耳にしたこと、かもしれない。事実と事実を起こした暗黙の仮定はソフトウェアを支える柱になる。仮定の論拠ははっきりとさせておくこと。

54　あなたの知識と経験を共有しよう - ポール・W・ホーマー

• 一人一人が知っていることは少ないので、業界レベルでみんなの情報を共有しよう。

55　パターンの病理学 - チャド・ラヴィーニュ

• 不必要にデザインパターンを使うのは本末転倒だからやめよう。必要なケースでのみ使うようにしよう。

56　たとえ話の使いすぎに注意 - デビッド・イング

• メタファーを使うのはコミュニケーションが手探り状態のときだけにしよう。無駄に使うと意思疎通を阻害するよ。

57　アプリケーションの保守に力を入れよ - ムセディシ・カスパー

• プロジェクトの早い段階で、保守リーダーを開発チームの中心メンバーに据える
• サポート計画にも保守リーダーを参加させる。
• リリース後のトラブルをなくすには、保守を考慮すること。やれる対策は、

58　3つから2つだけを選ぶ覚悟を決めよ - ビル・デオーラ

• 理想の性質を全て満たすのは無理なので、必要なものを選ぶこと。

59　趣味や個人的な意見ではなく、原理原則に従え - マイケル・ハーマー

• 自分の経験、意見、趣味でシステムを作ってはいけない。原理、原則に従って設計すれば、誰でも早く理解できます。

60　動くスケルトンから始めよ - クリント・シャンク

• まず動くスケルトンプログラムを作成し、完結性を保ったままで成長させていきます。そうすればフィードバックを早く得られ、すばやく対応でき、サイクルは短くなります。ユーザが求める品質にはこの繰り返し作業が必要です。

61　データがすべて - ポール・W・ホーマー

• プログラムの動作を理解するなら、扱うデータに注目すること。コードを追ってても役に立たないが、データは複雑度がコードより低いので理解しやすい。システムのもっともコアな部分はデータです。

62　単純なものは単純に - チャド・ラヴィーニュ

• YAGNI大事。将来必要になることを推測しても、50%の確率で間違い、49%の確率で大きく間違う。それよりは必要な問題だけ解決して設計をシンプルにしましょう。

63　アーキテクトは何よりもまずデベロッパーであれ - マイク・ブラウン

• メンバーから信頼を得るために、またソリューションが実現可能か見積もるためにアーキテクトはコーディングを行え。

64　ROI変数を意識せよ - ジョージ・マラミディス

• アーキテクチャー上の判断を一種の投資と考え、それに伴う利益/損失を計算しましょう。それは1つ1つの選択肢がどのていど現実的で適切か判断する上で役に立ちます。

65　目の前にあるのはレガシーシステムだという前提で設計せよ - デーブ・アンダーソン

• リリース後のシステムはレガシーシステムになります。別のチームがバグの追跡をしなければならなくなった、という想定を持って、システムはコードが明確に、テストが簡単にできるように、各部分が設計どおりに動作するように、コードを見たことがない人がシステムを見てエラーを診断士、フィックスに取り掛かれるようになってなければなりません。

66　解決策が1つしかない場合には、セカンドオピニオンを求めよ - ティモシー・ハイ

• 解決策を1つしか思いつかないときは、何か問題があります。そういう時は経験のある他人に助けを求めなさい。それを他の選択肢と比較しなくても自動的に解決策が分かってしまうときは、さらに悪質です。他人に助けを求めましょう。

67　変化の影響を把握せよ - ダグ・クロフォード

• システムにかかわる変化をツールやテクニックを使って影響度合いを予測しておこう。

68ハードウェアの理解も必要 - カメル・ウィックラマナヤケ

• ハードウェアの性能計画を立てるために、ハードウェアの知識もつけておこう。知識がないと見積もれないよ。

69　今の近道、後で大損 - スコット・マクフィー

• アーキテクチャ上の問題点や設計の欠点を見つけたときには、コストのかからない今の段階で修正することを主張すべき。

70　「完璧」は、「十分よい」の敵 - グレッグ・ナイバーグ

• 不備が残っていても、システムの機能、メンテナンス性、パフォーマンスにこれといった影響がなければ、そこで開発を止めよう。それ以上完璧を求めると、設計しすぎてかえってメンテナンスが難しくなります。

71　「よいアイデア」を避けよ - グレッグ・ナイバーグ

• よいアイデアは大抵やっかいごとを持ち込むので、取り入れるな。

72　優れたコンテンツは優れたシステムを作る - ズービン・ワディア

• システムが成功するかどうかはコンテンツにかかっている。十分なコンテンツを集めるように対策を練り、コンテンツの価値を評価しましょう。コンテンツはアーキテクトが扱う問題ではないと思うかもしれませんが、そうではなくなると予想しています。

73　怒れるアーキテクトとしてビジネスと対立するな - チャド・ラヴィーニュ

• ビジネスのドメインエキスパートに敬意を払え。

74　主要な指標の耐久性を試してどこで壊れるかを確かめよ - ステファン・ジョーンズ

• アプリケーション設計の初期で選択したアーキテクチャがどこまで耐えられるか確かめよう。そうすれば将来の決定の指標にもなるし、今の段階で設計変更が必要なことが分かるかもしれない。

75　設計するならコーディングできなければならない - マイク・ブラウン

• 設計の中で、自分が実装したことのないパターンを使うのを避けること。見積もりできないし、落とし穴が分からないし、リスクを持ち込んでしまうから。

76　他の名前でバラを呼べば、キャベツにしかならない - サム・ガーディナー

• 具体的な名前をつけることができないなら、何を作ろうとしているかはっきりさせること。

77　しっかりとした問題には高品質のソリューションが与えられる - サム・ガーディナー

• アーキテクトの腕は、かちっとした自己完結的な問題にすることができるかどうか。問題を正しく設定できれば、シンプルなコードを書くことができ、解決された問題はずっと将来まで解決されてしまう。

78　勤勉さが必要 - ブライアン・ハート

• 有能なアーキテクトは習慣として実践できていないことを思い出すために、毎日、毎週のチェックリストを作り、それに従うようにしている。

79　自分の判断に責任を持て - イ・ジュウ

• 効果的な判断を下せるようになるには、自分の判断プロセスを完璧に把握し、決定アーキテクチャを定期的にレビューし、アーキテクチャとして決めたことが実際に行われるようにし、ドメインエキスパートに任せるべき決定は任せましょう。

80　クレバーになるな - イーベン・ヒューイット

• 愚直に、適切に設計しましょう。トリッキーな設計は、もろいです。

81　武器は慎重に選べ、安易に手放すな - チャド・ラヴィーニュ

• 新しいテクノロジーを選択するときには、それが飛躍的に優れていること、リスク、学習コスト、将来性を考慮に入れること。

82　本当の顧客は目の前の顧客ではない - イーベン・ヒューイット

• 顧客の顧客が真の顧客であることを意識すること。もし顧客が自分の顧客の利便性、安全を軽んじるなら、手を引くことを考えよう。

83　設計した通りにはならない - ピーター・ジラードモス

• 最初に設計したものはそのままうまくいくことはないので、新しい発見があるたびに、継続的に設計を行っていくこと。

84　フレームワークは相性で選べ - エリック・ホーソーン

• フレームワークはそれぞれのドメインを完全に支配しつつ、単純で、控えめで柔軟性の高いものを使うべき。

85　強力なビジネスケースを作れ - イ・ジュウ

• 資金獲得のために、うまいタイミングで、ビジネスに有効なことをもりこんだ説得力のある説明を、予算をつける権限を持っている人に行え。

86　コードだけではなくデータをコントロールせよ - チャド・ラヴィーニュ

• 自動ビルド、テストプロセスの一部としてデータ・スキーマ管理を組み込み、アンドゥ機能を用意しよう。トラブルを避けることができるし、リファクタリングすることもできる。

87　技術上の借金は返済せよ - バークハート・ハフネーゲル

• ダーティフィックスを行ったら、必ず後で正しい修正を行い、適用すること。

88　問題を解こうとするな - イーベン・ヒューイット

• まず問題が適切か考えよう。問題が不要じゃないか？簡単な問題に変えられないか？

89　システムは用具的に作れ - キース・ブレイスウェイト

• 問題を解く前に、ツール自体の面倒を見ないといけないツールは使いにくい。そういうシステムを顧客に提供してはならない。

90　問題解決に情熱を注げるデベロッパーを探して手放すな - チャド・ラヴィーニュ

• 仕事に情熱を注げるメンバーを集めよう。そしてそれを維持するために力を入れよう。

91　ソフトウェアは実際には存在しない - チャド・ラヴィーニュ

• ソフトウェアは物理的な世界のオブジェクトに比べれば変更しやすいが、簡単にほいほい変更できるものではないということも覚えておこう。

92　新しい言語を学べ - バークハート・ハフネーゲル

• ビジネスの知識をつけて、ビジネスの人に説明できるようになろう。

93　未来永劫安泰なソリューションはない - リチャード・モンソンヘーフェル

• 今選んだソリューションは、必ず将来時代遅れのものになる。未来を予測してソリューションを選ぶより、今のニーズに合うものを選びましょう。

94　ユーザーの拒否感情の問題 - ノーマン・カーノベール

• 新しいシステムや大きなアップグレードはユーザに歓迎されないことがある。これは、未知のものに対する恐れや、予算を気にかけているためだ。ユーザの代表者にプロジェクトのサポーターになってもらえればユーザの拒否反応をやわらげられる。サポーターを探して、フォローしよう。

95　コンソメの重要性 - イーベン・ヒューイット

• アーキテクチャを単純にするように心がけよう。やり方は、1つ1つの要件を徹底的に検証することを繰り返すこと。

96　エンドユーザーの立場からはインターフェイスこそがシステム - ヴィナヤク・ヘッジ

• ユーザインタフェースが優れていれば、エンドユーザの生産性が上がります。ユーザインタラクションの専門家をチームに入れましょう。

97　優れたソフトウェアは構築されるのではなく、成長する - ビル・デオーラ

• 大規模なシステムは壊れやすいです。すでに分かっている要件や、ユーザが希望している特性以上に大規模なシステムを設計するのはやめましょう。

日本人アーキテクトによる知っておくべき11のこと

01　アーキテクチャは縦と横の基本構造を持つ - 萩原正義

• 高機能と安定性の両立は、2次元方向の基本構造を持つことで実現できる。

02　ビジネス・アーキテクトを目指せ - 萩本順三

• ビジネスの知識を持ってるアーキテクトはすげーからみんな目指せ。

03　問題にフォーカスせよ - 榊原彰

• 問題を知る、問題を解くためにいろいろ経験しろー。知識つけろー。

04　問題にとらわれるな - 榊原彰

• 問題を理解したら、要求項目にフォーカスしろー。

05　煩雑なことを非属人化し、創造性を高める - 萩原正義

• 全部の作業を自動化することは無理。普遍の規則、原理を発見し、それに基づき自動化するなら有効な解になる。

06　手段的な技術と陳腐化しない本質的な技術 - 伊藤直也

• 手段的な知識をwebや書籍で、本質的な技術を教科書や論文で、両方をバランスよく学ぼう。

07　開発スタイルをデザインする - 小野和俊

• 開発スタイルをデザインしていこう。開発スタイルには原則は存在するが、絶対的なルールはない。最良のスタイルは、メンバー、開発対象、開発状況によって変わってくる。

08　システムではなく、コミュニケーションをデザインせよ - 鈴木雄介

• まずユーザの真の要件に着目せよ。それはなにかとコミュニケーションを取ることなはずだ。それにしたがって開発せよ。

09　移り気な利用者を捉える - 牧野友紀

• クライアントがかかわりたい利用者を想定し、その目的と振る舞いを仮定し、検証を行うことを繰り返す。

10　受動的アーキテクトと能動的アーキテクト - 江島健太郎

• アーキテクトには受動的なタイプと、能動的なタイプがいるが、どちらの場合でも理想のアーキテクトになるためには、事業、プロジェクトがうまくいくかどうかを考えることが大事。

11　説明責任を果たす - 萩本順三

• ドキュメントつくれー。開発中と開発後に必要なドキュメントは別物だー。

統計

コラムをテーマ別に集計してみました。複数の話題を扱っているものは、メインとなるテーマに絞って集計しています。

• 設計 28%
• プログラミング 12%
• 分析 12%
• チーム内のコミュニケーション 8%
• 顧客とのコミュニケーション 6%
• チーム/プロジェクトマネジメント 5%
• 複雑さの管理 5%
• 開発/テスト/ビルド環境整備 4%
• 心がけ 4%
• パフォーマンス 4%
• リスクマネジメント 3%
• 開発ツール 2%
• ビジネスの知識 2%
• ドキュメント 2%
• 保守 2%
• その他 2%

やはりアーキテクト向けの本だけあって設計に関するコラムが一番多いですね。続いてプログラミング、分析についての話題が多いです。コミュニケーションについては意外と少ない印象。でもチームマネジメントまで含めると、結構ありますかね。