（ジュニア）開発者は、開発/ ITチームでより良いプロセスと実践を推進する必要がありますか？

私はジュニア開発者であり、変更を正当化することができ、チームが作業を完了するのに役立つ場合、チームのプロセスを形作るのに役立つ能力を与えられています。私の過去の企業は、管理から来るプロセスを多かれ少なかれ厳密に定義していたので、これは私にとって新しいものです。

私のチームはかなり小さく、やや新しい（<3歳）です。彼らは欠けています：

• 明確に定義されたソフトウェア開発/作業管理フレームワーク（スクラムなど）
• 強力な製品所有権
• 明確に定義された役割（たとえば、ビジネススタッフが手動テストを行う）
• 定期的なスタンドアップミーティング
• 統合された問題追跡プロセス（ツールがあり、プロセスはまだ開発中です）
• ユニット、システム、リグレッション、または手動テストスイートまたはリスト
• ビジネスロジックとプロセスに関するドキュメント
• 社内および顧客向けのヒントを文書化するナレッジベース

そしてリストは続きます。経営陣は、価値が正当化され、最も重要な作業（開発）が完了するのを助ける限り、改善の実施に対してオープンです。ただし、基本的な前提は、誰もあなたのためにそれをするつもりはないので、実装の所有権を取る必要があるということです。そして、言うまでもなく、上記のプロジェクトのいくつかは、時間のかかる疑いもなく、重要なものであり、明らかに開発作業ではありません。

時間が経つにつれて上記のことを試してプッシュする（後輩の）開発者の努力の価値はありますか？または、「自分のレーンにとどまり」、開発に集中し、プロセスの定義と最適化の大部分を管理者に任せることが最善でしょうか？

これまでのところ良い答えですが、すべての基盤を網羅しているわけではありません。

私の経験では、大学を卒業したばかりの人の多くは素晴らしい理論的知識を持っています。

しかし、それは大きなことですが、実際のシナリオでは知識は根拠になりません。現実の世界では、その理論の多くは平坦になります。または、実際には、現実の世界のシナリオではうまく機能しないことがわかっているので、少なくとも大量の塩を使用する必要があります。

適切な事例：私がずっと前に取り組んでいたアプリケーションは、オブジェクト指向の原理と理論に従ってTに準拠するように設計された、優れたオブジェクト指向理論家によって設計されました。

これは素晴らしいソフトウェア設計の一部でした。

悲しいことに、これは生産とメンテナンスの悪夢をもたらしました。コードベースは非常に大きく複雑であるため、場所を変更することはできません。特にもろいからではなく、とても複雑だったので、何が起こるかを恐れて誰も触れませんでした（元の建築家/設計者は、ずっと後になっていた請負業者でした）。

また、パターンの多層構造と、設計に必要なクラスライブラリが原因で、パフォーマンスが非常に低くなりました。たとえば、画面上のボタンをクリックしてデータベースを1回呼び出すと、数百のオブジェクトのインスタンス化とメソッド呼び出しが発生します。これはすべて、疎結合などを保証するためです。

このアーキテクトは大学教授であり、彼の名前の話題に関する本を数冊持っていました。彼は、商業プロジェクトでプログラマとして1日働いたことはありませんでした。

ソフトウェアを構築する実務経験のある人は、その設計がいかに不可思議なことにつながるのかを理解し、より実用的なアプローチを採用し、システムの保守とパフォーマンスが向上します。

同じことは、新卒者、または実際にあらゆる会社の新入社員として出会う他の多くのことにも当てはまります。理論的根拠から何かが間違っているか、次善の方法であると言われているので、そのように実行するのに十分な理由はないと仮定しないでください。

今でも、この分野で20年以上の経験があるので、一緒に仕事をする会社で物事がどのように行われるかを批判するのは慎重です。ちなみに、物事は私の経験が最も最適なものとは異なることに気づいたが、好戦的な方法ではないことに気付くでしょう。これはしばしば、それらの物事がなぜあるのかについて興味深い会話につながります。物事を変える価値がコストよりも小さいかどうかによって、変化が起こるかもしれません。

物事が良くなるかもしれないと提案することを恐れないでください、しかし、あなたが知っているすべての鼻のない子供として出会うのではなく、単に勉強しようとするだけでなく喜んでいる同僚として出会わないことを常に確認してください理論的な正確さだけでなく、会社の改善のためのプロセスの改善に役立ちます。

はい 、でも細心の注意を払って！

それを明確にしましょう。

ソフトウェアの居住性を改善するよう努力する必要があります。コード/チーム/ビジネス/プロジェクト/管理を見て、最初の対応がシャワーを浴びることである場合、居住することはできません。あなたの最初の対応が「はい！」と叫ぶことであり、オフィスを離れたときに文句を言うなら、あなたの家をより住みやすいものにする必要があります。その感覚、そしてあなたはそれを知っているでしょう。

そうは言っても、あなたは複雑な共感で働いています。単純な変更には波紋があるため、あなたがすることは何でもうまくいかない可能性があり、少なくとも短期的には事態を悪化させる可能性があります。ですから、まず謙虚になります。私は物事が悪いに違いないということを受け入れるつもりはありません。あなたの善意が悪意を持ってあなたをひっくり返してしまうという事実を受け入れます。

問題

最大限の意図を持って、広範な抜本的な変化を起こす必要があると感じるかもしれません。これらの状況が存在することには同意しませんが、少し考えてみてください。現在のシステムは動作しており、あなたとあなたのチームはコードを作成しています。おそらく遅く、おそらく痛みを伴いますが、それは動作しており、皆さんはこれを行う方法の経験があります。あなたは大体何を期待すべきかを知っている、要するにあなたはこのシステムの専門家である。

抜本的な変更の後、おそらく実装者以外の誰も、何を期待すべきかを知りません。要するに、システムのこの部分で全員が初心者レベルにリセットされました。それは良いことではありません。初心者は、時間がかかる新​​しいルールを学ばなければなりません。当時、新参者は練習されていないために間違いを犯しています。これらの間違いはシステムの一部になります。システムは今や一緒に生きなければなりません。

今後の道

スラッシュ、バーン、リビルドが可能な限り最高の場合があります。失われているのは成文化された知識だけであるため、古いシステムで誰も練習していない場合は特に魅力的です。この知識が完全に理解できない場合、すでに失われているため、最初からやり直すことが唯一の選択肢です。逆に、成文化の方法、またはその使用方法に問題はあるが機能している場合、その知識はまだアクセス可能であり、おそらく維持する価値があるかもしれませんが、おそらくそうではありません-決定を軽視しないでください。

もう1つの選択肢は、システムを操作して全員が参照フレームを持つようにすることですが、チームの全員が認識できるようにシステムの小さな部分を変更することです。気づきやすく、習得しやすい。これは、カイゼンと呼ばれるプラクティスの基礎です。開発者向けのフォーミュラは、「ゴールデンヤクのシェービング」のプレゼンテーションで紹介されています。見たり考えたりすることを強くお勧めします。

ですから、あなたの人生を改善する小さなものを見つけてください。状況を修正または改善します。これにより、変更を実践するための練習と経験が得られます。フィードバックが得られることを確認してください。それについてよりよく議論できたか、実際に有用か、システムの別の部分を混乱させたでしょうか。何ができるのか、どのようにそれを行うのかについてあなたの感覚を養います。

今、3つのことが起こりました：

• システムを改善しました。
• システムを変更する方法に関する経験を積んでいる
• チームは、システムの変更に成功したことを確認しました。

あなたの経験が成長し、ぶら下がりの問題を排除するにつれて、システムのより困難な問題に直面し始めますが、少なくともXを変更する必要があると言うときは、改善するために別のものを選択してください：

• 変更がシステムに与える影響を知っている
• どの問題が発生するかを知っている（再学習が必要なルール）
• 変更によって導入される問題を修正または改善するためのいくつかの即時の方法を知っている
• あなたの周りの人々はあなたがシステムに精通していて、それをうまく変えることができることを知っています

はい、できます。しかし...

あなたは注意する必要があります。

私のキャリアの始まり（かなり前）で、「ジュニア」として数か月前のプロジェクトに参加できたのは幸運でした。

私が最初に気づいたのは、（OMG）コードリポジトリがなかったことです！コードのすべてのマージは、郵便でzipファイルを相互に送信することにより手動で行われました。

それで、私も（また新しい）マネージャーに行き、リポジトリを作るべきだと提案しました。答えは次のとおりです。

助けを借りずにコードリポジトリを整理することは、会社にとって新しいことでしたが、今では謙虚な経験になりました。

私がそれをすべてセットアップしたとき、（ショック）誰もそれを使いたくありませんでした。だから私は物事を進めようとしましたが、幸いにも私のマネージャーはそれが重要だと理解していたので、私はサポートを受けました。

しかし、その結果、私はあまり好かれておらず、残念ながらソース管理システムから派生したニックネームを取得しました。

だから、これについての私の考えは、まずチームメンバーを感じ、次に彼らが重要だと思うことを感じます。

たぶん彼らもあなたのようなリストを持っています。たぶん彼らはすべてを通り抜けていて、リスト上のその「こと」をやりたかったのでしょう。たぶん彼らは....（何でも）....

チーム全体を調整する必要があります。

しかし、そうでない場合、あなたはまだ専門的に働くことができます。そして、同じように考えている人を見つけて、それがどうあるべきかを一緒に考えましょう。これが良い結果をもたらすなら、より多くの人々があなたと働き、最終的にそれは「プロセス」になります。

コードと同様に、開発プロセスでも同じです。継続的な改善が必要です。

そうです、あなたは常に改善することを試みるべきです。それは改善することが可能です。

しかし、あなたが働いている多くの人々を覚えておいてください、すでに専門家である可能性があり、彼らは何が間違っていて何が必要かを知っています。

時間が経つにつれて上記のことを試してプッシュする（後輩の）開発者の努力の価値はありますか？

はい、物事を改善するために努力する価値は常にあります。結局のところ、あなたが直面している問題を最もよく知っています。

しかし、あなたが言及したように、解決すべき多くの問題があり、それらの問題の多くはそれほど価値がありません。そして、多くの場所で、あなたの成功や、彼らを擁護するためにより良い位置にいる他の人々にとって、乗り越えられない障壁があります。だから、常にそれがピッキングを意味していても、物事をより良くするために試みるべき事は、あなたがより良いようにしようあなたの時間を過ごすことを。

結局のところ、あなたがソリューションの一部ではないなら、あなたは問題の一部だからです。

はい。しかし、組織の変更は高齢者にとっても難しいので、実際に違いを作りたい場合は、正しい方法で変更してください。

• 最初の数週間ではない：この時間は次の目的で使用します。

  • 良い最初の表現を作成します。チームに合っていることを示します。
  • 文化と政治またはあなたの会社を理解してください。変更をプッシュしても安全ですか？
  • 同僚と良い関係を築く
  • チームのプロセス、ルール、ニーズについて学ぶ
  • あなたの仕事を学び、できる限りのことをしてください。きっと忙しいでしょう。

• 戦いを選択してください。いくつかの初期の勝利を得る：あなたはすべてを変えるエネルギーを持って到着するかもしれませんが、これは非現実的です。ぶら下がっている果物に焦点を当て、あなたのアイデアが機能することを示します。あなたは彼らがより複雑な改善を受け入れることを望んでいます。そして、本では物事が簡単であることを忘れないでください。

• 他者への影響を考慮してください：私は多くのファイルに影響を与えるリファクタリングを行います。たとえコードが改善されたとしても、マージをお尻の痛みに変えないように非常に注意する必要があります。また、彼らがそのように働き続ける理由を理解するようにしてください。テストがないためにスクラムを使用できず、テストされていないコードを本番環境に頻繁にプッシュすることを恐れているのは当然です。現実的なテストを書くことは簡単なことではありません。現在のコードをテストするのは本当に難しいかもしれません。さらに、チームはテストやテスト可能なコードの作成にも使用できません。現在のコードベースはテストするのが特に難しく、リファクタリングする必要があります。この問題を変更するには何年もかかる場合がありますが、少なくとも根本的な原因に集中できます。

• 判断してはいけません。要求しないでください。それを求めて、注意深く耳を傾けてください。これはコミュニケーションが重要な瞬間であり、私たちプログラマーは通常微妙なニュアンスがあまり得意ではありません。役立つテクニックがあります。答えに集中するのではなく、アイデアを押し続けるのは簡単です。最初に、彼らがあなたが彼らのポイントを得たと感じていることを確かめてください。感情が重要であることを理解してください。この変更は彼らに何を感じさせますか？恐れ？不足？怒り？欲求不満？望む？怠け者？愚か？（人々を愚かに感じさせないでください）。もちろん、以前に多くの質問をしたことがあるでしょう。これにより、多くの誤った手順を防ぐことができます。

• 例を挙げてください。文句を言うのは簡単ですが、変更を加えるのは難しいです。結果を表示すると、人々はあなたを信じます。テストを使用しない場合は、ユニットテストを作成できます。他の人がドキュメントを作成していない場合は、Googleドキュメントをチームと共有できます。「OK、それをやる」は可能な限り最良のシナリオの1つであり、それを実現する必要があることを理解してください。この場合、どのリソースが必要になるかを考える必要があります。例：小さなAmazonインスタンスと、Jenkinsサーバーの管理者からの2時間を教えてください

• 小さくてシンプルな（そして安い）を保つ：正式な予算承認を待つことも、上司に高価なプログラマーから貴重な時間を無駄にしていると思わせたくないこともあります。このコードでソフトウェアをレビューしたり、いくつかのオープンソースツールを評価したりするのは素晴らしいことですが、とりあえずリポジトリを使用します。

• クリティカルマスを取得：品質の改善に焦点を当てた人々のグループを集めます。彼らと一緒に会議に行って、助けや助言を求めることもできます。ピープルウェアは、チームの基盤が文字通り生産性を低下させるいくつかの愚かな慣行に反抗する「巨大な現象を起こす」ことを説明しています。これは個々に非常に危険であり、私はお勧めしませんでした。しかし、すべてのグループが同意すれば、変更は簡単になります。

• しばらくしてください。その後、あなたの足で投票してください：あなたは、数ヶ月から2年までの間、それを試してみたいかもしれません。しかし、一部の企業には簡単な解決策がありません。一部のチームは変更を望まず、インセンティブがありません。そして、いくつかのコードベースは純粋な恐怖です。あなたがそれが世界に反していると感じるなら、ジョブプールにはたくさんのオファーがあることを覚えておいてください。あなたは良い習慣を学びたいと思っており、長い目で見れば、わずかに少ない賃金でより良いことになりますが、より価値のある経験を積むことができます。

ボーナス：成功した場合は、履歴書/インタビューに書き留めてください。ジュニアとしては、言うことはほとんどありません。より良い変化をもたらすことは、常に素晴らしい兆候です。自分が何をしたのか、他の人から何が得られたのかについて、非常に明確で現実的な見方をしたいのです。次のインタビューの質問を想像してください。

• チームに変化をもたらした時期について教えてください。
• まあ、私は彼らが非常に昔ながらの習慣を持っていた場所にいました。多くの人々はそれに満足しておらず、生産性には大きな改善の余地がありました。だから私は回顧で高速実験を行うことを提案しました。XとYを実行し、その結果、この素晴らしい測定可能な結果を​​得ました。」

はい。しかし、あなたが提案するものではありません。

リストからユニット/統合テストのみが進捗状況を確認できます。

最小限の時間投資で自分でこれらの追加を開始し、瞬時に価値を示すことができます。その技術的な問題は広く受け入れられている利点があり、他の作業慣行には影響しません。また、結果が受け入れられなかったとしても、コードベースの知識を覚えることができます。簡単に売れます。

その他は、通常、チーム全体または他のチームを含むビジネスプロセスです。改善を提案することはできますが、それらは後輩の従業員にとっては変更が困難であり、変更のプロセスは一般的に技術的ではなく、おそらく通常の仕事とは無関係です。

また、CIパイプラインのセットアップ、自動展開、バージョン管理、パッケージ化ライブラリを攻撃するのに適したものとして提案します

による：

• より良い慣行からどれだけ得ることができるか
• そこまで行くのにどれだけの労力が必要ですか
• 成功とリスクの可能性-単純な採用の失敗から新しいプラクティスまでは実際にひどい、コード品質の低下、キーパーソンが去り、誰もがあなたを嫌い、誰もあなたの名前を知らない別の街で別の仕事を見つける

基本的には、あなたが最善だと思うものを擁護するために合理的な時間を費やすことはあなたの責任の範囲内です-しかし、決定はチームまたは管理者の責任であるべきです。たとえあなたがより良い実践に至ったとしても、人々を疎外する価値はほとんどないことを覚えておいてください。

スクラムのような最も複雑なものから始めないでください。可能な限り簡単な手順から始めてください。

あなたはソースコード管理について言及しませんでした。ソースコードリポジトリ（git、svn、cvs、...）がありますか？タグ付けと分岐の戦略？これらは、初心者ができる簡単な手順です。これらの手順（試行）でどのような問題を解決し、それが会社のコスト削減にどのように役立つか（経営陣が関心を持っていること）を読んでください。

次のステップは、自動ビルド、夜間または毎回のチェックインの直後、たとえばJenkinsで行うことができます。テストを自動的に実行することもできます。そして、コード品質を測定するためのいくつかのツールを追加します（そうそう：いくつかのコーディング標準を定義することも良いステップです）。

スクラムについては、「エクストリームプログラミング」（XP）についてよく読んでください。スクラムはXPの多くのアイデアに基づいており、それらの周りに形式化されたプロセスを追加します-XPの概念は、そのプロセスなしでも使用できます。

物事を提案し、背景情報を提供し、他の人にそれを試してもらうように説得して結果を分析してみてください...しかし、他の人からの多くの協力を期待しないでください。しかし、それを試さないと、何も改善されません。

チームは非常に新しい（3歳）と言ったので、今すぐ良い原則を導入できない場合は、10年後にそれを行うのは難しくなります。テストやバージョン管理システムなど、あなたが言及したもののいくつかは、すでに提案できるものの中にありますが、明らかな利点を強調し、開発スタックに必要なツールを選ぶことなく、そのような提案を投げかけないでください。

最初は質問をします

あなたのリストを読んで、私は以下の質問を提案します（リストを参照して、それらがどのように適合するかを確認してください）：

• ビジネスオーナーがリクエストしている作業を確認するにはどうすればよいですか？
• [スクラム]を試しましたか？
• この製品の所有者は誰ですか？
• どんな役割がありますか？
• [この役割]は何をしますか？
• [このアクティビティ]を担当する役割は何ですか？
• 毎日立ち上がってみましたか？
• 障害を他のチームに伝えるにはどうすればよいですか？
• チームの他のメンバーがどのように働いているかを知るにはどうすればよいですか？
• [これ]を問題追跡ツールに含める必要がありますか？
• 問題追跡ツールでどのように[this]を書くべきですか？
• [これ]が発生した場合、問題追跡ツールに[その]として入れる必要がありますか？
• どのようにテストしますか？
• 他の人が再利用できるようにテストを記録するにはどうすればよいですか？
• [JUnit]を試しましたか？
• [これ]はどこに文書化されていますか？
• [MediaWiki]を試しましたか？

[括弧]内の項目を適切に置き換えて、質問が意味をなすようにするか、優先順位に合わせます。私の言い回しがあなたのスタイルと一致しない場合は、言い直しを検討してください。

あなたはすでにそれを始めているかもしれません。グループでの会話よりも一対一の会話を好む。1対1なので、相手の考えをよりよく読むことができます。その人はこの変化に賛成ですか？それに対して？弱い？猛烈に？

初心者の場合、質問は事実上無料です。人々はあなたが質問をすることを期待すべきです。あなたの質問が彼らの反対する立場を暗黙のうちに支持しているとしても、彼らは怒ってはいけません。彼らはなぜその立場に反対するのかを説明すべきです。私は彼らと議論しないことをお勧めします。主張は、納得させるよりもポジションを固める傾向があります。誰がどのような立場にあり、先に進むことに注意してください。

後で、手順を実行します

あなたとおそらく他の人（つまり、以前あなたに同意したことに気付いた人）が望む変更を開始できる方法を探してください。誰もがスタンドアップを望んでいませんか？何故なの？たぶん、あなたが欲しい人はあなた自身のスタンドアップを持つことができます。チーム全体ほど効果的ではありませんが、現在よりも効果的です。

障害がある場合（そして、スタンドアップで共有できないと仮定している場合）、チームにメールを送信してください。

おそらくあなたに同意する他の人のサポートを得て、役割がどうあるべきかを特定してください。仕事にあなた（おそらくあなたのグループ）が彼らが持つべきだと思う役割が含まれるとき、一貫して人々に行き始めます。プッシュバックする場合、そのロールの所有者を特定するように依頼します。

製品の所有者（お客様が特定したもの）に、製品が現在および将来どのように機能するべきかを説明するよう依頼してください。

テストフレームワークをインストールし（他の人がこれを好む場合は、どのフレームワークについて共同で決定するか）、プロジェクトに使用します。バグを修正するときは、テストを書きます。これを課題追跡システムのバグレポートに記録します（[location]に保存されているバグを示すテストを書いてください）。他の人が変更を加えたときにテストを実行するように奨励します。そうでない場合は、自分でテストを実行し、必要に応じてトラッカーに問題を送信します。

管理サポートを利用できる場合は、Wikiソフトウェアなどをインストールして、ドキュメントの作成を開始してください。ドキュメントを読んでいないことを示す質問が寄せられた場合は、関連するページを参照してください。ドキュメントを理解していない場合は、さらに質問するよう奨励します。ドキュメントに記載されている質問を続けている場合は、回答時にドキュメントから引用してください。問題が読んでいないというよりも構造的なものであると思われる場合は、Wikiを更新するように奨励することを検討してください。

一度に1つのタスクのみに集中することをお勧めします。そして、確かに一度に1つだけプッシュしてください。強く押し込まないでください。グループが望んでいたよりも強くプッシュするこの例を参照してください。自分の行動よりも自分の行動を変えることに集中してください。あなたの方法が正しい方法である場合、それはあなたを観察している人々に明白であるはずです。アクションは言葉よりも雄弁です。ナッジするときは、同じ人と同じことを繰り返さないようにしてください。馬を水に導いたら、いつ、または他の人に飲むかを選択できます。

最終的には、あなたはシニアになります

時間が経つにつれて、あなたのチームは新しい人を雇います。あなたは新しい雇用者であるのをやめて、新しい人とあなたのポジションを提唱できるようになります。それらを使用して変更を加えます。また、既存のチームメイトも同様に進歩していることがわかります。または、それがうまくいかない場合は、より良いプラクティスがある新しい仕事を探してください。急ぐ必要はありません。あなたは仕事がある。仕事を改善するか、より良い仕事を見つけることで、より良い仕事をするまでしばらく待つことができます。

短い答え：いいえ、他の答えで概説されているすべての理由によります。中級または上級の開発者であっても、通常は最初に新しいチームに参加するときに理解することをお勧めします。

提案されたソリューション：

1）改善すべきだと思うものを見つけたら、それをメモしてください！（ノートブック、デジタルノート...）

2）6か月後、メモに戻って確認します。今では何個のアイデアが無意味で不適切だと感じていますか？ほとんどの場合、あなたは恥ずかしさをいくらか省きました。いくつかのアイデアがまだ保持されている場合、可能であれば最初に自分でテストして、それらを紹介する良い機会になります。

遅い回答、および他の回答では多くの良い内容に同意します。

ここで重要な問題は特定の慣行ではなく、チーム全体の文化であると指摘する必要があると思います。

• 文化の変化をつくるのは難しいです。
• あなたが「ジュニア」として見ればもっと

継続的な改善を達成する手段があれば、他のすべてが従うことができます。

それを達成するための私のアプローチは：

• 文書化されたプロセスと手順
• アクションがプロセス文書の変更であるチームとの回顧。

スプリントがない場合、通常のレトロはまだないでしょう。必要なのは、チームとの会話、そしてそれを実行することだけです。

あなたは簡単にプロセスを文書化を開始することができます。「私は新しい人です。これは正しいですか？それを書き留めておきます。」その後、実際にプロセスを実際に実行するか、問題が発生した箇所を呼び出して呼び出すことが重要です。

たぶん、あなたはそのような会話がアドホックであることから始めて、それから規則的な儀式を提案します。

このアプローチをとることにより、漸進的でソフトにソフトなアプローチが可能になります。あなたは彼らがすべてを知っている後輩として現れることを避け、代わりに変更を行うチームのファシリテーターになろうとすることができます。

考慮事項：

• 一部のチームのプロセスは貧弱ですが、実際にはすでにそれを知っています。彼らは変化を望み、それを触媒する何かが必要です。他のチームは本当に行き詰まっていて、変更するのがずっと難しい。
• 個人にも同じことが言えます。
• あなたはそれに敏感であり、チームの誰が変化に対してオープンで、誰がそうでないかを把握する必要があります。理由を理解してください。
• 簡単な勝利を見つけます。
• 変更をチームに歓迎します。個々の問題点を見つけて、それらの修正を支援します。