Michevan

教育の会社で 子育てしながら デザインすること

Michevan

教育の会社で 子育てしながら デザインすること

ドキュメント整理の思考法

当社では最近、資産管理戦略の一環として、仕様書のドキュメント整理について検討していました。各部署からのインタビューを通じて、エンジニア、デザイナー、ビジネスサポート、マネジメントなどから、ドキュメントの中央集権化がないこと、情報の素早い検索が困難であること、管理指針の欠如などについての課題が報告されました。 また、Confluenceを使用することに制限があり、テンプレートやラベルの使用方法、分散したワークスペースの構造が検索の障害となっており、適切なドキュメントの検索が困

Michevan

    • ChatGPT

      今話題になっているchatGPTですがプロジェクトマネージメントとして，使用するにはどんなことが考えられるでしょうか。 アイディア生成とブレインストーミング： ChatGPTは、新しいアイデアや解決策を検討するのに役立ちます。アイディアや課題に関して解決策などを聞いてもいいですし、さらにその課題を深掘りし熟考された施策を考えることに使ってみましょう。 タスク管理とスケジューリング： プロジェクトの初期段階で、ChatGPTを使用してタスクのリストやマイルストーンを作成する

      Michevan

      • 運用保守フェーズ：UX計測（第２回）

        前回の話の続きです。 前回「今後どうしていきたいかというリスト」を作成し，そこからどんな数値をとっていくかを考えるという話をしました。 今回は，では「今後どうしていきたいかというリスト」をどのように運用していくべきかをお話します。 私達のプロジェクトではAsanaを使って日々のタスクを管理しているので，まずすべての「今後どうしていきたいかというリスト」をそれぞれチケット化します。そこで，「〜を〜したい」というチケットを作るのではなく，「〜の必要性を検討」のようなチケット名

        Michevan

        • 運用保守フェーズ：UX計測

          しばらく投稿が空いてしまいましたが，その間にデザイン部からプロダクトマネジメント部に配属が変わりました。これで晴れて（?），もうデザイナーがPjMに挑戦！ではなくなって，PjMが本職になりました。 今回は開発フェーズから運用フェーズへ変わる節目に考えなくてはいけない，運用し始めてから計測したいことについて書きたいと思います。 運用保守フェーズでは，改善したり，新機能を追加したりすることがメインの開発になるかと思いますが，ただ闇雲にやりたいことベースで行っていくといつの間に

          Michevan

        ドキュメント整理の思考法

        Michevan

          変更管理

          みなさん，変更管理というのを耳にしたことがあると思いますが，この変更管理とは，一般的には以下のようなものを管理することをいいます。 OSのアップデート セキュリティパッチの適用 新しいプロセスや仕組みの導入 文書の適用 担当者・担当業務の変更 プロセスや手順の廃止 プロジェクトマネージメントでは，特に顧客への新しいプロセスや仕組みの導入に対して，エンドユーザーや組織のメンバーなど、より多くの人々に変化を受け入れるよう説得することが重要です。 しかし，今回はプロ

          Michevan

          変更管理

          Michevan

          品質管理

          今回は品質の基準設定についてお話しします。 開発、テスト、ビジネス全てに大きく影響のあるものとなります。そのため、基準を決める際には全ての観点での要件をステークホルダーに確認する必要があります。また、メンバー全員の指標となるようにわかりやすく明示していく必要もあります。 前回書いたリスク管理にも大きく影響してくるものとなり、例えば開発やテストが伸びた場合に、品質の基準によって、開発項目を減らす選択をしたり、リリースを延期する等選択する基準にもなります。 品質項目の分かれ方

          Michevan

          品質管理

          Michevan

          プロジェクトリスクの特定と優先度付け

          今日は，プロジェクトのリスクについてお話します。 リスクには3つの種類があります プロダクトリスク プロジェクトリスク ソフトウェア開発リスク 今回は，プロジェクトリスクを見ていきます。 まずは，リスクとして考えられるものをリストアップします。リスクとして考えられる項目としては以下のようなものがあります。（引用：Asanaーリスクのタイプ ） 戦略リスク 意思決定の誤り ビジネスの方向性の誤り 顧客選択の誤り 技術リスク 脆弱性 設計 業務上のリスク

          Michevan

          プロジェクトリスクの特定と優先度付け

          Michevan

          ABM

          前回の投稿「リスク回避」の中の一番最後に書いた「ユーザーターゲットを考えると，一旦はリッチではなくなるが、なくても影響が少ないことにより決められる機能」のお話をします。 この考え方は、マーケットの一つの手法でABMに近い考え方です。 ABMとは、Account Based Marketingの略で以下のように説明されています。 これを導き出すためには、まずはそのプロジェクトで何をユーザーに体験して欲しいのかを明確に表す必要があります。 今回の私の関わるプロジェクトでは、「

          Michevan

          ABM

          Michevan

          リスク回避について

          スケジュールやリソースを整理していると自ずとそのプロジェクトのリスクが見えてきます。 今回は，そのリスクを回避する施策を見ていきます。 【３つのリスク回避方法】 リソースを増やす 教育コストも掛かるので早い段階なら採用もあり 緊急的なときには社内で探す 期限を伸ばす 会社の計画による ステークホルダーによる プレスリリースによる 開発項目を絞る まずは一番シンプルな最低限使えるラインを考える そこから足していく 最低限なことは意外とたくさんあります。 今回は，特に開

          Michevan

          リスク回避について

          Michevan

          デザイナーがPjMに挑戦　第9回

          先日，初めてのプロジェクト・マネージャーとしてのプロジェクトが完了し，さらに新しいプロジェクトに再びプロジェクト・マネージャーとして参加しています。 そして，プロジェクト・マネージャーの勉強をもっとしてさらにプロジェクトに参加しているメンバーにとってやりがいがあり，無理をする必要のない，充実した仕事になるようなプロジェクトとなる手伝いをできるようになりたいという気持ちから，Googleのプロジェクト・マネージャーの認定コースを受講しています。 自分が今までプロジェクトを成功さ

          Michevan

          デザイナーがPjMに挑戦　第9回

          Michevan

          デザイナーがPjMに挑戦　第8回

          画面仕様書のチェックをするために，テスト設計について少しかじりました。 テスト設計に関してド素人なのでこちらの 「【この1冊でよくわかる】ソフトウェアテストの教科書」 という超入門の本を読みました。 入門編でもまだ全然難しかったのですが，仕様書のチェックに必要な考え方として，2種類のパターン出しをしてみました。 まずは，機能についてのパターンです。 それぞれ搭載されている機能を画面別に書き出し，その機能がどのような状態になるかを書き出していきます。そこで忘れてはいけない

          Michevan

          デザイナーがPjMに挑戦　第8回

          Michevan

          デザイナーがPjMに挑戦　第7回

          夏休みを頂いていて記事が遅くなりました！ 私の勤めている会社では，タスクの管理にAsanaを使っています。 Asanaでタスクを作ると，Instaganttに接続することができ，細かいスケジュールを別に引かなくてもスケジュールを作ることができます。また，全体のスケジュールを見て，担当別に色分け（デザイナー，バックエンド，フロント等）すると，誰がいつ忙しくなり，いつなら手が空いていて，他のタスクを進めることができるなどが見えてきます。 AsanaとInstaganttを同期

          Michevan

          デザイナーがPjMに挑戦　第7回

          Michevan

          デザイナーがPjMに挑戦　第6回

          エンジニアさんの仕事を理解する。 今回のプロジェクトでは特に内部設計がタスクのほとんどの率を締めています。そのため，エンジニアさんが実際に一体何をしているのか，どのような動きをしているのかを理解する必要がありました。 いろいろな資料を読んでいくと，まずはどうやらAPIというものが重要とそうなことがわかりました。ググるとAPIとは Application Programming Interface の略で，ソフトウェアやプログラム結ぶ役割を持っています。そして，それぞれのA

          Michevan

          デザイナーがPjMに挑戦　第6回

          Michevan

          デザイナーがPjMに挑戦　第5回

          PjMしてプロジェクトの推進で一番気をつけていることは 共有すること です。 基本的にどんなチームでどんな立場であったとしても，情報共有が足りていないことがもっとも問題を発生しやすくするのです。 また，確認作業が大量に発生することで，業務効率も大変さがります。 そして，チームメンバーが自信をもって，信頼されていると思って業務を進めるのには，情報が共有されていることは重要なことです。 今回のプロジェクトで行った情報共有の施策はまずは， 今回のPJに関係のない人も興味があれば

          Michevan

          デザイナーがPjMに挑戦　第5回

          Michevan

          デザイナーがPjMに挑戦　第4回

          第３回で書いたように，フェーズ１はあっさりと，問題なく進行しました。 さて，ここからが本題のフェーズ２です。 フェーズ２は，本気で考えて，本気で実装です。 もちろんフェーズ１も本気ではあったのですが，とにかくスピード重視で，バシバシと決定，いらないものは徹底して捨てるという方針できました。 フェーズ２ではしっかりと学校での使われ方や細かい視点からの仕様を決めなくてはいけません。また，デザインとも整合性を取っていきました。そして，その仕様で実際に実装できるのかも問題になって

          Michevan

          デザイナーがPjMに挑戦　第4回

          Michevan

          デザイナーがPjMに挑戦　第3回

          スケジュールの立て方 まずは開発ですべての必要な工程を書き出します。 第１回で書いたとおりスケジュールはこのように引きました。 私達が通常，開発を行なうときは下のような流れで行います。 要件定義 ワイヤー・仕様決定 デザイン フロント実装・内部設計 しかし，今回のプロジェクトでは，「必ずやらなくてはいけない開発」というものが決められています。それは次のことです。 文科省の自社アプリを接続すること 先生がアプリに接続できること 問題検索 結果を見る 先

          Michevan

          デザイナーがPjMに挑戦　第3回

          Michevan